simple case strucutre causes labview to hang

[rossu]

This snippet is from a "working" program that has been running happily away for some time now. It is a data acquisition program based on a simple producer/consumer structure. I added a consumer loop to do a bit of error checking before the data acquisition and now the program hangs whenever the false case in the new loop happens - even if the false case is empty ! i.e. I've removed all fcns from inside.

False Case

Ideally the case structure should be connected to the > comparator, but I separated them just to test exactly what was going on.

The true case runs just fine.i.e. change the boolean constant attached to the case structure to T. The program happily behaves the way it always has cycling and taking data.

I've tried adding a queue operation to a NOP case, but that didn't help. I know the code in the false case executes OK because the Stop button goes back to false and the simple error handler doesn't report anything. I also know that the code never returns to the producer i.e. none of the events that should fire it do. The program is well and truly hung (Labview itself seems to still run fine) and only the abort button can stop it

It would be helpful if I could find a way for the program to tell what it is doing. I've dosed it liberally with breakpoints to try and find out where it is going and gotten nothing. I've attached the full code in case someone wants to have a go at this. You would need to dummy out all the DAQmx stuff.  I've tried deleting all of the case structure and rebuilding it to no effect. I'm open to suggestions

[mikeporter]

Have you turned on execution highlighting to watch it hang? (My bet is on the dequeue operation...)

Mike...

[rossu]

Turning on the execution highlighting can only be done for the short bit of code in the image or it lags too badly. It appears to execute the displayed code just fine and then no longer displays any executing code. I've also tried hitting pause and then turning on execution highlighting. No executing code is displayed.

[RavensFan]

I'd be worried about the 2nd event structure you have in the acquire case.  That along with all your event cases locking the front panel until they complete.

You could very well be having LabVIEW locking up because of that.

Read Caveats and Recommendations when Using Events in LabVIEW

[rossu]

I would have much preferred to run things with a single event structure, but that wouldn't run. The producer/consumer structure doesn't seem to be compatible with the data driven design. Although I could register the data event programmatically with the main event handler, it would never fire. I suspect a thread thing, I.e. The producer runs on the interface thread, but the data event runs on a different thread, but that's a guess.

In the current case, the program never reaches the start acquire, acquire or Stop acquire consumers before hanging (if the case structure is set to F. It still runs ok with the case set to T, which runs the consumers we are talking about) As I said, this program has run with zero problems for months with the producer wired to start acquire rather than pre acq consumer. It is pre acq case that causes the issues. I suspect a thread thing at the end of the day, but don't have the tools to check this. This conversation has given me a thought I could try.
You've obviously opened up the zip and looked at the whole thing. Thanks for the effort.

[mikeporter]

If a LabVIEW application appears to lockup (and it is only by appearances) it's a matter of poor design or implementation -- not some "thread thing".

The basic problem with the default way of implementing the producer/consumer pattern is the use of a queue. As you have discovered, queues are inherently in conflict with event-driven operations. There is no way to make them play well with each other. Queues are all about polling. Events are about do nothing until something happen that needs a response.

As I have demonstrated, the real solution is to get rid of the queue. The use of a queue in the LabVIEW implementation of this pattern is an artifact of older implementations in other languages. While there are clearly special cases where a queue offers valuable functionality, all you need for most scenarios are events.

Check the link in my signature. Start at the beginning, the first post is about a proper LabVIEW implementation of this design pattern.

Mike...

[crossrulz]

I'm with Mike here, that queue is not really doing anything for you except add complication.  A good state machine is all you need here.

[rossu]

Following the advice above I have rewritten the whole thing as a state machine - no queues anywhere (only took an hour or so).  The new main vi is attached. Unfortunately, it still locks up in excactly the same spot. At least now with execution highlighting on, one can see that it is just spinning its wheels in the event loop that traps front panel events (under the state case "Idle"). It would appear that somehow the front panel events have become disconnected from this event structure. Again, if I change things so that the True case under the Stop button click event (in Idle) goes to Start Acq instead of Pre Acq, the program runs normally.  The thing that is bizarre is that the Pre-Acq case runs without errors. I tried taking out the one button dialog (the only piece of UI in that loop) and it made no difference. Suggestions?

[altenbach]

Firstly, remove the inner while loop around he event astructure in the idle case. It has no purpose. Then you have a second event structure inside the "acquire" state. That's just asking for trouble.

Secondy, all your events are set to lock the front panel until the event completes, so if an event occurs while the code is in a different state, the event structure cannot execute and will lock up the front panel forever. Your code is completely constipated.

[nathand]

Learn to use Type Definitions! I'm not certain this is the problem, but it might be:

See the little red triangle? That indicates that the data types don't match. The enums are not all identical. LabVIEW will use the numeric value, not the text value, to determine which case to go to next. Your Actions enumeration should be a type definition, and every Action constant should be linked back to that it, so that when you update the list of enumeration values in the type definition it is reflected everywhere that enumeration is used.