Mini5+ 3.3b2 homing woes

jay_s_uk

@carcamerarig if you run this code as your homex, does it stall immediately?

M915 P0 S-127 H10 R1 ; Set very sensitive stall detect
M574 X1 S3 ; configure endstop for stall detection
G1 X200 H1 ; Should stall pretty much immediately

carcamerarig

@jay_s_uk said in Mini5+ 3.3b2 homing woes:

M915 P0 S-127 H10 R1 ; Set very sensitive stall detect M574 X1 S3 ; configure endstop for stall detection G1 X200 H1 ; Should stall pretty much immediately

it does nothing except I hear the motor engage and the home X button stays blue in DWC

jay_s_uk

@carcamerarig thats good.
Means its stalling. You can confirm by sending M84 and then rerunning that code.
I would suggest you use the example homing files I have you a link to earlier and rather that using a H value of 400, aim for something around 250. Then start tweaking the S value to suit.
Not much other help I can give you really as its very machine specific.
But at least we know its working. You just need to find that sweet spot

carcamerarig

@droftarts said in Mini5+ 3.3b2 homing woes:

@carcamerarig said in Mini5+ 3.3b2 homing woes:

but the Y axis still activates even though I only home X??

I can at least help with this bit, after watching your video; you've got this in your config.g:
M564 H0							; allow unhomed movement
and this in your homex.g (which also explains the X move after it attempts to home):
G1 X125 Y100 F6000	; centre the head and set a reasonable feed rate
Ian

Thanks Ian
so one needs to go, my understanding is M564 H0 allows the movement even though its not un-homed (H1 forbids un-homed)
im telling it to:
G1 H2 X10 Z5 ; Move Z and X up for a running start
then
G1 H1 X-270 F4000

Im not sure how that line G1 X125 Y100 F6000 came to be but if I understood correctly why do I even need this command, is then moving to the centre of the bed a common command and if it is the Y parameter shouldn't be here?

dc42

@carcamerarig said in Mini5+ 3.3b2 homing woes:

so one needs to go, my understanding is M564 H0 allows the movement even though its not un-homed (H1 forbids un-homed)

No. G1 H1 and G1 H2 moves are p-rmitted even when the axis has not been homed.

im telling it to:

G1 H2 X10 Z5 ; Move Z and X up for a running start

then

G1 H1 X-270 F4000

I assume you also have G91 before those commands so that the movement coordinates you supply are relative. If you are running firmware 3.3beta, try this instead:

G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X

If you are running earlier firmware, then instead of M17 X use G1 H2 X0.02.

droftarts

@carcamerarig Unless your homeall.g calls each individual home[axis].g command, you're far more likely to use homeall.g than the others, once the printer is up and running correctly. So I wouldn't worry too much about what's in homex.g.

I'd remove the M564 H0 from your config.g. This starts the printer in a state where it's possible to crash it.

Note the difference between G1 H1 ... and G1 H2 ... see https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_G0_G1_Move

H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).
H2 Individual motor mode. X refers to the X motor, Y refers to the Y motor, and so on. Normally used with relative motor coordinates (see G91).

Has this configuration set of files been generated by someone else? It doesn't look like it's come from the configuration tool https://configtool.reprapfirmware.org/Start and as you said you're new to Duet, it's pretty complicated. It's always a bit of a gamble starting with someone else's config!

Ian

jay_s_uk

@dc42 said in Mini5+ 3.3b2 homing woes:

M17

Can you add this to the gcode page as theres currently no information about what it is or what it does, other than its been implemented in the change notes

carcamerarig

@dc42 said in Mini5+ 3.3b2 homing woes:

@carcamerarig said in Mini5+ 3.3b2 homing woes:

so one needs to go, my understanding is M564 H0 allows the movement even though its not un-homed (H1 forbids un-homed)

No. G1 H1 and G1 H2 moves are p-rmitted even when the axis has not been homed.

im telling it to:

G1 H2 X10 Z5 ; Move Z and X up for a running start

then

G1 H1 X-270 F4000

I assume you also have G91 before those commands so that the movement coordinates you supply are relative. If you are running firmware 3.3beta, try this instead:
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X
If you are running earlier firmware, then instead of M17 X use G1 H2 X0.02.

and keep this part of the code?

M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X30           	; reduce motor current to 50% to prevent belts slipping

so the file would look like this complete:

; homex.g
; called to home the X axis
;
M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X30           	; reduce motor current to 50% to prevent belts slipping
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X

