Syncronization of two counters

[ChrisH76]

I am trying to synchronize two counters to collect data from a rotational and linear encoder. I have followed several examples on how to do this however I am having trouble triggering the counters. I am using a dummy voltage input to set the clock source and I set the source of the sample clock to ai/sampleclock. When I run the vi it collects no data and gives me a 200284 error. I assume it is due to the external clock not being routed to the counter sample clocks. I can not figure out how to make the route beyond changing the timing engine to ai. I change the sample timing engine to ai (option 2) by setting the DAQmx timing property.

I also have a random 201133 error stating that one of the counters can not be configured for I/o because it is being used by another task. I have reset the tasks at the beginning of the code and I still get the error. I assume it is because the task is not cleared after a fault but the reset device vi should fix this.

I am using Labview 2013 with a cdaq-9174 with a Ni-9401, NI-9263 and b-9201.

Note: this was previously posted in the Labview board but I think this is a better location.

Thank you,

Chris

[Kevin_Price]

I'm not too familiar with cDAQ hardware, but generally speaking the config section looks good.

One definite problem (maybe the only one) is that you stop the AI task immediately after starting it, thus taking away the sample clock your encoder tasks depend on.  You can easily use dataflow to make sure the AI task isn't stopped until the loop has completed execution.

-Kevin P

[ChrisH76]

Kevin,

Thank you for the reply. Good catch. I did reroute the error line to ensure the task ended after the loop executed however the issues persisted. I did try and remove the sample clock from the counter inputs and rely on the cDAQmod1/ai/startTrigger. This worked however I am not sure if the two measurements will continue to be synchronized over time or if they will drift overtime. Is it necessary to have a sample clock for each individual input line if I use a common trigger from the dummy AI?

Thank you,

Chris

[Kevin_Price]

Removing the sample clock from the counter tasks means that your "sync" can never be any better than software timing under Windows.  Often rather good, not fully reliable, occasionally bad to a stupefying degree.

Having just an Arm Start trigger *will* make sure that the hardware counters are synced, the problem is that the 2 different instants that you query the 2 different count registers gives you *data* that's not really synced.  A hardware sample clock gives you the ability to retrieve synced data.

If you want sync, you need the sample clock.  What issues persist specifically?  Did you make any other mods besides preventing the AI task from stopping early?

-Kevin P

P.S.  I'd get rid of that Device Reset.  It shouldn't be needed.  The lack of breathing time between the reset and your task configuration might possibly be causing trouble too.  I'd like to think the reset wouldn't return execution flow until the hardware is fully ready to be reconfigured, but have no way to confirm that from here.

[ChrisH76]

Kevin,

I did not make any other modifications other than the reroute. The vi runs but no data is collected/displayed. I get a 200279 error that says "Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten."

I will remove the Device reset. This was added to prevent another error. One channel was getting an error at the star task. The error was a 201133 stating "Device cannot be configured for input or output because lines and/or terminals on this device are in use by anther task or route." The error appeared random so I assumed something was not ending or clearing when the vi stopped. This was my attempt to ensure the tasks were cleared.

Chris

[Kevin_Price · Accepted solution]

Another fairly simple one, sorry I didn't catch it before.

The 10 msec loop timer is overconstraining you, preventing your read rate from keeping pace with the sample rate, leading to an eventual overflow of the task buffer..  

With a 1000 hz sample rate, you can accomplish the same thing by removing the wait timer, use the DAQmx Read for 1 Channel N Samples, and request 10 samples at a time.  The DAQmx Read function won't return until those 10 samples (at 1000 Hz == 10 msec) are available, causing your loop to iterate at 10 msec.

There are other approaches, but because you're specifically concerned with sync, it's important to read the same # samples from both tasks on each iteration to keep your data streams in sync just as you've taken pains to put the hardware in sync.   (A common approach with a single task is to use the generic 10 msec wait timer while letting DAQmx Read deliver "all available" samples.  You get "all available" by wiring a -1 to the # samples to read input, or simply leaving it unwired b/c -1 is the default value.  It would probably be a *bad* idea to do this on both tasks at once in the same loop.)

-Kevin P

[ChrisH76]

Kevin,

That was the issue. I made the suggested changes and the vi is collecting the data with no overflow error. Thank you very much for the help!

Chris