Sending an arbitrary analog signal acquired using NI9205 to an analog output device (NI9264)

[Vhha1972]

Hi All,

I am using LabVIEW 2018.

I am apparently trying to accomplish a simple task but not with much success.

I want to acquire one analog voltage signal via the cDAQ9191 module using NI9205 (Analog Input). I then want to output the above signal via another cDAQ9191 module using NI9264 (Analog Output).

Please see attached image. The first part seems to work. I use a function generator to feed a sine wave into one channel of NI9205. Then I can display the same in LabVIEW.

However, how do I send this acquired analog data (sine wave) to NI9264 so that the NI9264 can output this data as an analog output (AO)? I do what is shown in diagram but when I put an oscilloscope at the desired output port on the NI9264, I do not quite get what I send to NI9205 via the function generator.

On NI9264 DAQ Assistant, I am using “continuous samples”. I have tried “N samples” and “samples on demand” too but in vain (I get errors like “cannot keep up”, “not all channels are configured/assigned”, etc.).

Any help would be greatly appreciated - thanks!

[JÞB · Accepted solution]

First off we need to see some code.  A picture of some Express vis just won't do.  We have no idea how you have configured them!

Then get rid of the express.vis and use the DAQmx API. They are much more performant!  Use the DAQmx Wizard to prototype your Tasks, then, just right click the task constant and Generate code.

Look into the example finder.  There will be a continuous Acquisition and Generation example.

Post back if you have questions about what you learn from the experience. 

[Vhha1972]

Thanks for your message Jay!

I tried what you suggested. Still confused. Attached are 2 VIs in Daqmx format (not sure why a 2nd one was created?). It seems voltage data from AI module is not being transferred to AO module for outputting it.

Saif

[JÞB]

---

@Vhha1972 wrote:

Thanks for your message Jay!

I tried what you suggested. Still confused. Attached are 2 VIs in Daqmx format (not sure why a 2nd one was created?). It seems voltage data from AI module is not being transferred to AO module for outputting it.

Saif

---

Not sure why a second vi was created myself 

But you could replace the vi contents on your new BD.   Then my phone might let me know how to help you 

[Vhha1972]

Hi Jay!

I included everything in single VI now. Attached.

Saif

[Vhha1972 · Accepted solution]

Hi Jay,

Update on my side is that things have slightly improved....

I used the "generate Daqmx code" functionality to generate and create a code that can actually output at NI9264 the data being read in at NI9205. There are only 2 issues:

1. In the code generation process, the system created a SUB VI which I called "WDT". I cannot seem to get rid of this (its part of the code that actually works for a few seconds; see 2).

2. The code works slow (AI plot is shaky) and then after few seconds I get error 200279: "The application is not able to keep up with the hardware acquisition". Until the application does not crash, I can actually see the AI waveform read at NI9205 at AO of NI9264 with an oscilloscope. 

So, actually the attached code works but with error 200279.

Saif

[JÞB]

That seems to be a buffer overflow or underflow error.

<Still posting via phone >

I would expect that would happen if the loop cannot sync.  You really have two timing issues crossing 

1 the 10hz acquisition 

2 the preload of the generation 

I think that autostart is not what you want. 

[Vhha1972]

At 50 samples and 250 Hz, this VI works ok (does not crash). The other issue is about synchronization between the actual waveform and the generated waveform -- there is random phase shift between them when the VI runs (they lag and lead each other arbitrarily). However, this is enough for my purposes at the moment. So, I will close the thread.

Thank you so much Jay!

S 

[Kevin_Price]

So, it appears you're using 2 distinct single-slot WIFI chassis.  That makes it unsurprising that the amount of lag from AI to AO would be variable.  It's not really possible to make it 0, and it may not even be possible to make it consistent unless those chassis offer a method to share a hardware timing signal.

In general, you're going to get more robust behavior with less likelihood of task errors as you take the following advice, which will also tend to *increase* the lag (commonly referred to as "latency"):

    Read & write larger chunks of data per loop iteration while iterating more slowly.

You may also want to learn about the "producer consumer" pattern that would let you have distinct parallel loops for AI and AO.

-Kevin P