DC Motor Encoder adds control dropout

[Steve_Brooks]

I have been helping a team with a manipulator arm.  The have a DC Motor with an encoder on it.  They have the power set to 20% and use the encoder to set the limit of the arm movement.  They were driving last night and were having control dropouts.  I have narrowed it down to reading the encoder on this DC motor.  If we take this out control is perfect, while left in we get 3 second drop outs every 10 - 20 seconds.

Any thoughts?

[Kevin_F]

Hey Steve,

Could you include a screenshot of your block diagram with the DC control in it?  My first thought is that if you are using the move fixed distance with a wait enabled instead of returning immediately that your program is blocking at that VI until it times out (3 or more seconds) and that is long enough of not updating the watchdog to cause a motor timeout. 

[Steve_Brooks]

Here is a screenshot of the code.  I am not using the fixed distance, just the normal DC power move.

[Steve_Brooks]

Just to add a little more data, the control drop out is not just on the motor tied to this encoder, but all robot functionality.  Also the dropout is not for 3 seconds (seems like a long time when trying to drive ) but closer to 1.5 or less.

-Steve

[Kevin_F]

Hey Steve,

I don't see something that would obviously cause this so I am going to try and set it up here and see if I can replicate what you are seeing.

[Steve_Brooks]

I have recreated this with a very basic VI on a completely seperate robot.  For some reason I cannot attach the VI to this post so I will put in a screen capture.

[ESearl]

Hi Steve,

Just to verify, by "control dropout" you mean that motors are still running but arent getting updated when you manipulate the joystick right?

It sounds like reading the motor encoder is taking too long which is blocking the loop from finishing thus preventing the program from processing new commands from the fcs and updating the motor power.

The Encoder vi does attempt to retry reading the encoders if it fails initially. It may be that it is continually failing and then timing out.

One thing you might try is sequencing a wait for 10 - 20 ms directly beofre or after the encoder reading. This will help to prevent the initial failure that induces the timeout behavior.

I will also dig around and see what I can find out. Thanks for the report.

-Ethan

[Steve_Brooks]

Ethan,

Control Dropout means whatever state the robot is in when this occurs it continues in this state.  Tried the timing thing, but it didn't work.

Thanks for looking into this,

-Steve

[ESearl]

Hey Steve,

I've reproduced the issue here. The problem is sudden cascading i2c failures that last generally until the tetrix watchdog resets the controller. I've found adding waits inside the encoder vi reduces the severity but doesn't eliminate the problem entirely. I'll keep investigating.

-Ethan