(Re-)Enable TOFF=0 for M569 Cnnn

wilriker

RRF 2.02 introduced new paramters to M569 that allow to set TOFF and other variables in CHOPCONF 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 valid TOFF=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 with M569 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.

dc42

Isn't setting motor currents to 0% in M913 sufficient for this sort of test?

wilriker

@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?

dc42

@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?

wilriker

@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 over CHOPCONF (except invalid combinations as stated above).

wilriker

@dc42 I have this prepared and can create a PR if you are basically OK with this idea.

dc42

I am OK with that idea, but it needs to be implemented for all 3 smart driver types supported by the firmware.

wilriker

@dc42 I will check the implementation I already have against this requirement and send a PR probably tomorrow.

wilriker

PR sent.