Firmware 2.03RC5/1.24RC5 released

[dc42]

@boldnuts said in Firmware 2.03RC5/1.24RC5 released:

Yes that's correct, first image is 2.02 and second is 2.03RC5

Does the speed of convergence change depending on whether you do or don't home the printer between auto calibration runs?

[boldnuts]

I don't re home between calibrations, but I will re check this for you

[dc42]

@boldnuts said in Firmware 2.03RC5/1.24RC5 released:

I don't re home between calibrations, but I will re check this for you

I don't normally home between re-calibrations either, but it is conceivable that there could be a firmware bug that causes it to make a difference. There were small changes in RRF 2.03 to how the corrections made by auto calibration are applied. That said, I've checked that code several times and I believe it should have exactly the same effect as the 2.02 code.

[dc42]

@denke said in Firmware 2.03RC5/1.24RC5 released:

@dc42 It did in my case, I use 24V sunon 40x40x20 fans, which are very noisy (electricly speaking)
My solution was connecting the main fan to a PWM output and stopping the fan for the duration of the delta calibration.

It's actually the magnetic field from the fan(s) that causes the problem. In revision 2 of the Smart Effector we moved the heatsink fan away from the sensitive electronicas to mitigate this issue. The E3D heatsink fan doesn't cause any issues, but some other fans do.

[boldnuts]

First image is 2.03RC5, homing between calibration which does seem better than before and 2nd image 2.02 with the same settings

[dc42]

Thanks. Please can you try 2.03 without homing between calibration runs a few times, to see whether it is consistently worse.

[boldnuts]

2.03 it's not quite as consistent as 2.02, but very little in, nit picking at best, ran both 6 times with no homing, bottom image is 2.02

[dc42]

Thanks. On that basis, I think there is no significant difference between 2.02 and 2.03.

[dragonn]

I see 2.03 final on github, question - what is the "jerk policy" for?
I can not find any information about that.

[wilriker]

@dragonn said in Firmware 2.03RC5/1.24RC5 released:

I see 2.03 final on github, question - what is the "jerk policy" for?
I can not find any information about that.

It made me curious, too. I found it in the GCode documentation:

The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

[dragonn]

@wilriker It must be recently add when I search it it wasn't there

[dc42]

@boldnuts said in Firmware 2.03RC5/1.24RC5 released:

2.03 it's not quite as consistent as 2.02, but very little in, nit picking at best, ran both 6 times with no homing, bottom image is 2.02

@boldnuts , you were right! There is a bug in the 2.03 autocalibration function. Please try the 2.03+1 binary at https://www.dropbox.com/s/zfv4p7dr2ycmjzd/Duet2CombinedFirmware.bin?dl=0 and see whether it gives you better results, as good as 2.02 did.

[boldnuts]

Calibration all sorted out now dc42, Thank you

[dc42]

Thanks for confirming this.

[jakemestre]

@dc42 I've got a delta with end stops that are shy of ultimate height movement. There's a tool changer in the dead space of the delta and this way I can easy move in XY to get new tools. Any way the "target position outside machine limits" could controlled with the M208?

[dc42]

@jakemestre said in Firmware 2.03RC5/1.24RC5 released:

@dc42 I've got a delta with end stops that are shy of ultimate height movement. There's a tool changer in the dead space of the delta and this way I can easy move in XY to get new tools. Any way the "target position outside machine limits" could controlled with the M208?

Not currently; but with care you could use G1 S2 individual motor moves to move beyond the limits.

[Kodachrome]

@dc42

I have this problem too, but I don't have a pure XY move, I had a pure Z move (Starting Script in S3D):

; START SCRIPT START
G28
G1 Z300 F3000 ;
; START SCRIPT END

I also tried
G0 X0 Y0 Z300 F3000 ;
and same result: "G1/G0: target position not reachable from current position"

I need to move to a "not home" slightly lower Z position otherwise Filaswitch (Multi extrusion tower generator script for Prometheus System) smashes into the bed as it tries to move X (or Y) from the top Z position which isnt possible on a Delta.
I think the problem is Homedelta G28 now doesnt work correctly/as before, see below.. This was all good before.
What should I change in that GCode?

EDIT:

Crap, now this new warning is creeping into just doing Auto Delta Calibration!!
I have these as defined tools (E3D Chimera):
; Tools
;M563 P0 D0 H2 F5 S"Disconnected" ; Define tool 0 (Extruder 0) - P0 (drive Tool0), D0 (Extruder first), H1 (heater 1)
;G10 P0 X-9 Y0 Z0 ; Set tool 0 axis offsets
;G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C
;
M563 P1 D2 H1 F5 S"Right 0.8" ; Define tool 1 (Extruder 1)
G10 P1 X9.0 Y0 Z0 ; Set tool 1 axis offsets
G10 P1 R0 S0 ; Set initial tool 1 active and standby temperatures to 0C
;
M563 P2 D1 H2 F5 S"Left 0.4" ; Define tool 2 (Extruder 2)
G10 P2 X-9 Y0 Z0 ; Set tool 2 axis offsets
G10 P2 R0 S0 ; Set initial tool 2 active and standby temperatures to 0C

The offending line in Homedelta is: G1 X0 Y0 F6000
I presume its stating it cant move to X-9 as its at the top already and cant make a flat horizontal move as its a Delta.
Going to test using Tool 1 (Left) as origin and Tool2 (Right) as set to +18. Which in my head is wrong as both are offset from an imaginery centre line by 9mm either side but lets see.

[Kodachrome]

@dc42

Just FYI, tool change scripts (move to corner, wait, move back, no Z move required as on same level) also fall afoul of this new logic on not allowing pure XY moves; these no longer work: https://www.thingiverse.com/thing:1467258

Really not liking this change!

[A Former User]

Did you try G1 S2* or M564 S0 to override?
https://duet3d.dozuki.com/Wiki/Gcode#Section_M564_Limit_axes

Not sure it will override the limits for a delta at Zmax, but if the end stops are in the way to move the carriages anyway it hardly matters.

[Kodachrome]

G1 S2 - move individual stepper motors is way beyond the complexity and my ability to do savely.
M564 H0 S0 - just tried and doesnt work, Duet rejects the gcode upon print start.

The only workaround I have right now is arbitrarily putting in a Z-height for the nozzle change and changing that per thing that needs to be printed to ensure its not crashing into something.