Synchronization problem in "continuous measurement and logging" template

[ofirkh]

I don't understand.

I'm working on the basic continuous measurement and logging too.

I added just one thing that I circled in red in the picture below in the acquisition loop.

try to do it now please and run the program and you will see that if you start the measurement

for some time and press the stop button it doesn't come back to the "ready" state and stays

at the "Acquiring and Logging" state.

Do it again without the delay and you will see it going back to the "ready" state

Can you explain this?

BR

ofir and roey

[ofirkh]

I don't understand.

I'm working on the basic continuous measurement and logging too.

I added just one thing that I circled in red in the picture below in the acquisition loop.

try to do it now please and run the program and you will see that if you start the measurement

for some time and press the stop button it doesn't come back to the "ready" state and stays

at the "Acquiring and Logging" state.

Do it again without the delay and you will see it going back to the "ready" state

Can you explain this?

BR

ofir and roey

[paul.r]

I've already tried it and do not get the same results as you. What has changed between this post and the last??

If that is all you have changed, why can't you post your code? Zip up the entire project directory and post it.

[ofirkh]

Here is the code

[paul.r]

Thank you. 

I had been using the DAQmx continuous measurement and logging example - the design isnt exactly the same as I thought it was. The problem is due to a race condition that can be traced to the logging.lvlib:Log Data.vi - if the acquisition loop stops before the logging loop, the data queue will be empty, and the logging module will be stuck waiting to dequeue from an empty queue. Put a small timeout on that queue, and wrap the TDMS write into a case structure so that if the queue times out, nothing gets written. 

[Roey]

Hi Paul,

It seems that the solution you suggested has been solved the problem. Thank you very much!

If you don't mind, I would like to ask 2 more questions about this:

1. Why this problem prevented the logging loop from going into the "stop" case? even if it was stuck in waiting for dequeue, doesn't the stop string suppose to take it out from there?

2. What is the way to find this kind of problem by myself next time?

Thanks again,

Roey

[paul.r · Accepted solution]

Regarding question 1 - think dataflow. The stop string isnt dequeued from the logger's main queue, because it is still waiting on the data dequeue. The logger module is stuck at that node until it executes, so new commands to tell it to stop are not processed yet. The only thing that stops it when you end the program is that the data queue is destroyed, so then the logging module can process new incoming messages. I would say having a dequeue there with no timeout is a bug/serious design flaw in the template. 

I made some quick changes to the code to help with the debug - in the main VI I added a UI log of each command received and the current state just to see what was happening. I saw that the logger module was never responding to the stop message, so from there I did something similar with the logging module and was able to find the point where it was stuck. I attached the code with the update. 

If you dont have one, developing a good internal logging module that you drop down in any project to create a log of module states etc is very valuable in terms of being able to debug problems. 

[Roey]

Thank you very much! I am still learning your code but it seems that you gave me a better ubderstanding of the queue and dequeue processes. 

Best regards,

Roey