DAQmx - Using same Task multiple times, alone and synced?

[Kevin_Price]

Exactly where did those errors get thrown?

My best initial guess about the counter task error is that I made a bad assumption in my code.  The DAQmx property node where I query SampClk.Term from the Bridge device is a construct I use very commonly and successfully on "regular" desktop MIO boards (like M-series and X-series).  I suspect that on your particular device, it returns some kind of null data which the counter task doesn't interpret as a valid sample clock source.

<a little searching happens>

If the 9239 is what you're using for the torque measurement, that's *also* a Delta Sigma device.  And that would explain the Sync error b/c Delta Sigma devices don't accept external sample clocks directly.

I'm not nearly as familiar with cDAQ systems as with desktop devices, but I *think* you can use the "channel expansion" feature to put both the load cells and the torque measurement in a single task that spans across 2 distinct cDAQ modules.  I *think* all the necessary voodoo to sync up these 2 Delta Sigma modules will then happen behind the scenes for you.

I'd recommend focusing on this part first and then we can come back to the encoder part later.  Give the following "v02" version a try.  I put Diagram Disable structures around all the encoder stuff so it'll be easy to come back to later.

-Kevin P

[mcduff]

I'm not nearly as familiar with cDAQ systems as with desktop devices, but I *think* you can use the "channel expansion" feature to put both the load cells and the torque measurement in a single task that spans across 2 distinct cDAQ modules. I *think* all the necessary voodoo to sync up these 2 Delta Sigma modules will then happen behind the scenes for you.

Channel Expansion for cDAQ devices in the same chassis works really well in my limited experience; it works between DSA and SAR devices or any combination of them. Some caveats, both modules will have the same sample rate, you cannot have separate sample rates, Channel Expansion will pick one of your modules to be the master clock, you can set up a "dummy task" and and use the timing property node to find out your sample rate, clock source etc.

Dummy Task. If you get an error, devices cannot be combined in channel expansion.Use this property node after a dummy task to see what the timing source is, max rate, etc. You can then use the source for other things.

mcduff

[Douggle07]

Thanks Kevin and Mcduff,

The channel expansion method definitely helped to sync up the Torque and Load Cell Measurements! Now just to bring the NI 9411 Card into the synchronization...

@Kevin_Price, I noticed you were involved in a forum discussion I was looking at a few weeks ago for this exact problem;

https://forums.ni.com/t5/Counter-Timer/NI-9411-Continuous-Edge-Counting-external-sample-clock/td-p/3...

I ran into the same issues when testing for the first time, using 100kHz clock and 100kHz sample rate would strangely work... but this is far too fast for my application. I will try syncing the Analog Input and Counter Tasks today, using the AI sample clock from the channel expansion for the Counter Task. 

Otherwise, I'll have to dig a bit deeper into the 9411 sample clock and syncing documentation.

FYI: You probably have figured this out by now, but I'm using the cDAQ 9189 chassis, and don't have a function generator or another DAQ board to generate an external clock right now.

Best Regards,

Douggle07

[Kevin_Price · Accepted solution]

I made up some simulated devices to see if I could troubleshoot.   Looks like me query for the AI task's sample clock rate & terminal produced an error (which gets hidden by the subsequent counter task error which takes precedence when they get merged later).

It says the task must be committed or running in order to query for the terminal.  Which makes sense in retrospect.   I don't *remember* needing to do that with desktop boards, but that doesn't mean it didn't happen.   (It may also be a side effect of using channel expansion?)

So I simply added a call to "DAQmx Control Task" to commit the task before the query, and bingo!  The app started running without DAQmx errors, at least here with simulated devices.  Give it a try.

-Kevin P