LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronizing counter input (edge count) and analog input - Daqmx

I am wanting to synchronize the data between an edge counter measurement task with a continuous analog input measurement task. I have done this by setting the input clock source on the counter to use the analog input clock as a master, and also setting sample clock frequency to be the same between modules. However, I don't think I have understood how to correctly synchronize both tasks' start times. Looking at the data for both it seems the analog input task is starting before the counter, however they both acquire the same number of samples and at the same frequency (CI does not take a time measurement, so I estimate this by incrementing the inverse of the sample frequency for each sample). Is my data synchronized?

0 Kudos
Message 1 of 4
(3,919 Views)

Hey Schafbo,

 

The way you currently have your task configured you are synchronized via software. Basically, that means you are at the mercy of your computer in terms of how synchronized your starts are. In order to achieve a tighter synchronization, you should look at using a trigger to start your tasks. Keep in mind that the topic of synchronization is quite a rabbit hole and the tighter the synch need to more complicated the configuration.

 

Here is a quick resource about triggering, pay close attention to section 3.

NI-DAQmx Data Acquisition Triggering Techniques Using LabVIEW

 

 

Hunter D.
Applications Engineer
0 Kudos
Message 2 of 4
(3,886 Views)

Thanks Hunter. I know the acquisition starts are not synchronized, but the counter is configured to use the analog input sample clock, which results in both tasks acquiring the same number of samples at near the same interval. However, I am skeptical that they are synchronized given that start times are not the same.

 

I have tried to set up triggering for the counter as you described, but it appears that it is not supported? I am receiving this error message, it occurs with any type of trigger source:

 

sync_issue5.png

0 Kudos
Message 3 of 4
(3,880 Views)

It looks to me like you've done the correct hard parts of getting your tasks synchronized.

 

1. They share a sample clock signal, in this case both use the sample clock from the "master" AI task.

2. Any dependent "slave" tasks (in this case, the counter task) are started *before* any sample clock signals can occur.  You've used dataflow properly to sequence the task starts to guarantee this.

 

Your AI and CTR data samples *are* sync'ed.   The discrepancy in the timestamps attached to those samples arises because of your method for creating timestamps for the CTR data. 

    I can't see that part of the code, and you might well be using the best possible method.  It's just that even the best possible method is still fraught with uncertainty.  The problem is that you're doing a software query for a time-of-day timestamp and then *supposing* that it represents the time of the first CTR sample.  It won't and it *can't*, at least not *exactly*.

 

If this were my project, I'd trust the samples to be in hardware sync based on the way the tasks are configured and started.  I would then choose to believe the t0 value from the first AI read and *assign* it as the t0 value for the CTR samples. 

 

But that comes from having done many dozens of apps with synced tasks in DAQmx.  You may need to spend a little more time proving to yourself that the samples are in hardware sync before believing me.  In fact, you *should*.

 

 

-Kevin P

 

 

P.S.  Your app doesn't need triggering to establish sync.  You've done it with a shared sample clock and the sequence of task starts.  For future reference however, it's useful to know that Counter Input tasks can only use a special "Arm Start" trigger instead of the more standard Start trigger used by most other tasks.  It has to be configured using several properties in a DAQmx Trigger *property node*.

 

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 4 of 4
(3,859 Views)