Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

Probably never - just preventing a divide by zero error

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

Thanks,
-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

Please feel free to comment here.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

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