Thoughts on Updated Motor/Encoder Test and Questions

I get that you will have to miss a lot of steps to see a difference, maybe you didn’t build your custom controller well, or there’s an intermittent short going on due to stray piece of saw dust… who knows, but as my kids like to play with me, “Would you rather…” have a test that can show you have a problem under some circumstances, or not have the test at all.

My personal experience tells me it will continue without an error condition (other than sled not keeping up), and though this may be a long explanation, I think it’s helpful at least to document what’s going on for posterity. When working on the four motor design with external encoders, I’ve had the situation where the encoders have bound up (don’t turn) while the motor is turning. This is equivalent to having the encoders disconnected (no changes coming from the encoder). When this has happened during a move, the motor that has the faulty encoder signal runs to full power for a period of time but then stops… and how long it takes to stop depends strictly on how long of a move you sent.

When you send a move (either a coordinated move of all motors or a single axis move of a single motor) it divides the movement into a series of steps based upon the PID loop interval (10,000 us) and the feed rate of the move. After each step is completed, the PID controller recomputes and adjustments to the PWM duty cycle is made. When all the steps are completed, an “end move” is performed that sets the PID setpoint to what the target was and therefore, PWM duty cycle goes to zero and the motor stops.

So, if you do a move of say 2.5-inch with a feedrate of 30 inches per min (0.5 inch per second), the total time of the move is 5 seconds (I was wrong earlier about RPM having an affect, its the feedrate instead). When the PID controller recomputes after every step, it thinks that the motor hasn’t moved because the encoder value hasn’t changed and therefore increases the PWM duty cycle… it continues to do this every step until PWM is 255. After 5 seconds, when the time is up, PID setpoint is set to the target and the PID controller sets duty cycle to 0 and motor stops.

The advantage of doing it as a B-code is that I can write the function so that it spews out the results as text to ground control (if someone makes a macro to run that B-code) just like the current test does, but for webcontrol I can parse those messages and do something more ‘fancy’. In reality, I can do all of this in webcontrol without a new b-code by issuing a series of motion commands and measurement reads, but then GC users wouldn’t be able to use it. So making it a B-code at least gets it to a point where GC users can macro the test… like the PID tuning tests.

singleAxisMove is a function in motion.cpp that is called by the B09 command. And I’m not trying to suggest a motor running at maximum voltage for three seconds will turn a single revolution. What I’m trying to say is that it you do a singleaxismove for 2.5 inches (63.5 mm) with a feedrate of 30 ipm, then it will run for 5 seconds (not 3… see my long post above).

That is correct if the encoder is working, but if the encoders are not connected/not working, it will run at full duty cycle (see my long post above). The point I’m trying to make, and so far failing miserably at, is that the result of issuing a B09 L63.5 S800 command when the encoders are not connected properly is no different than telling the motors to run at full duty cycle for 4.7625 seconds.

And I should have noted in my long winded post above, I had positional error checking turned off when the encoder bound up. I was trying to get the machine to work in general and having to constantly clear the sled alarm wasn’t helping. To @dlang’s point, under normal circumstances, the singleAxismove would have failed before being completed but positional error checking will be disabled when we are doing the new test, as it is done with the current motor/encoder test.

1 Like