ShaunR

Mark I ear hole and a precision digit works best.....lol If you search this forum you will find a IDE addon that enables you to control Labview using voice commands. Most of what you need is in that.

Welcom Markus. Not sure about a good time, but is always interesting

QUOTE (normandinf @ Apr 30 2009, 10:30 PM) Right...lol So it must be impossible to do this then http://lavag.org/old_files/monthly_04_2009/post-15232-1241128886.png' target="_blank">

Whats the micro controller expecting?

You can change the cursor legend font as with any other indicator/control. Just set the font of the cursor legend to "Plain". Then they won't be bold.(If that's all you need to acheive).

QUOTE (bEMOL @ Apr 30 2009, 12:14 AM) If you want to programmatically add tabs to a tab control then use an active X container and browse for the Microsoft Tab Strip. This has the methods to add, delete,clear etc. http://lavag.org/old_files/monthly_04_2009/post-15232-1241110320.png' target="_blank">

There's an example in the Labview examples directory of a tank filling system. Might be worth a look.

QUOTE (jdunham @ Apr 30 2009, 02:45 AM) I'll take a look later...thanks. QUOTE (jdunham @ Apr 30 2009, 02:45 AM) That's an interesting quote. I think just shows that the NI VISA team is not on the forefront of LabVIEW development (to be fair, I don't know how old that doc is). Their API could easily accept a VI reference and invoke VI.Run on it when the event happens. They could also accept an occurence or a queue refnum, but I think it would make more sense to do the VI reference. Then inside that VI you could invoke whichever queues or notifiers or occurrences (or polled globals) you need to interact with your running processes. LabVIEW with a callback (which you can also implement in your own code with a private notifier or a VI reference) is no less event-driven than C code with a callback. Jason You may be right. In fact, there ARE callbacks, in the true definition of callbacks (well in 8.6.x at anyrate). I've been playing with them for my event problem (well its not really a problem, it would just greatly simplify code and maintenance). But VISA doesn't expose the event refnum so you can't attach a callback. Or conversely, callbacks don't accept VISA resource sessions.There is/isn't/probably a way to get at it, but that aspect isn't on my priority list at the mo. I would go one statment further. Labview is event driven (in the context of truly asynchronous events) with a callback, however C is not event driven....ever.

No. Your DAQ definitely won't be enough to drive the motor. Motors are high current devices. You will need a separate power supply and control it via that. I agree with carlover in so much that really you need a dynamic tracking system (as well as it has been done before). You will also probably want to go backwards and forwards, as well as up and down (since the sun tracks in an arc and starts in the east and sets in the west every day) so a single motor probably won't be enough (2) and they will need to rotate in both directions. You might find this useful in thinking about what you want to acheive. Solar Tracking Project Although I'm at a loss as to why it took 13 weeks...lol.

QUOTE (Mark Yedinak @ Apr 29 2009, 09:53 PM) Read the thread again from 7 posts up.

Short answer "yes". We need to know more too. How are you interfacing to the motor (is it RS232 , PWM card, digital card, parallel port, force of will?). Regardless of the interface, you will need a while loop that generates a timed pulse. It'll look something like this There are many examples in the Labview examples directory. I would take some time to look at them as quite often you can modify them to suit your needs.

QUOTE (Mark Yedinak @ Apr 29 2009, 03:50 PM) We were talking about a full Labview development environment my comment was aimed at this QUOTE The LV development environment is very useful in debugging on the fly if you have live code. NI even supports it with a licensing option. Since the OP said he deploys the vi's and anyone can change them (have to have labview on there for that). That is more than $500.

QUOTE (shoneill @ Apr 29 2009, 02:03 PM) Ah. Thats not it then. I'm looking for a way to link events from dynamically loaded vi's So that the vi can basically "hook" the existing event mechanism.

QUOTE (shoneill @ Apr 29 2009, 08:12 AM) I think that's what I'm missing for me to use events effectively from within an encapsulated architecture. Whats the workaround?

QUOTE (manojba @ Apr 29 2009, 08:00 AM) Hmm. Got me thinking. This would be a good one for a Coding Challenge. Who could write the best URL Label XControl. Be nice to be able to just plonk one on the FP.

QUOTE (jzoller @ Apr 13 2009, 09:40 PM) I'm thinking more about the cost of deployment. Exes and dll's are don't require licensing.I'd find it impossible to justify that the customer pays thousands for a full package which he/she never uses just so that they can use my software.

QUOTE (candidus @ Apr 29 2009, 09:02 AM) Much better solution.

The "Specify path on diagram" is the way forward but I don't think that exists in 7.1 (long time since I used that). So you would have to use the old method of creating an intermediary DLL which you can call from the "Call Library Function node" to pass data too and from other the other DLLs. (2D array in and out always worked best for me). Not elegant, but it works.When you create the plugins, if you make their inputs/outpts are a 2D array then your intermediary dll only needs 2 inputs (the dll name and the 2D array) and one output (2D array).

QUOTE (jbrohan @ Apr 27 2009, 02:30 PM) If I remember correctly, you can hook IE using active x to get click info. Might solve your positioning problem. I'll see what I can dig up if your interested.

QUOTE (PaulG. @ Apr 27 2009, 05:44 PM) You can always ignore us (like 90% of the lurkers ). Or you could read it during work time when your paid for it...lol. QUOTE (jdunham @ Apr 27 2009, 04:09 PM) Queues are cool that they can even the load if your data is bursty, but queue or no queue, if you're not processing fast enough, you have a problem that queues couldn't fix. Unfortunately my data isn't "bursty". It is multiple continous streams with control on top. No problems either. QUOTE (jdunham @ Apr 27 2009, 04:09 PM) I would never send data through a queue that wasn't meant for the queue listener. I would just use separate queues to send data to separate loops that were 100% devoted to handling that data. If I were to adopt the same strategy in the current project I would end up with 87 queues QUOTE (jdunham @ Apr 27 2009, 04:09 PM) OK, I give up trying to convince you. We obviously use queues in very different ways. I find them useful, even indispensable. My team's code doesn't suffer from any of those things you say queues suffer from, and we're doing things that you say are nearly impossible in LabVIEW, and they were pretty easy to code up and have great performance and scalability. Ummm. Are you referring to spawning multiple (200+) threads like in the BT client? I don't think that is possible. Especially if you can only have cores x 4 threads. QUOTE (jdunham @ Apr 27 2009, 04:09 PM) It's fine if you don't want to use more queues, but I don't think you'll manage to dissuade the rest of us. So I guess your in the Q or die camp (but suspected that quite a few posts ago)

QUOTE (jdunham @ Apr 27 2009, 09:41 AM) Quite the converse in fact. You would use a queue to "queue" ( or buffer) the messages/data/etc (because you can't process them fast enough) in the hope that they may ease up later so you can get through the backlog. QUOTE (jdunham @ Apr 27 2009, 09:41 AM) Why do you need wait functions if there is data available? Because you may be busy doing something else that is time critical and higher priority. QUOTE (jdunham @ Apr 27 2009, 09:41 AM) Why is the receiver inspecting the data? So many why's. I've already explained that one. QUOTE (jdunham @ Apr 27 2009, 09:41 AM) Why would you let a queue consumer get data that wasn't meant for it? That's what I call a bug. How can you not? Since there is data in the queue how does it know that its not for it? Thats what I call the nature of queues. QUOTE (jdunham @ Apr 27 2009, 09:41 AM) One way I like to think about it is that a queue is a 'dataflow wormhole' between parallel loops. Since you like dataflow as much as I do, maybe that makes it clearer why a queue is so useful. Don't get all Trekky on me now And I know why as queue is useful, in the same way I know that a car is useful unless you in a swamp. QUOTE (jdunham @ Apr 27 2009, 09:41 AM) Well, do a Google search on "Global variables are bad". I got 400,000 hits. They are considered dangerous in every language. I have been using more unnamed queues and notifiers lately so that they are not available globally. Do a search on "kill Bush" and you get 12,700,000. Your point is? This is what NI have to say on it: http://zone.ni.com/devzone/cda/tut/p/id/5317 QUOTE (jdunham @ Apr 27 2009, 09:41 AM) About my version of the sample application, I tried to add some asynchronous behavior to show the power of the queues. Did you read all the diagram comments? I though that would have answered your questions. It would be easy to modify it to match the original more closely. I took all the globals out because I think they are a defect, not a feature. For asynchronous behaviour they are already in while loops. If data is lost, then I'm not really sure what you were trying to demonstrate with the example.

QUOTE (jdunham @ Apr 26 2009, 06:29 PM) As lame as my weekends eh? we may have converged on a spin-off topic. But you are still quite a way from convincing me that queues are "the magic bullet" and all applications should use this architecture. QUOTE (jdunham @ Apr 26 2009, 06:29 PM) Same thing would work better with a notifier. No polling, no latency. Oooooh. No. Because then the UI would have to wait on the notifier(s). Also if you go down this path you end up with notifiers everywhere like a plague of mosquitos. A pain in proverbial to debug. All I have to do to debug is watch the global. There is no need for sequencing so a notifier is not useful. QUOTE (jdunham @ Apr 26 2009, 06:29 PM) Still confused why you started this thread! Queues are elegant and extremely useful. That's what the fuss is about. Where I think we agree is that if the system is NOT asynchronous and doesn't need event handling, then larding it up with an event handler or a state machine is not good. I started this thread after a comment in another thread that suggested a fairly simple implementation would be better as a queue. I asked whats everyone fascination was with queues on this forum. As a newbie to this site, as I looked at more and more posts it seemed everyone was queue crazy and the remit was...lets start with a queue and make it all fit. So Rather than hijack the thread, I started a new one to find out why people thought (and I think even you said this too) queues are "the magic bullet" to application design. All applications have some degree of asynchronicity that doesn't mean you should design around a queue. It sounds almost as if you are agreeing with me in repesct to queues adding complexity QUOTE (jdunham @ Apr 26 2009, 06:29 PM) Amen, brother. Dataflow is your friend. Easy to read, simple coding. But when you have parallel processes, dataflow doesn't apply. If they need to share data, you can use globals, which have lots of problems, or queues, which don't. The only problem with globals arises when you require synchronisation. But that isn't really a problem, it is (a very useful) feature of globals. The fact that it creates copies of data is a drawback (if you were running on a ZX spectrum...lol). But a queue isn't a replacement for globals as you point out in your example (removed the stop button from the user). And even in the first example it was used. QUOTE (jdunham @ Apr 26 2009, 06:29 PM) Well my app has a networked sensor array with dozens of concurrent connections, with data going in both directions. Each TCP or serial connection is handled with a lightweight process (diagram almost fits on one screen), which is cloned and spawned as a dynamic call. Each of these identical handlers feed their bytes to a central queue for parsing, analysis, notification, and logging. The comm handlers register their own queues so the central code knows how to send individual responses and control messages. Sometimes the comms appear and disappear at random (some radios are crappier than others), but the LabVIEW handles it smoothly. In short, it works great, and queues make it all happen. The peg's looking kind of round from where I sit. I did say that distibuted IO (which is I think what you are describing) is one scenario that would warrant a queue. However, yours is a large app as I seem to remember (how much of that is event management and interprocess comms?) and certainly realising the BT client wasn't a large app because Delphi is event driven therefore very suited to the task. Horses for courses. QUOTE (jdunham @ Apr 26 2009, 06:29 PM) I generally run these handlers with infinite timeout, so there is no timeout case (and no wait function). LabVIEW's internal execution scheduler may have to poll the queue somewhere deep in the bowels of LV, but that's not exposed to me. We have dozens of queues waiting in parallel with very low overhead and very low latency when an event is fired, so I suspect it's not polling at all, but is really sleeping. I don't know what you mean about a difference between queues and notifiers. As far as waiting and timing out, they act exactly the same. Queues do not have a wait function. Yes you can get similar behaviour IF you only ever have 1 message on the queue at asny one time, but if your producer(s) is faster than your consumer this is rarely the case. Therefore having an indefinite timeout makes no difference as your sub process still needs to inspoect the message to see if it was meant for it. So it is not sleeping, it is inspecting. You would then need a case for if the message wasn't for it and you can't just let it run through a tight loop so a wait so many milliseconds would be needed. So it's not sleeping evertime there is a message on the queue regardless of who it is for. QUOTE (jdunham @ Apr 26 2009, 06:29 PM) OK that's why I'm still on this thread. I rewrote your version using queues. No globals, no polling (except to simulate acquisition), no latency, asynchronous (event-driven), no possibility of race conditions or data loss, and no crowbar needed -- all thanks to queues. Queues of data, not of messages. And yes, it runs as fast or as slow as you ask it to run. There is a little bit of jitter at 1 or 2 ms, but I think that is caused by using the Timeout case of the event structure, not by the queues and notifiers. http://lavag.org/old_files/post-1764-1240766707.zip'>Download File:post-1764-1240766707.zip Ummm. It doesn't do what it says on the tin. It uses no globals, because you have removed the "Stop" from the user in SubVI1. The original example uses a global also. In the example I posted (ver 2), I set the aquisition time to 0ms and could acheive 3 ms of aquisition (mainly due to the 1ms delay I have in my notifier VI). All of the VI's show 3ms and all the vi's show the same loop iteration thus proving they are all capturing the aquisition "Event" with no loss.(well. The aquisition VI might show one more since it gets an extra go after you press stop on the aquisition vi). In yours, however. If I set it to 0ms the aquisition vi runs like the clappers (6229 for the length that I ran it) but the others show significantly less (2654). What is happening to the other 2654 samples of data?

QUOTE (Aristos Queue @ Apr 26 2009, 08:50 PM) Shorter ones first...lol. Even if there IS data in the queue but not for that "thread"? And (just a point to fill my knowledge gap) Are you saying that 2 while loops (or 50 even) will run in their own separate threads?