carcamerarig

@droftarts said in Mini5+ 3.3b2 homing woes:

@carcamerarig Unless your homeall.g calls each individual home[axis].g command, you're far more likely to use homeall.g than the others, once the printer is up and running correctly. So I wouldn't worry too much about what's in homex.g.

I'd remove the M564 H0 from your config.g. This starts the printer in a state where it's possible to crash it.

Note the difference between G1 H1 ... and G1 H2 ... see https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_G0_G1_Move

H1 terminate the move when the endstop switch is triggered and set the axis position to the axis limit defined by M208. On delta printers, H1 also selects individual motor mode as for H2. Normally used with relative motor coordinates (see G91).
H2 Individual motor mode. X refers to the X motor, Y refers to the Y motor, and so on. Normally used with relative motor coordinates (see G91).

Has this configuration set of files been generated by someone else? It doesn't look like it's come from the configuration tool https://configtool.reprapfirmware.org/Start and as you said you're new to Duet, it's pretty complicated. It's always a bit of a gamble starting with someone else's config!

Ian

Yes it was given to me, somebody started to help me out but then ive ended up actually with a number of people chiming in and out with very much welcomed support but I think I got lost in translation. Its ended up as a try this try that situation...
You're the second person to suggest binning the home X Y in favour of home ALL it concerned me as why include it if its not necessary?

droftarts

@jay_s_uk said in Mini5+ 3.3b2 homing woes:

M17

Can you add this to the gcode page as theres currently no information about what it is or what it does, other than its been implemented in the change notes

Done. https://duet3d.dozuki.com/Wiki/Gcode?revisionid=HEAD#Section_M17_Enable_all_stepper_motors
I also added a note about how to use it for stealthChop tuning.

Edit: I probably need to add it to these pages, too...
https://duet3d.dozuki.com/Wiki/Stall_detection_and_sensorless_homing
https://duet3d.dozuki.com/Wiki/Tuning_Stepper_Motor_Drivers#Section_stealthChop_tuning

Ian

droftarts

@carcamerarig said in Mini5+ 3.3b2 homing woes:

Yes it was given to me, somebody started to help me out but then ive ended up actually with a number of people chiming in and out with very much welcomed support but I think I got lost in translation. Its ended up as a try this try that situation...

Fair enough. We'll try to get it sorted, but once you understand what each part is doing, probably worth going back and tidying it up, and adding notes for yourself. Don't forget to back it up as well, just in case your SD card dies!

You're the second person to suggest binning the home X Y in favour of home ALL it concerned me as why include it if its not necessary?

Because some people's machines need this functionality. And sometimes you do need to home just one axis.

Ian

carcamerarig

@dc42 said in Mini5+ 3.3b2 homing woes:

@carcamerarig said in Mini5+ 3.3b2 homing woes:

so one needs to go, my understanding is M564 H0 allows the movement even though its not un-homed (H1 forbids un-homed)

No. G1 H1 and G1 H2 moves are p-rmitted even when the axis has not been homed.

im telling it to:

G1 H2 X10 Z5 ; Move Z and X up for a running start

then

G1 H1 X-270 F4000

I assume you also have G91 before those commands so that the movement coordinates you supply are relative. If you are running firmware 3.3beta, try this instead:
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X
If you are running earlier firmware, then instead of M17 X use G1 H2 X0.02.

Awesome thank you, so im cooking on gas for X and Y

X and Y axis playing nicely

So using the same code can I configure Z the same? I have tested the sperpinda with a metallic object mid homeALL move and it triggers:

G28
Error: Z probe was not triggered during probing move

my current homeZ

; homez.g
; called to home the Z axis
;
M561
G91							; relative mode
G1 Z4 F6000 H2				; raise head 4mm to ensure it is above the Z probe trigger height
G90							; back to absolute mode
G1 X100 Y100 H2  F6000		; put head over the centre of the bed, or wherever you want to probe
G30							; lower head, stop when probe triggered and set Z to trigger height

im quite worried about burying the nozzle into the bed lol

carcamerarig

@dc42
Sorry and is it safe to now to increase the motor current back to 100% or is it generally left in the reduced state?

; homex.g
; called to home the X axis
;
M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X40           	; reduce motor current to 50% to prevent belts slipping
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X

droftarts

@carcamerarig Set it back to 100%, or it will have reduced torque, and will skip.

Ian

carcamerarig

@droftarts said in Mini5+ 3.3b2 homing woes:

