Mini5+ 3.3b2 homing woes

dc42

Also, when using stealthChop you need to enable the motor (using M17 in firmware 3.3beta, or a very short move in earlier firmware) and pause for a short while before you move it, so that the driver can measure the motor characteristics.

carcamerarig

@dc42
Couple of people have told me that I will never be to get it configured due to current bugs and that I should run in standalone mode and with a custom compiled fw, not having the knowledge right now my conundrum is do I re-flash to standalone on the last stable, continue to configure my fw on sbc or run with someones custom fw?
In your opinion will LDO's 0.9's configure up once I get the parameters dialled in?

jay_s_uk

@carcamerarig we also have some example homing files here which incorporate the small suggested move.
https://teamgloomy.github.io/sensorless.html#homing-file-changes
Theres no reason why you won't getting working that I'm aware of.
I also don't know of any other custom firmware versions

dc42

@carcamerarig said in Mini5+ 3.3b2 homing woes:

@dc42
Couple of people have told me that I will never be to get it configured due to current bugs...

The known bugs are fixed in 3.3beta1 and beta2.

... and that I should run in standalone mode and with a custom compiled fw

No need for that. With some issues we do recommend trying in standalone mode, but this isn't one of them.

In your opinion will LDO's 0.9's configure up once I get the parameters dialled in?

Almost certainly yes, unless the motors are high inductance/very low current types.

Argo

I've tried LDO-42STH48-MAC which are 0.9 motors rated current is 1.68A.
Inductance is 2.8 mH/Phase.

FW 3.2.2 (latest official stable release) = sensorless homing did not work as it brutally crashed
FW 3.2.2 with the fixed TMC stallguard sensitivity file from 3.3.b1(compiled by me) = homing works and also prints like a charm. That is the FW I'm using right now.

I don't know why there isn't a 3.2."3" bugfix release which is basically a stable release with sensorless homing (stallgaurd sensitivity) fix. Right now people need to flash a beta version which will change a lot and thereby may introduce also a lot of new bugs.

FW 3.3.b1 = sensorless homing worked like a charm but the extruder skipped about 40% of it's steps
FW 3.3.b2 = Have not tried it yet

I've disabled hybrid mode for all tests as I kept the speed under 100 mm/s for all tests. Some smaller test cubes were only printed at 30 mm/s as this is my external perimeter speed anyway.

My discovery: The 0.9 motors need a lot of current in order to operate at acceptable noise levels. I managed to run them at an "ok-ish" noise level with 1400mA for X and 1500mA for Y currents. Though I'm using a case with active cooling at the back (the air comes from the bottom and goes around the board and blows behind the drivers to the top) I got "high temperature" warnings.

TMC2209 and 0.9 motors are a hot topic, also in the Marlin 2 world: https://github.com/teemuatlut/TMCStepper/issues/132
So I see this not as an RRF issue tbh. More like a limitation the TMC2209 have.

I switched back to 1.8 motors as the last 5% in print quality is imo not worth the noise levels.

freighttt created this issue in teemuatlut/TMCStepper

open TMC2209 with LDO 0.9 VERY noisy/resonant/vibratory #132

carcamerarig

@dc42
Reassuring and appreciated
motors are:
LDO-42STH48-1684MAC 0.9
LDO-42STH25-1404MAC 0.9
I was concerned they were too high current if anything for the board with out active cooling, 1.4A RMS, 2A peak.
(waiting for a 40mm fan to arrive)

with the short move and pause implemented should I still use the M17?
I added:

G91
G1 X1 Y1 Z1 ; calibrate StealthChop values
G90
M83
G4 S2
M84 ; disable motors

and set the speed to 40 as it was disabled wasn't it @jay_s_uk

m569 p0
Drive 0 runs in reverse, active low enable, timing fast, mode stealthChop, ccr 0x00053, toff 3, tblank 0, tpwmthrs 40 (93.8 mm/sec), pwmScaleSum 18, pwmScaleAuto 1, pwmOfsAuto 61, pwmGradAuto 14, pos 776

carcamerarig

After updating and adding the suggested parameters, its still crashing like a heroin addict on a Monday morning lol
albeit minus the errors but the Y axis still activates even though I only home X??

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 Mini 5+ version 3.3beta2 running on Duet 3 Mini5plus WiFi (SBC mode)
Board ID: Z9NZN-A296U-D65J0-40KM4-LY03Z-ZPQPD
Used output buffers: 1 of 40 (11 max)
=== RTOS ===
Static ram: 99720
Dynamic ram: 93204 of which 40 recycled
Never used RAM 47884, free system stack 191 words
Tasks: Linux(ready,129) HEAT(delaying,317) CanReceiv(notifyWait,943) CanSender(notifyWait,372) CanClock(delaying,341) TMC(notifyWait,109) MAIN(running,599) IDLE(ready,20) AIN(notifyWait,269)
Owned mutexes: HTTP(MAIN)
=== Platform ===
Last reset 00:01:36 ago, cause: software
Last software reset at 2021-03-11 13:15, reason: User, none spinning, available RAM 47884, slot 1
Software reset code 0x0012 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00000000 BFAR 0xe000ed38 SP 0x00000000 Task Linu Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Aux1 errors 0,0,0
Supply voltage: min 0.0, current 24.0, max 24.0, under voltage events: 0, over voltage events: 0, power good: yes
Heap OK, handles allocated/used 99/0, heap memory allocated/used/recyclable 2048/14/14, gc cycles 0
Driver 0: position 200, standstill, SG min/max 94/302, read errors 0, write errors 1, ifcnt 135, reads 13740, writes 17, timeouts 0, DMA errors 0
Driver 1: position 200, standstill, SG min/max 2/272, read errors 0, write errors 1, ifcnt 131, reads 13740, writes 17, timeouts 0, DMA errors 0
Driver 2: position 400, standstill, SG min/max 0/286, read errors 0, write errors 1, ifcnt 117, reads 13740, writes 15, timeouts 1, DMA errors 0, failedOp 0x6a
Driver 3: position 0, standstill, SG min/max 0/0, read errors 0, write errors 1, ifcnt 76, reads 13746, writes 10, timeouts 0, DMA errors 0
Driver 4: position 0, standstill, SG min/max 0/274, read errors 0, write errors 1, ifcnt 103, reads 13744, writes 13, timeouts 0, DMA errors 0
Driver 5: position 0, assumed not present
Driver 6: position 0, assumed not present
Date/time: 2021-03-11 13:17:30
Cache data hit count 211054849
Slowest loop: 1.56ms; fastest: 0.11ms
=== Storage ===
Free file entries: 10
SD card 0 not detected, interface speed: 0.0MBytes/sec
SD card longest read time 0.0ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 83, maxWait 2222ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 1, completed moves 1, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed moves 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters = 0 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP* is doing "M122" in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger* is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== CAN ===
Messages queued 860, send timeouts 857, received 0, lost 0, longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 17 (min 16)
Last cancelled message type 4514 dest 127
=== SBC interface ===
State: 4, failed transfers: 0
Last transfer: 3ms ago
RX/TX seq numbers: 3415/3415
SPI underruns 0, overruns 0
Number of disconnects: 0, IAP RAM available 0x11584
Buffer RX/TX: 0/0-0
=== Duet Control Server ===
Duet Control Server v3.2.2
Code buffer space: 4096
Configured SPI speed: 8000000 Hz
Full transfers per second: 35.77
Maximum length of RX/TX data transfers: 3072/796

jay_s_uk

the Y moves because of line 14 of your homex file

droftarts

@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

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