Write on AO in continous sample mode (allow regeneration) without stopping task

[samuel_monter]

Using a PCIe-6353 I need to generate analog and digital output signals with a high sample rate.

For the digital signal this is possible by setting the "sample mode" of the "DAQmx Timing" to "continous sample" and setting the "RegenMode" property of the "writing property node" to "Allow Regeneration". Then it is possible to write sample to the buffer while output is generated continously at the set sample rate. This can lead to glitching which is however tollerable.

If I try the same for an analog output singal, writing new data to the buffer while it runs in the "continous sample" mode is not possible.

It is necessary to stop the process, write the new data and start it therby. This however introduces a 2 ms delay, which is not tolerable.

(Note that using a timed loop is not an option as the requiered sample rates exceed what is possible using an CPU.)

Thanks very much for your kind help.

[santo_13]

Attaching a PDF of an image of the VI is like touching your nose around your head, so why not attach the VI as such?

Please define "high sample rate". Sure, you can generate analog and digital signals at high speed, the question becomes are these signals static or dynamic? Static in the sense the whole signal is fully defined before generation or do you need some kind of dynamic logic that determines the signal along the way?

[samuel_monter]

By high sample rate I mean talk about the realm of 10 - 100 kHZ.

I am not sure if I can follow your definition of static and dynamic, but the signal needs to change at a slower rate (~10 - 100Hz) while it still given out at the high sample rate (10 - 100 kHZ). This is where the problem occurs since it is apparently not allowed to wrote new data to the analog output while it is running continously in the "allow regenration" mode.

I hope that are all the details you require to fully understand the issue and thanks in advance!

[samuel_monter]

And here is the VI.

[Kevin_Price]

Check out the shipping example for non-regenerating AO.   If that seems to work correctly (as I expect it will), then look for the differences against your approach to see what needs to change.  For starters:

1. You should write data to the task *before* starting it

2. You shouldn't be using "Wait Until Task Done" with a Continuous Sampling task.  Only an error will ever make it report that it's done.

-Kevin P

[samuel_monter]

Hi thanks fir your tips. I checked out the available example.

Regarding your second comment, you are right and that is how it used in the example VI - just to catch an error. So it is not actually touching my problem.

Your first comment makes my believe that I did not communicate my problem clearly.

I want to write while my task is already running.  This is possible for digital outpus (if you accept possible glitches). However using analog output I observe a large delay, which is not acceptable for me. My question now: Is it is simple not possible to write new AO during the continuous sample mode?

[Kevin_Price]

Well, saying there's an unacceptably large delay updating an AO task with new data is a *different* problem than your earlier posts that declared it was not possible or not allowed.  New data *can* be written to a regenerating task, but it must work its way through at least 2 buffers before it becomes a real world signal.  That leads to a potentially large delay that we typically refer to as latency.

There *are* ways to reduce those buffer sizes and reduce the latency, but I doubt you can get below 2 msec (the interruption time you described as "not tolerable") reliably.  FWIW, here's a rather long & involved thread I was in that gets into some of the details about reducing latency.   When I've experimented, I typically make it a point to write a full buffer worth of new data when I'm writing any to prevent having a mixture of old and new.

-Kevin P

[samuel_monter]

Thanks for linking me to this thread, but I am not sure if this is the same problem since:

1.) regeneration is not allowed

2.) it is about USB devices and I use a PCIe card

Also I think I caused some confision again about 2 ms or  10s of latency. So let me try to clarify once again:

My goal is to give a sequnce to my AO which in my example* is just 2 values [1V 0V]. These shall be repeated continously. During the repetition i want to be abble to change these values at an arbetrary point in time (with minimal latency).

Currently I have the following observations:

1.) I set up a AO channel in the continous sample mode and I allow regeneration. I can write initial data to the channel and start it. Then I want to write new data by executing the write function in a while loop. If I now change the data input I can only observe changes after ~10s.

=> Problem: 10s latency are realy bad

2.) I set up a AO channel in the continous sample mode and I allow regeneration. I can write initial data to the channel and start it. Then I want to write new data by executing the write function in a while loop after stopping it. The stop introduces a pause of ~2ms in my output singnal.

=> Problem: The stopping will desync the signal before and after the stop, which is not acceptable.

What is additionally confusing me is that version 1.) works just fine if use a digital instead of an anolog output.

Thanks for your time.

I would be very thankfull for any specific clarification on this issue.

*will be more complex in the actual application

[Kevin_Price]

Reread the thread I linked.  Yes, some of the context differs from yours.  But the methods for reducing latency remain valid.  Reduce the onboard buffer size (or, depending on DAQ device, change the "Data Transfer Request Condition").  Minimize the task buffer size as much as possible without inducing buffer underflow errors.  Write a full buffer worth of AO data when you want to change the output sequence.

I don't know exactly how you define "desyncing the signal".  Even if you get your latency down to a small fraction of a second, you still can't perfectly sync the software calls involved to any specific instant or event.  At best, you can get pretty close, but there's *inevitably* some uncertainty about the time it takes to notice when conditions dictate you should make the change, do the software calls to initiate the change, and the process of moving data through variable-size buffers to instantiate the change.

-Kevin P