I need to create a VB program to measure voltage, current and frequency on three different channels ( 2 analog and one digital/counter). Is this possible to achieve all three acquisitions at the same time? I can run the examples to measure each in individual programs, although when i try to combine them, I recieve errors.
1) Must I create three different tasks?
2) Or must I create one task to read from 3 different channels on the DAQ?
3) Or is this possible at all
If theres a particular way to do this, could somebody steer me in the right path.
There is only one analog input timing engine on that DAQ board, so you must combine your voltage and current tasks into one task. Simply use the same task handle when you create your current and voltage channels, and they'll be in the same task. They will then automatically share all timing and triggering properties like sample rate and start trigger source and so on. The counter task that you're using to measure frequency can operate independently of the analog task, so you shouldn't need to change it.
[I keep composing responses a minute here, a minute there, and I keep finding out that by the time I finish there's other answers in the queue. Some of what you find below is now a repeat, but there's some new info as well.]
The 6221 doesn't natively measure current. I'll suppose for the time being that your "current measurement" is actually measuring a voltage which *represents* a current.
All AI channels will need to be in 1 AI task. Today you have 2 such channels, but in general for your device, the AI subsystem only has 1 timing engine available for sample timing so any AI channels you acquire must be in the one task that takes ownership of that timing engine.
Frequency measurement should be done with a counter, and that will need to be its own task.
Now the tricky part. "At the same time." The answer is yes, no, and sorta.
1. Yes, an AI task can run simultaneously while a Counter task is running.
2. No, you probably won't sample AI voltages and Counter frequency at the exact same instants. (More below).
3. Sorta. With effort, you can do things to sync the tasks' start times and interpolate data that kinda sorta mostly lines up the sample data.
The way frequency is measured with a counter is that the pulse signal itself pretty much *becomes* the sample clock. That's the meaning behind the DAQmx Timing option of "Implicit" timing. As the frequency of the signal varies, so does the effective sample rate vary, and thus it can't match the normal constant-rate sampling folks usually want to do with the AI acquisition.
You *can* choose to use the variable-rate frequency *as* the sample clock for your AI task. Or you *can* collect data from the 2 tasks and then post-process the data to kinda sorta mostly align it.
Along the way as you do either of these things, you'll need to deal with configuring an "Arm Start" trigger for the counter task. Search for the term here and you'll find more info.
Thank you both, that cleared up alot for me.
What I meant by current measurement was, im using a 1 ohm shunt resistor to measure the voltage across the resistor (V = IR) so Ill need two voltage channels then.
As for the timed aquisitions, Ill take a look around in the forums, but If i were to write some code to, say, start the tasks at the exact same time and then use a looptimer to use the CounterInReader and AnalogInReader to take a measurement every x timer interval, wouldnt that give me the results im looking for? I plan on storing these in an array and exporting to an excel workbook (I have that code completed).
Ill give it a try anyway, thank you both again
The approach you describe is often referred to as "software timing" and will often give you "simultaneousness" to within a handful to 10's of millisec. It's pretty good but not totally reliable, and will vary with the whims of Windows (or whatever other non-real-time OS). The hardware-based approach I referred you to would give sync to within fractions of a microsec.
You'll need to figure out what's "good enough" for your system and application. There are a lot of test scenarios where software timing is plenty good enough. There are others where it isn't.