View Single Post
  #13   Spotlight this post!  
Unread 29-02-2016, 16:49
cantdecide cantdecide is offline
Registered User
FRC #5773 (YAFL Mechatronics)
Team Role: Programmer
 
Join Date: Jan 2016
Rookie Year: 2016
Location: Turkey
Posts: 31
cantdecide is an unknown quantity at this point
Re: Encoder instability

Quote:
Originally Posted by ahartnet View Post
We had an encoder problem where we weren't putting pull up resistors - but that doesn't seem to be needed by this encoder. I've also seen where there's a bad solder joint or a bad crimp that could cause similar problems. Buying a motor that already has the encoder installed and premade cables would seemingly eliminate those problems.

So like others in this thread - it seems to me that the code might be getting hung up. I think in Labview it's probably easier to accidentally do that than in some other languages. Are you able to command other things during this time?

In particular the teleop function in labview (I think, my memory is fuzzy) must complete within a certain amount of time and it could be relatively easy to accidentally take more time than you're allowed (especially if you're doing vision). When you put old code back in - was it all the old code? Or just the old code for controlling your arm.

I'd second Ether's recommendation of a standalone program that does nothing except reading the encoder and move the arm. My suspicion would be that you have something that is holding your processors attention longer than it should.
We're using C++, and the odd thing is, all of the other values(that are set in the same loop as the encoder function) in SmartDashboard are updating while the encoder stalls, so it's probably not software hanging. We also do vision on a co-processor.

Also, when I said "old code", I meant "old complete code that worked". I unfortunately don't have the option of testing an arm at this moment since our robot is bagged, but I'll try to test a standalone encoder + motor assembly's stability tomorrow.