I'm trying to synchronize a set of signals including two analog outputs to a counter signal. This is using X-series PXIe-6356 DAQ cards. This counter signal is in turn gated by another counter signal. This would be an example of what the TTL (or LV-TTL) output looks like:
The red line is the gate signal (ctr2), the blue line is the timing signal (ctr0) and reflects time-to-digital conversion (TDC) pulses measured on the rising edge. The gate signal is required to be low every 10 s by a third-party device to do ... something. In this plot, the period of the gate is 3x the TDC period, plus 25 ns so the last rising edge shows up, although in practice the TDC will probably be ~1 MHz and the gate about 0.1 Hz. What I want to do, is also send out a two analog outputs (ai0:1) that change with each blue TDC rising edge. Importantly, the analog outputs are not repeated every gate pulse, I need to provide the entire analog output sequence, one for each TDC. In the below script I am just using random numbers to illustrate the requirements. This 6356 card has two simultaneous AOs.
Here's my simplified script (Python using the`nidaqmx` package):
Here's the routing table:
My main question is, what are valid ids for the `source` argument in `cfg_samp_clk_timing` (or `CfgSampClkTiming` in C parlance)? I've not been able to establish any acceptable strings for this input argument. I've taken a look at the ANSI C examples, which seem to be the most exhaustive, and there's no use cases of it for the analog outputs where the `sample` argument isn't the default sample clock. For the analog inputs, sometimes they specify by PFI, but if I try `dev1/PFI12` which corresponds to `ctr0` I get the same error as if I specify `dev1/Ctr0Source`:
Any thoughts? Using the latest DAQmx 2022 Q4 release.
Solved! Go to Solution.
This is a subtle one. The correct string to designate a terminal needs to start with a forward slash '/' character.
So "/dev1/PFI12" would be the correct designation.
I don't know enough Python to comment on any other details, but can confirm that what you describe *wanting* to do is in fact do-able with your device.
Hi Kevin, thanks for your help, it's running without errors at least now. Now I have to connect the Picoscope and see if it's doing what I think it's doing...