LabVIEW Encoder not reliably returning Rate

[apalrd]

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?

[rwood359]

Originally Posted by apalrd

It worked two years ago.

After a mid-season correction.

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

[Shawnk]

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.

[Coda]

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

[robotsteve]

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

Thanks-
Steve

[robotsteve]

Originally Posted by Coda

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

Can you explain what this means ??

Thanks-
Steve

[Ryan Gordon]

Originally Posted by Coda

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

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

[jhersh]

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

[grosh]

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?

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

[wireties]

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

double RhsEncoder:IDGet()
{
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

[robotsteve]

Originally Posted by lynca

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.

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

Please explain --

Thanks-
Steve

[Ether]

Originally Posted by wireties

if((dfNewTime - dfLastTime) == 0.0)
	   {
		   dfNewRate = 0.0;
	   }

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

double RhsEncoder:IDGet()
{
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 = dfLastRate;
//don't reset dfLastCount; let it accumulate
}
else
{
dfNewRate = (dfNewCount - dfLastCount)/(dfNewTime - dfLastTime);
dfLastTime = dfNewTime;
dfLastCount = dfNewCount;
}
}

dfLastRate = dfNewRate;
return(dfNewRate);
}

[ayeckley]

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

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.

[jhersh]

Originally Posted by ayeckley

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

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.

Originally Posted by ayeckley

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.

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