# Laser Cutting causes “Missed scheduling of next hard pwm event” shutdown – possible bug? **URL:** \ **Category:** General Discussion\ **Created:** [March 1, 2026, 11:42am UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686 "2026-03-01T11:42:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![redinsch](https://avatars.discourse-cdn.com/v4/letter/r/f08c70/32.png) [@redinsch](https://klipper.discourse.group/u/redinsch)\ **Post date:** [March 1, 2026, 11:42am UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686/1 "2026-03-01T11:42:05Z")
### Basic Information: Printer Model: Tronxy X5SA Pro MCU / Printerboard: BigTreeTech Manta M8P v2.0 & Biqu Hermit Crab V2 CAN Host / SBC: BigTreeTech CB1 klippy.log [KlippyLog.zip](https://klipper.discourse.group/uploads/short-url/tKoA0ttpg3KpuwxozL3uyoLzcN4.zip) (37.0 KB) _Fill out above information and_ _ **in all cases attach your** _ **`klippy.log` _file_** (use zip to compress it, if too big). _Pasting your_ `printer.cfg` _is **not** needed_ _ **Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there** _ ### Describe your issue: ## Laser Cutting causes “Missed scheduling of next hard pwm event” shutdown – possible bug? I’m running a laser module on a Hermit Crab toolhead plate for engraving and cutting. **Engraving works flawlessly** , but cutting consistently triggers the following shutdown: ```plaintext MCU 'HermitCrab2' shutdown: Missed scheduling of next hard pwm event This is generally indicative of an intermittent communication failure between micro-controller and host. Once the underlying issue is corrected, use the "FIRMWARE_RESTART" command to reset the firmware, reload the config, and restart the host software. Printer is shutdown ``` ### What I’ve observed - When cutting a rectangle, three sides complete without issues – the **fourth side fails** with this exact error. - Even a single straight cut reproduces the problem reliably: This leads me to believe that during a long, constant-power move, Klipper does not send periodic PWM updates to the MCU. Once `maximum_duration` expires without a new PWM event being scheduled, the MCU triggers the shutdown. ### Regarding the `maximum_duration` parameter I found [a post on this forum from 2024](https://klipper.discourse.group/t/missing-scheduling-of-next-hard-pwm-event/15614) describing the same issue. The suggested solution was to remove the `maximum_duration` parameter, claiming it is deprecated. However, this does not seem accurate: - The `maximum_mcu_duration` parameter in `[output_pin]` **is** deprecated (and has since been removed). - The `maximum_duration` parameter in `[pwm_tool]` is **still documented** in the Klipper configuration reference without any deprecation notice. Simply removing this parameter is not a solution I’m comfortable with either, as it eliminates an important safety mechanism – especially for a laser module where an uncontrolled pin state is a serious fire hazard. ### My question Is this expected behavior, or is this a bug in how Klipper schedules PWM updates during long constant-power moves? It seems like Klipper should either periodically refresh the PWM state to satisfy `maximum_duration`, or handle the timeout differently when the PWM value hasn’t changed. Any insights would be appreciated. ---
**Author:** ![nefelim4ag](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/nefelim4ag/32/2387_2.png) [@nefelim4ag](https://klipper.discourse.group/u/nefelim4ag)\ **Post date:** [March 1, 2026, 3:03pm UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686/2 "2026-03-01T15:03:30Z")
I guess there is a bug, from your example snippet: > [@redinsch](#): > > Even a single straight cut reproduces the problem reliably: In the batch mode ```auto # rp2040 12MHz queue_digital_out oid=0 clock=1370640371 on_ticks=6000 queue_digital_out oid=0 clock=1506871196 on_ticks=0 ``` So, it schedules the first enable and then schedules the disable in 11.35s. It seems to me that: ```auto def set_pwm(self, print_time, value): clock = self._mcu.print_time_to_clock(print_time) if self._invert: value = 1. - value v = int(max(0., min(1., value)) * self._pwm_max + 0.5) self._send_update(clock, v) ``` Schedules PWM in that way, and I guess, there are some checks missing. Because it should probably be scheduled only up to 3s. It may take some time. Thanks for the report, -Timofey ---
**Author:** ![nefelim4ag](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/nefelim4ag/32/2387_2.png) [@nefelim4ag](https://klipper.discourse.group/u/nefelim4ag)\ **Post date:** [March 1, 2026, 3:32pm UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686/3 "2026-03-01T15:32:05Z")
> > > Report: https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling…-of-next-hard-pwm-event-shutdown-possible-bug/25686 > > As far as I understand, with max\_duration code should generate updates every 3s. > But that happened, that set\_pwm() set \`self.\_last\_clock\` to a faraway time. > So, the flush callback cannot generate any intermediate updates. > \`\`\` > \[pwm\_tool laser\] > pin = gpio13 > cycle\_time = 0.0005 > shutdown\_value = 0 > maximum\_mcu\_duration = 3 > \`\`\` > > I'm not sure if it is the correct way to handle that: > \`\`\` > G28 > G0 X0 Y0 > SET\_PIN PIN=laser VALUE=1.0 > G1 Y140 X0 F740 > SET\_PIN PIN=laser VALUE=0.5 > G1 Y280 X0 F740 > SET\_PIN PIN=laser VALUE=0 > \`\`\` > > Probably, one can mimic the \`GCodeRequestQueue\` logic, and queue the values on time, > That way, it would be able to actually run the flush callback, I think. > > Thanks, > \-Timofey So, this is a duct tape, it should help. But I’m not sure that this specific solution is correct. Hope that helps, -Timofey ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [March 1, 2026, 8:30pm UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686/4 "2026-03-01T20:30:40Z")
> [@redinsch](#): > > Is this expected behavior, or is this a bug in how Klipper schedules PWM updates during long constant-power moves? It’s a bug. I applied @nefelim4ag’s change. Hopefully it fixes the issue. Thanks for reporting. -Kevin ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\ **Post date:** [April 1, 2026, 6:31am UTC](https://klipper.discourse.group/t/laser-cutting-causes-missed-scheduling-of-next-hard-pwm-event-shutdown-possible-bug/25686/5 "2026-04-01T06:31:23Z")
Closed on April 1, 2026, 6:31am UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.