Deque errors

[Geologian]

Good day, I am running a producer consumer set-up for the first time and am getting some bizarre errors:

1. When the VI is stopped I get an Error 1, which states that it has to do with an input parameter is invalid at the Deque element.

2. I ran the VI over night (plotting but not writing the data to file). When I left everything was working fine. When I returned this morning, the VI was not plotting new data and had cleared the data that had been there the night before, i.e. the plots were all blank.

3. About 1 out of every 4 or 5 times I run the VI, nothing happens. That is to say, the VI starts, I'm prompted to write the data to file or not, but then nothing is plotted or written to file. When I run the VI in 'highlight execution' mode, nothing beyond the deque element is working.

Any insight would be appreciated. I can't drop all the subVI's into a single message, so I'll post them in a response below.

Cheers.

[Geologian]

Attachment 1.

[Geologian]

Attachment 2

[tmf171]

From the way you describe this it sounds like you have a race condition. Whenever I run into an issue as you have described I look very closely at the code to determine if a race condition has happened. Double check that to make sure and maybe you can get the intermittent failure to act more more consistent.

[Geologian]

In your experience, is the likely source of this being the local variable I'm calling "local variable element'? If so, how would you suggest working around this? The purpose of this element is to shut down the consumer loop if there is an error in the data acquisition loop (i.e. the producer loop). Are producer and consumer loops designed in such a way that this is redundant? That is to say, if there is an error in the producer loop will the consumer loop terminate automatically?
Thanks.

[tmf171]

Let me get access to LabVIEW 2012 and take a look at your code. Generally you program the shutdown of one loop to ensure you shut down the other. Local variables linked between loops can do this (not recommended) or you can use the queue natives to allow both parts to error out and allow the error control to stop both loops. There is no automatic termination, thats for you to program how you want the loops to stop. 

[tmf171]

1) Make sure you reinitialize your stop button to being False (The program could just be stopping itself because the value never reinits once stop is pressed).

2) If there is a problemw with your analog waveform you will stop because of error and not know why. I would suggest trying to capture that error. You may be flushing and releasing the queue after it only gets 1 element because the top loop has stopped.

3) I generally wire a value to Queue timeout in the dequeue element because then I can know if a timeout occured versus an actual error (queue was destroyed). That may be a personal preference though.

I do not have daqMX, so I can't run the software and see if I can see anything more.

I would verify that the race condition - in this case your queue is being destroyed because of an error in the daqmx task does not exist. Local variable element will not be able to stop the consumer loop because it is erroring out on the first iteration and will not run a second iteration due to timeout in dequeue not being wired.

Maybe ignore erros from the acqusition (if there is a problem with that) and only write to the enqueue IF you get a good reading?

[Geologian]

tmf171, thank you for your help thus far. I've been fiddling with a few things since your last suggestion and I've discovered that the error is coming from the 'Write to Text File' element. This confounds me even more as the error line from the Deque element never merges with the file error line. Any idea how it could be getting into this element?
Thanks.

[tmf171]

Now it seems like you are looking at a few different issues. Make sure the file is not locked by something else (like it being opened). Also, I would start a new file each time you "run" the program, so I would take out get file size and set file position as these can cause errors if not used correctly. Then the writing will just keep appending to the file because its using a refnum to write instead of a file name.

This still does not solve the issue from earlier with the queueing. Use highlight execution and probes to get a better handle on all the errors. Be aware the only way to stop the producer loop is on error from aquisition or stop button being pressed. The only way to stop the bottom loop is for it to be running and an error is seen on the queue or the local variable element was able to stop it.

I made a few adjustments to the VI if you want to take a look at it. Might be easier to track errors.