Is there a speed sensor input example for Labview?

[marccenter]

CD,
Is there a speed sensor input example for Labview?
I'm looking for one but cannot find it. I am thinking about using
one of the old honeywell optical sensors to read one pulse per
revolution as a CIM motor speed sensor (black tape on alum disk).

If there is no speed sensor input example can someone post one they
have successfully used in the past?

Thanks in advance,

[Mark McLeod]

Is this what you mean?


The 5 should be a 1 in your example. If you had more than one piece of reflective tape, that would be the number of pieces of tape.
The 99 also should be a 1

[marccenter]

Mark,

Yes.. great example.. Let me throw it into my code and maybe I can see motor speed this afternoon for FRC 1188 (sister team). Thanks,

[Ether]

Originally Posted by marccenter

Let me throw it into my code and maybe I can see motor speed this afternoon for FRC 1188 (sister team).

Important: What is the part number of that "old Honeywell sensor", what is your wheel speed, and how wide is your piece of tape (in degrees or radians at the point where it is being sensed)?

[marccenter]

Ether,

I am planning on using one of the three Rockwell Automation light sensors provided in the 2011 FRC KOP, PN 42EF-D1MNAK-2.
The shooter wheel is either a six or eight inch direct driven by a CIM (1000 to 5000 rpm, 2000-3000 rpm typical).
I was planning on using a piece of reflective tape, like one inch square, my goal being about double the size of the sense eye. My goal was to place the reflective tape near the edge of the wheel on one of the spokes.
Because of the rather high speed I believe only one signal per rev is sufficient for crude speed measurement and control. There is no plan for position based control.

[nickcvet89]

We used the photoelectric sensor (line follower) from the 2011 season and, used this as a tachometer and sent the information to the DS similar to marks example. I might post a video on how to do it next week.

[marccenter]

Dear CD,

Mark's example worked with me with one small modification, I changed the 0.05 value going to the config Timer to 0.5 (timeout value) and I placed the Periodic Tasks inside a 100 msec loop not the 10 msec loop also available.

I am able to read the Tachometer on the Variables page but not on the smart dashboard. I have fiddled with the smart dashboard displays and they seem to have a much slower update and seem to "freeze up" after a short period of time on my bench setup at home. I wouldn't trust them too much if you are using them for control purposes... use the variables page to confirm your software is operating as expected is my 10-cent advice.

BTW, I am testing an AndyMark PG188 gearmotor at home that has a free speed of about 75 rpm. This operates at a safe
speed and I can see the Rockwell Automation sensor built in lights toggling to indicate a change of state. I have not yet configured a CIM for higher speed measurement operation.

I see the code segment below appears to be run in the 10 msec loop. Hmm... I may move the 100 msec counter logic into the 10 msec loop and see if the motor speed shows up on the smart dashboard.

[Ether]

Originally Posted by marccenter

Ether,

I am planning on using one of the three Rockwell Automation light sensors provided in the 2011 FRC KOP, PN 42EF-D1MNAK-2.
The shooter wheel is either a six or eight inch direct driven by a CIM (1000 to 5000 rpm, 2000-3000 rpm typical).
I was planning on using a piece of reflective tape, like one inch square, my goal being about double the size of the sense eye. My goal was to place the reflective tape near the edge of the wheel on one of the spokes.
Because of the rather high speed I believe only one signal per rev is sufficient for crude speed measurement and control. There is no plan for position based control.

Sorry, I just now saw your post.

8" diameter wheel at 5000 rpm with 1" wide tape puts the tape under the sensor for only ≈ 0.6ms. If things start to get flaky at high speeds, that might be why.

[tr6scott]

We are using a banner sensor, (very similar to AB, just smaller packaging, and polarized) two pieces of reflector tape, on a vex hub. We have sized the tape so it is 90 degrees on, 90 degrees off.

We are using the same code that was posted, and but averaging over two samples to balance any, not quite 90 cuts, on the reflectors.

