Strange behavior after re-homing printer

p8blr

The issue I'm experiencing is that after an estop, reset, M18, running G28 in any form will result in the endstop being ignored and the axis crashing, or on my 2-motor y-axis the motors will move out of sync on the second homing attempt.

The printer has a 6XD, multiple 3HCs, and a 1XD. All running 3.5.0-rc.3 (however I've noticed this issue on past firmware versions). I am using Teknic ClearPath motors.

The error in Teknic's MSP is: "[94]: Steps during posn recovery - Probable causes: Controller not waiting for position recovery move to complete, brown out, power supply too small." Which is unlikely because I'm using their IPC-5's and I only experience this issue when re-homing, not during normal (high acceleration) moves.

config.g DriveSetup.g variables.g homeall.g homeu.g homev.g homex.g homey.g homez.g

Phaedrux

@p8blr said in Strange behavior after re-homing printer:

All running 3.5.0-rc.3

Update to 3.5.1 which was released recently and test again.

https://github.com/Duet3D/RepRapFirmware/releases/tag/3.5.1

p8blr

@Phaedrux Just updated and still experiencing this issue. I wrote some more reliable homing routines but they did not help.homeall.g homex.g homey.g homez.g

Here's how I can reproduce the issue:

Turn on printer
G28
G1 X100 Y100 Z100 F5000
M18
G28 (ganged y motors lerch and go out of sync with teknic error 94)

Phaedrux

Have you updated to 3.5.2 yet?

p8blr

@Phaedrux No but I can today. I'll report back.

droftarts

@p8blr I think this is an interaction between the Teknic ClearPath motors and the Duet controller. It's hard to say what exactly is happening, because you are calling other macros within the homing files eg "prepare.g", "soundNotifyShort.g", "uvHomeCond.g", "0:/sys/doorLock.g"

If none of these are causing motion, which is possible if this is the second time through the homing sequence, the motors aren't energised until the first G1 X or Y move. The first homing gives the motor it's position via the encodeer, which I think is kept even when you send M18 to disable the motors. The first move in the homing sequence enables the motors and sends step pulses, telling it to move, but the error message says that the motor is trying to recover it's position.

I think adding M17 (to enable the motors) before a one second pause with G4 S1 (which is already in the homing macros) should allow the motors to recover their position, and then be ready to accept new movement commands. If there's any movement in 'prepare.g', you probably want the M17 and pause in before that.

Ian

p8blr

@Phaedrux
I've been stuck here for the last 10 minutes...

Update: I was patient and it finished within the next few minutes!

droftarts

@p8blr It sounds like it has got stuck updating one of the boards. It should be okay to reset, then check which boards didn't update, then update them manually with M997 B[CAN address].

Ian

p8blr

@droftarts @Phaedrux

I'm happy to report back that I'm no longer getting that error on 3.5.2 and with a M17 G4 S1 in my homex.g/homey.g/homez.g files.

Thanks!

droftarts

@p8blr Great! So... solved?

Ian

p8blr

@droftarts SOLVED!

Solved Strange behavior after re-homing printer