PXIe-6739: write and hold data without interfering other AOs

[p_dieng]

Hello @all:

i am working a project implementing DAQmx in CANoe via Solution C#. The outputs work pretty well. But i want to create a mode which allows me to load a file and generate my own voltage flow. But the voltage shall only be outputted on the specific channel without interfering the other tasks / channels on the same device.

1. What I attempted until now (didnt work)

• I put each ao channel in a sperate task
• tried to load data into the device "m_writer.WriteMultiSample(false, data[])".
• TaskAction.Unreserve does not work

When I execute the write-methode i encounter an exception that the resource is already reserved.

2. What I attempted until now (works but not what I want)

• I put all ao channels in the same task
• wrote the data into the buffer "m_writer.WriteMultiSample(false, data[ , ])"
• task.Start() --> EventHandler and so on.

Works as expected, but isn't the I want it.

Question:

Is there a way to solve my issue or is it unfortunately impossible with just one channel (Without interfering the others)?

greetings

p_dieng

[Kevin_Price · Accepted solution]

There's a way to do it, and it will need to be much more like your method #2 than #1.  I only program with LabVIEW and can't give any detailed advice on C# syntax.

The constraint is that your device only has one timing subsystem available for AO, so you need all your hardware-clocked channels to be grouped into a single task.

That means that when you want to change the values for the 1st channel, you'll *necessarily* also need to write values to all the other channels.  BUT, there's nothing stopping you from writing the *same* values to those other channels repeatedly.  So they'll keep generating the same as they would have if you hadn't intervened to change the 1st channel.

You can expect some latency between when you write values to the task buffer and when the data gets generated as an output signal.  To reduce latency, you can:

1. Configure a DAQmx property to disallow regeneration.  This will require your app to be able to continuously feed new data to the task buffer at a regular rate that stays slightly ahead of the actual signal generation. This is not necessarily trivial to accomplish.

2. Limit the size of your task buffer.  By default the task will repeatedly regenerate everything in the buffer.  When it comes time to update the 1st channel, DAQmx will manage the process of overwriting data in the buffer *after* it's been transferred down to the device for signal generation.  This means that it may need to wait as long as (buffer_size / sample_rate) to have that access.   This is the first source of latency.

3. Another source of latency is the device's onboard FIFO.  There are DAQmx properties you can set to limit how much of that buffer gets filled.  I know of 2 possible methods, though any given device probably supports no more than 1. 

   One can set the "Data Transfer Request Condition" to something like "Onboard Buffer Empty".  That makes the driver transfer data just in time to generate the signal while spending a minimal time working through the hardware FIFO.

   Another method to try is to explicitly declare the "Onboard Buffer Size".  If you do this, you should also try to read back this property.  Many devices won't actually obey this request, and I *think* I recall that it might be ignored silently, without returning an error code.

-Kevin P

[p_dieng]

Hello Kevin_Price,

I really appreciate your comment. I got a lot to do and now I was able to test it and it works! Thank you very much!

And by the way ... your performance tips helped me by another issue I had 😅 so thank you a second time.

Greetings regards

p_dieng