Continuous Measurement and Logging Template - May hang-up due to lost Exit

[heel]

The template Continuous Measurement and Logging in LabVIEW 2012SP1 has a flaw in the both the Acquisition and Logging loops.

The Stop message handler discards all messages in the message queue. The note says:
"Stop - Flush the queue of any pending "Log" messages. Close the TDMS file reference." See picture below.

This concept breaks if the Exit message is posted while the Stop message is being processed. The Critical time gap for this to happen is small because Exit is posted to the front of the queue. But it depends on the processing in the Stop handler case. Small or large - it can happen.

The symptom is that the application hangs in an infinite wait on the message queue - all controls are with no effect as the rest of the loops are terminated. Only Break will terminate the application. Pause button does not work either. (see this forum entry)
This problem may only appear after the application has become more complex and the timing has changed - the fresly made template works and does not reveal the issue.

The cure: First I thought of previewing the queue elements before discarding them selectively, one by one in the Stop loop, but that wont work either, because the Exit may arrive precicely in the time laps between preview and dequeue - remember Exits are posted to the front of the queue.

I think the best option is to replace the flush of the queue in the Stop message handlers with a Selectively dequeue of messages one by one and check each if Exit is found - if so, re-insert it into the front of the queue. All other messages are discared. This look like this, having the interesting parts visible...

 

Below is what the Stop message loop looks like with the problem highlighted.

Given that I am not mistaken, I think it is better that NI updates the templates to prevent this problem.

[SimonH]

heel,

You are correct.  While unlikely without a lot of modification, you could miss an Exit message.  

Internally, we've updated the message loops in the Continuous Measurement and Logging Sample Project to include an idle state which eliminates the need to flush the command queue (log messages recieved by an idle logging loop are simply ignored). The benefit of doing things this way is it scales a little nicer - you don't need to specifically look for certain messages to preserve before a flush and you have the option of handling different messages differently depending on the state you are in.

We expect to ship the updated sample project in the next version of LabVIEW.

Regards,

Simon

[heel]

Ok, Thanks for a swift reply. I will try that solution as well.

You wrote that this event of lost Exit is unlikely, but it happened to me the very first day ever of work with this sample project.

I have one problem however with your description - what do you do in the idle case? You set the next state to Logging Stopped - yes, but you have to make sure it does not waste a lot of processing power calling back itself.

Eventually I will figure it out, but to ease the matter for other readers as well: Could you publish this logging-vi, or at least the essantial part, here?

As a side note: The problem is the same in the acquisition message loop,  so - i assume, is the cure.

thanks

Henning

[SimonH · Accepted solution]

Here's what the idle state case within the stop message case looks like:

We don't hang the CPU handling a constant stream of no-op messages because we only enqueue "Log" messages when we are in the valid logging state (the Idle state here is again a passthrough).

The worst case scenario is that there are number of Log requests already in the queue when the system stops. Upon recieving the Stop message the state transitions to idle and the remaining Log messages become no-ops due to the state.

I will look into the feasibility of posting some updated VIs.

~Simon