LabVIEW Encoder not reliably returning Rate
 

Hello, all.

Yesterday, I was testing and tuning some code on a test chassis. It has two Toughboxes and US Digital encoders (from AndyMark, 250 count) connected to the last four digital inputs on the Digital Sidecar. In code, I found that Encoder Get does not reliably return Rate: I always get Distance (which I found to be accurate in both forward and reverse, by drawing a line on the wheel and reading the distance both ways. Only one of the encoders returns rate, though, which puzzles me. What puzzles me even more is that when I set the Decoding Type to 4x (Because that uses an FPGA Encoder instead of an FPGA Counter) it works - but only until I reboot (when the problem happens again, and is fixed by switching back to 1x).

I dug into the WPI Encoder Get to see if there was a bug there. WPI Counter Get is returning a time of Inf, which Encoder Get is scaling to 0. I went into WPI Counter Get, but that just talks to the FPGA (meaning I cannot dig deeper). When I first had the issue, I probed the Dev Refs and the non-working encoder was using Cntr 1 while the working encoder was using Cntr 0. I did not probe them using the 4x decoding, but when using 4x decoding, the other side (the one that worked before) now has the issue.

I am sure all of the hardware works. I swapped the encoder wires (Between encoders) and the problem is not the encoder itself. I also know that I am not missing the B-phase, because it counts forwards and backwards. Everything I have looked at points to a bug in the FPGA encoder handling, I am using the latest 2011 image. (I guess I could try the 2010 image to see if it works, but I won't have access to the robot until Monday).

Has anyone seen this issue? How did you solve it?

Re: LabVIEW Encoder not reliably returning Rate
 

We had a similar issue in Java.

We had one returning a reasonably rate and a second encoder that was returning essentially garbage. We spent an hour debugging, swapping connectors and twiddling without any success.

We eventually just wrote our own rate functions and moved on.

Re: LabVIEW Encoder not reliably returning Rate
 

We also noticed the encoder rate not working when using 4x decoding and also found the problem coming from the counter returning a time of Inf. The rate returned a value of 0. We changed the decoding to 2x and began receiving rate data.

Re: LabVIEW Encoder not reliably returning Rate
 

I'm really curious if the same issue reproduces in any other language. There have been a few issues with the encoder rates in the past, but I had thought we fixed them all.

Have you tried modifying the averaging settings? How does that setting impact the behavior? Is there any interaction between the 2 resources... i.e. if you make one encoder 4X and the other 2X, does it still do this?

Thanks,
-Joe

<edit>I assume you are using v25 since that is the only non-beta 2011 image</edit>

Re: LabVIEW Encoder not reliably returning Rate
 

We ran into similar issues in Labview over the weekend. Like others, we wrote our own rate code and moved on.

Re: LabVIEW Encoder not reliably returning Rate
 

Today we tested the 9 possible resolution combinations of our two encoders, which we'll call Left and Right. When still, the encoder rates both return 0.0; when moving, the non-working one returns NaN (Not a Number). Here are the results:
Y = Yes/returned decimal value
N = No/returned NaN
Format:
LeftResolution, RightResolution: LeftResult, RightResult
4, 4: N, Y
2, 4: Y, N
1, 4: Y, N

4, 2: N, Y
2, 2: Y, N
1, 2: Y, N

4, 1: N, Y
2, 1: Y, N
1, 1: Y, N

Re: LabVIEW Encoder not reliably returning Rate
 

I did some testing last night:
I found that, after booting up the robot as flashed (1x, 1x) it worked fine for about 2 hours, only rebooting once to change the battery.

After it stopped working, nothing would fix it. Nothing. I rebooted several times and re-downloaded the code. I set the counter to average 2 samples, as advised in this thread, and it worked.

I didn't spend a whole lot of time testing, so I don't know if the problem will re-appear after use. I will try tonight.

Re: LabVIEW Encoder not reliably returning Rate
 

More testing today (about 3 hours or so):

1. The encoder does not work, even averaging 4 samples (only 1 side dosen't work, the other one is fine).

2. After getting it to work, it worked reliably for about an hour before quitting. Then, after changing some settings (like the decoding type) and rebooting, it worked again (and didn't quit while I was working on it)

3. It seems very random, yet always affects the same side. Has anyone from NI been able to reproduce this problem?

4. I am running image v.25

Re: LabVIEW Encoder not reliably returning Rate
 

I have reproduced this and believe it is a bug in our code. I suspect we may document this rather than fix it for this season for two reasons:
1. It would be a risky fix.
2. There is the work around of writing your own rate code.

Re: LabVIEW Encoder not reliably returning Rate
 

We just got started with the encoders that came in the KOP and are running into the same issue as everyone else. Our right side has both rate and distance but the left side only shows distance (rate is 0).

We're going to write our own rate code and was wondering...since distance works for both sides if it's as simple as storing the present distance into a variable and subtracting the saved (previous present distance) from the prsent distance. This will be in periodic task...so that you can divide it by the loop time interval to obtain rate.

We tried this for our working side and came up with similar results as the encoder rate output and are hoping to get it working on the left side.

One thing we noticed though (both with our rate and the VI rate) is that it's REALLY noisy. When maxing out the joystick it bounces around anywhere from zero to 250 rpm (low gear). We had to up the sample average (which cleaned it up a little) and then added a point by point median filter. The only thing bad about this is that the filtered rate is only 100 rpm (can you imagine the noise to produce this!).

Anyone else have noise issues? We're still not sure if the rate data will be workable after all this filtering. More testing today...

Might also be the placement of our wires...will test that today too.

Re: LabVIEW Encoder not reliably returning Rate
 

One thing that was discovered is that every other encoder works... so if you allocate one and ignore it and then allocate another one, you can use the built-in rate function. Naturally this means you have half as many that you can use, but if you don't need that many, this may be a good solution for you.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

We've also had a problem witho our encoder. At first it was working well and i then went on to do some calibration with distance but after about 5 runs of calibration it was then only producing the values 0 and the resolution of .0038..... something. We looked through my coding and found nothing wrong and then assumed hardware issued. Nothing was apparently wrong and we left the issue for later. Unfortunetly, someone wasn't looking and ripped the wiring right out of the encoder. Nonetheless, it died. We reinstalled it but hadn't wired it up again and tried calibration.

Re: LabVIEW Encoder not reliably returning Rate
 

So, was there ever a fix for this?

Re: LabVIEW Encoder not reliably returning Rate
 

Sorry. This was deemed not critical enough to fix in the middle of build season by Management. Fortunately there are 2 workarounds... implement the rate calculations yourself (high CPU burden and less accurate) or construct twice as many encoders as you need and only use the even ones (you can only decode half as many).

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

Can we create these on an unused DIO slot? Unused IO pins on the one DSC we have are hard to come by.

Re: LabVIEW Encoder not reliably returning Rate
 

There was a new LV Update released a couple days ago. LV Update 3.1 for 2011.

Does anyone know if this issue was resolved with that update?

Re: LabVIEW Encoder not reliably returning Rate
 

Do you have a single document describing all the bugs this season?

EDIT:
The Readme describes some of them, but leaves out CAN issues.
Is there a document that shows new issues, BEFORE a fix is created?

Re: LabVIEW Encoder not reliably returning Rate
 

I do not believe this release has a fix for this bug. I saw a post from Joe stating who would not let him fix it. He also didn't indicate whether he had really really fixed it this time, sorta fixed it, turned it into a feature, or other.

I agree there should be a known issues list along with workarounds. I'm not sure if the support forum has one. That would be the appropriate place to request one.

Greg McKaskle

Re: LabVIEW Encoder not reliably returning Rate
 

It has NOT been fixed in this update!

From the 3.1 README:

Re: LabVIEW Encoder not reliably returning Rate
 

The readme for LV Update 3.1 (included in the zip file) lists the encoder rate issue as a known issue and suggests that you write your own rate code.

Re: LabVIEW Encoder not reliably returning Rate
 

Or,
"You're holding it wrong."

Re: LabVIEW Encoder not reliably returning Rate
 

Yes... they can on slot 6.

Re: LabVIEW Encoder not reliably returning Rate
 

Is there any reason why it worked fine last year (cRio image 20) but doesn't work this year (tested cRio image 25)?

Also - Will it care if I allocate the dummy encoders on slot 6, if I don't actually have a DIO module on slot 6?

Also again - Is it that every other encoder works, or every other encoder created works? If I were to edit the VI that assigns counters (or encoders), and told it to only assign the odd or even counters (or encoders), would that fix things?

Re: LabVIEW Encoder not reliably returning Rate
 

What would be really nice is if we were told exactly what the "bug" was so that we could fix it.
I know that we can create our own code, but knowing what is wrong with the current one could help us NOT create our own buggy code.

Re: LabVIEW Encoder not reliably returning Rate
 

Because the FPGA image is different than last year.

No... it won't care. And neither will you because you aren't using them.

Based on reports, it is every other encoder... so if you change the VI to assign only even encoders, then they should all work. I have not actually tried this approach so I can't guarantee that it will work, but it sounds reasonable.

Re: LabVIEW Encoder not reliably returning Rate
 

We can't touch the FPGA code. It's going to stay broke.

Re: LabVIEW Encoder not reliably returning Rate
 

The actual bug is most likely in the FPGA (we believe... we haven't actually debugged to find what the bug is exactly) and therefore not implemented the same way you would implement it in your code. Therefore there should be little risk of you writing code with the same problem.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

No one postd anything about having a lot of noise from the encodes so I figure I should ask again.....how does the signal from the encoders look? Ours looks extremely ugly. To the point where when we apply a median filer what we get out is almost half of the peak rpm being measured.

Re: LabVIEW Encoder not reliably returning Rate
 

You can reduce the noise by using 1x decoding rather then 2x or 4x. This eliminates noise introduced by the phase error of the encoder.

Re: LabVIEW Encoder not reliably returning Rate
 

Even starting with zero or one?
Is the procedure to start with a dummy and then daisy-chain error out and error in to create the sequence?

Re: LabVIEW Encoder not reliably returning Rate
 

NI really doesn't believe that this isn't important enough to fix?

Re: LabVIEW Encoder not reliably returning Rate
 

A look inside any industrial control encoder interface shows that typically there is quite a lot of digital filtering done on the A,B,I signals before introduction to the count tracking logic. Take a look at the old HP HCTL-20xx data sheet as an example. They employed multiple stages of demetastabilizing flip-flops, these are necessary because any input signal is asynchronous to the processor clock, meaning that sooner or later you will get a clock edge which is coincident with a signal edge, causing flip-flops to make wrong decisions. After the inputs are synchronized, then more flip-flops are needed to verify that the A,B signals are not in illegal states, because real encoders do not produce signals which are in strict quadrature. After the signals are verified good, then the up/down logic may increment or decrement the encoder tracking count. I suspect there is none of this within the NI device and we can't do much to fix it. On the electrical side, we can filter the power connections to the encoder, shield the wires, shorten the wires, and provide the correct pullup load (US Digital calls for 2.7K ohm pullups) that's about it.

Re: LabVIEW Encoder not reliably returning Rate
 

During the beta period and the FRC season, FIRST engineers and NI engineers discuss the risk and impact of all bugs that are found. Some bugs are worth fixing, but others are difficult or risky to fix. Sometimes, as long as the customer is aware of it and they have a good workaround, the best course of action is to leave things alone.

This bug was deferred, meaning it will be fixed after the season is over, and when side-effects from the fix can be discovered somewhere other than your robot on Thursday before an event.

Greg McKaskle

Re: LabVIEW Encoder not reliably returning Rate
 

This year encoders will almost certainly be used on most robots so I find it interesting that this was deferred so quickly. I understand NI's point of view (I know how you feel, I've worked in development for 6 years and SQA for 3 and I know how it's like when there are deadlines to meet) but as the end user this seems kind of like an easy fix to do. The hardware is the same as last year so it must be on the code side of things. It worked last year so there was working code before but this year it's broken so it must be a regression. Usually when I have to deal with regressions (unless code was refactored?) it's easy enough for me to do comparisons of code from when it did work to when it didn't and see what caused the issue.

Can an official help document, or something to that effect, be provided to teams? I've read through this thread and I think most of us are still at a loss on the best way to workaround this issue.

Best Regards

Re: LabVIEW Encoder not reliably returning Rate
 

I agree. Some type of how to should be provided to teams for this "workaround". I have opened up the encoder VIs and I don't even know where to start changing things. It doesn't at all look like how we use to do it in C with the IFI controller.

For our noise issue, we are at 1x and still have 50% being noise. Not sure what to do about this now. Is it possible that there's dirt or something in the encoder when we put it together that could cause this? What kind of noise is everyone else getting? I would post a screen capture but our robot is being worked on and not operational at the moment.

Re: LabVIEW Encoder not reliably returning Rate
 

The workaround is to recreate the "rate" from the "distance".
You subtract the previous distance from the latest distance, and divide by the seconds in between the two measurements.

Or use CAN.

Re: LabVIEW Encoder not reliably returning Rate
 

We tried this and our rate for left and right are not close. For some reason the encoder that doesn't read rate also doesn't read distance accurately. It reads, but it just thinks it's moving a lot more than it actually does.

Re: LabVIEW Encoder not reliably returning Rate
 

Distance is just an integration of rate; If distance works then rate must work too, right? Or more clearly written, if rate doesn't work then distance won't work either.

Re: LabVIEW Encoder not reliably returning Rate
 

If you look back at the first post, the issue with calculating rate is that the encoder returns an elapsed time of inf.
It appears that rate is calculated from differentiating distance, not the other way around.

Re: LabVIEW Encoder not reliably returning Rate
 

Looks like your right. However it seems like the issue stems even further then that based on cabbagekid2's tests... hmmm

Re: LabVIEW Encoder not reliably returning Rate
 

It's possible that you have damaged the encoder and the signal coming from one of them is missing part of the signal. It could also be that the encoder is to far from he sensor and only partially reading it. This assumes that you are using an encoder that you build, not an enclosed unit.

If it really is digital switching noise on the wires, there are digital filters available to you in the hardware, but they are not enabled by default (since we have no idea what the frequency of your input signal should be). You can configure them with VIs in the Advanced Digital Input palette.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

That is correct. The rate is calculated based on detecting when the position changes.

Re: LabVIEW Encoder not reliably returning Rate
 

I believe there may be another workaround, and that is to only use the "even" encoders. I'd have to test it out myself to say for sure, though. I'll look into it.

At the very least, that would be a great way to validate your encoder hardware vs. the decoding.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

It worked two years ago.

It worked last year.

It does not work this year.

What changed? Why did you decide to re-write code that worked well? How did none of the beta test teams find this?

We consider encoders and potentiometers to be extremely valuable sensors. The inability to trust the WPIlib to handle encoders correctly is extremely annoying, as is the black-box nature of the FPGA image which prevents us from fixing the root cause.

Could you revert to last years encoder code? It is known to work, and I know of no differences between this years and last years (or the year before that).

Re: LabVIEW Encoder not reliably returning Rate
 

The FPGA image changed. That's where the rate calculation is performed.

Re: LabVIEW Encoder not reliably returning Rate
 

Better question: What part of the FPGA encoder handling changed? I never had any issues with it, it worked as expected, why not leave it?

Re: LabVIEW Encoder not reliably returning Rate
 

After a mid-season correction.

Re: LabVIEW Encoder not reliably returning Rate
 

we at team 171 had the same problem and we don't really know how to write rate code (We are new to using labview). but we found out that you can alternate encoders quickly and use them in a series and not in parellel and this fixed our encoder issues.

Re: LabVIEW Encoder not reliably returning Rate
 

ANDYB - "we at team 171 had the same problem and we don't really know how to write rate code (We are new to using labview). but we found out that you can alternate encoders quickly and use them in a series and not in parellel and this fixed our encoder issues."

Would you be able to post an example of this? Team 1802 is looking for some help and we dont know how to write our own rate code either.

Re: LabVIEW Encoder not reliably returning Rate
 

What we meant to say was that if the Encoder Get Function was placed inside of sequential frames of a flat sequence structure. One after another. You can tunnel the rate outside of the sequence structure. That is our solution, its rather simple and doesn't cure the problem, but it treats the symptoms and you don't have to write rate code

Computing Rate
 

What do you mean by "writing your own rate code"? We're using Java, not Labview.

Thanks-
Steve

Re: LabVIEW Encoder not reliably returning Rate
 

Can you explain what this means ??

Thanks-
Steve

Re: LabVIEW Encoder not reliably returning Rate
 

I think it would be extremely beneficial to all of us if you could perhaps post a screenshot so we can all try it ourselves :)

Re: LabVIEW Encoder not reliably returning Rate
 

I've sat down and tried using all of the quadrature decoding resources and discovered something a bit odd. In 4x decoding, the 2 odd numbered decoders return rate correctly, the other 2 do not. In 1x or 2x decoding, the first 3 even numbered decoders and the last (odd) decoder return rate correctly.

I've modified the Open and Close VIs for the Counter and Encoder APIs to have them only use the ones that work. If you need the rate output, you can replace these after installing the update. Extract this to C:\Program Files\National Instruments\LabVIEW 8.6 or wherever you installed LabVIEW. If you install a new update or reinstall anything, you need to replace them again. Note that this may cause confusion for your team if you use more than one computer for development and you forget to install these on all development machines.

The downside to this work-around is that you now can only use 2 encoders in 4x mode and 4 encoders in 2x or 1x mode.

You always have the option to write your own rate algorithm based on the distance instead, but that may be less accurate.

-Joe

Re: LabVIEW Encoder not reliably returning Rate
 

OMG! We have spend two 5am-7pm days working around the builders trying to fix the same encoder problem. Now we find out it wasn't our code or hardware AND their won't be a fix?:ahh:

I have no clue how to write our own code. Can anyone explain?

Re: LabVIEW Encoder not reliably returning Rate
 

This was our fix for exactly the same problem. We created our own encoder class and put in this PIDGet method:

double RhsEncoder::PIDGet()
{
double dfNewRate;
double dfNewCount = pQuadrature->GetDistance();
double dfNewTime = GetClock();

if (pQuadrature->GetStopped())
{
dfNewRate = 0.0;
}
else
{
// calc the rate

if((dfNewTime - dfLastTime) == 0.0)
{
dfNewRate = 0.0;
}
else
{
dfNewRate = (dfNewCount - dfLastCount)/(dfNewTime -
dfLastTime);
}
}

dfLastTime = dfNewTime;
dfLastCount = dfNewCount;
return(dfNewRate);
}


HTH

Re: LabVIEW Encoder not reliably returning Rate
 

What do you mean about writing your own rate encoder??

Please explain --

Thanks-
Steve

Re: LabVIEW Encoder not reliably returning Rate
 

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

Re: LabVIEW Encoder not reliably returning Rate
 

Writing fixed timebase rate codes (as opposed to interrupt-triggered ones)gets complicated, especially at low rates when there are relatively few ticks per loop (aka discretization error). Looks like we'll have to add a second DSC and DIO module to our already-completed electronics board be able to use closed-loop control for our drive motors since all of our DIO channels are used (assuming I'm understanding the "every other channel" workaround correctly).:mad:

Unless: Joe - any chance someone at NI could provide some reference code based on an interrupt-driven approach instead of a timed loop approach? We just don't have enough time between now and ship date to write and test our own version.

Re: LabVIEW Encoder not reliably returning Rate
 

I don't think you are reading my post very carefully. The issue has nothing to do with the I/O on the side car... only the decoding engines in the FPGA. Adding a side car will not help. You simply need to allocate the encoder or counter objects that have functioning timer modules (rate calculators). I have provided VIs that will do just that. If you use the VIs I posted, you don't need to call anything twice or whatever other things people have been saying to do. Just use the API as it was intended and it should work for you.

I don't have that ready to go, so I would be trying to make sure it was perfect too, and with just a few days left, it's probably not worth while and wouldn't be perfect. Perhaps some other team has implemented it this way and wants to share.

The work around above allows you to read up to 6 encoders with the FPGA calculating rate for you. Only if you need more than 6, do I recommend writing your own rate algorithm.

-Joe

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