Light sensor as shaft encoder too fast for Lab View Code?

[mbone206]

Please help, I am a relatively new mentor, minimum experience with LABView and sensors

My team is using a fisher Price motor, connected to 5/8 inch shaft to operate an extension arm.
Extension Arm is a tube inside tube type design, they indicated they can not put limit switches to
determine if at the required extension length. They put approx 1/8 inch reflective tape on shaft and
are using Banker? QS18V6LV light sensor.

They are using LAB view. The sensor is connected the digital side card. The motor and sensor digitial input is assigned / ref num in Begin. In Teleop, the digital input refnum is wired to the digital get VI. We are using a counter, every time Digital input goes low, set low Boolean flag, when goes hi, if Boolean low flag set, increment counter then set flag to high (only add when sensor went low then high). We manually turned motor sensor/counter code worked fine. When ran motor at full speed, counter did not work. When we slow the motor down, counter worked.

At this point, we commented out the counter code and only put a Boolean LED on teleop front panel to blink every time shaft tape pass sensor. Note: Mainly the only code left is the Robot Main Code, I wanted to minimize user code being caught in any loops as possible problem. When slow, Boolean LED blink fine, correlated with the sensor LED blinking. When increase motor speed, Boolean LED looks like it would skip some flashes, but LED on sensor looked OK, did not skip. It is acting like the motor speed is going too fast for LABView to detect the sensor properly. I am surprised how slow we had to go to get it to work.

I am at a loss of how to help this team if the code can not keep up with the speed of the motor/light sensor.

Any ideals what problem is? Did any one face this problem before?

If there are any other ideals of how to keep track of this type of extension arm (they are using three extension lengths, default fully retracted, extension length 1 (middle pegs) and extension length 2 (highest pegs)) I will also like to disable motor if students trying to retract while arm fully retracted and disable motors if student tries to extend when max extension required is met. I was hoping if the counter worked and correlated to extension are, I can do this in the code. FYI: They are going to use a POT for arm angle, did not get that far.

Thanx for support

Mark

[RyanN]

There's a reason why you have an LabVIEW Encoder block. If I remember correctly, most of the robot code only gets executed every 40ms. If your sensor goes through a transition state during those 40ms, then it won't be counted.

Now I haven't looked under the cover for the encoder VI, but I would have to imagine it is using some sort of an interrupt, or is polling that digital input very quickly.

You may want to take a look at the encoder block under sensors in the WPI library. If you want to make your own, place a very quick (5ms or less) while or timed loop in your Period Tasks VI.

Do what Alan said below. I believe that will work better than what I recommended.

[Alan Anderson]

Use a built-in counter function in the WPI library. It uses the cRIO's hardware support to watch the input signal fast enough for anything you might want to throw at it. In your code, you can look to see when the counter changes value.

[mbone206]

Thank You Allan, I will give it a try

[Speeder]

At this point, we commented out the counter code and only put a Boolean LED on teleop front panel to blink every time shaft tape pass sensor. Note: Mainly the only code left is the Robot Main Code, I wanted to minimize user code being caught in any loops as possible problem. When slow, Boolean LED blink fine, correlated with the sensor LED blinking. When increase motor speed, Boolean LED looks like it would skip some flashes, but LED on sensor looked OK, did not skip. It is acting like the motor speed is going too fast for LABView to detect the sensor properly. I am surprised how slow we had to go to get it to work.

Try putting an indicator (numeric), either in your .vi or on the dashboard. Watch the indicator to see it count up/down. You'll probably see the sensor is working fine. There is a tremendous lag between the cRio and the Classmate display. The LED cannot possibly display accurately anything other than a very slow pulse but the numeric indicator, when the screen refreshes, will show actual counts.

Don

[BornaE]

Originally Posted by Speeder

Try putting an indicator (numeric), either in your .vi or on the dashboard. Watch the indicator to see it count up/down. You'll probably see the sensor is working fine. There is a tremendous lag between the cRio and the Classmate display. The LED cannot possibly display accurately anything other than a very slow pulse but the numeric indicator, when the screen refreshes, will show actual counts.

Don

Your information is inaccurate.

The led shows the information that it can process.
depending on the loop rate(usually maximum 100hz) you can only measure up to 50Hz which is 300rpm.
Anything faster will have to be done using the counter vi's as noted before.

Counter vi's direct the fpga to count the number of pulses. The fpga can count as fast as 50 MHz(this is not exact, but it is much much much faster than the processor without using an interrupt).
Then the processor can ask teh fpga for the count every loop and get a number back and act upon that number 100 times a second.