Can someone explain to me how the CI Linear Velocity module is supposed to work? I've been trying with no successt for some time to use it to take velocity measurements using a counter input. I'm using an NI 9411 Digital Input card to accept a signal from a radar system that outputs a measured speed as a frequency (that just so happens to work out to a rising edge every 0.176 inches moved).
Everytime I run the VI I get an error out of the Create Channel module that is as follows:
Source: DAQmx Create Channel (CI-Velocity-Linear).vi:2530001<append>
<B>Requested Value: </B>Velocity:Linear Encoder
<B>Possible Values: </B>Frequency, Period, Pulse Width, Semi Period, Two Edge Separation, Pulse Frequency, Pulse Time, Pulse Ticks, Position:Angular Encoder, Position:Linear Encoder, Count Edges
<B>Task Name: </B>_unnamedTask<6>
Which, on a similar topic, is there a document anywhere that lists DAQ chassis module and DAQmx measurement compatability? Cause I cannot find this documented anywhere that is obvious...
Solved! Go to Solution.
Well never mind.... I finally found a document that lists the measurement type compatability and appearently the only module capable of doing using the Velocity measurement virtual channel is the NI 9361....
Just carifying sources for others in the community
Yes, the 9411 has no counters- so it is not a device that you can use for your measurement. The Product search (By Data Acq, Counter/timers, cDAQ) Yield only one device - NI 9361.
Um... Except that I have been using it for my measurement but have just been doing it in a round about way. I've been using it to take a frequency measurement using the DAQmx CI Freq block and then back calculate that into a velocity. There are two main issues I run into with that. First is that I have to be able to sense speeds near zero so I have to specify a time out and then provide error handling to catch the timeout and provide a zero value for the speed. Secondly this makes the speed measurement an event style measurement in a VI in which everything else is timing based and getting the two to sync and run concurently has been a real challenge. And according to labview, the 9411 does have counters, or at least can be used as a counter input.
Actually on that note, I do have one quick question. I noticed that the only way I could get this to work was to specify my module's CTR as the physical input, but then I'd have to add in a task node to set the "CI.Freq.Term" to the matching PF* input. See Below.
Is this the correct way to do this, is this wrong, or is there a better way?
Ok, I'll bite.
So first, I cannot post up the entire code for two reasons. First, it wouldn't fit. The entire VI is about 6 full screens in size. Second, company policy forbids.
Why am I using counters? My sensor is a radar set up to output a pulse train that has a frequency equivalent to the speed at which the sensor is travling. Not my choice, that's just how the output is set up from the manufacturer and there is no way to change it. So, the easiest and most accurate way perform the measurement on this signal that I could come up with was to use labView to directly measure the frequency. I initially wanted to set it up as a direct velocity measurement since the pulse train is esentially equivalent to the signal a "two pulse" encoder would put out if it was always moving in the same direction, i.e. moving one direction pulses A and moving the other pulses B. Since I only cared about absolute movement the fact that I never pulsed the B input, the "Two Pulse Counting" decoding type using a CI Linear Velocity block seemed to be the obvious choice. But, since the 9411 doesn't support that measurement my fall back was to directly measure the frequency and back calculate it into my speed. That measurement type necessitated a CI Freq Virtual Channel, hence why I am using counters.
If not that method, how would you recomend doing it?
And no. You cannot get the two portions of the VI to sync. The frequency measurement as implemented by the blocks is inherently an event driven process unless you can sample at a rate lower than the lowest expected input frequency. Since I need to detect speeds "at" or near 0 that means that my minimum frequnce IS 0 and I cannot sample at a rate lower than that. My hopes were that by using the Velocity measurement block I could at least simplify some of my VI to make it run a little more efficiently. The other analog and digital measurements I need to make have to be done at a constant sample rate with all data synced with a time stamp. This is a requirement of the testing standards we have. As such I have a secondary loop that polls the frequency measurement and updates an array with frequency measurements and time stamps as the pulses come in and my main loop running at a fixed rate that pulls off the most recent couple values and performs an interpolation to fill in any "gaps".
That a really interesting application of the NI 9411 module and quite a creative work around with the counters. I don't think I could make a recommendation that would work any better given that your radar uses a pulse train that has frequency equivalent to speed.
Applications Engineer, NI
I can only describe how I'd approach this with a desktop plugin board -- I'm not very familiar with the specific differences you might face with cDAQ chassis/modules.
1. Analog and counter measurements need to share a common timebase.
2. Since your frequency sampling rate is determined by the frequency itself, the task buffers will *NOT* be synced. (I realize you know this already, I'm emphasizing it for any other readers.)
3. So your frequency measurements need to be triggered, likely with an "Arm Start" trigger. You'd probably use the same signal as a Start trigger for the Analog task.
4. If you have DAQ-STC2 counters, the 1st freq measurement will not *really* be a frequency, but *will* represent the time from Arm Start trigger to 1st edge to be measured. The 2nd measurement will happen at the 2nd edge and represent the 1st full interval.
If you have DAQ-STC3 counters, you might be kinda hosed. The behavior was changed so that nothing gets buffered until the 2nd edge, and the value always represents the 1st full interval. The info about time from trigger to 1st edge is no longer available AFAIK.