Firmware 2.03RC5/1.24RC5 released

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 0_1560427323477_Screenshot (3).png 0_1560427333286_Screenshot (4).png

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
0_1560430906349_Screenshot (5).png
0_1560431008983_Screenshot (6).png

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 0_1560880596309_Screenshot (8).png

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.