10-13-2021 02:55 AM
Solved! Go to Solution.
10-13-2021 08:59 AM
You can use sample clock synchronization for Analog and Digital tasks but I am not sure about the counter.
Further read - Synchronization Basics - National Instruments, Synchronization Explained - National Instruments
10-13-2021 09:55 AM
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
10-19-2021 12:35 AM
Actually, i want to combine analog input and counter input. Do have any solution?
10-19-2021 12:51 AM
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)
10-19-2021 01:38 AM
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
10-19-2021 08:17 AM
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:
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
10-20-2021 03:03 AM
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?
10-20-2021 05:56 AM
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
10-20-2021 08:22 AM
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?