Topics created by nikscha

@dc42 I see, I expected the file to be "reloaded" after saving and then not being found afterwards because of the renaming. Thank you for the solution!

@dc42 I tried that but M400 introduces a weird stutter:
PXL_20231019_120452795.jpg

Same gcode, left one uses G4 before M569.4, right one uses M400

@nikscha at present there is no locking around M569.4. However, M569.4 will fail if the motor is moving due to a previous G1/G2/G3/G4 command.

@droftarts Much appreciated, thank you!

My problem wasn't caused by the 1HCl board.
Instead daemon.g simply doesn't run often enough to catch a changed value in the object model in time.

@chrishamm using curly brackets works, thank you!

@dc42 Thanks, I'll give that a try!

I found the issue:

I have another axis defined, which I don't use for normal printing.
If this axis is not homed then pause.g isn't executed.
Homing all axis solves my issue

@nikscha please file an enhancement request at https://github.com/Duet3D/Duet3Expansion/issues.

@chrishamm 😃

@Phaedrux Will do, thank you ^^

@dc42 Probably.
But the random "freezes" I'm experiencing shouldn't be related to that, as I'm now on the official release version, right?

@nikscha yes, do a check before hand e.g.

if !exists(global.feed_torque) global feed_torque = 0

@nikscha See https://docs.duet3d.com/en/User_manual/Reference/Gcodes#custom-gcodes

Ian

@nikscha Thanks, I've updated the Gcode dictionary. https://docs.duet3d.com/en/User_manual/Reference/Gcodes#m567-set-tool-mix-ratios

Ian

@nikscha currently commanding torque mode does not enable the driver, hence the need to command M17 or a normal move first. I will raise a Github issue about this.

https://github.com/Duet3D/RepRapFirmware/issues/911

dc42 created this issue in Duet3D/RepRapFirmware open EXP1HCL torque mode doesn't enable the driver #911