Leaderboard

Can anyone provide more info on this? Is this the Dynamic vs Static registration issue of User Events? Is there a known bug? It does not sound very nice that LabVIEW would not process events in the order they are received !! I disagree - I guess I am one of those touters I have found I can write cleaner code using a QSM. As LabVIEW is a dataflow language it can get complicated if I have to share data between parallel processes, so I try to avoid this (where possible) if I don't have to. It can be beneficial if a single loop is used, as it means I share its state within the loop, making use of passing by-value - just the way LabVIEW likes it. I don't want to sound like a nuthugger either but this is why I find the JKI State Machine a very elegant solution, esp wrt Macros in this case. I do agree through that as soon as you start queuing states in the QSM it can start to get tricky - but pre-buffering (i.e. Macros) states then running through them is very handy, clean and easy to debug. Also it does not affect the UI experience as you can disable the cursor if it has to think for a while or crunch some heavy stuff if you are responding to User Interface Events as well. You can also communicate with the QSM through an Event Structure, allowing external messages in (although I recommend creating an API so that you have a controlled interface). There is more work in setting up Event messaging but sometimes it is nice to have Static Data defined for events rather than say e.g. a Queue with an enum and variant for the data. (You could implement messaging using LVOOP, but that would most likely be more work) Of course every design pattern has its limitations and if you need to separate the UI from the Engine or run a Control thread then you will require a more complex pattern but I have found that I usually just have multiple JKI State Machines. I even like to use this as the framework for a process in an Active Object. Anyways, I find for what I do, 80% of my use cases can use a QSM and not have to worry. And if I need to expand I create more QSMs (on the project I am currently working on, it was decided to separate the UI from the Engine and it was quite painless). I find I don't use Queues that much for messaging any more but rather for buffering up data etc... Even though Events were not designed to replace queues for messaging and you can't flush, preview etc... there seem a logical evolution and I find very easy to work with. E.g. having all messages (User Events and User Interface Events) coming through the one interface (Event Structure) helps me to share the statefullness and make use of by-value as mentioned above. I.e. I don't have to poll another queue for messages and listen to the User Interface. This is just how I currently like to do things. I used to always startup a GUI using multiple loops, namely QSM-PC (Event) but I found this complicated this fast. Plus using Queues (enum/variant) meant I had extra data types per loop to create and maintain - JKI State Machine is string based and so there are no data-types needed and therefore e.g. the State Manager (for checking if an error occurs and going to the Error Handler state etc...) can be reused. That is why I like it better than the Expression Flow QSM-PC example. Nowdays I am like, why make things more complicated if they do not have to be...

Hi all, As we all known, we can define user events in labview and then we can triger the events. I just want to known how may events can be queued in event queue of labview? the reason why I am asking this is because that I want to decide whether to use event or queque to impliment a state machine. thx

This is starting to be a nice discussion. A LabVIEW event structure is indeed listening to two event queues, one for dynamic events and one for static events. When there are events in both queues it picks the one with the earliest timestamp. However these can be duplicate (I am not sure but I guess the resolution of this timestamp is 15/16 ms on windows) and then LabVIEW just picks the one it likes best. Ton

I can't give you an exact number, but the answer is "more than you should ever need." To be honest, I think you're basing your decision on the wrong criteria. Events and queues can both be used to transmit data to parallel loops, but they have different purposes. Events are used in a "one-to-many" situation. You have one event source and many event consumers. Queues are used in a "many-to-one" situation. You might have many sources enqueueing messages, but only one consumer dequeuing messages. If you have a "one-to-one" relationship you can use either, but queues are easier to work with. I try not to think of it as an "event queue" because the event structure doesn't necessarily process events in the exact order they were received. (Ton knows more about that than I do.) Plus you have no way to manipulate the "event queue." Think of it as an "event handler" instead. When using events it is better to set up an event structure in a loop to receive events and then send messages and the event data (via a queue) to a parallel loop to do the actually processing. That way your event handler stays free to process events as they come in and you don't have to worry about events stacking up. When is it a good idea to use events? The first is obviously when you have to process the user's fp input. The Producer/Consumer Design Pattern (Events) template is a good starting point for that. I also use events when I'm writing asynchronous code modules as a way to notify clients of things they might be interested in. Personally I haven't found events particularly useful in other situations, mainly because of the edit time overhead associated with them. Uhh... neither. I know lots of people tout the virtues of the Queued State Machine; personally I think it's a poor pattern because it doesn't promote good design decisions. Using a queue to store sequences of states to be executed can easily lead to code that contains hidden errors and is hard to maintain. You can use a queue to transmit messages and data from the UI loop to the Processing loop, but don't use that queue to control state as well.

The exact difference between the two timestamps is 786 out of 2^64 of a second (4,16334E-17). Ton

Your new best friend in 2009.1: openProbesInOwnWindows=True As with all NI features that haven't shipped, I'm not promising anything, but we've been listening and the developer that owns the probe watch window has added the ini token. -Brady

QUOTE(Michael_Aivaliotis @ Oct 4 2007, 04:36 AM) I've heard Stephen admit that LabVIEW isn't perfect previously, but, as my Ma says, "I'm not perfect, but I'm as close as anyone you'll ever meet."