(Re-)Enable TOFF=0 for M569 Cnnn
-
RRF 2.02 introduced new paramters to
M569
that allow to setTOFF
and other variables inCHOPCONF
without setting the full register as a bit-masked integer. Also it added some sanity checks on the values provided.
It though also disabled the use of the validTOFF=0
. Given, this is usually not very useful since it does enable the drivers but will not send any current to the steppers.Though, there is one scenario where this can be useful: in case one wants to test something e.g. on the extruder that only happens while printing (e.g. Pressure Advance) but it is not necessary to really move the other axes as well. Or testing this requires accel/jerk/max speed settings that the current machine is simply not capable of. In this case one could disable power to the steppers via
TOFF=0
and pseudo-print the GCode.I would only allow
TOFF=0
together withM569 Cnnn
in the thinking of giving full control once using the full register. I would also keep the checks for invalid value combinations.If this is OK, I would submit a pull request incorporating this change.
-
Isn't setting motor currents to 0% in M913 sufficient for this sort of test?
-
@dc42 I think
src/Movement/StepperDrivers/TMC2660.cpp:559
const uint32_t iCurrent = static_cast<uint32_t>(constrain<float>(current, 100.0, MaximumMotorCurrent));
will ensure a minimum of 100mA. Or did I miss something along the code path?
-
@wilriker said in (Re-)Enable TOFF=0 for M569 Cnnn:
@dc42 I think
src/Movement/StepperDrivers/TMC2660.cpp:559
const uint32_t iCurrent = static_cast<uint32_t>(constrain<float>(current, 100.0, MaximumMotorCurrent));
will ensure a minimum of 100mA. Or did I miss something along the code path?
Yes, the current will be 100mA on the Duet WiFi/Ethernet, or 50mA on the Maestro. Is that still too much?
-
@dc42 If the motors should not move at all, I'd say yes.
This idea came from a test as described in this post. My machine is not able to handle the required jerk in Y. Also XYZ movement did not really matter for this test. What I did was that I disconnected X, Y and Z steppers but if it could have been solved by software this would have been a bit easier.
Also I think if someone goes through the hassle of creating the bit-masked integer needed for
M569 Cnnn
then they should have full control overCHOPCONF
(except invalid combinations as stated above). -
@dc42 I have this prepared and can create a PR if you are basically OK with this idea.
-
I am OK with that idea, but it needs to be implemented for all 3 smart driver types supported by the firmware.
-
@dc42 I will check the implementation I already have against this requirement and send a PR probably tomorrow.
-
PR sent.