Solved unable to home[xyz] using my homing scripts

[Danal]

@spllg said in unable to home[xyz] using my homing scripts:

the strange ting is that homing works when i enter the commands into th console

Hmm... then, just for debugging, try that set of commands in a macro (not in sys) and try them in a 'print job'.

And/or, basic debugging: Shorten the script. Assuming that works, add things back slowly. Minimal is probably something like:

G91 ; relative positioning
G1 H1 X-355 F3000 ; move quickly to X axis endstop and stop there (first pass)
G90

[Phaedrux]

@spllg said in unable to home[xyz] using my homing scripts:

which makes me think that there might be a dwc <-> duet timing issue

That's certainly a possibility, which is why it would help to have things cleaned up as much as possible so that we can rule out configuration error.

In cases like this it can be helpful to go to the web configurator, input your printer specifics, and generate a fresh set of files to compare against. You can backup your config and try the configurator version. If it works and yours doesn't what is the difference?

[spllg]

@Danal created the macro.

executing

M564 H0
G91 ; relative positioning
;M208 X-26 S1 ; set axis minima
G1 Z5 F6000 H2 ; lift Z relative to current position
G1 H1 X-355 F3000 ; move quickly to X axis endstop and stop there (first pass)
G1 X2 F3000 ; go back a few mm
;G1 H1 X-355 F100 ; move slowly to X axis endstop once more (second pass)
;G1 x+26 f3000
;G1 Z-5 F1000 H2 ; lower Z again
;G90 ; absolute positioning
M564 H1

works fine and i can move in x direction after execution. when i uncomment ;G1 H1 X-355 F100 i cannot move in x-direction after execution.

oh no, not again this complete configuration process.

but why did homing via scrip ever work?

[spllg]

@Phaedrux

changing

M201 X1500.00 Y1500.00 Z100.00 E3000.00 ; set accelerations (mm/s^2)
(i was advised to try this but forgot about it)

to

M201 X500.00 Y500.00 Z100.00 E3000.00 ; set accelerations (mm/s^2)

did the trick.

thanks for your assistance.

btw: g- and- m-codes are horrible - the g-m language reminds me on assembler languages of the early 1970's (e.g. honeywell) but i cannot and don't want to remember details.

[Phaedrux]

So at 1500 acceleration the motor was stalling preventing the endstop from being hit and thus hanging?

[spllg]

@Phaedrux looks like - but only for a small feed rate (G1 H1 X-355 F100) and a small distance (2 mm back to end stop) and not if command was executed from the console.

i feel this is strange, maybe someone wants to have a look at the code.

i do not know if the stepper(s) were/are stalling of if the 'firmware was stalling' - only a reset (hard or soft, power cycling the board was not necessary ) could end the faulty state.

[Danal]

@spllg said in unable to home[xyz] using my homing scripts:

only a reset (hard or soft, power cycling the board was not necessary ) could end the faulty state.

There is a reproducible behavior in RRF3: If a homing move does not end, everything hangs, and it takes a reset to get out of that state. Furthermore, if you have a Pi, both the Duet board and the Pi must be reset.

[spllg]

@Danal in my case it is sufficient to reset the duet - don't have to touch the rpi.

[dc42]

@Danal said in unable to home[xyz] using my homing scripts:

@spllg said in unable to home[xyz] using my homing scripts:

only a reset (hard or soft, power cycling the board was not necessary ) could end the faulty state.

There is a reproducible behavior in RRF3: If a homing move does not end, everything hangs, and it takes a reset to get out of that state. Furthermore, if you have a Pi, both the Duet board and the Pi must be reset.

Firmware version? Does it happen in standalone mode as well as in SBC mode?

[spllg]

@dc42

• firmware version = 3.01-RC2
• it happens in sdc mode
• never tried standalone mode (although probably is should)