unable to home[xyz] using my homing scripts

Danal

Since you are moving Z in your homex... is Z homed before X?

Phaedrux

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

homex.g
91 ; relative positioning
M208 X-26 S1 ; set axis minima

Looks like you're still got an M208 in homex that isn't commented out. I assume the missing G for G91 is just a copy and paste error.

Insufficient axis homed error message indicates you're trying to move an axis before it's been homed. Usually this is from a Z axis lift. To allow it you use the H2 option, which it appears you are. So when exactly does that error happen?

Are you using homeall as well?

Your config.g has a lot of duplication and commented out sections. Be careful that it doesn't catch you out. Might be time for some clean up.

spllg

@Danal no, but home[xy].g used to be working for weeks. i thought it would be a good idea to make sure the nozzle is away from th bed.

Danal

Even though it worked before...

You might add

M564 H0 ; Allow unhomed axis to move.

and, of course, turn it off later

M564 H1

Phaedrux

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

Even though it worked before...

You might add

M564 H0 ; Allow unhomed axis to move.

and, of course, turn it off later

M564 H1

Shouldn't be necessary since he has H2 on his Z moves to allow unhomed movement.

spllg

@Phaedrux you're right, there is another m208 in homex.g - commented it out. i know that i should do cleanup and i'm sure i will do that when everything is working.

yes, i was using homeall.g but as long as home[xyz] are not working i do not care.

the strange thing is that homing works when i enter the commands into the console one by one which makes me think that there might be a dwc <-> duet timing issue.

Danal

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

Shouldn't be necessary since he has H2 on his Z moves to allow unhomed movement.

Ah, good point, I missed that.

spllg

@Phaedrux done but did not solve my problem

homex.g

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

btw: i can see that G1 Z5 F6000 H2 is executed

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)