Write Digital Out on 6133 board using RT

[solitude]

The data points range from 0 to 4095, where 2048 represents 0 volts.  I'm using the RAW 1D U16 for the DAQmx Write VI and it appears to work.  I can see a waveform on the scope.

I have a couple of other questions. 

1.  Is DMA being used in the data transfer for the DAQmx Write VI? 

2.  If I try to send two waveforms out to two separate analog out channels, the scope only sees the first channel (a0).  I notice that the "number of samples written per channel" for the first waveform is 80000 (a0), and 0 (a1) for the second channel.  Any ideas?

solitude

[Brian F.]

Hello. 

The best way to tell what type of transfer method is being used, is to use the DAQmx Channel Property Node, which is located on the Functions Palette » DAQ - Data Acquisition palette. Left click and select Properties » Analog Output » General Properties » Advanced » Data Transfer and Memory » Data Transfer Mechanism.

In terms of your second question, what is the text below the DAQmx write that you are using.  This indicates the polymorphic instance of the VI.  Please make sure this is configured for Multiple Channel output.  Possibly posting your code would be helpful in this case, which would allow our members to find the answer in the most efficient way possible.

Brian F
Applications Engineer
National Instruments

[solitude]

I have attached two VIs for viewing purposes.  The first VI is the setup for outputting a waveform, and the second VI is outputting the waveform.

I'm currently working on the sample rate for the 6713.  If I setup the sample rate at 100 kHz, the 6713 board outputs the waveform.  If I increase the sample rate to 200 kHz, the 6713 board does not output a waveform.  I would like to increase the sample rate to 700 kHz, which is close to the maximum sample rate for outputting data on all 8 channels, but I'm unable to do so.  What could be the limiting factors?

solitude

[solitude]

What is the correlation between the "samples per channel" input of the DAQmx Timing.vi, the "data" input of the DAQmx Write.vi, and the "number of samples written per channel" output of the DAQmx Write.vi?

What happens when the number of samples per channel in the "data" input of the DAQmx Write.vi (such as a small array) is less than the "samples per channel" input of the DAQmx Timing.vi?

There seems to be a direct correlation between the number of samples per channel in the "data" input of the DAQmx Write.vi and the "number of samples written per channel" output of the DAQmx Write.vi?  Whenever I change the number of samples per channel in the "data" input of the DAQmx Write.vi (change the size of the array), the "number of samples written per channel" output of the DAQmx Write.vi always matches it.  However, only a portion of the samples are outputted by the 6713 on any one channel as viewed on a scope.

I placed the DAQmx Write.vi after the DAQmx Trigger.vi and DAQmx Start.vi in my "target - 6713 - transfer and trigger.vi", just as a test.  I also increased the sample rate from 100 kHz to 500 kHz.  I was able to observe the waveforms on the scope.  I don't why the 500 kHz sample rate works with this type of an arrangement.  However, it appears that the sample rate is not exactly 500 kHz, but rather something like 450 kHz, and the larger waveforms get truncated.

Anyway, thanks for your patience.  I'm just trying to grasp the capibility of the 6713, and also understand the DAQmx VIs and use them properly.

solitude

[Kenn_N]

Hey Solitude,

The Samples per channel on the timing vi in conjuction with the sample rate are used to determine buffer size.  Whereas the number of samples written per channel on the Write.vi is just how many samples written to the created buffer.  So if the number of samples written per channel is smaller than the samples per channel on the timing it shouldn't be a problem.

You didn't post all of your vis so I get errors about missing vis, but using a trigger and explicitly starting each task can be a more effective way to use the hardware.  Doing so is controlling the state of the driver in a more explicit way.  The driver is basically a state machine that moves from one state to another on it's own, but if you control the transition you can gain better performance on occasion.

Regards,