LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Trying and failing at performing velocity measurements

Solved!
Go to solution

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:

Code: -200431

Source: DAQmx Create Channel (CI-Velocity-Linear).vi:2530001<append>
<B>Property: </B>CI.MeasType
<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...

0 Kudos
Message 1 of 12
(4,158 Views)
Solution
Accepted by JÞB

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....

0 Kudos
Message 2 of 12
(4,155 Views)

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.

 

 


"Should be" isn't "Is" -Jay
Message 3 of 12
(4,152 Views)

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.

0 Kudos
Message 4 of 12
(4,063 Views)

 

Hello Balmerjd,

In regards to the 9411 module. Jeff was correct in saying that it has no internal counters. But you are also correct, the 9411 is counter compatible within a cDAQ chassis. There is a good resource on ni.com "C Series Signal Connections for Counters." With this forum post titled "Physical Connections to use 4 counters with NI 9411 in cDAQ 9178 chassis" explaining it well. 

As for your synchronization problem, having not seen your code, the architecture you are describing seems to be a reasonable work around to this timeout problem. I'm not sure at this point I can think of a silver bullet solution to your problem. 

 

Best,

Spencer R.

Applications Engineer, NI

Message 5 of 12
(4,036 Views)

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.

2016-10-05_8-29-04.png

 

Is this the correct way to do this, is this wrong, or is there a better way?

0 Kudos
Message 6 of 12
(4,013 Views)

Hey Balmerjd,

 

So without the context of your entire code or specifics of your application I wouldn't want to give you incorrect information on this specific section of code. If it seems to be working in your application and you are getting the expected results that seems promising. 

Why exactly are you needing to use counters in this application?

Also, have you gotten the speed measurement and the rest of the VI to synch? What is the importance of this in context to your application?

 

Spencer R

Applications Engineer, NI

0 Kudos
Message 7 of 12
(3,991 Views)

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".

Message 8 of 12
(3,981 Views)

Hello Balmerjd,

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. 

 

Spencer R

Applications Engineer, NI

 

0 Kudos
Message 9 of 12
(3,956 Views)

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.

 

 

-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 10 of 12
(3,924 Views)