Application freezing - "Requested samples have not yet been acquired"

[tone5]

Hello

I have a vi which controls a test rig. The vi was created using Labview 8.6. The vi works fine and controls the test rig correctly when running on the pc onwhich it was created in the full development version of the software (i.e. not converted to a standalone executable).

The problem occurs when I create an executable and try to run it in a different pc. Initially the application seems to work ok but then after a random amount of time (anything between 30 seconds and 12 hours) the application begins to run slowly and then looses communication with the hardware (cDAQ-9178). After this has occured when I open MAX and try to run the task I get an error message which says "Some of the requested samples have not yet been acquired..."

When the application begins to slow down I see a reduction in the available physical memory and one of the CPU's usage increases to 100%.

I built the application using Labview 2012 and am using MAX 5.3.1 on the pc which is hosting the executable.

Below I have inserted a screen capture of the area of the block diagram which is probably most relevant to solving this problem. In MAX the task is set to continuous samples, 1k samples to read at a rate of 1k.

Does anyone have any suggestions for me to try please?

Thanks

[Blokk]

Hi!

Have you got any error codes? I am not sure what could be the problem, but first of all, I would try to check from MAX whether you get error or not. If you just run a simple DAQ from Max (Test panels), with the same sampling rate, and in continous mode.

If you get error also in MAX, I think you have USB problem (if the USB port is via a hub in your PC or laptop).

If no error via MAX, you can start to look for bugs in the code itself.

edit:

also, I would reconsider the structure of your code. there are kind of "dangerous" elements: why do you need the flat sequence structure? I never ever used this, it is really not necessary usually (and violates the data flow principle of labview). So the overusing of local variables...
I would suggest to look some labview examples, like producer-consumer with events and queue. There are very well written DAQmx examples in LabView, you could also set timing of your DAQ with DAQmx drivers, so you do not need the timed loop.

Regards,

[Albert.Geven]

In addition to the previous post: where are your error out controls to see which error occurs in daqmx?

[tone5]

Thanks Blokk for the suggestions. I have had error codes 200361 and 200284 and will do some research on these, hoping to better understand the cause of the problem.

I don't think that the problem occurs when MAX is running the task on its own. However to be sure I have left MAX running the task and will see if it continues to run or freezes and gives errors.

I received these error codes when I opened MAX and ran the task after my application froze (I had closed the frozen application before running the task in MAX). After a few minutes the errors go away and the task runs fine in MAX.

I cannot get involved with a major restructuring of the vi. I need to get the test rig running asap and it worked reliably a few weeks ago (which was before I added 3 additional strain measurement channels). Therefore I feel that the required change to get it back to its working state is small. Incidently, since adding the additional channels I have tried the original version of the application (without the additional channels) and the same problem occurs i.e. it runs slow and then freezes after a random amount of time. So, this seems to indicate that the problem is not caused by adding the extra 3 channels.

Admittedly the vi's structure is far from elegant - I am a Labview newbie. The reason I have used timed loops is that I needed to make the functions which control the test rig a higher priority than those that record data. This is because the control functions are time-critical i.e. if the timing if I/O signal are not within about 10ms the test specimen is overloaded and the rig shuts down, which is not acceptable for a test which is required to run for several weeks. This is what was happening before I seperated the code into 2 timed loops with control loop's priority set to 100 and the data acquisition loop set to priority 50.

[Blokk]

Hi,

Please test the following:

