Troubleshooting motor RPM code

[jseele69]

I have a code that uses an obstacle sensor that senses the RPM of a motor with reflective tape.  The code uses this sensor to count the number of revolutions of the motor, along with LabVIEW timing functions to calculate the average speed for a certain number of revolutions.  The code is very accurate (no problems there) however it is very computationally expensive.  In fact, I cannot add any other functions to the code, otherwise LabVIEW loses the ability to keep up with the motor revolutions, regardless of the motor speed.  I was hoping for some ideas or suggestions to improve the efficiency of my code so I can handle other tasks such as writing to a file.  Any help is appreciated.  I have attached my VI.

[GerdW]

Hi jseele,

mind to share a downconverted version of your VI?

(Most recommend LV2020 or older, I prefer LV2019.)

[jseele69]

Here is both.

[mcduff]

Main issue I see is that your are processing 1 point at a time. There is overhead in each call to the DAQmx Read function. Is it possible to download multiple points at a time? Can you use hardware timing, for example, download 100 ms of data at once? Point-by-point acquisition will always bottleneck. What device are you using? (Not all devices support hardware timing.)

[Bob_Schor]

For some reason, LabVIEW 2019 and 2021 both "hang" when I try to open your VI (I can see the Front Panel, but nothing else).  Still, following up on some comments made by @mcduff, I have some comments/questions.

In order to determine RPM from a "bit sensor" (presumably a Digital Input line where the critical question is the time difference between successive Low->High transitions), you need to be "looking at the signal" for about two revolutions (in order to be sure to capture two such transitions and determine the time difference between them).

Example -- assume 60 RPM, or one revolution/second.  Sample for 2 seconds.  The Sampling Rate must be fast enough to be certain to catch a "rising edge", so if the reflective tape subtends an arc of 45°, 1/8 of a revolution, you need to sample at a rate of at least 8 Hz, though you'll probably want to sample much higher, maybe a few hundred Hz, to more accurately (in time) "see" the rising edge, and in two seconds, you'll catch 2 rising edges.

Calculate the number of samples between these two rising edges, divide by the sampling rate, and you have Revolutions/second, easily converted to RPM.

I played a little "fast and loose" talking about "sampling" a Digital Input, which, as @mcduff notes, not all DAQ hardware supports.  So who said you had to read TTL signals with a DI line?  You can "sample" it with an Analog Input signal, and subject the 2-second sample to the following analysis:

• Pre-condition -- you know the previous value (i.e. saved in a Shift Register, initialized to F (or Low).
• Read the next Analog value.
  • If between 1 and 4 V, output Previous Value.
  • If <1, output F (Low)
  • If >4, and Previous Value = F, output T (and set Previous Value to T)
  • Otherwise output F (and set Previous Value to F)

If I've done this right, this will convert your Analog waveform, which most of the time is near 0 or +5, into a Digital Waveform which is F except when the signal rises from <=4 to >4.  Find the two "T" elements in the Array -- the difference in their Array Index gives you the number of samples between rising edges.

Bob Schor

[jseele69]

I am using a NI usb-6000.  I could create a single channel N samples daqmx, but I'd like to implement control algorithms for my motor and add other measurements in the future, so I don't think that is ideal.  I'm more concerned with the efficiency of my algorithm.  One of the engineers I work with suggested this code for a more efficient measurement.  It seems replaces all the digital logic with a counter may work more efficiently.

[jseele69]

Bob, I understand your point, but I'm not sure that your method has much difference on computation time.

[Bob_Schor]

---

@jseele69 wrote:

Bob, I understand your point, but I'm not sure that your method has much difference on computation time.

---

Well, it does have a built-in "lag" in that every 2 seconds, you get a very quick (probably <1 ms) estimate of the RPM during that time period.  With a single once-per-revolution digital "event", even using a Counter-Timer can hardly do better.  So to spend 1 ms every 2 seconds seems like a great deal, giving you 1.9995 seconds to do any other computations (or waiting) that you need.

Counters are another way to go.  I have less experience with them, and haven't used them in this kind of situation.  But since you still need to "wait" for two successive "ticks" in order to get the "time between ticks", the methods seem almost equivalent in efficiency.

Bob Schor