data acquisition..........reading input with execution highlighting

[raj_iastate]

Hi all,

I am trying to read an input from device after generating voltage, and I am confused about the difference in results when

1. I am using execution highlight

2. without execution highlight

3. when the start vi is in front of generate vi instead of after vi. Also can someone explain why ?

[raj_iastate]

I forgot to mention that when the start vi is before write vi .

I get following error...........can someone explain why. ?

[John_P1]

Your output and input task are in parallel threads and you are not using any triggering to ensure that they start together.

In case 1, it looks like you're just picking up noise.  Highlight execution makes software run really slowly--based on your results there must be at least one second between the starting of the input and output task.

In case 2, the tasks will start much more closely together--although it looks like the output task starts ~5-10 ms after the input task based off of the graph.

You didn't mention your devices (I notice you are using two different DAQ cards), but most NI DAQ devices support a hardware start trigger for analog inputs and outputs.  You'll want to do something more like this to ensure the tasks are synchronized:

Since the output and input are on separate devices, you'll need to export the start trigger to a PFI line, then physically wire it to a specified PFI line on the other device (or if the devices are connectec via RTSI cable or the devices are in a PXI chassis you can use implicit or explicit routing and connect the trigger signal through the RTSI cable/PXI backplane).

Best Regards,

[John_P1]

As to the error in your second post, you can't start a task when it is already started.

Best Regards,

[raj_iastate]

Thanks for the explanation, it all making sense now. I am trying to understand the functioning behind write/read vi. Can you please explain the difference between having the start vi before or after the write vi ?

[raj_iastate]

I modified the code according to your suggestion with some changes...........I am using two devices

dev 1 : PXIe 6361

dev 2 : PXIe 6221

I see that I am reading all the samples, but just for my knowledge I want to know how does the read vi make sure that it read all the samples generated without missing any samples ? is there a way to double check that ?

[John_P1]

response to first post:

On a clocked output task, writing the data first will allocate a buffer in kernel memory.  The device pulls samples from this memory into a hardware buffer and outputs one sample on each clock edge.  You need to write first so data is pre-allocated in the buffer in time for the start of the task.

If you start the task without writing data, no buffer would be allocated.  This is what you want to do if you are just writing a single sample to the output from software (i.e. you don't have any timing configured or you have configured hardware-timed single point mode).  DAQmx does allow you to write an array of data to a non-buffered task (strangely enough), but I think this is a legacy behavior that has since been replaced by hardware-timed single point mode--I can't think of a valid reason to program a task this way.

resposne to second post:

Since they're PXIe devices you can synchronize them this way since they are able to route timing/triggering signals across the backplane.

The read call will always read the specified number of samples (250000 in your case).  The first sample occurs on the first sample clock edge after the start trigger is received (with the internally generated sample clock, the start trigger also starts generating the sample clock).  The start trigger is generated when the AO task is started.  The tasks are starting synchronously in this case, so for just looking at the graph and validating that you have output a sine wave for 1 second this is probably all you would need.

However, if you really wanted to synchronize the tasks, you would need to share a sample clock or timebase between the two devices.  Right now, each device is generating its own sample clock from its on-board oscillator and these will drift from each other over time (in fact, the 6221 uses 20 MHz by default whereas the 6361 uses 100 MHz by default--this would pose a problem if you wanted a sample rate that can't be achieved by dividing down 20 MHz).

If you're looking to measure stimulus-response on a sample-by-sample basis, you'll probably also want to include a delay between the output and the input in order to account for the settling time of the analog output (there are a few different ways to go about doing this).  That is, when you clock out a new value to the analog output, it takes a finite amount of time for it to reach that value and settle (check the specifications of your device).

So if sharing a sample clock, you can make the claim that each sample of AI corresponds to each sample of AO and be confident that no samples are missed.  Without a shared sample clock however, there isn't a guarantee (50 ppm of timebase error would be 50 us of offset for a 1 second generation, which in your case would be about 12 samples at 250 kHz).

Best Regards,

[raj_iastate]

thanks for clear explanation !!!

1. If I would share the sample clocks then I would have to keep the sampling rate same on both devices. My requirement is that I want to generate at highest sampling rate which is 2M samles/s for 6361 and 250k samples/s for 6221. Is there a way to achieve this ?

2. And what is purpose of starting the read task before the write task  in sequence structure ?

[John_P1]

1.  You can share a sample clock timebase (which gets divided down to generate the sample clock) or reference clock (which goes through a PLL circuit and aligns the DAQ's oscillator to itself) instead.  

Reference clock probably makes more sense since the devices are in the same chassis and have access to a common reference clock source.  Just use the 100 MHz backplane clock for your X Series reference clock, and the 10 MHz backplane clock for your M Series reference clock.  These clocks will be phase-aligned (well not quite--but at least they don't drift relative to each other) so even though they are different frequencies this will achieve what you wanted to).  You can set the reference clock source with a DAQmx Timing Property Node.

One thing about using a reference clock is that if you have any other tasks using a derived clock on your devices they must be configured to use the same reference clock source.

2.  In order for the task to be triggered by an external source, it must first be started by software.  So, you start the read task first which arms the task.  Then start the write task which issues its start trigger signal.  If you started the write task first the read task wouldn't be armed and would not receive the trigger signal.

Basically, you start whichever task is issuing the trigger signal last, so that the other task(s) will be armed and ready to receive the trigger when it is issued.  You could have configured the output task to be triggered by the input task's start trigger if you wanted to, in which case you would start the tasks in the opposite order.

Best Regards,

[raj_iastate]

I made the above changes and I am a little confused about what to connect at RefClk.Src terminal ? Please let me know.