analog voltage generation with NI 9188 & NI 9263

[newbieeng]

Hi all. I need to embed a control system on my test set-up. All I need is to generate analog voltage from two channels of NI 9263 and synchronize it hardware timing of the NI 9188 chassis wich is used by NI 9214 thermocouple module for data acquisition. But I could not do that. All samples associated with analog voltage generation covers waveform signals, however, all I need is to generate constant analog voltage signals. How could I do that? And also I cannot generate analog signal from 1 channel of this device, it pops up  a buffer error says that your buffer is too small at least 2 samples are required in buffer something like that...

[REDS · Accepted solution]

Hello Egemen,

If you are doing a temperature control system, then I would recommend you use the Producer / Consumer Architecture, so you can acquire the temperature samples in the producer loop and have your control algorithm and voltage generation on your consumer loop. This way you won’t compromise your acquisition time with the time it takes for the algorithm to process the acquired data. On the example below, just replace the write to binary files functions with the control algorithm and DAQmx VIs for voltage generation. For the latter, you could use the example “Voltage - On Demand Output” below.

Using Producer/Consumer Architecture for DAQmx Read and Write to File

Because this is not a VI that’s going to process or aquire a lot of channels, you just might be OK acquiring, processing and generating in a single while loop. However, if you run into lags or buffer overwrite errors, I recommend the Producer / Consumer solution.

For the buffer error, you want to consider using the “DAQmx Configure Output Buffer” VI and set the buffer size to 2 or greater. You could also use the DAQmx Buffer VI and set the property to Ouput.BufSize. That being said, if you are doing a control system, you don’t know what the value you want to generate ahead of time is. It’s going to depend on your set point, process variable and of course, your control algorithm. Because of this, you shouldn’t be using hardware-timed (buffered) generation as the software is going to decide what the next value is. With hardware-timed generation, you supply the DAQ card with the array of values it will generate before it generates them.

As a note: I don’t know how much of an embedded solution a cDAQ 9188 will be, as it doesn’t run a Real-Time OS nor it’s stand-alone.

[newbieeng]

Hi Daniel,

I use master/slave structure with notifiers. Actually, it is really similar with prodcuer/consumer structure. The main reason that I want to use hardware time is to provide accuracy. But I realized that generation of analog output is too complicated via using hardware time. Anyway, I changed the the vi to utilize software time. It works good for now. Thank you for your suggestions. I have never thought about the relation between software time and control algortihm as you explained. It is a really good point. I wrote it to my mind.

By the way, as far as I remembered, cDAQ 9188 has not a real time OS in it, but it has three independent hardware clocks.

[REDS]

Hi Egemen,

I'm glad that I could help you. And you are correct, the cDAQ 9188 does have three independent analog input timing engines. So you are able to sample at three different sampling rates from different cards but within the same chassis. The chassis doesn't run an RTOS like you mentioned.