[DAQmx] Send multiple waveform to one device asynchronously

[Basjong53]

I have a PCI-6738 32-channel AO DAQmx board. I want to use this board to send a waveform of voltage to some channels. The important part is that it should be possible to start one waveform while another is still running.

Example: Send a sine wave for 10 seconds to /ao0/. After 4 seconds (so while the first is still being sent), send a different sine wave (same sample rate is fine) to /ao1/ and /ao2/ simultaneously. 

My idea for this was to simply create multiple tasks and create them at the moment that you want to send the waveform to the selected channel. However, the problem is that the DAQmx device is reported as reserved. I'd have to abort and start the entire device to apply a new waveform. This is not something I want since it'll affect the other channels that should still be running.

Is there a way to asynchronously send differently sized waveform to different channels without affecting other channels? I don't need any synchronization between tasks, although the tasks will contain multiple channels that have to send the waveform at the same time.

(If neccesary, I can provide a stripped down vi, it'll take some time to clean up the mess that I have in my test vi now 😅)

[GerdW]

Hi Basjong,

---

@Basjong53 wrote:

Example: Send a sine wave for 10 seconds to /ao0/. After 4 seconds (so while the first is still being sent), send a different sine wave (same sample rate is fine) to /ao1/ and /ao2/ simultaneously. 

---

Create one DAQmx task containing all 3 channels.

Have the waveform for AO0 start with sine data right from beginning, but set AO1/2 to zero for the first 4 seconds before starting their signal…

[Basjong53]

---

@GerdW  ha scritto:

Hi Basjong,

---

@Basjong53 wrote:

Example: Send a sine wave for 10 seconds to /ao0/. After 4 seconds (so while the first is still being sent), send a different sine wave (same sample rate is fine) to /ao1/ and /ao2/ simultaneously. 

---

Create one DAQmx task containing all 3 channels.

Have the waveform for AO0 start with sine data right from beginning, but set AO1/2 to zero for the first 4 seconds before starting their signal…

---

I should have been more specific to say that it's only an example. It should be possible to send additional waveforms at any time. A user should be able to send additional waveform to channels of their choice at any time. So it's not known beforehand when the waveform should start.

[GerdW]

Hi Basjong,

---

@Basjong53 wrote:

---

I should have been more specific to say that it's only an example. It should be possible to send additional waveforms at any time. A user should be able to send additional waveform to channels of their choice at any time. So it's not known beforehand when the waveform should start.

Then you just need to change my suggestion to "include all AO channels in the task and set waveform data as needed"…

This is what the UserManual says:

Analog OutputNI 6738/6739 have either 32 or 64 AOchannels that are controlled by a single clock and are capable of waveform generation.

As there is "a single clock" you need to place all channels into one task to have them hardware-timed based!

[Basjong53]

---

@GerdW  ha scritto:

Hi Basjong,

Then you just need to change my suggestion to "include all AO channels in the task and set waveform data as needed"…

---

But the problem is that if I have all channels in one task, and I want to send a waveform to one specific channel, I would have to provide the "Write DAQmx" vi with waveforms for all channels. SInce one channel is already running, I cannot modify this channel. This is why I wanted to use different tasks so that the channels don't affect each other.

---

@GerdW  ha scritto:

Hi Basjong,

This is what the UserManual says:

Analog OutputNI 6738/6739 have either 32 or 64 AOchannels that are controlled by a single clock and are capable of waveform generation.

As there is "a single clock" you need to place all channels into one task to have them hardware-timed based!

---

I cannot have multiple tasks which share the same clock?

[GerdW]

Hi Basjong,

---

@Basjong53 wrote:
But the problem is that if I have all channels in one task, and I want to send a waveform to one specific channel, I would have to provide the "Write DAQmx" vi with waveforms for all channels. SInce one channel is already running, I cannot modify this channel. This is why I wanted to use different tasks so that the channels don't affect each other.

You would place a wrapper around the DAQmxWrite call, which keeps track of all channels and only updates the data for the specific channel you want to change.

There are example VIs explaining how to update AO channels to output long running AO waveforms…

---

@Basjong53 wrote:
I cannot have multiple tasks which share the same clock?

---

This is how I understand it. And what you get by that "reserved resource" error message…

[Basjong53]

---

@GerdW  ha scritto:

Hi Basjong,

You would place a wrapper around the DAQmxWrite call, which keeps track of all channels and only updates the data for the specific channel you want to change.

There are example VIs explaining how to update AO channels to output long running AO waveforms…

---

---

I'm not exactly sure how I would keep track of all channels. Could you provide a link to some examples? I haven't been able to find the examples you mention.
Though one idea I have is to split the waveforms in chunks of say 1 second, and leave the DAQmxWrite in a loop that continously writes. This way I can update other channels after each chunk has been written.

---

@GerdW  ha scritto:

Hi Basjong,

---

@Basjong53 wrote:
I cannot have multiple tasks which share the same clock?

---

This is how I understand it. And what you get by that "reserved resource" error message…

---

I see, that's quite a big drawback. However, I would be able to use software timing then. I would have to check it out if the first suggestion doesn't work well.

[Kevin_Price]

Basjong,

Just a little forewarning: if you *also* want the physical output signals to update very soon after you decide to change a waveform, you're going to have some significant work & learning ahead of you.  Responsive, low-latency, variable output tasks are pretty demanding.

Carefully consider what your app really *needs* to do compared to what you *hope* it can do.  You can save yourself some considerable effort if you're willing to accept more latency.

-Kevin P

[Kevin_Price]

Just saw your latest message after I posted mine.

Software timing makes it much easier to get low latency, but basically impossible to create accurate dynamic waveforms (such as a sine wave).  You can create a signal that's kinda sorta usually pretty sine-wave-like, but only for relative low frequency sine waves (maybe 20 Hz or less?), and sample timing will still have unhelpful fluctuations.

Output control can be quite a bit trickier to manage well than input capture.

-Kevin P

[Basjong53]

---

@Kevin_Price  ha scritto:

Basjong,

Just a little forewarning: if you *also* want the physical output signals to update very soon after you decide to change a waveform, you're going to have some significant work & learning ahead of you.  Responsive, low-latency, variable output tasks are pretty demanding.

Carefully consider what your app really *needs* to do compared to what you *hope* it can do.  You can save yourself some considerable effort if you're willing to accept more latency.

-Kevin P

---

Low latency is not a concern. I just need the program to accept waveforms at different times. The user configures the waveform parameters, presses apply and within a reasonable time (let's say <1 second) should see that the program outputs it.