heaters: drop control delay

[nefelim4ag]

Heaters control is reactive, the faster we apply new PWM - the faster we will see a response.
Add command to directly apply PWM as fast as it arrives.
As a bonus, we relaxed time constraints, Timer Too Close should happen "never".
As a safety check, we still have Missed scheduling of next digital out event.
This code is mostly related to this topic/comment: https://klipper.discourse.group/t/remove-the-300ms-heater-control-delay/17771/11

I'm not sure about the right value for reqclock. If I understood the code correctly the reqclock=0 command should be sent in the next batch. - is the right one

This is more like a simple and safe solution because we just avoid timer calculation on the host.
I think the proper way to do this for heaters is to make another timer function and update fields on_duration, off_duration, end_time on each command arrival.

In addition, if we want to remove the 5-second limit, cycles counter can be used there, which will be decremented on each cycle, and then there will be no dependence on timer resolution.

Thanks.

[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.

[KevinOConnor]

Thanks. For what it is worth though, I'm not sure this is a good idea. In particular, I'm not sure the safety checks would work the same way they do now. (For example, consider the case where the host has frozen or delayed but has some messages queued up for transmit.)

I guess the main question I would have is - how do we measure an improvement from a change like this? What kind of tests can be run to demonstrate the real-world benefits of it?

Cheers,
-Kevin

[nefelim4ag]

I understand safety concerns with heaters, so there I tried to not break important one - timeout.

the case where the host has frozen or delayed but has some messages queued up for transmit.

Rereaded the code and I agree there are hypothetical situations where we have a lot of updates in the queue (up to 5/0.3 ~ 16),
and if the queue emits them fast enough - timers do not reach end time, and slowly, like 1 msg in 4 seconds.
The heater will never time out with my patches.

Current clock requirements will force all those messages to "decay".
It will be "enough" to use send_wait_ack (to "block" heater updates).

However, the initial intention was to reduce apply latency.
I think the proper solution will look like this: apply now if it has arrived early.

void command_queue_digital_out_now(uint32_t *args)
{
    uint32_t oid = args[0];
    uint32_t time = args[1];
    uint32_t on_duration = args[2];
    uint32_t time_now = timer_read_time() + timer_from_us(1000);
    if (timer_is_before(time_now, time))
        time = time_now;
    uint32_t new_args[] = {oid, time, on_duration};
    command_queue_digital_out(new_args);
}
DECL_COMMAND(command_queue_digital_out_now,
             "queue_digital_out_now oid=%c clock=%u on_ticks=%u");

I guess the main question I would have is - how do we measure an improvement from a change like this? What kind of tests can be run to demonstrate the real-world benefits of it?

There is no rush or pressure from my side, I try to fix an issue that is not even mine.
TLDR:
Directly answering the question, an actual real-world test, is to use too powerful heater or too low thermal mass hotend and print something like LW-PLA. If there is a thermal issue we will see a different volume of material in different places - because of temperature instability.

---

There are users with strange extruder heaters and as a consequence, strange behavior of PID regulation. I think PID itself is totally fine. So, only heater/thermistor/mass/loop time can be an issue.

I can do a test setup with a small thermal mass heater, and thermistor and check if it is more stable. But it will be just a spherical cow in a vacuum.

A perfect test will be to get results from a users with unstable pid/temperature and check if it goes better - like if fix is in the right direction. I only heard of strange things (I talk about 1-2 degree swings) on:

• Goliath hotend
• Bamboo's hotends

So, this is a target audience and I think this is who actually can give usable feedback, like magnified graph of before and after or graphs from log file (or just log file), or we can even apply some analysis to check if it is more "stable".

Such degree swings, I think will be only important for materials with temperature-dependent properties (filaflex foam or LW-PLA what I know). For everything else, this is just a graph cosmetical issue.

Thanks

---

Err:3 http://security.ubuntu.com/ubuntu focal-updates/universe amd64 libpython2.7 amd64 2.7.18-1~20.04.4
  404  Not Found [IP: 52.252.75.106 80]
Err:4 http://security.ubuntu.com/ubuntu focal-updates/universe amd[64](https://github.com/Klipper3d/klipper/actions/runs/11954521769/job/33324802337?pr=6706#step:4:65) libpython2.7-dev amd64 2.7.18-1~20.04.4
  404  Not Found [IP: 52.252.75.106 80]
Err:7 http://security.ubuntu.com/ubuntu focal-updates/universe amd64 python2.7-dev amd64 2.7.18-1~20.04.4
  404  Not Found [IP: 52.252.75.106 80]