This is giving solid RPM measurement. We are controlling with "take back half" controller, posted by 123 last year.

Our target speed is 3700, and max speed of 4400 on the wheel. We have confirmed the speed with a handheld optical tachometer. We come to speed in about 2.8 seconds, and can hold a +- 3% to shoot.

We tried bang bang, but the counter resolution was fighting with the motor update cycle. I realize now the problem was the RPM calculation, with the low resolution "encoder" we could really only calculate RPM's in steps of 300 RPM's. TBH is working, so we are working on things that aren't but when I get time we will go back and try bang-bang with rpm calculated as period in lieu of counter, to see the real comparison.

[Ether]

Originally Posted by tr6scott

We are using a banner sensor, (very similar to AB, just smaller packaging, and polarized) two pieces of reflector tape, on a vex hub. We have sized the tape so it is 90 degrees on, 90 degrees off.

Could you please post a photo or a sketch? Or if not, explain in a bit more detail what you mean by "sizing the (2 pieces of) tape so it is 90 degrees on, 90 degrees off" ?

[tr6scott]

See my cad pic, Yellow indicating where the reflector tape is mounted.

90 degrees on, 90 degrees off, 90 degrees on, 90 degrees off, as it spins.

With the low resolution counter method in bang-bang, the difference between (I am going from memory from a couple of weeks ago) in a 10 ms loop, it was 9, 10, or 11 counts, which equated to 3000rpm, 3300rpm, 3600rpm. We realized that if the tape did not start at 180 degrees apart, this was an issue and an error. As we increased the loop time to get more counts, we were reducing the motor output changes which increased the error.

We are using the "gear tooth" mode, and a timer avg over two counts, which is one revolution. This really reduced the error in not placing the reflector tape exactly 180 degrees apart.

Does that make more sense?

Edit, Banner part number DS18VN6LP

[Ether]

Originally Posted by tr6scott

See my cad pic, Yellow indicating where the reflector tape is mounted.
90 degrees on, 90 degrees off, 90 degrees on, 90 degrees off, as it spins.

Yes, that's clear, thank you. Are you counting only rising edges, or both rising and falling?

Originally Posted by tr6scott

We are using the same code that was posted

Are you referring to the code Mark posted? What you are describing is not what he posted. The code he posted is equivalent to the getPeriod() method in the WPILib, which uses the 153KHz sampling and 1μs timer in the FPGA to measure the elapsed time between counts. If you use the code Mark posted, and if you are counting rising and falling edges, and if you have the FPGA sample averaging ring buffer set to 4 samples, you should be getting rock-steady accurate rpm readings.

[tr6scott]

Attached are screen shots of actual code. We are using the "Gear Tooth sensor" mode of the counter, which based on our results, must only be counting the rising edges, and not the falling edges.

The questionmark in the timed task is the TBH control. (Not sure where my son put that one

Scott.

[Ether]

Originally Posted by tr6scott

based on our results, must only be counting the rising edges, and not the falling edges.

3000rpm at 2 counts/rev with FPGA sampling set to 2 should also give you very accurate and jitter-free rpm reading.

This was the portion of your previous post which I must have misinterpreted:

Originally Posted by tr6scott

With the low resolution counter method in bang-bang, the difference between (I am going from memory from a couple of weeks ago) in a 10 ms loop, it was 9, 10, or 11 counts, which equated to 3000rpm, 3300rpm, 3600rpm.

In retrospect, I see you were describing what you were doing, not what you currently are doing.

If you use your present method, I can't see why bang-bang shouldn't work.

[tr6scott]

I agree, the lower performance of the bang-bang method was in the RPM calculation, and not in the control method.

We have moved on, but I have two students that understand that the difference in the performance between the two, was not control algorithm, but the RPM calculation. I would like to go back, and implement bang-bang with the same RPM calculation, and compare bang-bang to TBH for control methods.

Thanks for all your great posts, I learn so much, and in turn, and some of my students do too.