Is there a speed sensor input example for Labview?

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

[jhersh]

Originally Posted by 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.

While it probably has no impact on the system as you are using it, the "Gear Tooth Sensor" mode is not likely what you want. Read the context help on that mode. It is meant to allow bi-directional counting based on the length of the pulse. This behavior was available from gear-tooth sensors provided in the kit years ago. If you happen to be near the magic number for your pulse length, you could generate glitches in your speed measurement as you "reverse directions". You would be best served selecting Up/Down counter mode and only configuring and connecting the "Up" channel.

Cheers,
-Joe

[tr6scott]

Thanks for the info Joe, we will change it up to the up/down mode, don't need any anomalies to pop up in competition.

I noticed I did not link to the TBH code posted by 123 last year, here is the link in case someone is searching this out later.

http://www.chiefdelphi.com/media/papers/2674