There has been much discussion over the years about the effectiveness (or lack thereof) of Tetrix encoders. I believe the attached snippet demonstrates the unreliability of encoders. This should effectively be an infinite loop but it ends if the encoders incorrectly return a value of 0.
I've attached two more snippets that demonstrate the buggy encoders. The first calculates the encoder failure rate (~.4%) and the second runs an endless pattern. Eventually, an encoder read is missed and the pattern is considerably changed.
Digging deeper, these failures stem from an unsuccessful i2c read. Rather than report an error, LabVIEW returns 0. This faulty reading fouls up the encoder logic and erratic behavior is the result.
The fix is simple but requires delving into the underlying code Place a while loop around the i2c calls until a sucessful read:
Any comments would be welcome. NI, how about a patch so this longstanding bug can be put to rest?
Have you tried this fix in an autonomous program that communicates with the FCS? In my attempts to resovle this exact issue, doing things like this (adding loops to try to keep going to get a good read) cause significant issues when running with the FCS.
Also the code you show as being the underlying code looks different than what I see. Are you using the latest version of all the toolkits?
I agree that someone from NI should provide some feedback on this issue. Atleast say, "Encoder communication is an issue and we can't do anything to fix it".
Thank you for bring this to our attention. We are aware of the issue and there is a bug report filed on it. I can't speak on when this will be fixed, but hopefully it will be in a future patch or release.
As for workarounds, I know it's probably not feasible for you to edit the underlying code in competition situations. The best I can think of is to look for the 0 return value and treat it as an error, and implement some error handling code for that situation. Unfortunately, this isn't a great solution since there may be times where you do expect the encoder to return 0.
Thanks for your response. Can you confirm that the only issue is in the communication between the Hitechnic controller and the NXT or are there other issues? My experience is that random values other than 0 are also returned. Attached is some logic that I built that actually works really well at addressing all of the issues I found.
However, this code does not work when included in an Autonomous program with FCS communication. I believe this is becuase my code relies on a high sample rate. Becuase the FCS communication or the motor mutex is running in another loop the sample rate drops so low that my code no longer works. I would love some feedback on this logic. I know this logic is not very clean. You are just getting my raw code after weeks worth of troubleshooting.