DAQ simulated indicator

[Mister_Rose]

I am working on an app and currently using a simulated NI-DAQ Analog output channel. Is there a control or tool somewhere that will let me see what the output is on the simulated channel. Something like a virtual oscilloscope to see the signal.

I'd like to see if there's any output errors, glitching or other artifacts going on.

[AdnanZ]

You should post a screen shot of your code; you could just use a waveform graph or a chart to see what kind of signal you are producing.

[Mister_Rose]

Here's the code. Use "GenerateCode.vi" to create a data file a few minutes long. Then use Miniplay2 to vplay it back. I used a simulated Analog output channel, soyou'll probably have to create one of those.

Basically, I am periodically writing chunks of data into the DAQ buffer. I could display the data in a graph, but I would rather see how the DAQ library is handling things. If I just display what is going into the DAQmx functions, I will not see any problems like glitching, etc. I could code up something that behaves like DAQ and updates a graph, but then I would have to debug that widget and hope that it functions like the simulated instrument.

I figured there would be a tool or indicator that would display what DAQ is sending out in realtime. Perhaps in MAX or something.

[AdnanZ]

I believe there isn't a way to view 'real-time data' using a simulated analog output channel.

[Mister_Rose]

Is there a way to get the current value being output by the DAQmx Write? I could read that and then send that to a Waveform chart for a pseudo-monitor. Otherwise I need to compute where the DAQ task is in its buffer, and I would need to maintain my own ring buffer and handle all the computations to figure out where the DAQ task is. It seems to me that it should be easy to expose these properties.

Perhaps there is a call to a DLL I can use?

[TCPlomp]

There is a property for the DAQmx Device class called 'Simulated?' that returns True if the device is simulated.

To detect which device you use, use the 'Devices' property on a task, this will return an array of devices. (However I don't know any task that can have multiple devices).

Ton

[Mister_Rose]

TonP,

The title of this thread is probably a bad one. What I am actually looking for is a way to display the current value at an analog output. Not an indicator for a property. If there was a property like "OutputValue" that returned a float with the last value that the DAQ system put on the wire, that would be great.

But I see there is no such property, and I am looking in the DAQmx DLL to see if there is a low-level function that might do this.

[DavidMN]

Hi Mister Rose,

It is not possible to see the output on a simulated channel.  While you can create a front panel display that shows the data output, it is still simulated data.  You can address the channel, but no real data is actually being output.

[Dennis_Knutson]

The functions in the C dll are the same as the functions available in LabVIEW, I believe. You may need to use the DDK and create your own driver. If you need this functionality, is it jsut while you are waiting for the actual DAQ board to arrive? If so, then creating your own driver would probably not make much sense. If this is a long term situation, it might be. You could also go to the Product Suggetion Center.

[Mister_Rose]

With the DDK, would I be able to add a function that can look into the buffer and get the value being sent to the DAC hardware?

What I am looking for is a GetValue function that will give me the float or boolean value of what is being output on the DAC hardware. This way I could hook that function to a graph or chart and display, with minimal error, what is being sent out on the wire.

Otherwise I need to code up a duplicate buffer and manage that buffer and perform some math based on the SpaceAvail property to determine which sample is being put on the wire. It is cumbersome and error-prone, and in the end it would only show what I think is being put out on the wire, not what DAQmx is actually sending.

BTW, I just posted this suggestion to the PSC.