06-06-2012 05:43 PM
hi MrO,
I began buidling this VI as you describe, so I know it works with the "Multi-Device Synch-Analog Input Acq-Ext Dig Start.vi" example (that's why I started adapting it). I have checked the signal is suitable by collecting it independent of the trigger - it is a sharp falling edge from 5 to 0V.
Thanks,
Claire
06-06-2012 09:27 PM
Hi Claire,
It is generally recommended that you create all your virtual channels before configuring parameters such as timing and triggering. However, this is not required and having the code the way you have it should be fine.
The reason why using PXI1Slot2/ai0 is not working is because you are naming that virtual channel "V1" at the DAQmx Create Virtual Channel VI. Either remove this constant on the block diagram so that the name of the task defaults to the physical channel name ("PXI1Slot2/ai0") or change the analog trigger source control on the front panel to simply "V1". If this doesn't work, please respond with a screenshot of the error message.
More info about the "name to assign" input terminal can be found in the LabVIEW Help file. In the block diagram, press Ctrl+H to open the context help window. Then, hover your cursor over the DAQmx Create Virtual Channel VI for a couple seconds. The context help window should update. Click "Detailed Help" in the context help window and it will open another window with detailed information about the VI and its input terminals. Context help and the LabVIEW Help are valuable resources, so I'd keep those in mind when developing applications if you have questions.
Also, what hardware are you using? Based on the programming and task configuration I've infered that "PXI1Slot2" is a PXIe-6361 module, and "PXI1Slot4" is a PXIe-4330 module, correct?
Hopefully this helps,
Chris G
06-07-2012 12:52 AM
Hi Chris,
Fantastic!!! thanks so much. Such a small thing, with such large consequences. I didn't understand the implications of naming a task (and to be honest had completely forgotten that I had named it at all).
We are now tackling getting a few seconds of data pre-trigger, so I'm sure I'll be back with some more questions soon.
Thanks for your patience over the last few days.
Cheers,
Claire.
06-07-2012 02:25 AM
Hi Chris,
Now that we have the trigger working, it's evident that the signals from the different devices are not synchronised. I had expected that the master-slave synchronisation section would have sorted this out, but apparently not. I've been doing a little reading on the NI website to try and understand how we can fix this. It seems that using Skew synchronisation (and forfeiting some latency) might be the way to go. But, regardless, I wasn't expecting such a large delay (10ms between the first two channels and 250ms between the first and third channel, see the attached screenshot) between the channels. Can you recommend a way to move forward? Is there something wrong with the way I'm implementing the Master-Slave, or is my only option to use Skew Synch (we'd prefer not to have a delay as we are collecting data on other computers also)?
Thanks for your continued help.
Claire
06-07-2012 05:53 PM
Hi Claire,
Interesting. You should be getting much better synchronization than that. And using reference clock synchronization with the X series DAQ card as the master start trigger should work fine. How are you actually measuring this synchronization delay between channels (i.e. where did the 10 ms and 250 ms numbers come from)? The reason I ask is it can sometimes appear that data is not synchronized because the X scale on the different waveform graphs is set slightly different, when in fact the data is synchronized.
Try changing the interpolation for the plots on the waveform graph to only show the data points and not lines between the points. Then, zoom in close (really close) to those data points to see the phase difference between the different points on the graph (probably your middle graph since you have multiple measurements on this graph).
I'm curious, do you see this same latency when you run the original example by itself, or a similar multi-device synch example? Also, are you using the PXIe-6361 and the PXIe-4330?
Chris G
06-07-2012 07:11 PM
Hi Chris,
The delay is between the different devices, rather than within one device. I've attached a screenshot of the output plots with individual dots without connecting lines. I have lined up the very first data point with the y-axis (i.e. x=0). From what I can tell, the four data lines on the centre plot have only a very slight (insignificant) delay between them. But, there is a >200ms delay between the centre plot and the other two plots.
I changed my data output to collect a timestamp for every channel in the waveform, and I have attached the CSV file here. On the first line, I can see that the first 5 columns all collected their first data point between 08.689289 and 08.689333 (corresponding to the central plot), the 6th col 08.433274 (bottom plot) and the 7th-8th columns at 08.437275 and 08.437275 (top plot).
Yes, I am using a PXIe-6361 (with BNC2120) and a PXIe-4330 (with TB-4330).
I have collected data from the two devices using the "Multi-Device Synch -Analog Input Cont Acquisition" example VI (which doesn't have a trigger). I will attach the screenshot of the graphs and the output data (exported from the plots) to the next message as I don't appear to be allow more than 3 attachments here.
Thanks,
Claire.
06-07-2012 07:12 PM
Please see shipping example data and screen shot attached here (as per previous post).
06-08-2012 11:08 AM
I think I see the problem - the example, when you select "X series (PXIe), SC Express", tries to do master/slave synch. That only works for non DSA-like devices. To synchronize the 433x devices to X-series devices, you must use the 433x sample clock as the sample clock of the X-series device, and share the same start trigger. It looks like you are sharing the start trigger already, so just set the sample clock source to (433xDevice)/aiSampleClock on the X-series task.
The reason for this is that DSA devices (including the 433x bridge devices) have group delay due to the filters on them. You can see what the delay is for different sample rates in the 433x manual, but fortunately the device performs group delay compensation on the exported sample clock for you, automatically. See http://www.ni.com/white-paper/11369/en#toc5 for details about this, look under the "Digital Filter Group Delay" section. When you set the X-series to use the 433x sample clock, the x-series will end up delaying it's sampling to match the 433x group delay.
06-08-2012 09:15 PM
Hi Nathan,
Thanks for your input and for trolling the manuals for information.
I have tried setting the clock to ai/SampleClock of the PXIe4331 (with RefClk.Rate=100000000), but get the following error:
Error -89136 occured at DAQmx Start Task.vi 1
Possible reasons: specified route cannot be satisfied because the hardware does not support it.
Property: RefClk.Src
Source Device: PXI1Slot4
Source Terminal: ai/SampleClock
I get the same error if I change the RefClk.Src to the PXIe4331 10MHzRefClock (changing the RefClk.Rate to 10000000).
Do you think I need to change the 4331 to be the Master (and the 6361 to the slave) also?
Thanks,
Claire.
06-11-2012 08:57 AM
You should wire ai/SampleClock of the PXIe-4331 to the DAQmx Timing - sample clock VI's source terminal, rather than ref clock source. Sorry for the confusion!
Ref Clocks are used for ref clock synchronization, usually between M or X series devices. You don't need to set it when you share a sample clock like for 4331 to X-series synchronization. I would not set the sync type property on either device at all, master/slave is really only used for ref clock synchronization on X-series and non-DSA SC Express devices.