myDAQ & NI USB-6002- big delay between analog output and input on same device

[TSE_Expert]

Hi Nandor,

a generálás valamekkora véges ideig tart, amit nem vár meg a kódod (Generate on DAQ loop, Generate eset). Erre a DAQmx Wait Until Done függvény lenne alkalmas. Ezzel lényegében a DAQmx megvárja, hogy a buffer kiürüljön.

Várom visszajelzésed.

Üdv,

NI TSE 

[Spacsi]

Szeva Akos,

ezt mar probaltam es nem fog mukodni. Most szimulatam a eszkozt, ezt a hibat kapom:

Error -200560 occurred at DAQmx Wait Until Done.vi:3580001

Possible reason(s):

Wait Until Done did not indicate that the task was done within the specified timeout.

Increase the timeout, check the program, and make sure connections for external timing and triggering are in place.

Task Name: _unnamedTask<F>
Probaltam a timeout-ot pontosan kiszamolni, akkor sem mukodik jol.
Probald ki te is.
Udv
Nandor S.

[TSE_Expert]

Hi Nandor,

állíts be egy nagyobb timeoutot, alapból 10 másodperces, a -1-es beállítás határozatlan ideig tartó várakozást eredményez:

timeout (sec) specifies the maximum amount of time in seconds to wait for the measurement or generation to complete. This VI returns an error if the time elapses. The default is 10. If you set timeout (sec) to -1, the VI waits indefinitely. If you set timeout (sec) to 0, the VI checks once and returns an error if the measurement or generation is not done.

Csatoltam Sample-VI-okat.

A következő linkek átolvasása segíthet:

http://www.ni.com/academic/students/learn-daq/generate/

http://www.ni.com/tutorial/5371/en/

Üdv,

NI TSE

[Spacsi · Accepted solution]

Draga Akos,

mielot irsz kerlek probald ki. Ezeket mindet atneztem mar hamarabb.
Wait until done soha nem fog dolgozni a Continuous bealitasal, ugyanugy a Is task done. Es nem kell semien Wait until done, azer mert epen anyit tart a genralas ,amenyit is kell tartjon ha kiszamolod, ki van merve is az ido a progiban amit kultem.

Nem valaszoltal a kerdesre, mi tortenik a a eszkoz bufera? Mert generalja 8 alkalomal a kimeneten a regi adatot?

Kiprobaltam a MyDAQ-al ezt a hibat adja vissza:
Error -200290 occurred at Main.vi Possible reason(s): The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated. To avoid this error, you can do any of the following: 1. Increase the size of the background buffer by configuring the buffer. 2. Increase the number of samples you write each time you invoke a write operation. 3. Write samples more often. 4. Reduce the sample rate. 5. If your data transfer method is interrupts, try using DMA or USB Bulk. 6. Reduce the number of applications your computer is executing concurrently. In addition, if you do not need to write every sample that is generated, you can configure the regeneration mode to allow regeneration, and then use the Position and Offset attributes to write the desired samples. 

Kerlek segitsel hogy megercsem ezt, mert ez lesz a valasz:
http://digital.ni.com/public.nsf/allkb/9548564333A0437F86256FC00060516C?OpenDocument
https://forums.ni.com/t5/Multifunction-DAQ/DAQmx-Continuous-Analog-Output-Write-with-Buffer-Offset/t...
Kerlek kuldje valami linkeket hogy jobban megercsem a eszkoz kimeneti bufert, mi tortenik vele.

Finite bealitas nekem nem jo mert stop meg start kozot 30ms lesz -> 30ms hogy a kimeneten nem tortenik semmi. On Demand meg nem jo mert varijal idoben meg tovabb tart a generalas.

Koszonom a megertesre,
Udv
Nandi

[abuzahra]

Dear all,

I got the same issue. there is delay between analog output and input channel using BNC NI 6229.

I tested also on the oscilloscope for AO channels.

It seems the delay came from the AO channels instead of AI channels.

the delay occurred at 6-7 s.

if you have some information about this, please kindly let me know.

I appreciate for all your help.

[Spacsi]

Hello,

first check that regeneration mode is appropriate for you goals.
If you loading data in a buffer in each iteration, you have to check that your data is not increasing in length in every iteration.

These will be first steps.

Best regards,

Spacek N.

[Spacsi]

you can send me your code, i will check it when i have time

[abuzahra]

Dear Spacek,

Thank you for your reply. I am beginner in LabView programming.

I am not sure my works are correct. but by using USB-6002, the VI can be operated well as i expected. the regeneration mode default i used is non-regeneration mode. i have problem when i run the VI by using BNC NI-6229. there was a delay, as I enter new value on the control panel, i.e Bias voltage, the generated value will be written after 6-7 s.

after i followed your advice, i changed to regeneration mode, but the time consuming between loop will be 2 s.

Here I attached the VI.

please kindly advise me.

[Spacsi]

Try to separate in different loops acquisition and generation, one loop just for generation, one loop just for acquisition.
After that, you have to find out in generation loop how much time take DAQmx Write without data preparation, find out how long take a data preparation before DAQmx write, measure this two times. So then you will get answer why it take 2s, identify the problem,spot.

[Kevin_Price]

This is all about latency due to buffering.

You're generating at 1 kHz.  The 6002 has a 2k sample onboard FIFO, the 6229 has an 8k FIFO.  By default, DAQmx will try to keep the onboard FIFO full.  This leads to onboard FIFO-induced latency of ~2 seconds for the 6002 or ~8 seconds for the 6229.

There can be additional latency due to the task buffer in PC memory.  The size of that buffer is set by your first call to DAQmx Write.  In your case, that's 1000 samples which is the same amount you write every loop iteration.  DAQmx is now smart enough (once upon a time it didn't used to be) to block and wait until it can successfully write all the new values without overwriting any old values that hadn't yet been delivered to the board itself.

So you'll write your first 1000 samples, immediately iterate and attempt to write another 1000.  The second (and every subsequent) iteration DAQmx Write will block and wait for nearly 1 full second before returning.  That'll mean that the last sample from your previous Write was transferred, and the first sample you started trying to Write about a second ago is about to be transferred more-or-less immediately.

The net result is that you probably have an additional ~1 sec latency from your call to DAQmx Write until the data gets transferred to the board.  I'll call this the software buffer latency.

To reduce the *hardware* latency due to the onboard FIFO, DAQmx provides a DAQmx Channel property known as "Data Transfer Request Condition".  You can choose from among settings that mean "Not Full" (the default), "Half Full", or "Nearly Empty".  The "Not Full" default means the board tries to keep its hardware FIFO filled up, giving your system the maximum buffer and maximum latency.  The "Nearly Empty" setting provides the minimum buffer and latency.  I'm not sure how reliable it will be on a USB device though.   

    Just speculating, I'll bet that DAQmx doesn't let a USB device's FIFO get quite as empty as a desktop board with DMA access to PC memory.  NI was probably careful to make sure the setting would have a chance of working on USB devices.

    I recently did some tinkering and without too much trouble was able to get latency below 10 msec with a PCIe board using DMA.  I'm not sure what you should expect with a USB device.

-Kevin P