LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx synchronisation AO+AI+CI (Digital Frequency)

Solved!
Go to solution

HI there,

 

I am using NI 9263 for AO, NI9225 for AI (two channels) and NI9401 for counter frequency measurements. All these tasks should be synchronised. I've seen a lot of different examples how to perform this process, but i could not get my head how to implement a frequency measurement part. 

 

I was using the code "Multi-Function-Synch AI-AO" and was trying to add a frequency code.The issue is that I can't even start the code, since my digital trigger for the frequency code does not work. I was trying different options, but without any success. AO and AI are synchronising without any complications by using this trigger, but the CI code. Is anybody able to help me with this question? Thank you in advance.

 

DAQ_synch.PNG

0 Kudos
Message 1 of 5
(3,627 Views)

I can only give general thoughts on an approach that would work with a PCIe multifunction board (or some combo of boards on a desktop bus).  I can't really speak to whether your specific cDAQ hw supports these things.

 

Generally speaking, you need a shared timebase to sync tasks so that the sample times don't drift relative to one another.  The easiest method is when you can share a sample clock among many tasks operating at the same rate, and make sure the designated "master" task starts last.

 

Many devices don't support constant-rate sampling for frequency measurement.  One option is to make the frequency measurement counter task the master and allow AO & AI to do variable rate sampling (but which is hw-synced to the freq measurements).  Another option is to also share a trigger signal to set the same t=0 point across tasks.

 

Most counters from NI require the use of an "Arm Start" trigger for counter *measurement* tasks.  The regular Start trigger can only be used for pulse *generation* tasks.

 

I'll have to leave it to others more familiar with cDAQ hw to comment on whether and how these approaches can be carried out on your system.

 

 

-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 2 of 5
(3,587 Views)

Thank you Kevin,

 

When I start to google about an Arm Trigger, I found some examples. Even though you are not an expert in DAQmx. but your vision is absolutely correct. I modified the code a little bit, so I am wondering, should I was a sequence structure in order to run "master" and "slave" tasks, or this trigger solution will be enough to ensure that we will start acquisition at the same time?

 

DAQ_s_2.PNG

And mainly the reason being is that I am planning to log this data, hence I need to be sure that it is perfectly synchronised.. In any case, Thank you very much for your help. If anybody else has something to share, my ear are open.

0 Kudos
Message 3 of 5
(3,580 Views)
Solution
Accepted by topic author ESturov

No need for a sequence structure, just wire the *output* error cluster from the frequency task's call to DAQmx Start up to the 'merge errors' node (after growing it by one input).  This will enforce the proper sequence that your master AI task starts *after* both AO and Counter have started.

 

There's a possible additional subtlety you'll need to explore.  Here's what I *know*: various NI devices treat *period* measurement a little differently.  Some of them will buffer a 1st measurement upon receipt of the 1st active edge after the arm start trigger.  In this way, the first buffered sample gives an accurate time period from the trigger to the beginning of the first full interval.  The 2nd edge marks the end of the 1st full interval, and buffers it as the 2nd sample.   Other (generally newer) devices will only measure full intervals.  So the 1st buffered sample measures the 1st full interval and occurs on the 2nd active edge.  These devices provide *no way* to know the time from trigger to 1st edge.  I consider that a poorly considered design

decision.

 

Having said all that, I'm not sure if Frequency measurement has the same kind of differences across various devices.  My hunch is no.  Despite the fact that period and freq are just reciprocals, the meaning isn't quite so interchangeable.  Measuring a partial period (to know the time from start to 1st edge) can be meaningful.  Calculating a frequency from that partial interval is *not* meaningful.  My hunch is that on all devices frequency measurement buffers its 1st sample at the end of the 1st full interval which is defined by the 2nd active edge after trigger.

 

Here's the problem:  devices which do not buffer a sample on the 1st edge after trigger give you no good way to sync up the sample times of your frequency task to the sample times of your AI and AO tasks.  The only workaround I know of is to make a 2nd unbuffered counter task that measures "2 edge separation" from the trigger signal to the first freq edge.

 

 

-Kevin P

 

P.S.  I know DAQmx pretty well, it's cDAQ hardware that I don't know so well.

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 4 of 5
(3,575 Views)

Kevin_Price,

 

Thank you for your clarifications, I see what you are trying to say. Will try it out and get back to the forum with my results after some additional research.

 

P.S. Fair enough, did not plan to underestimate your experience with DAQmx Smiley Happy Have a good day!

0 Kudos
Message 5 of 5
(3,572 Views)