Leaderboard

It's faster than cooking a potato, and that's good enough for me.

I wrote up two lengthy responses to this so far... both of which got crunched by IE. It depends on how complex the parallel process is. For simple processes almost any flavor of Producer Consumer State Machine is just fine. It's the Queued State Machine flavor that causes trouble. As long as you keep the messaging component (to pass data from the producer to the consumer) separated from the consumer's state component you probably won't have trouble. The QSM combines the messaging system and the state system into a single queue, and this creates problems. For more complex processes or if I want to hide the parallel process' internals I'll use an Active Object. Active Objects add a considerable amount of complexity to your system though. If you don't need the flexibility or encapsulation there isn't much reason to go that route. Yep, that's what I was referring to, but I didn't remember the details. It's probably fair to call me a QSM denier. I have a challenge for you. Next time you want to implement a QSM, use a regular state machine instead and restrict yourself to one state for each message from the producer loop. For example, if you have four buttons on the fp, you have only four states (+an init, exit, and an idle state if you want one) regardless of how complex the process is for each state. If you need to use code in more than one state, put it in a sub vi instead of new state. Then compare the 4 state SM with a 20 state QSM and decide which is cleaner. (Of course I'm saying this without having examined one of your QSMs, so maybe yours don't have the problems that most of them do.) Handy, yes, but I've found that for all but the most simple applications they are very difficult to debug. Suppose you put states X, Y, and Z on the queue, but you forgot that X queues up A and B before exiting. Instead of XABYZ you end up with XYZAB. So to fix that you have X enqueue A and B on the front of the queue instead of the back. Now you have XABYZ, just like you want. All good? Maybe, maybe not. Do you have an Abort button that flushes the queue and/or throws a quit state (Q) on the front of the queue? What happens if X is executing when the user hits the Abort button? While X is executing the queue is flushed and Q is put in it. X finishes executing and put AB on the front. Now your queue has ABQ and your application isn't exiting. Pretty soon you have to start examining the queue (and possible maintaining a history of previous states) just to figure out what states you should enqueue next. Application control logic is way easier to follow when it's on the block diagram instead of the queue. I believe QSMs are inherently flawed. They depend on the states being executed in a specific order. However, when you have independent loops adding items to the queue (as most QSM implementation do) you forfeit your ability to guarantee the order will be correct and open the door for nasty bugs that may occur rarely and are very hard to track down. You certainly can be disciplined enough to only enqueue states in your producer loop, but is everyone that works (or will work) on the app just as disciplined? QSMs practically encourage you to enqueue states in the consumer loop--it's an easy way to reuse code. It's hard to pass that up when it looks like an quick fix to a problem. Good design patterns promote good design decisions. QSMs don't promote good design decisions. (The one time a QSM might be justified is if you're doing a lot of operations in the consumer loop that can't easily be put in a sub vi, like using front panel property/invoke nodes. Even in those cases I'm more inclined to send user events from the consumer loop back to the UI loop and let the UI loop handle all the fp control functions.)

I think that's fine. I hope classes not in .lvlibs appear before or after, not intermingled, though.

Yeah, that's the sort of "option" that ultimately makes things less usable -- most people toggle it once if ever, it clutters the screen, taking real estate away from other elements, and it opens a source of bugs for a rarely tested code path. Every usability guide you'll ever read will condem this sort of option, and if you doubt, you can run the usability studies to confirm it. Data presentation in a dialog should be something you commit do and do, not something you waffle over. Even if a few customers find the result less optimal than another option would have been, the net is still more usable than introduction of the option.

I guess untill the memory of your computeris full. That will happen faster with an event structure than with a queue, the overhead of the event structure includes the actual timestamp when the event happens. Ton