shoneill

QUOTE (jasonh_ @ Apr 29 2009, 04:02 AM) Queues have other advantages like being able to preview the entire contents of the queue or to insert at the opposite end. With Events this is not possible. Events on the other hand also have other advantages. Events can be 1 to n multicast capable (more than 1 register for events on the receiver side) and the fact that we can essentially use user events as a triggering mechanism for a state machine - Event-driven producer/consumer state architecture..... Events (when passed pre-registered) can be used as one-way communication channels. There is a workaround to get at the actual event using the Event refnum when the event in question actually fires (I have made a suggestion that this refnum NOT be exposed because I can't think of a use case for it and removing it would enable real "listener" events.). QUOTE (jasonh_ @ Apr 29 2009, 04:02 AM) With this in mind, perhaps it would be nice to converge the functionality of both so that users can use one or the other depending on their coding styles/application. For example, register events from controls, or indeed any software events, into a queue so that an event structure is no longer necessary for things like GUI control (improving queues). Or, allow named events which are available globally like named queues (improving event structures -- coincidentally, this is exactly what ShaunR and shoneill are asking for). Wouldn't this allow one to, theoretically, use queues and event structures interchangeably? Is there a fundamental reason why there shouldn't be more than a superficial difference between the two? AQ? I don't thnk Queues and Events are interchangeable just like that. They target different needs and that's good. There's no point having multiple tools for the same job, it just complicates things. There are many pieces of code where I use both queues AND user events, precisely because of their differing capabilities. Having said that, I think there ARE possibilities to improve both, some of these you have already listed. In a mixed Queue/Event usage the ability to register an event for a queue receiving data (Or being destroyed and so on) would be SUCH a cool thing to have..... I know it can be done with a small while loop and an extra user event but I would love to be able to simply wire up a Queue to a "register for events" node and be done with it. Of course the same goes for Notifiers, Occurrences and so on. Shane. PS can anyone comment on the performance difference between event structures and queues I have mentioned earlier? Any reason why this should be so?

For the speed freaks out there, here's a comparison between relative Queue and E vent "dequeueing" (for want of a better word). I was a bit surprised to see that the Queue (with associated "Variant to data") is much faster than Events until the data gets quite large (where the "Variant to Data" probably becomes expensive). Does an event structure require a thread switch even if there are ONLY user events being handled? The following VI is saved in 8.2.1. It fills a Queue with N elements (A U32, a String and an XY point). It also creates N user Events with the same data. The Dequeuing requires a "Variant to data" to get the actual data out, the event structure dues not. The size of the string used can be set on the FP. Watch out for memory problems with high N and String size values.... Shane.

QUOTE (jdunham @ Apr 27 2009, 10:41 AM) Well, sometimes it's a good idea to queue up operations where each and every operation should be processed. Just not necessarily in a UI. QUOTE (jdunham @ Apr 27 2009, 10: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. 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. 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. Unnamed queues are cool. Like secret post..... Shane.

QUOTE (Aristos Queue @ Apr 26 2009, 09:50 PM) Indeed. The differences are, when you get right down to the nitty gritty, more subtle than at first apparent (apart from the event structure being rather unwieldy but I digress). For me the big advantage of user events is that I generally have Events sending data back and forth (through defined interfaces defined by events to and from several processes). When I want to control or listen to a process, I access it's list of events (method of acquisition may vary but often involves a queue) and I essentially have an API for that module. It really doesn't get simpler than that. I also like the fact that there are no variants or strings needed when the API gets a bit more varied. Each and every event has its own strict datatype which saves me having to cast here, check there and so on. An interesting idea is using a user event passing a notifier refnum. The notifier has the latest data and a quick check of the current and last set of data allows the "slow event" problem to be rather easilt overcome (Where unwanted past events get queued and the system get's bogged down). Quite often I even -gasp- have multiple event structures in one VI. It's do-able when you are aware of the things to avoid. I use both queues and events and I think all have their merits (Events, Notifiers, Queues, Semaphores and Occurences). For inter-process communication I generally go with events though. <Crazy idea mode> What I would REALLY like would be able to wire up a Notifier/Queue/Semaphore/Occurrence refnum to an Event structure just like a registered event and handle the receiving of data from the event handler. (I think this is what was being referred to earlier in the thread) :thumbup: What I woull ALSO really like would be an updated interface for the event structure. With user modules running via events, things get very messy very quickly. Adding Queues et. al to this would not necessarily be a good thing until the Event structure interface got a facelift. </Crazy idea mode> Just my 2c. Shane.

QUOTE (ShaunR @ Apr 23 2009, 08:18 PM) I second this part. Why can't we wire up a queue (or notifier and occurrence of course) to an event structure? It's a logical extension of the current ability to use queues. QUOTE (ShaunR @ Apr 23 2009, 08:18 PM) I don't see why they should work less naturally just because they don't use queues. I also agree with this. It all comes down to the application architecture. I've recently done a relatively large application using not a single queue yet it's all modular and rather easy to follow. Instead of queues I used user events. For me the big drawback of queues and notifiers is that there has to be a part of the code which is waiting for data to arrive. With an event, this is not the case. With an event, the code to receive new data can be one pane of an event structure. You can even have multiple "receiver" panes in one event handler, each one with their own strictly defined data type (No variants and so on). Just my 2c. Shane.

QUOTE (normandinf @ Apr 24 2009, 05:06 AM) :thumbup: :worship:

QUOTE (Val Brown @ Apr 16 2009, 10:38 PM) QUOTE the development PC isn't connected to the internet Shane.

QUOTE (asbo @ Apr 16 2009, 05:11 AM) That ad is just too good! Shane

QUOTE (Val Brown @ Apr 16 2009, 01:22 AM) Same for me too. Shane.

QUOTE (crelf @ Apr 15 2009, 01:17 AM) I'm pretty sure if somebody put some of my code from 10 years ago in front of me I'd start cursing the programmer left right and center. And most likely rightly so. Shane

Norm and Ben, Are you guys serious that this might be the answer? That would surprise me more than a little. The CLAD Questions need a major overhaul. The amazing thing about most of the Qs is the more I think about them, the less sure I become of the answer. I finished my CLAD exam in half an hour and I think if I had taken longer, my score would have been lower.... Shane.

QUOTE (neBulus @ Apr 13 2009, 03:40 PM) But it's not, I'm pretty sure it's C, thus adding to the confusion. So many interpretations.... I think a linguistics degree should be compulsory for the CLAD so that you can understand the questions. Even worse, the question asks what the "output" will be but A to C are phrased "will be displayed". Which is it? Shane.

QUOTE (crossrulz @ Apr 13 2009, 02:22 PM) Well a totally different question is what is the "output" of the loop? I would normally tend towards the value in the shift register, but the indicator is clearly the object in question here. I mean, the Indicator is not actually an output of the loop at all.... The only actual output would be the last single measurement contained within the shift register... Shane.

QUOTE (lightworker @ Apr 12 2009, 10:43 PM) That, in itself, is typical of so many CLAD questions. Others just SEEM to have multiple answers until thought about enough. Shane.

QUOTE (jdunham @ Apr 10 2009, 07:46 PM) Nah, somebody just posted a big image. Check out the "Data table" post. Shane.

QUOTE (normandinf @ Apr 8 2009, 02:08 PM) I think that's just the nature of boys and girls TBH..... Way to go off-topic. Shane.

QUOTE (ggatling @ Apr 8 2009, 01:04 AM) Could we start a poll on how many people would want a LTS (Long-term support - i.e. Bug fixes with no new features) version of LabVIEW released every, say 3 or 4 years? This way we could have a cutting-edge version and a more stable (but perhaps less exciting) version with long term bug-fixes. Of course these bug fixes can be in the newest cutting-edge version, but the difference is the addition of NEW features (and bugs). I've long thought this would be a very good way to go. Shane.

QUOTE (normandinf @ Apr 7 2009, 05:37 PM) If you need local variables or property nodes, try to use local variables. Property nodes are much less efficient than a simple local variable. Property nodes have other capabilities which locals don't, but if these extra capababilities are not needed, locals are the way to go. Shane.

QUOTE (Aristos Queue @ Apr 7 2009, 05:21 AM) With the documentation as shipped as the only source of information? Seems unlikely to me but perhaps, perhaps. Shane.

QUOTE (crelf @ Apr 6 2009, 09:05 PM) I've never done scripting in LV, but it seemed relatively straight forward in my mind. But that's nothing, lots of things look really different in my mind.... Shane.

QUOTE (Mark Yedinak @ Apr 6 2009, 05:24 PM) Would it be possible to write a Stacked Sequence Structure to State Machine converter using scripting? Shane.

QUOTE (Aristos Queue @ Apr 4 2009, 12:46 AM) That's cool, any other hard-wired Typedef names out there? Shane.

QUOTE (rolfk @ Apr 4 2009, 09:29 AM) Curioser and curioser. I always wondered why the code was so, how should I put it, fugly. Who did NI acquire it from? Shane.

Re: stacked sequence structures at all.... And of course let's not forget that NI's leading by example on this...... Shane

QUOTE (Cat @ Apr 3 2009, 05:22 PM) A stacked sequence, in contrast to a state machine or an event structure does not contain frames which MAY be executed. They will ALL be executed. An event structure groups many different possible execution units together, one of which will execute at a time. Here it makes sense to hide the other possible execution units. Ditto with a state machine. Granted a state machine CAN execute from 0 to n like a stacked sequence, but it doesn't HAVE to be that way. So that's the difference for me. A stacked sequence structure adds no extra functionality over a flat sequence and while it's at it hides code which is a bad thing unless it's necessary. Shane.