Laser Cutting causes “Missed scheduling of next hard pwm event” shutdown – possible bug?

General Discussion
1

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 (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:

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:

    M106 S255
G1 Y140 X0 F740
M106 S0

    This shuts down after roughly 3 seconds – which matches my configured maximum_duration value exactly.

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

2 Likes
2

I guess there is a bug, from your example snippet:

In the batch mode

# 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:

    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

3

So, this is a duct tape, it should help.
But I’m not sure that this specific solution is correct.

Hope that helps,
-Timofey

1 Like
4

It’s a bug. I applied @nefelim4ag’s change. Hopefully it fixes the issue.

Thanks for reporting.
-Kevin

1 Like