Showing results for 
Search instead for 
Did you mean: 

none of ai, te0 & te1 clock source work except OnbordClock for cDAQ9174?

Go to solution

acquisition system used: cDAQ-9174, NI9206, Labview2009, NI-DAQmx 9.2, MAX 4.7.1

Refering to ''Specifying Different Sample Rates for Multiple CompactDAQ Modules'' , the following time engines could be use for cDAQ9174 (ai, te0 & te1)





However, for the attached Acq Voltage-Clk, none of the above clock works unless OnbordClock is chosen. Can anybody explain this please?

where error occurs.JPG

0 Kudos
Message 1 of 14


i don't have a clue of the problem but I think this is related to de DAQ board. Anyway, if you want to use different timers, for different boards, on 9174 you can use three different tasks each one with its timer.


0 Kudos
Message 2 of 14

Thank you for your reply.
Please also check ''Concurrent Multiple Sample Rates with cDAQ 9178'' at the following web-address and the diagram below:

This is a multiple sample rate example for cDAQ-9178. However, the same error 200284 happens. Why does't it work for me? I don't know if there is any hardware fault in my cDAQ9174 chasis, though the self-test has passed.

Concurrent Multiple=

0 Kudos
Message 3 of 14
Accepted by topic author NCLbingji

Hi NCLbingji,


The "source" input on "DAQmx Timing (Sample Clock).vi" tells DAQmx to get the sample clock from a PFI pin or from another subsystem (like AO, DIO, or counters). It's not designed to select which timing engine to use. I think the community example that you mentioned is setting the sample clock source incorrectly.


On a device with only one AI timing engine, like the cDAQ-9172, specifying "ai/SampleClock" as the source for the AI sample clock tells DAQmx to route the AI sample clock to the AI sample clock, which it can't do, so it gives you a more helpful error:


"Error -89131 occurred at DAQmx Start

Possible reason(s):

An attempt has been made to perform a route when the source and the destination are the same terminal.

In many cases, such as when configuring an external clock or a counter source, you must select a PFI, PXI Trigger, or RTSI line as the source terminal.

Property: SampClk.Src
Property: SampClk.ActiveEdge
Source Device: Dev1
Source Terminal: ai/SampleClock"


On a cDAQ-9174, DAQmx chooses the timing engine when you reserve the task. The timing engine it picks doesn't necessarily match the timing engine that you specify in the VI. If it doesn't match (e.g. your VI specifies te1/SampleClock, but DAQmx chooses te0), then your task will wait for the specified terminal to produce clock pulses. Since there there is no clock on that terminal, the task eventually times out and returns error -200284 (samples not yet available).


The correct way to explicitly specify which timing engine to use is to set the SampTimingEngine property.




Unfortunately, the table showing values for this property in the NI-DAQmx Help for version 9.2.x is also incorrect (reported to R&D as CAR #239502). Here are the correct values:

  • 0 selects te0.
  • 1 selects te1.
  • 2 selects ai.

You can also let DAQmx choose a timing engine, then ask it which one it chose. To do this, reserve the task and then get the value of the SampClk.Term property.



Brad Keryan
Message 4 of 14

Oops, the cDAQ-9172 doesn't return -89131 in that situation. However, M Series and X Series do.



Brad Keryan
0 Kudos
Message 5 of 14

Thank you for the helpful detailed explanation.

Is it normally to leave the "source" input on "DAQmx Timing (Sample Clock).vi" without any connection? However, I did see lots of community examples with the source input specified.


when I chose ''/cDAQ1/ai/SampleClock'' as the source to run the above attached VI, sometimes it runs normally (maybe coincidently cDAQ has pick the same clock )and sometimes it ends with error.

0 Kudos
Message 6 of 14

Hi NCLbingji,


Yes, it's perfectly normal to leave the "source" input unwired. The help for the VI says what this does:


"source specifies the source terminal of the Sample Clock. Leave this input unwired to use the default onboard clock of the device."


Passing "" (empty string) for this parameter is equivalent to passing "OnboardClock". Pass a different value for this parameter only when you want to synchronize the task to an external sample clock (usually from a PFI terminal or an AO/DIO/counter task).



Brad Keryan
Message 7 of 14

Because NI9219 has different maximum sampling rates for different types of tasks, I have set NI9219 to work as thermocouple high speed mode.

The 2 tasks VI could work. Both tasks could start simultaneously however, I don't know which timing engine both tasks are using(te0,te1 or te2). Are they synchronized? Thank you.  


0 Kudos
Message 8 of 14

Hi NCLbingji,


The reason we added te0 and te1 was to make it possible to do AI at multiple rates. If you want to do AI at the same rate on multiple modules, it's easier to put all of the modules in the same task instead of sharing clocks and triggers. You can wire the AI Voltage VI's task out to the AI Temp TC VI's task in, use the ActiveChans property to restrict the AI.ADCTimingMode property setting to a subset of the channels, and split the data into two separate graphs after you read it.



Brad Keryan
0 Kudos
Message 9 of 14

Thank you Brad.

The only problem to use the same task and timing for both AI voltage and AI temp is that the  ''ADCTimingMode(selected as high speed here) '' does not work for AI voltage. However, I don't know how to do with what you mentioned ''use the ActiveChans property to restrict the AI.ADCTimingMode property setting to a subset of the channels''. I have attached the VI and circuit diagram below.




0 Kudos
Message 10 of 14