@carcamerarig Set it back to 100%, or it will have reduced torque, and will skip.

Ian

So setting it back to 100% causes it to crash again, 60% causes a triple bounce before stalling.

droftarts

@carcamerarig Sorry, I misunderstood. You need to leave the setting at 40% while homing, then set it back to 100% after. eg:

; homex.g
; called to home the X axis
;
M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X40           	; reduce motor current to 50% to prevent belts slipping
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X
M913 X100

Ian

carcamerarig

@droftarts said in Mini5+ 3.3b2 homing woes:

@carcamerarig Sorry, I misunderstood. You need to leave the setting at 40% while homing, then set it back to 100% after. eg:

; homex.g
; called to home the X axis
;
M561
M400                    ; make sure everything has stopped before we make changes
M574 X1 S3            	; set endstops to use motor stall
M913 X40           	; reduce motor current to 50% to prevent belts slipping
G91
G1 H2 Z5 ; Move Z up
M17 X ; energise X motor for stealthChop tuning
G4 P100 ; pause to allow the driver to establish the motor parameters
G1 H1 X-270 F4000 ; home X
M913 X100

Ian

I was asking that very question to myself, did you mean 913 X100. Me being a numpty

just set my probe height and homed Z all good but can I tidy up the code and include M17 or does the probe make it different?

; homez.g
; called to home the Z axis
;
M561
G91							; relative mode
G1 Z4 F6000 H2				; raise head 4mm to ensure it is above the Z probe trigger height
G90							; back to absolute mode
G1 X100 Y100 H2  F6000		; put head over the centre of the bed, or wherever you want to probe
G30							; lower head, stop when probe triggered and set Z to trigger height

droftarts

@carcamerarig You can tune stealthChop on Z if you want (with M17 Z and a pause), but realistically you're not using stall detection/sensor less homing on Z, so it's not necessary.

I've gone back to the datasheet (https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_V103.pdf page 35 '6.1 Automatic Tuning), and I think there's one more change to be made.

In the datasheet it says that the motor has to be idle for greater than 130ms. So you need to change the G4 P100 after M17 to G4 P150.

stealthChop will continue to be tuned on the fly, on all axes, so long as it pauses for longer than 130ms after being enabled, and then moves the motor at around 60-300RPM; this will be quite common during a print. It's just that the first movement needs to be correct for sensorless homing to work.

Ian

carcamerarig

@droftarts said in Mini5+ 3.3b2 homing woes:

@carcamerarig You can tune stealthChop on Z if you want (with M17 Z and a pause), but realistically you're not using stall detection/sensor less homing on Z, so it's not necessary.

I've gone back to the datasheet (https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_V103.pdf page 35 '6.1 Automatic Tuning), and I think there's one more change to be made.

In the datasheet it says that the motor has to be idle for greater than 130ms. So you need to change the G4 P100 after M17 to G4 P150.

stealthChop will continue to be tuned on the fly, on all axes, so long as it pauses for longer than 130ms after being enabled, and then moves the motor at around 60-300RPM; this will be quite common during a print. It's just that the first movement needs to be correct for sensorless homing to work.

Ian

Amazing thanks so much.
yeah so I realise the probe is the end stop for Z but I was thinking at the top of the frame 415 in my case, chances of it doing that are probably never but I while im here I might as well get It done? What I didn't understand was will the probe still be the "end stop" for the bed if I use M17? I sometimes send the X carriage to hit the top frame to check the X carriage is level, at the moment it unsets the homing. I don't know if its a more elegant solution to set the Z height in printer geometry or use the frame as an end stop?

droftarts

@carcamerarig Yes, you can use the motor stall homing on Z at the top of the frame, and keep the probe for bed levelling. I'd write the motor stall as a separate macro, so you call it when you want to do it, not as part of homing Z. The commands will be pretty similar to your homex.g.

However, as you have two Z motors, each connected to separate motor drivers, and a probe, you can level the X axis to the bed. See https://duet3d.dozuki.com/Wiki/Bed_levelling_using_multiple_independent_Z_motors

However, this does assume that the bed is square to the frame first! If you're sure the frame is square, and stalling the X axis at the top of the frame sets the X axis square, then you can use this to check the bed is square to the frame and X axis, by running a bed mesh and seeing if it needs levelling. Once level, you can then level the X axis to the bed.

You also need to change your M208 Z value, currently Z-0.5:205. If you have 415mm of Z travel, and Z is high up (over 205+10%), you'll get failed homing behaviour.

Ian