How to combine (DAQmx AI and AO with non-regeneration) with a (Producer-Consumer)?

[Byeong-uk]

HI, I am stuggling with it. 

I want the "DAQmx AI and AO with non-regeneration" in real-time with no delays in the loop. 

When I was using a hardware timed single point working PCI devices, there was no problem. 

Now I am using USB-6363, and I should configure a buffered task to do all the stuffs in hardware-timing. 

After searching and practicing, I've made a vi to update an output buffer with a function, while reading it with the buffered analog input task. 

I've heard that the Producer-Consumer is appropriate for the job that I want to do. However, there is no any single example or tutorial or an Youtube lesson that deals with actual DAQmx tasks working on a real hardware. 

Could you please give any recommendation to my vi and relevant idea? I guess some skilled users might have the program. Could you please open it here? Or should I pay for it to learn how to program?

Looking forward to your help

[Bob_Schor]

Unfortunately, you are using the Most Recent version of LabVIEW (LabVIEW 2022 Q3), and many (most?) experienced LabVIEW developers "delay in installing the Latest Version" as it throws their code "out of compliance" with their colleagues running earlier versions.

Please open your LabVIEW Project, and select "Save for Previous Version" in the File menu.  I recommend you choose LabVIEW 2019 to allow most of the more experienced participants in this Forum to be able to open your code.  Not that I'm such an expert, but I only recently (3-4 months) installed LabVIEW 2021, and have no plans to install LabVIEW 2022 in the near future ...

Bob Schor

[Byeong-uk]

Dear Bob Schor,

Thank you for the reply.

I attached the programs saved for LV2019.

The Queue control sample is downloaded from an article in this forum. 

I wonder if an interrupt-like structure can be configured using the queue structure. 

Please review these if you mind. 

[Kevin_Price]

I looked the code over a little bit and have some comments and some further questions.

Comments on "MyProgram.vi":

• Tidying your diagram will be helpful.  As a start, make sure that either the task wire or the error wire that works through all the DAQmx functions follows a straight horizontal line.  (The mix of regular functions and property nodes prevents you from doing this with both at once.)
• You're setting more DAQmx properties than you probably need to, but I understand that you're still experimenting.  Just be aware that you won't usually need to configure most of those things explicitly.  Not allowing AO regeneration may be the only one that you *need* to configure.
• Your choice of sample rate (12800) and # samples to read per loop iteration (128) imply a 100 Hz reading loop rate.  A more typical rule of thumb is to aim for a 10 Hz reading loop rate by reading & writing 1280 samples per iteration
• There's no sign of a producer/consumer pattern in this vi, and it's unclear to me whether you should want one.

Question:

Can you give more detail about *exactly* what you want when you say:

I want the "DAQmx AI and AO with non-regeneration" in real-time with no delays in the loop

    With USB and hardware clocking, there *will* be inevitable delays between real life and your program.  Most of it will relate to the required use of buffers for tasks with hardware clocking on USB devices.  There will be a delay from the time a real-life signal changes until your program becomes aware of it via DAQmx Read.   And there will also be a delay from the time your program writes new data via DAQmx Write until that data becomes a real-life signal.

    So it's important to understand exactly what you mean by "real-time" and "no delays".  It might be impossible with your device and approach.  Or you might be really close already.  I can't tell without a much more complete description of what you want to accomplish with your app, and the specifications for what you consider "real-time" and "no delays".

-Kevin P

[Byeong-uk]

Dear Kevin Price,

Thanks for your invaluable reply. I just changed the measurement system to PCIe cards to use hardware time single point sampling. 

One conclusion is that usb devices are only applicable to loop rates less than 100 Hz with software timed operations. 

Second, for example, to achieve higher loop rate with fully available HW R/W while software computing, the only option from NI devices is the PCIe-type boards that supports HW-timed sampling. 

[Byeong-uk]

Dear Kevin Price,

Hi, I just came up to this problem again.. as I would need to output signals at a much faster rates. 

I configured the producer loop with analog input, and the consumer loop with the analog output. 

The output signal in the attached vi is a simple waveform, and the frequency and amplitude are determined in the producer loop, 

which is then delivered to the consumer loop. 

I tested it using my h/w PCIe 6374 for analog input, and cDAQ 9269 for the analog output.

The waveform is successfully generated, and the analog input measures data in real-time as well. 

However, the problem is that the analog write sub vi doesn't do anything, and the number of samples actually generated is always zero. 

Could you please give me a comment on this?

[ZYOng · Accepted solution]

PCIe-6374 cannot share the sample clock and trigger with cDAQ without external wiring. You configured cDAQ as the slave for synchronization. It will never start running.

If you really want to synchronize 6374 and 9269, you need to connect the trigger signal physically via external wiring.

1. The simplest approach would be sharing the same sample clock via a single PFI, but both AI and AO will have the same rate.
2. If you want AI and AO tasks to have different rates, you need to wire the 10MHz reference clock. And export the start trigger via another PFI line.

Your code would work if both AI and AO channels are on the same device or chassis.

[Byeong-uk]

Dear ZYOng,

Hi, thank you for your comment.

I moved the analog input task on the cDAQ 9223 module on the same chassis. 

Both are configured with continous generation, but with different sample rate and number of samples. The producer loop rate is running at 2,000 Hz, and the consumer generates waveforms at 50,000 Hz, while the waveform can be updated by producer loop at 2,000 Hz. 

Please comment if you have any suggesstions to further improve the present methods.. 

I've also tried the PFI connecting method, where the PCIe6374 is configured to do Hardware time single point task. 

But the cDAQ analog output of the consumer loop runs at the same rate with the producer loop, which does not output the samples.  

Anyway, I would go with the single cDAQ, for I need to use some more modules on the chassis.. Thank you!

[ZYOng]

You are trying to do the Non-Regeneration AO streaming with cDAQ at 50kHz. I am afraid that cDAQ is not capable of doing that.

NI cDAQ-9174 Specifications states that it only supports 127 samples per slot for non-regeneration FIFO.

To output at 20kHz, you need to write the data at a minimum 400Hz (50000/127) to prevent buffer underflow. USB communication typically takes 10 to 100 ms hence cDAQ cannot keep up with the streaming speed.

I think it is better to run both AI and AO on PCIe-6374

[Byeong-uk]

Well, I followed your comment and reviewed my code. 

It actually was not regenerating anything in the analog output. 

The waveform is generated by the initial queue data if presented, and the updating of the queue from the producer is not handled by the consumer. 

Actually, I have been using the PCIe boards to generate the non-periodic samples at the AO. 

However, since the updating of the single sample is again limited by the loop sampling rate which is around 2kHz, 

it generates a 2kHz audible "beeping sound" on the signal receiver (an actuator)..

My purpose was to build a function generator that runs much faster than the audible frequency range (above 20kHz) using an AO module, and update its amplitude, phase, or frequency at a different rate around 2kHz.    

Then, I guess the AO on the cDAQ cannot achive buffer updating rates above 127 samples/slot, even if I might configure the method you've mentioned above where the AO is configured by external 10MHz clock. Hence, any buffered AO non-regenerating task wiill always blocked by the **bleep**ing USB latency. 

Is there a way that can I directly handle the "Onboard" program so that I can directly shoot my signal into the module??

Why is NI making the devices in this way?