05-04-2022
10:06 AM
- last edited on
05-08-2024
12:10 PM
by
Content Cleaner
Hello Fancy Folk,
I've been looking into cDAQ systems for a bit and I can't figure out how I am supposed to sync my digital and analog cards. My current goal is to make sure that I am reading 2 voltages and the frequency of a digital signal and make sure they are in sync. The hardware I am using is seen below:
Chassis: cDAQ 9189
Cards: NI 9205 and 9401
What I've done:
I have been googling a lot about sync and cDAQ and I can only really find information about syncing analog cards signal or time based. Most of the information I find says "don't worry, DAQmx automatically handles it for you," which would be great, if there was a document showing me something like "this clock gets routed to this signal and everything works out". Unfortunately, I haven't been able to find that document. Below are 3 NI links that seem to be the closest thing I can find but they seem to be more about syncing chassis.
https://www.ni.com/en/shop/compactdaq/choosing-a-compactdaq-synchronization-technology.html
Where my confusion comes from:
I started acquiring data with LV in PXI and PCI based systems. I am used to having either a PXI backplane or a RTSI cable that I can share clocks or triggers around. Additionally, I'm used to being able to go to NI MAX and look at my card routing to know what goes to where to verify that my set up is correct. My issue is, I can't find any of this information regarding cDAQ stuff so I can't know what clock is going to what card nor using a trigger to start acquisition for all my signals.
I tried to set a trigger for my frequency read and it has been throwing an error saying that I can't have a trigger for my frequency read.
What I'm looking for:
Basically anything that can show me how signals are shared in cDAQ systems and how I can sync my cDAQ digital with analog devices.
Thanks,
Matt
Solved! Go to Solution.
05-04-2022 11:37 AM
My cDAQ-specific knowledge & experience is fairly rudimentary, but I think I can offer at least *some* help.
1. I'd definitely aim for a type of signal-based sync
2. A cDAQ chassis can manage timing signal routing in ways that are partly *analogous* to PXI but not *identical*. (And as you've already found, the lack of routing maps in MAX makes it much more opaque.)
3. Freq measurement is likely bringing in a signal via digital module and then a counter onboard the chassis does the actual measurement. Counter *input* tasks can't use the regular Start trigger, they need to be configured for a special "Arm Start" trigger that's only available through DAQmx Trigger property nodes.
4. The chassis will typically be the common clock source used for module tasks, so you shouldn't need to worry about skew due to module-to-module variations in clock freq.
5. The approach where you Start Trigger the AI task with the same signal used to Arm Start Trigger the CTR freq task will be the most flexible approach, but you'll need to do your own work to correlate sample times from the tasks since the freq task will have variable sample intervals (or else why would you need to measure it?)
6. An alternate approach that's somewhat unlikely to be acceptable is to use the freq signal as an external sample clock for the AI task. But that'd make your AI sample rate variable and possibly either intermittent or too slow.
-Kevin P
05-04-2022 12:39 PM
@Kevin_Price wrote:3. Freq measurement is likely bringing in a signal via digital module and then a counter onboard the chassis does the actual measurement. Counter *input* tasks can't use the regular Start trigger, they need to be configured for a special "Arm Start" trigger that's only available through DAQmx Trigger property nodes.
I saw in NI MAX that there are 4 counters for the cDAQ 9189. Is it safe to assume that the digital cards take the inputs and route them to the chassis' counters? If so, does that mean that the cDAQ 9189 can only have 4 counter ins only? I ask because it seems like the total number of counters is chassis dependent.
From what you said, it sounds like when only using 1 chassis, I can only really set the trigger for both the Ai and Di tasks to try and sync them together, correct? I am asking because I wanted to verify that there is no way to manually share a common clock amongst the cards in the chassis. My understanding is that using the same clock and trigger means that the data is sync'd as much as possible.
Also, I love the signature that you added, I feel the exact same way. Mind if I use it as my signature as well?
05-04-2022 05:46 PM
Yes, the digital modules will route signals to the chassis for use by the chassis' counters.
You normally *can* share both trigger and clock signals among different modules within a chassis. For example, you could sync up AI and DI tasks that way.
Your situation is an exception, but NOT because of cDAQ. It's because of the fundamental timing incompatibility between a (normal) clocked AI task and a counter-based frequency measurement task. This same syncing issue has arisen in many prior threads discussing desktop or PXI multifunction devices.
AI tasks are typically clocked at a constant rate using a sample clock derived from a fixed chassis timebase. Counter frequencies are "clocked" implicitly by the varying rate of the external frequency signal itself. The only way to line up their sampling times is to use the freq signal as an external sample clock for the AI task. But in most circumstances that'll cause more problems than it solves. (See item #6 in my earlier reply.)
You're likely going to be best off going with item #5 in my earlier reply, though it will require a little after-the-fact work to align the data in time. Both tasks will have the same t0, but probably none of the individual samples will coincide in time. AI runs at a constant known rate, CTR freq runs at a variable and unknown rate.
Note: if your 9189 chassis uses the newer DAQ-STC3 timing chip, you'll have a further difficulty due to a design decision I consider unfortunate. You won't be able to know the precise time from the Arm Start Trigger until the first frequency sample. More info here. You *can* do a workaround where another counter tasks focuses only on measuring that time, probably using "Two Edge Separation Measurement" from the triggering signal to the active edge of the freq signal.
Feel free to work up a similar signature -- I think there's more chance of impact if you put it in your own words though rather than merely copy & paste.
-Kevin P
05-05-2022 08:19 AM
@Kevin_Price wrote:
You normally *can* share both trigger and clock signals among different modules within a chassis. For example, you could sync up AI and DI tasks that way.
Your situation is an exception, but NOT because of cDAQ. It's because of the fundamental timing incompatibility between a (normal) clocked AI task and a counter-based frequency measurement task. This same syncing issue has arisen in many prior threads discussing desktop or PXI multifunction devices.
Would changing my read from frequency to edge counting make the sync easier? I don't necessarily need frequency, but the number of edges that have risen from my digital signal then convert the number of edges to the data that I actually care about. My basic understanding of counters is they count edges on the source then give you the number of edges counted when the gate see an edge, thus providing someone with the number of edges (or ticks if you will) per gate's sampling clock.
If I can use edge counting, do you know if I can route a signal to my counter's gate? I don't have access to my cDAQ but have simulated it in NI MAX. I have created an edge counter task, set it to continuous sampling and set my clock to the cDAQ/ai/sampleclock and "ran" it in NI MAX without it throwing an error. My assumption is that my edge counter will now be at the same rate as what I set my Ai task to since they will share the same clock, correct? so in other words, if my Ai is sampling every 1 ms, then my edge counter should sample at every 1 ms as well.
Matt
05-05-2022 10:06 AM
Sounds like you've got it worked out. Since sampled edge counts give you the info you need, you only need to share a common sample clock (as you've already done). Just 2 little subtle things to watch out for:
1. Make sure you start the edge counting task first so it's armed and ready when you start the AI task. (Note: by doing this, you won't need to configure any triggering on either task. The shared sample clock alone is enough to establish and maintain sync.)
2. Any chance you'll be running more than 1 AI task simultaneously? Some (many? most? all?) cDAQ chassis have more than 1 timing engine available for AI tasks. AFAIK, the first AI task will be assigned the 'ai' timing engine. Subsequent ones may get 'te0', 'te1', etc. So the explicit reference to '/cDAQ/ai/SampleClock' could conceivably turn out to be wrong.
A better solution is to query the AI task for its sample clock terminal and route the result of that query over to the 'source' input of DAQmx Timing for your edge counting task. You probably will also need to first call DAQmx Control for your AI task to either reserve or commit it before doing the query. See this thread for more info.
-Kevin P