Continuously Measure RMP of BLDC Motor: 3,000RPM Max, 24 Pluses per revolution. NI 6009

[bluebeardx64]

Hello,

Can someone please help, I need to measure the RMP of 2 BLDC Motors they are 3,000RPM Max, 24 Pluses per revolution from the encoder. I have the NI 6009 and I'm using LabView 2017.

Can the NI 6009 effectively measure the RMP of these motors accurately and can someone please post a VI of the solution to doing this.

Thanks.

[Kevin_Price]

What are your specs for "accurately"?

We'd need to know both the normal accuracy specs but also some stuff related to update speed.  How often must the measurement be updated with this accuracy?  What latency is allowed between the moment the speed is true and the moment your measurement task can establish the speed value?

The USB-6009 is a poor choice of hardware for this kind of task, you'd be much better off with a device containing at least 2 general-purpose counters.  You only have 1 counter and its dedicated to the wrong kind of purpose.

If you need USB, I'd advise something in the X-series line.  Some M-series devices would work too, though some would be more suitable than others (look for larger FIFO size on the counter).

-Kevin P

[bluebeardx64]

Thanks for your reply, my specs for accuracy isn't very high, I know my hardware is limited, my goal is basically experimental. Reading the speed every second would do. Can this be achieved using the digital ports only and performing the counting at the software side?

[Kevin_Price]

No, you really can't do that with digital inputs on a USB-6009 device.  It doesn't support hardware-timed, buffered digital I/O.  And neither Windows timing nor USB latency will reliably support the > 2.4 kHz software-timed sampling you'd need to capture the ~1.2 kHz encoder square wave.

-Kevin P

[bluebeardx64]

Is there a way I can perhaps overcome the limitation of the 6009 by using a dedicated external IC that does the HZ to Voltage conversion and feed that into the DAQ? Eg. using the LM331 or related chips. I'm hoping I can get an inexpensive way that doesn't involve buying another DAQ.

[Kevin_Price]

I don't know details about that chip or other frequency-to-voltage converters, but that seems like a viable way to get some reasonable data using your board's analog inputs. 

Accuracy may suffer a little, but the chips you look at should have specs for that to help you make an informed decision.  Realize too that the physical encoder and assembly tolerances will add their own error term no matter how you do the measurement.  So the F-to-V may not even be the dominant part of the inaccuracy.

-Kevin P

[bluebeardx64]

Hi Kevin,

I came across this thread; https://www.labviewmakerhub.com/forums/viewtopic.php?f=11&t=362

Is this a viable approach for solving my problem?

[Kevin_Price]

I don't know and can't know.  That's one of the problems with screenshots of Express vi's and DAQ Assistant vi's -- the behavior greatly depends on hidden configuration options.  Same for those blue "Dynamic Data" wires.  Further, the code over there wasn't working correctly for a much slower 15 Hz signal, parts of it that I *can* interpret look a bit haphazard, and there really isn't much "code" there anyway.  I would advise starting from scratch rather than trying to use that code as a starting point to build from.  Shipping examples for AI would be a good starting point, the post-processing would be up to you.

More generally, capturing the encoder signal using AI is at least feasible to try to do with a USB-6009.  The posted code shows a PID node though, implying a desire to run a control loop.  *That* part probably will *not* be viable with your USB-6009.   

Previously you narrowed your question to the use of digital inputs for acquisition.  *That* is still *NOT* viable with the 6009.

-Kevin P