LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to synchronize tasks

I need to synchronize two tasks - one for analog and one for digital data collection of waveforms. I have looked for examples and what I find is "Analog Input - Sychronization.vi". I am stuck because there are quite a few different styles of synchronization in the case statement and quite a few notes about details I know nothing about regarding various chassis or module types.

 

This is where I currently am where I have two different tasks that are not synchronized. When I run this I get a pretty significant difference between each task regarding when they start - up to about 0.1 seconds.

 

flycast_0-1624391609567.png

 

My equipment is a cDAQ-9185 with two modules:

  • NI 9205 voltage
  • NI 9425 DI

 

Is there someone who could kindly point me in the right direction on how to synchronize these tasks?

0 Kudos
Message 1 of 10
(2,430 Views)

When possible, I like to sync with a shared sample clock as shown in the code below (a small mod of your posted code).

 

A trigger is another way to sync tasks, but only if they're on the same device or in the same chassis (cDAQ or PXI).  Otherwise, only the very initial start is in sync, but the clocks of the separate devices will drift apart from one another over time.   

 

The effect is more pronounced for longer acquisitions that last hours or days.  But it's present even in shorter acquisitions.  A decent rule of thumb is that data acq clocks in different devices may differ by a few millisec per minute of acquisition time.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 2 of 10
(2,387 Views)

@Kevin_Price:

Thanks for that! I am getting an error I do not understand though. The error is on the Analog 1D Wfm NChan Node and states:

You only can get the specified property while the task is reserved, committed or while the task is running. Reserve, commit or start the task prior to getting the property.

 The VI goes ahead and collects the digital data but does not collect data for the analog channels.

 

 

flycast_0-1624451711374.png

 

0 Kudos
Message 3 of 10
(2,359 Views)

Since you are on the same cDAQ with your modules, try to select the ai-Sampleclock directly:

JensG69_0-1624455376401.png

Regards, Jens

Kudos are welcome...
Message 4 of 10
(2,352 Views)

@ JensG69:

Thanks! That seems to work.

 

General question. I am basically just following instructions without really understanding the basics and fundamentals of timing and triggering. Does anybody have pointers to good tutorials? When I look at the LV help it is easy to drop into reading about something out of order - meaning I actually need more fundamental info first.

Message 5 of 10
(2,349 Views)

Sorry about that.  Some tasks let you do that query without reserving first.  Not this one apparently.

 

Insert the "DAQmx Control Task" function between the timing config and the terminal query and set the 'action' input to "reserve".  Then the terminal query ought to work, and the lack of error should allow the analog capture to work too.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 10
(2,333 Views)

Kevin_Price:

 

No need to apologize! You helped me get past this hump and I learned there is a whole area of LabVIEW that I need to learn. Thank you.

Currently I am getting excellent synchronization. There is a 0.0000000500586 of a second difference. I guess 5 trillionths of a second will have to do! 🤣

 

This is what the timing part looks like:

 

flycast_0-1624477592495.png

 

0 Kudos
Message 7 of 10
(2,313 Views)

FWIW, you'd get the same level of sync by following the earlier suggestion from JensG69.  Both establish the same hardware timing signal routing.  His method is simpler and more explicit so often preferable.  Mine is a bit more of a pain and only advantageous if you have multiple analog tasks on your cDAQ chassis and the one you need isn't using the default AI timing engine.  (cDAQ chassis offer multiple timing engines to support independent analog tasks on different modules.  When you use just one, it's going to be the one designated "ai".  When you use more than one, the others use "te0", "te1", and so on.  If you happen to be in a scenario where you don't know which timing engine will get used, you'll be more sure of success with my querying method.  But also keep in mind that most users don't seem to get into such scenarios much.)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 8 of 10
(2,302 Views)

Kevin_Price

 

Do both of these methods keep the two tasks synchronized over days?

0 Kudos
Message 9 of 10
(2,249 Views)

Yes, because in both cases the same hardware sample clock signal driving one task is routed out to be used by the other task.  That keeps sampling sync'ed for as long as you keep running.

 

Reminder though, as mentioned back in msg #2: cDAQ modules generally (or maybe always?  My cDAQ knowledge is limited) get their sample clock signals from the chassis.  Because a single master clock drives sample clock timing for all modules within a single chassis, you'd also get no timing drift even if you *don't* explicitly share a sample clock.  In such a case, you'd just trigger all involved modules once off a common trigger signal and thereafter the chassis' clock will keep them in sync for as long as you keep running.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 10
(2,240 Views)