Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

some questions about AQmxCfgSampClkTiming

Hello,

I use AQmxCfgSampClkTiming to set Collection frequency in two channels,but sometimes they are out of sync.

I read the " https://forums.ni.com/t5/Multifunction-DAQ/NI-DAQmx-C-API-Controller-seems-to-set-the-wrong-sampling...  "And so, the sampling rates that are actually available to you must be based on dividing the master timebase by an integer.",  my AcquisitionCard is PCIE-6376 ,I see the Frequency Generator in specification,

Number of channels

1

Base clocks

20 MHz, 10 MHz, 100 kHz

Divisors

1 to 16

Base clock accuracy

50 ppm

How can I use these paramters to make the  two channels in sync? 

And the result of  DAQmxGetSampClkTimebaseDiv is 100M,what‘s the use of this parameter?

0 Kudos
Message 1 of 10
(1,592 Views)

It's unlikely you'll need to use the frequency generator you referenced.  It's a bit of a special purpose clock with limited options.  "Regular" options are better until/unless you've used up all your other resources.

 

What device(s) are you using?  What kind of signals are you capturing?

 

I generally advocate sync via shared sample clock alone whenever feasible.  For two tasks on the same device at different sample rates, then I'd suggest sync via shared start trigger.  Two tasks on different devices at different sample rates may need both (but not necessarily.  On cDAQ and PXI you still may only need the shared trigger because, well, reasons...)

 

For sample clock sharing, designate one task as your "boss" and the other as the subordinate.  The subordinate is configured to use the boss' sample clock as its own, *and* must be started first (before the boss task is emitting any sample clock signals).   Then the boss task is started last and both stay sync'ed by sharing a common hardware sample clock signal.

 

 

-Kevin P

ALERT! LabVIEW's subscription-only policy coming to an end (finally!). Permanent license pricing remains WIP. Tread carefully.
0 Kudos
Message 2 of 10
(1,580 Views)

If you are using multiple AI channels, you can simply use channel expansion to synchronize them.

Easily Synchronize and Trigger NI-DAQmx with Channel Expansion

 

If synchronizing AI and AO, route the start trigger. See shipping example in C:\Users\Public\Documents\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Synchronization\Multi-Function\Synch AI-AO

-------------------------------------------------------
Control Lead | Intelline Inc
Message 3 of 10
(1,574 Views)

In my program.the two channels (one ao and one ai )start at the same time, and I use AQmxCfgSampClkTiming set the same rate. sometimes they are in sync,sometimes one of them run slower.I think it dues to the rate I set is illegal.because I saw these words in another post“And so, the sampling rates that are actually available to you must be based on dividing the master timebase by an integer.  (There can be further restrictions that only *certain* integer divisors are allowed, but it'll always be restricted to integers.)”.And I found if the two channels is in sync depends on if the result of DAQmxGetSampClkTimebaseRate is same.I want to set a legal rate to check, what should I do?

0 Kudos
Message 4 of 10
(1,557 Views)

If you are using multiple tasks on a single device, you don't have to specify the source of the sample clock. Just leave it blank and use the default onboard clock. The AI and AO clocks all PLL-ed to the same source of the onboard 80 MHz oscillator. See Clocks

 

The reason why the AI and AO are not sync-ed is most likely that they are not started at the same time. You simply refer to the shipping example and route the ai/StartTrigger to AO, (or ao/StartTrigger) to AI. The DAQmx driver will handle the rest for you.

-------------------------------------------------------
Control Lead | Intelline Inc
0 Kudos
Message 5 of 10
(1,548 Views)

I read the SynchAI-AO.c.But the DAQmxCfgDigEdgeStartTrig seems not effective,the result of GetTerminalNameWithDevPrefix is always same no matter what I set.the ao channel get "/Dev1/ao/StartTrigger",the ai channel get "/Dev1/ai/StartTrigger".

I think I have the same question with " https://forums.ni.com/t5/Multifunction-DAQ/NI-DAQmx-C-API-Controller-seems-to-set-the-wrong-sampling...   ", the result of DAQmxGetSampClkRate is different in ai and ao.

 

the ai and ao  set same ClkTiming.

DAQmxCfgSampClkTiming(m_taskHandle, "OnboardClock", A, DAQmx_Val_Rising,DAQmx_Val_FiniteSamps, B);//Parameters A and B need to be changed frequently.

DAQmxCfgDigEdgeStartTrig(m_taskHandle, "/Dev1/PFI0", DAQmx_Val_Rising);


Thank you.

0 Kudos
Message 6 of 10
(1,541 Views)

In the testing, I found some new situations where even by adjusting the rate to make the DAQmxGetSampClkTimebaseRate of ai and ao the same, they may still be out of sync,data of ai lags behind AO after multiple calls to DAQmxReadAnalogF64. For example,when ao outputs 100 data, ai only collects 99 data, and then 200/198...300/297.... How can I solve it?

0 Kudos
Message 7 of 10
(1,488 Views)

GetTerminalNameWithDevPrefix is always same no matter what I set.the ao channel get "/Dev1/ao/StartTrigger",the ai channel get "/Dev1/ai/StartTrigger".

This is expected. The purpose of that function is to return <DeviceName> + ai/StartTrigger for AI task or ao/StartTrigger for AO task.

 

I think I have the same question with " https://forums.ni.com/t5/Multifunction-DAQ/NI-DAQmx-C-API-Controller-seems-to-set-the-wrong-sampling...   ", 

In that case, he is using two modules with different ADC types (DSA and Delta-Sigma). 

 

the result of DAQmxGetSampClkRate is different in ai and ao.

What are the sampling rate values configured for both tasks in your case? The shipping example configures 10k for AI and 5k for AO. DAQmxGetSampClkRate should return the same value for the A value you input in the DAQmxCfgSampClkTiming.

 

data of ai lags behind AO after multiple calls to DAQmxReadAnalogF64. For example,when ao outputs 100 data, ai only collects 99 data, and then 200/198...300/297.... How can I solve it?

They appeared to be lagging from the buffer of the PC point of view only. You need to understand that the data returned by DAQmxReadAnalogF64 function is not the real-time data from the ADC but transferred to the onboard FIFO then the host PC buffer. See Understanding and Avoiding NI-DAQmx Overwrite and Overflow Errors to understand how the data is being transferred. You can't rely on the number of data points sent or read as the indicator of synchronization. Instead, you can connect the AI and AO, then send a square wave from the AO to the AI. If the offset of the waveform on both AI and AO are the same, they are in sync.

-------------------------------------------------------
Control Lead | Intelline Inc
Message 8 of 10
(1,419 Views)

Sorry to bother you again, I have resolved some of the issues after ensuring that the frequency of AI and AO is the same. Please disregard my previous seventh message, which was my mistake.
I have encountered a new problem. I used the example in \Multi-Function\Synch AI-AO, but there is still a phase difference of 160us between ai and ao. I used DAQmxSetStartTrigDelay to eliminate this delay, but it still confuses me. Can you give me some suggestions?

0 Kudos
Message 9 of 10
(1,269 Views)

Sorry to bother you again, I have resolved some of the issues after ensuring that the frequency of AI and AO is the same. Please disregard my previous seventh message, which was my mistake.
I have encountered a new problem. I used the example in \Multi-Function\Synch AI-AO, but there is still a phase difference of 160us between ai and ao. I used DAQmxSetStartTrigDelay to eliminate this delay, but it still confuses me. Can you give me some suggestions?

0 Kudos
Message 10 of 10
(1,299 Views)