LabVIEW Encoder not reliably returning Rate

[ayeckley]

Originally Posted by jhersh

I don't think you are reading my post very carefully.

Probably a correct assessment. Will give it Deeper Thought. Thanks...

Edit: For those that haven't met him in person, Joe is a very valuable resource for teams having problems with their code at regionals (-- ask me how I know). Hopefully he'll be out on the circuit again this year...

[jhersh]

Originally Posted by ayeckley

Edit: For those that haven't met him in peron, Joe is a very valuable resource for teams having problems with their code at regionals (-- ask me how I know). Hopefully he'll be out on the circuit again this year...

Thanks! I'll be at San Antonio (Alamo) and Oklahoma City. I might also be at WPI (depending on a potential conflict).

-Joe

[wireties]

Originally Posted by Ether

When would (dfNewTime - dfLastTime) ever be zero; and if it were, wouldn't you want ...

Probably never - just preventing a divide by zero error

[ayeckley]

Originally Posted by ayeckley

Probably a correct assessment. Will give it Deeper Thought.

Using LabVIEW, our initial application of the workaround seems to result in the "Rate" output scaling based upon the value of "DistancePerCount" (for a given angular velocity using an E4P and 2X decoding). This behavior is nonintuitive and isn't suggested by the Help File for the WPI_EncoderGet.vi even when reading between the lines. We know we didn't accidentally wire into the "Distance" output since the output value is constant rather than accumulating. We haven't had time to test the full range of conditions that this occurs under; that will have to wait for after ship date at this point. It's totally possible that the same thing happend before we applied the workaround; there's no obvious connection between the two in looking at how the workaround was accomplished. It's also totally possible that we accidentally varied some other condition without realizing it and noticed something that wasn't really there at all.

Has anybody else seen this? If this is known behavior then we won't invest any time trying to study it, but if nobody else has experienced it then we probably need to dig deeper after ship date. Thanks...

[jhersh]

Originally Posted by ayeckley

Using LabVIEW, our initial application of the workaround seems to result in the "Rate" output scaling based upon the value of "DistancePerCount" (for a given angular velocity using an E4P and 2X decoding). This behavior is nonintuitive and isn't suggested by the Help File for the WPI_EncoderGet.vi even when reading between the lines.

It should and always has been scaled by the distance-per-count. Without that, the units would not be consistent between distance and rate. The idea is that if you differentiate the distance, you should get (almost) the same answer as rate.

-Joe

[ayeckley]

Ah - so the output units for "rate" are actually inches/sec (or meters per second, or lightyears per femtosecond, etc.) rather than Hz. Thanks for the clarification.

Could I suggest that perhaps next year this VI and the associated help file refer to this output as "velocity" rather than "rate"? I think it would prevent future confusion (I realize it's probably a request that should be directed to WPI rather than NI). Thanks...

[jhersh]

Originally Posted by ayeckley

Could I suggest that perhaps next year this VI and the associated help file refer to this output as "velocity" rather than "rate"? I think it would prevent future confusion (I realize it's probably a request that should be directed to WPI rather than NI). Thanks...

Thanks for the suggestion... please create a tracker at FIRST Forge so we will remember to address it.

Thanks,
-Joe

[Joe Ross]

I thought this might get more attention in this thread. It sounds like NI found the problem in the FPGA and fixed it. Now they want to know if people want the fix released. Here is the thread where Joe Hershberger asked for feedback: http://www.chiefdelphi.com/forums/sh...ad.php?t=94954

[jhersh]

Originally Posted by Joe Ross

I thought this might get more attention in this thread. It sounds like NI found the problem in the FPGA and fixed it. Now they want to know if people want the fix released. Here is the thread where Joe Hershberger asked for feedback: http://www.chiefdelphi.com/forums/sh...ad.php?t=94954

Yes... I had meant to post it here as well... I just forgot.

Please feel free to comment here.

-Joe

[Jared Russell]

I for one would love to use the new for offseason prototyping.

[jhersh]

There is a LabVIEW update posted that should fix the issue described in this thread. C++ and Java updates to follow.

http://firstforge.wpi.edu/sf/frs/do/viewRelease/projects.wpilib/frs.wpilib_labview_update_for_2011_f.frc_2011_labv iew_offseasonupdate?_message=1308686260516

Enjoy!
-Joe

[Joe Ross]

C++ update was posted in September. http://firstforge.wpi.edu/sf/frs/do/...e_for_2011_f_2