Is there a speed sensor input example for Labview?

[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