tmc: Fix stepper enable time for tmc virtual enable

[MRX8024]

When using the "Enabling TMC virtual enable for ..." function, motor activation is controlled by the toff register. On motor enable, the toff register value is sent to the tmc via _do_enable()-->_init_registers(), which occurs with print_time=None. Because of this, actual motor activation may occur earlier, up to ~1 second earlier.

For example:

G4 P1000
SET_STEPPER_ENABLE STEPPER=stepper_x ENABLE=1

Which will cause the motor to turn on immediately.

The change consists of moving the sending of the toff register to the required print_time, while the other registers continue to be initialized in advance. Since every on/off operation happens with mutex, everything should be fine.

[KevinOConnor]

Thanks. However, sending the motor enable well in advance of the command is the intended behavior. We want to make sure the motor is enabled prior to any upcoming movement commands. Applying a print_time to a TMC register update only ensures the update does not occur before the provided time and there isn't a good way to ensure the update is fully processed by a given time.

Is there some problem resulting from turning on the motor power slightly in advance?

-Kevin

[MRX8024]

Honestly, I don't know where the typical user might encounter problems with this. I'm supporting a project for Klipper that helps AWD printer users synchronize their motors; the algorithm works with motor enable and requires relatively precise timings. Unfortunately, the current behavior of virtual enable breaks it, and I thought it would be more appropriate to try to improve it here. I understand that print_time isn't a complete guarantee, but at least I haven't had any issues with it. We could have activated the motor a little earlier, say 20-50ms, but activating it earlier by up to 1s ~300ms is too much; I believe this is incorrect behavior.

Any thoughts?

[KevinOConnor]

Any thoughts?

That sounds challenging. Out of curiosity, could you explain why the enable timing is critical to the calibration? Maybe there is an alternative. Not sure.

For what it is worth, I'm not sure how one would go about ensuring precise timing of TMC messages in general. For example, the TMC UART code is not very fast, there could be host<->mcu message retransmits, and line noise could result in mcu<->driver retransmits. So, having confidence in even a 200ms time window would seem challenging. I suppose one could try for a time, check afterwards if the goal was met, and cancel the test otherwise. Not sure.

-Kevin

[MRX8024]

Out of curiosity, could you explain why the enable timing is critical to the calibration? Maybe there is an alternative.

Without going into too much detail, the algorithm measures the impact value created by the motor upon activation using an accelerometer/encoder. The analyzed range is quite large, 200 ms, with the spike occurring near the center of range. However, given the current behavior with virual-en, the motor activates outside (before) the measured range.

I can actually find various hacks to make it work, but I was interested in a mainline solution.

I would suggest adding a pause before/after activating the motor, but it seems like turn-on callback is already a post-factum of steps flush, so we can't just add a time offset to next moves.

[github-actions]

Thank you for your contribution to Klipper. Unfortunately, a reviewer has not assigned themselves to this GitHub Pull Request. All Pull Requests are reviewed before merging, and a reviewer will need to volunteer. Further information is available at: https://www.klipper3d.org/CONTRIBUTING.html

There are some steps that you can take now:

1. Perform a self-review of your Pull Request by following the steps at: https://www.klipper3d.org/CONTRIBUTING.html#what-to-expect-in-a-review
   If you have completed a self-review, be sure to state the results of that self-review explicitly in the Pull Request comments. A reviewer is more likely to participate if the bulk of a review has already been completed.
2. Consider opening a topic on the Klipper Discourse server to discuss this work. The Discourse server is a good place to discuss development ideas and to engage users interested in testing. Reviewers are more likely to prioritize Pull Requests with an active community of users.
3. Consider helping out reviewers by reviewing other Klipper Pull Requests. Taking the time to perform a careful and detailed review of others work is appreciated. Regular contributors are more likely to prioritize the contributions of other regular contributors.

Unfortunately, if a reviewer does not assign themselves to this GitHub Pull Request then it will be automatically closed. If this happens, then it is a good idea to move further discussion to the Klipper Discourse server. Reviewers can reach out on that forum to let you know if they are interested and when they are available.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.