Allowing regeneration without using it

[BogdanB]

Thank you for your suggestion!

I have in fact tried this structure, and left it out, since it doesn't really adress the basic issue. The errors are not caused by the input, but rather by the output method. This can easily be checked by replacing the input with a constant: without other modifications, there are still random failures (in non-regen).

I have found that without regeneration, there are 2 ways of writing to output: as fast as possible (which fills the device buffer, leading to 50ms loop cycles while waiting for more space to be created, which eventually leads to a drift in response time), or "just in time", as I try to do by strictly controlling when it is time to write (a risky operation, since no timing is ever perfect).

My problem is that I do not understand regeneration behaviour. I would expect that, provided my VI is able to send data in time, there would be no difference between regeneration and non-regen: each period is 'fresh'. However, this is not the case: regeneration happens anyway, leading to the long "wait-to-write" cycles described above (in fact, it's even worse, since the write loop delays for 2 or 3 50ms cycles, not just one). I would be grateful if you could point me to some documentation (if publicly available), besides the basic introduction, where I could find more intimate details of how regeneration works, what triggers it, and what I can do to temporarily (i.e. every time I send data) inhibit it

[Chris_1890 · Accepted solution]

I spoke with one of our DAQ experts, and he explained to me that allowing regeneration is an either/or option.  You can either allow regeneration and use it, or do not allow it.  There is no way of temporarily disabling it or getting around it.  He said it is possible to use the FIFO buffer with regeneration and then overwrite it with a new sample each period, but it is glitchy.  You run the risk of meshing your data and outputting some data points from the old waveform and some from the new.  (I have attached links to  two KnowledgeBase articles which go into more detail on the different types of regeneration available and the different data transfer request condition options.)

After explaining your goal and the issues you're running into, this individual suggested implementing the two-loop structrue and not allowing regeneration.  As far as the CPU usage relating to VI crashes, he said that is more of a system problem dealing with the available memory on your machine. If it is an older machine, then the VI will be more sensitive to crashing.  The machine I was running the testing on has a 1.86GHz processor and 1.50 GB of RAM.  I did not experience any time-out errors on this machine, even when I forced the CPU usage to 100%.  The latency was noticeably increased however.  If possible, I would suggest running the VI on a different machine and see if you can achieve different results.  Please let me know if you have any more questions or if there's anything else I can do for you.

Analog Output Regeneration Modes

http://digital.ni.com/public.nsf/allkb/DD750D84BAD703E386256E6E005B41AC?OpenDocument  

Data Transfer Request Condition for Continuous Analog Output using NI-DAQmx

http://digital.ni.com/public.nsf/websearch/45A7AC6B59E026B386256F90006DAA49?OpenDocument

 

 

[BogdanB]

Well, not the answer I was hoping for, but at least it's clear and definite.

That you for your help!

There is one other thing that I need to ask: in all the variants, after the loop there was an extra write operation, meant to set the output value to a certain value after the VI exits. This however does not work, the output stays at a random value. Any ideas? Should I make another thread about it?

[Chris_1890]

I added a DAQmx read to the end of the original VI code you sent me to verify what was happening.  Without making any alterations (except selecting the proper input and output channels for my device) the output data showed an array of all zeros with N elements equal to the output buffer size.  So it seems like the issue lies in your hardware setup.  Please double check that all of your connections and selected channels are correct.  If you still experience problems, then yes, since this is a separate issue please create a new thread.  In the new thread, be sure to indicate what hardware you are using and how you are verifying the buffer contents.  Best of luck and have a great weekend!