Important: Bug found with Counters, Encoders, and Ultrasonic sensors

[BradAMiller]

There is a problem that was discovered in the FPGA that causes reading the period or rate on an encoder or counter to be incorrect. It also causes unreliable readings from ultrasonic sensors using the Ultrasonic class. We are currently working on a fix for the problem and it will be in the next update. If you are using these features of the library, continue planning on using them but be aware that your results might not be correct until the next update.

Counters and encoders are correctly reporting counts (just not time related values). So using an encoder to measure distance is not a problem.

Since the encoder/counter/ultrasonic problem is in the hardware, it applies to LabVIEW programs as well as C/C++ programs.

[mlest2011]

i have just a simple question.
Can you run the encoder program without having to run it through the cRIO, or does the cRIO have to be connected to it at all times. I ask this because we want to do an encoder program that counts but we want to run it to make sure that everything is right before we run it through the cRIO.

Please let me know and thanks for your time,
~emmie93~



you can email me at mandm11@gmail.com.

[Joe Hershberger]

I'm not quite sure what you are trying to do. If you aren't going through the cRIO, then where do you have the encoder plugged in?

[mlest2011]

we wanted to see if we could run the encoder only on labveiw. before we deploy it to the cRIO. So we wouldn't have it hooked up to anything.

[tvrobotics]

we wanted to see if we could run the encoder only on labveiw. before we deploy it to the cRIO. So we wouldn't have it hooked up to anything.

Well, you can't have it just floating in thin air...


anyway, no i don't think so. You can run it without loading it permanently though.

[mlest2011]

thanks i have noticed that....

I have changed the way to wording of the questions

1. What can I display on our front panel to represent the signals A and B, the inputs of the encoder. I'm writing an encoder program and I'd like to test it, on the computer, before I run it down to the robot.
2. What do Channel A and Channel B represent.
3. How can Channel A and Channel B both be wired into DIO Channel 1, in slot 4.

Thanks
~emmie the great blonde~

[Joe Hershberger]

1. What can I display on our front panel to represent the signals A and B, the inputs of the encoder. I'm writing an encoder program and I'd like to test it, on the computer, before I run it down to the robot.
2. What do Channel A and Channel B represent.
3. How can Channel A and Channel B both be wired into DIO Channel 1, in slot

1. I'm afraid that if you want to test your application in the sense that you want to test code that you are writing that will do something with data that the library returns, you currently need to copy that code (or preferably make it a subVI) and put it in a new VI that is under the My Computer target of your project. You can then simulate the output of the encoder Get by just using the "i" of a loop counter or something.

If you want to test the API use itself, I'm afraid you can't. We don't currently have a simulation feature for this API.

2. They are digital inputs that you need to call Open Digital Input, which returns a reference that you pass through ToDigitalSource.vi and then into the Encoder Open. Look at the Encoder Example on the getting started window.

3. It certainly wouldn't do much. You should open a digital input for each of the two channels that you have plugged in to the digital sidecar digital I/O lines.

[MikeE]

There is a problem that was discovered in the FPGA that causes reading the period or rate on an encoder or counter to be incorrect. It also causes unreliable readings from ultrasonic sensors using the Ultrasonic class. We are currently working on a fix for the problem and it will be in the next update. If you are using these features of the library, continue planning on using them but be aware that your results might not be correct until the next update.

Counters and encoders are correctly reporting counts (just not time related values). So using an encoder to measure distance is not a problem.

Since the encoder/counter/ultrasonic problem is in the hardware, it applies to LabVIEW programs as well as C/C++ programs.

Is there an approximate schedule for the next update?
It would be helpful to know for planning purposes whether it's likely to be available in the next couple of days or in a week or two.

Many thanks for all of the effort being put in by WPI, NI and many others. You have done an awesome job guiding so many teams through a complex system.

[Joe Hershberger]

Is there an approximate schedule for the next update?
It would be helpful to know for planning purposes whether it's likely to be available in the next couple of days or in a week or two.

We are beta testing an update tomorrow and plan to release by the end of this week.

[Charles Harris]

What is the current ETA for the fix to this bug?

Thank you.