Firmware 2.03RC5/1.24RC5 released

[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.

[A Former User]

Yeah, maybe the wiki isn't very clear on that topic; it also suggest S2 only works on deltas, which isn't the case, probably worth trying just in case, do Z and towards the bed, won't cause any issues if just the one motor moves.

[Kodachrome]

@bearer

"Do Z" - you mean the Z tower stepper or Z height (ie 3 steppers would need to move)??

EDIT: I can't test right now as printing, but wouldnt this be better achieved via running G91 first, then (hopefully if not blocked by new safeguard) the pure XY move, then run G90?

Something like (Simplify3D script):

{IF NEWTOOL=2} G91
{IF NEWTOOL=2} G1 X0 Y40 F7000; Move out of the way while it stabilises active tool temp.
{IF NEWTOOL=2} G90

{IF NEWTOOL=1} G91
{IF NEWTOOL=1} G1 X0 Y40 F7000; Same park position for left nozzle.
{IF NEWTOOL=1} G90

{IF NEWTOOL=2}; RIGHT Extruder is active (T2)
{IF NEWTOOL=2}M104 S165 T1; Cool inactive extruder to 165c (T1)
{IF NEWTOOL=2}M109 S205 T2; Heat active extruder to 210c (T0).

{IF NEWTOOL=1}; LEFT Extruder is active (T1)
{IF NEWTOOL=1}M104 S165 T2; Cool inactive extruder to 165c (T0)
{IF NEWTOOL=1}M109 S205 T1; Heat active extruder to 210c (T1).

Expectation:
What I expect/want is the head to move off to the back and switch the tools on the same Z height, dynamically changing pending whatever Z height Duet is printing at.

Result:
Didnt help, G91 not the solution.

[Kodachrome]

So I tried various combo's of G1 S2.
There is something really wrong here. I dont know why it tries to run these scripts at the start of the print, but anyway, tried various combos of G1 S1, at the start, in the tool change NEWTOOL script etc. All of them screw up in various ways.

Tool Change Script in S3D:

--

T[new_tool]
G1 E-2 F2000 ; Retract
G1 S2 X-10 Y-10 Z-10 F3000

;{IF NEWTOOL=2}T2 0.4 Left Polysmooth
{IF NEWTOOL=2}T2 0.4
{IF NEWTOOL=2} G91
{IF NEWTOOL=2} G1 S2 Z10 F3000
{IF NEWTOOL=2} G90
{IF NEWTOOL=2} G1 X0 Y40 F5000; Move out of the way while it stabilises active tool temp.
;{IF NEWTOOL=2} G1 E-2 F2000 ; Retract
{IF NEWTOOL=2}M104 S165 T1; Cool inactive extruder to 165c (T1)
{IF NEWTOOL=2}M109 S205 T2; Heat active extruder to 205c (T2).
{IF NEWTOOL=2}G4 S5 ;Stabilize Hotend's pressure with dwell for 5 seconds

;{IF NEWTOOL=1}T1 0.8 Right PLA
{IF NEWTOOL=1}T1
{IF NEWTOOL=1} G91
{IF NEWTOOL=1} G1 Z10 F3000
{IF NEWTOOL=1} G90
{IF NEWTOOL=1} G1 X0 Y40 F5000; Same park position for left nozzle.
;{IF NEWTOOL=1} G1 E-2 F2000 ; Retract
{IF NEWTOOL=1}M104 S165 T2; Cool inactive extruder to 165c (T2)
{IF NEWTOOL=1}M109 S200 T1; Heat active extruder to 200c (T1).
{IF NEWTOOL=1}G4 S5 ;Stabilize Hotend's pressure with dwell for 5 seconds

--

Result

Error: G0/G1: attempt to move individual motors of a delta machine to absolute positions

Where abouts was G1 S2 meant to be placed to get around this non-pure XY move restraint?

[A Former User]

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

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

THANKS for fixing the strange movement when re-homing in additional csys (in my case G55) -> only thing still observed: when re-homing in an additional/the machine beeing in that additional csys (e.g. in my case the G55) it seems to ignore the endstop (in my case simple switches)
In G54 (main/general/standard csys) all seems to be fine/work fine !

Can you try that again? There should be no different in homing behaviour whichever workplace coordinate system you are using. You can reduce the motor current using M913 to avoid damage in case the endstops are not recognised.

hey,
I already moved, but my colleagues made another test and when rehoming within set and active G55 it ignores the endstop (also it ignores that I put in every homing script that g54 has to be...). Did you maybe have time to look into it?
Best, L