daqmx close task freezes

[Buadam]

Hi All,

I have been struggling for a while with the following problem, finding no relevant answers to it. Maybe someone here have encountered this before.

I have written a data acquisition program in Labview 2011, using daqmx 9.3+, It acquires data from a NI 6008 card. The program works fine at all runs with my notebook, but freezes for like every third run on another notebook. Both have win7, the other is 64bit (I am not sure that matters).

The program itself is rather complicated, so here I pase an image of one of the parts it tends to freeze at. (there are many other acquisition tasks, where it bounds to freeze, but every time the structure of the block diagram is basically the same, with the creation and the closing of the task). Most often it freezes when there is continious sampling with 1000Hz rate, and simultaneous processing (plotting, fft, etc), in a producer/consumer scheme. The interesting thing is that it does not ALWAYS freeze,

Everytime I check though the program freezes at the STOP TASK.vi without sending an error message. I can produce the same error with the simple example I insert below, if I run the program several times (it needs 10-20 runs to stick in the stop task.vi)

Please, post any suggestions about what the problem might be.
One other hint is that the MAX itself gives an "onboard memory overflow" error, when started multiple times. However I tried the workaround with the property node - without any success.

[crossrulz]

Since you are reading finite number of samples, you don't need to stop your task.  Just clear it.

[ValkoA]

Hi Buadam and welome to NI Forums!

From the code you've posted, this seems like a race condition issue between finishing the finite measurement and closing the task. As a simple fix, place a DAQmx Wait unil Done VI to run between the Read and Stop VIs. 

Kind regards:

Andrew Valko

NI Hungary

[crossrulz]

---

ValkoA wrote:

From the code you've posted, this seems like a race condition issue between finishing the finite measurement and closing the task. As a simple fix, place a DAQmx Wait unil Done VI to run between the Read and Stop VIs.

---

Wouldn't the read be waiting until the task is complete?  It has to wait for the number of samples desired to read.  Therefore the task should be done when the read is complete.  Or is there something I totally missed?

[Buadam]

Hi,

Thank you both for the prompt reply. I tried adding the wait until taks complete vi, but it did not fix the problem. Actually, now the wait vi. times out, meaning that it is the daq read that cannot finish sometimes. Also the problem occurs in MAX, when I test the panels, if I stop and restart the continous sampling multiple times (as does the program I use) it gives an onboard memory overflow error. Funny though that this computer is newer and faster than the other one on which the program is stable. I found the workaround with the daq channel property node on the overflow error, but in this version of daqmx I understand that it is already implemented (req.count=1 per default, and I cannot even find the channel req.count property).

However the close task.vi doesnt make a difference, I inserted them in hoping that they would solve the problem in the first place. Previously it stopped at the clear task.vi 🙂

I forgot to mention in the previous letter, that the only way I can restart the program from this state is unplugging the daq card. Even the whole LV freezes, and the red record button wont respond either until then.

Altogether I suspect that the problem is deeper inside the properties of the usb hub or the operational system. As you see the sampling rate is not that fast (1kHz), and the other computer can easily cope with 10kHz sampling rate in max too. Unfortunately I dont know much about usb properties, I think this notebook has at least usb2 with proper drivers installed (image attached, if any help).

Thank you again, and I appreciate any further ideas.

[ValkoA · Accepted solution]

Dear Buadam,

The workaround you've mentioned was first implemented in NI-DAQmx 9.4, and should be available from that version on. The default value it definitely not 1, since that would limit USB throughput considerably, especially on faster devices.

To explain it in more detail: This property (Analog Input»General Properties»Advanced»Data Transfer and Memory»USB Transfer Request Count) is responsible for setting the burst size of a USB transfer. The default USB transfer size is 32 kB. For very fast or high channel count applications, increasing the USB transfer request size will likely increase throughput. In this case however, we willfully decrease this transfer size, to make absolutely sure that the bug occurring in Windows 7 (the way the system handles requestors on USB 2.0, specifically, how packets are split up) does not affect us, resulting in stalled packets like you experienced. So the idea here is to make the packets small enough that the USB driver is unable to split them, this in turn also impedes USB performance, but since the 6008 is a relatively low-speed, low channel count device, we still have more than enough bandwidth.

So, to summarize:

• Please upgrade to DAQmx 9.4 or higher if you can (LabVIEW 2011 is supported up to the newest, 9.8 version)
• I'd also recommend to upgrade the notebook's USB drivers from the vendor's site if applicable.
• Set the AI.UsbXferReqSize to 1 once available. If you can't find it, try right-clicking the property node, Select Filter... > Show All Attributes

crossrulz: You are indeed correct in that a finite measurement will stop the task once all the samples have been read, so a Wait Until Done I recommended is redundant here, as it is expected to return immediately with Done = True. The reasons why I suggested using it are:

1. To requery the task status, "double-check" that it has been properly stopped.
2. To give the device some extra time before the Stop Task/Clear Task command is sent. 
3. To catch any errors that are stored in the DAQmx object, but not caught by the Read operation, before attempting to Stop/Clear.

Hope is makes sense.

Kind regards:

Andrew Valko

NIH

[Buadam]

Dear Andrew,

Seems that the daqmx 9.8 (and the property node) has done the trick. Thank you for the support. Best,

Adam