LabVIEW Encoder not reliably returning Rate

[billbo911]

Originally Posted by Tom Bottiglieri

So, was there ever a fix for this?

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?

[kamocat]

Originally Posted by Doug Norman

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.

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?

[Greg McKaskle]

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

[billbo911]

Originally Posted by Greg McKaskle

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

It has NOT been fixed in this update!

From the 3.1 README:

Known Issues:
When you use more than one encoder, the rate indicator does not update for all encoders. To avoid this behavior, write your own encoder rate code.

[Joe Ross]

Originally Posted by billbo911

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?

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.

[Tom Bottiglieri]

Known Issues:
When you use more than one encoder, the rate indicator does not update for all encoders. To avoid this behavior, write your own encoder rate code.

Or,
"You're holding it wrong."

[jhersh]

Originally Posted by Tom Bottiglieri

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

Yes... they can on slot 6.

[apalrd]

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?

[billbo911]

Originally Posted by apalrd

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?

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.

[jhersh]

Originally Posted by apalrd

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

Because the FPGA image is different than last year.

Originally Posted by apalrd

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?

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

Originally Posted by apalrd

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?

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.

[Alan Anderson]

Originally Posted by billbo911

What would be really nice is if we were told exactly what the "bug" was so that we could fix it.

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

[jhersh]

Originally Posted by billbo911

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.

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

[cabbagekid2]

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.

[Joe Ross]

Originally Posted by cabbagekid2

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.

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.

[rwood359]

Originally Posted by jhersh

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.

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?