LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to Synchronize or Combine How to combine programs with different input types such as analog inputs with digital/counter inputs and run at the same

Solved!
Go to solution
Hello Friends,
I want to discuss about my final project, make DAQ Dynanometer with Software Labview to measure Torque, Power, and RPM. The issue is, I have programmed several sensors with analog input types such as loadcell, thermocouple, humidity, and ambient temperature with the sub creating a new sub vi to function as the configuration of each terminal on each sensor.
I did this to program several counter/digital input sensors such as flowmeter, hall effect, inductive pick-up, in the following picture.
I use DAQ Hardware with NI USB 6212
Case: How to combine programs with different input types such as analog input with digital/counter input and run at the same time?
I hope your suggestion or solution
Regards
 
munthefelix_0-1634111619119.pngmunthefelix_1-1634111650518.png

 

0 Kudos
Message 1 of 18
(1,354 Views)

You can use sample clock synchronization for Analog and Digital tasks but I am not sure about the counter.

 

Further read - Synchronization Basics - National InstrumentsSynchronization Explained - National Instruments

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 18
(1,326 Views)
Solution
Accepted by topic author munthefelix

If those 2 programs run on their own (I don't recall being able to put multiple counter freq channels into a single task, but it's been a lot of years since I might have wanted to try), then they should also be able to run at the "same time" because there should be no conflict in the DAQ device resources they each need.  Have you tried running them at the same time?  What happened?

 

Having said that, the ability to run those 2 chunks of code at the "same time" is only a small step toward getting data that's actually sync'ed with respect to time.  That's gonna take quite a bit more work and I don't have time to lay out the entire tutorial.   Here are some key items:

 

1. Even if you *could* lump multiple freq/period channels into a single counter task, it's almost certainly not going to be a good idea.  I'm doubtful it's even possible.

 

2. For sure you can't perform 3 counter measurements on a device with only 2 counters.

 

3. Broadly speaking, there are 3 things you must do to establish and maintain sync:

1.  Use triggering to start the tasks at the same time.  For counter input tasks, you'll need to use the "Arm Start" trigger.

2.  Use a shared or common timing reference signal such that the tasks maintain hardware sync.  For tasks on the same board, this occurs automatically as both AI and CI tasks have their timing defined by a common timebase clock.

3.  Retain sync in your data stream by the way you gather and correlate the data from your tasks.

 

When using "Implicit" timing for counter tasks, step 3 gets tricky.  The sample rate is defined by the signals whose freq/period you're measuring, and generally will be variable and not match up to the AI sample rate.  Probably not particularly close.  So you need to use the freq/period data to *calculate* the cumulative time at which the measurements were made.  Each of the freq/period tasks will have its own associated array of sample times.  Any further processing you do will need to carefully keep track of the specific instants of time the various samples were taken.  (Easy example: you'll need to plot data vs. time on an X-Y Graph because your counter time intervals will be variable and not suited to a Waveform Graph.)

 

 

-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 3 of 18
(1,319 Views)

Actually, i want to combine analog input and counter input. Do have any solution?

0 Kudos
Message 4 of 18
(1,277 Views)

Dear Kevin P

 

I've tried to combine the 2 programs. Actually, this program consists of analog input and counter input. I've tried running concurrently. What happened was that the analog data value was successfully entered and read by the data acquisition system and the front panel (display) was visible.

my problem is, the data from the input counter does not enter and is read by the data acquisition system, no changes occur in the front panel (display)

0 Kudos
Message 5 of 18
(1,274 Views)

I send the program that I made, consisting of sub vi analog input and counter input. Separate programs, namely, Program DAQ analog input and Program DAQ Counter input. And I've tried to combine the 2 programs. for hardware DAQ I use NI USB 6212

0 Kudos
Message 6 of 18
(1,270 Views)
Solution
Accepted by topic author munthefelix

Let's focus on the counter part.  Have you tried debugging with execution highlighting on?  When you do, you'll find that there are many things in the counter config that lead to task errors, preventing you from getting any data.  For example:

 

  • Trying to put multiple counter channels into a single task.  This isn't supported by your device.
  • Trying to do 3 counter measurements with a 2 counter device.  Not possible.
  • The Underflow Behavior property is not supported for this task.
  • The regular Start Trigger is not supported for counter input tasks.

 

You're going to need separate tasks for each counter channel, and there are only 2 counter channels available on your DAQ device.  You'll need another DAQ device to be able to measure a 3rd channel.

 

Spend more time (a *lot* more time) experimenting with highlight execution on, researching more info about errors you see, trying out a variety of shipping examples, searching for further examples of counter measurements on this site.  Start small by getting 1 counter freq / period task to work on its own.  Use the shipping examples as a guide.

 

 

-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 7 of 18
(1,257 Views)

Dear Kevin P

 

Thank you in advance for your answer. it really helped me, but still found the right solution.

I've tried using execution highlighting, and the result is that the output or value from digital sensors such as hall-effect sensors, flowmeters, inductive pick up doesn't come out on the front panel on Labview. But the analog sensor can be read by the program I made, no problem.

in my project, using NI USB 6212. you said that my device can only use 2 counter devices, what solution can I get by still using NI USB 6212?

For triggers, I will try to learn arm triggers. regarding underflow behavior, do you have any suggestions for supported properties?

0 Kudos
Message 8 of 18
(1,239 Views)
Solution
Accepted by topic author munthefelix

Execution highlighting can show you where errors are generated and where function outputs don't match expectations *before* you get to the point where you try to send measurement results to the front panel.  At each point something doesn't work as needed, you have to investigate and solve that problem, then move on to find the next one.

 

Start with a shipping example for measuring period or frequency with a single counter channel.  Build from there.

 

Counters are the best way to do freq & period measurement.  Your best bet is to add another DAQ device so you can do all 3 pulse measurements with counters.  A small compromise would be to purchase one or more frequency to voltage converter modules so you can use your analog task to capture signals that represent frequency.   A much larger compromise (and quite possibly too large to seriously consider) would involve *sampling* the raw digital pulse signals at a high rate, doing some post-processing, and calculating badly-quantized and "noisy" looking frequencies.  From what I've seen, I don't think you're ready to tackle that approach anyway.

 

 

-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 9 of 18
(1,232 Views)

Dear Kevin P

 

Well, thanks a lot for the great advice and answers. I now understand a little to solve this problem. Actually, I am a student majoring in mechanical engineering, but my final project is to make a data acquisition system but it doesn't matter. we can learn something by our efforts.

by the way, what if I build all these programs separately without combining them with one task, so all kinds of programs are parallelized, any suggestions or references?

0 Kudos
Message 10 of 18
(1,225 Views)