do test runs in MAX, but do not keep it running. If the bug is related to DAQmx driver low level (http://forums.ni.com/t5/Multifunction-DAQ/USB-6009-overflow-error-on-continuous-mode-after-restart-o...). after several attempts, you should get always error in MAX. So run the DAQ task for several seconds, stop it. Run again, etc. If the bug is usb related (see above link), then you will get error in MAX after random number of attempts. When I had this problem, sometimes I got the error after 5 attempts, sometimes only after 20 attempts...

If you cannot recreate error in this way, then it is not this kind of usb bug.

About the timed loops: if you use a producer-consumer structure, you can avoid many possible bugs and traps...
Since you send your data from the top DAQ loop via a Queue, you do not loose data. So even if you have a slower data evaluation loop (lower loop), it will not effect the top loop. So I would suggest to remove these timed loops, and really look some simple examples, they come with labview, they are very useful...So let the DAQmx driver do the timing, much better...

https://decibel.ni.com/content/docs/DOC-2431

EDIT: another note: if you have time consuming, resource hungry data manipulations on the acquisited data, you should not do it in the Producer top loop.

The idea is that, you use the top loop only for DAQ, and you send "down" the data via the Queue data line to the consumer loop. So if you need to save this data to file, or doing data evaluation, you do not slow down the top loop (its speed will be what you set on the "Sample clock" VI). If you need to do also something with this acquired data which is "time sensitive", I would recommend to use two consumer loops. So the important things to separate tasks, so every while loop can work with a speed what they need to.

[BCL@Servodan]

From the code snippet, I see that You do not start Your task outside the timed loop.

This might also be a possible reason.

When making continuous measurements, without starting the task, Labview will Start the task, take the measurement, and end the task, as soon as the Daqmx read is called.

There is quite some overhead to this functionality, so instead use the Start task outside the loop, and put an End task when the loop finishes.

Also as I understood your setup, You've added some channels (maybe even extra modules) to the task. If You've added more modules, the initialization and hardware committing takes even longer.

Just my 2 cents.

/BCL

[tone5]

Hi Blokk

I have tried starting and stopping the task numerous times in MAX and the error did not occur. So, I guess that proves that it is not a DAQmx driver low level issue.

[Blokk · Accepted solution]

So now you could try what BCL@Servodan suggested. Create and start tasks with DAQmx before your while loop, and see if it helps. Removing the timed loop would be also adviced, and you set sampling rate before the normal while loop, as in the official example.

This would not require too much effort, and may help...

[tone5]

Hi Blokk, BCL@Servodan

I have tried starting the task by using a 'DAQmx Start.vi' outside the high priority loop like this:

On the other side of the timed loop I used a 'DAQmx Stop Task.vi'

Unfortunately this has not solved the problem.

Before I embark on major changes to the vi, such as changing it to a producer-consumer structure I am going to try anything I can think of to get the vi to work as it is. Currently I'm trying different combinations of values in MAX for 'Rate' and 'Samples to Read'.

I have a second task inside my top loop. I'll try starting this task before the timed loop as well.

If you have any other ideas of quick things to try, I'd appreciate your thoughts.

To reply to BCL@Servodan

"Also as I understood your setup, You've added some channels (maybe even extra modules) to the task. If You've added more modules, the initialization and hardware committing takes even longer."

I have added extra channels but not extra modules.

Thanks

[Blokk]

"If you have any other ideas of quick things to try, I'd appreciate your thoughts."

Change the timed loops to normal while loops. Use the "Sample clock" DAQmx VI before you start the DAQ task, just before the top while loop starts. If you set your DAQmx task for continous reading, specify the number of sample at the DAQmx Read VI inside of your top while loop. Iteration time of your top while loop will be  = Number of samples / Sampling rate in Hz  . For example, if your rate is 1 kHz, and you read out 1k samples in one iteration of your top while loop, you have 1 second iteration time. Of course, if you do some other tasks after your DAQmx Read in your top while loop, the iteration time will be 1 sec + the time needed for the other operations.

The lower second while loop will be timed after the top loop, so you do not have to worry about it: the Queue will trigger iterations of the lower loop, whenever you do "Enqueue element" in your top loop. (of course, if the operation in the lower loop is slower, then its iteration time will be also slower)

So you DO NOT need to use timed loops!  And these changes are really minor ones...

Also, actually you do use a kind of Producer-Consumer structure, but not in the best way 🙂

Other thing: you show us that, you put a DAQmx Start VI before your while loop. This is not enough, use the proper way to set up a DAQmx measurement, like shown here, a very simple example (Create channel --> Sample clock --> DAQmx Start VI):

https://decibel.ni.com/content/docs/DOC-2431

EDIT: I read that now, you use MAX to set up the things. I would recommend you just using LabView to set up DAQmx tasks. So specify the physical channels as in the example link, and do everything in LabView. I never use MAX to configure DAQmx tasks, but as much as I know, it can cause problems in executables (you need to carry over the MAX settings to the target computer, or do some settings in the Builder, i guess?)