Poor update rate for PWM tools

General Discussion
1

Basic Information:

Printer Model: Custom CoreXZ laser
MCU / Printerboard: Octopus V1.1 F446 (non-pro)
Host / SBC: RPI4 4GB

logs-20260308-124004.zip (8.7 KB)

Describe your issue:

I am attempting to do a simple raster at 200mm/s, but the XZ steppers keep stuttering as more PWM updates occur. It does eventually finish with no errors thrown, but it looks horrible. I am using the pwm_tool for laser power and have a pin to enable the laser. I have tried PWM frequencies of 30khz, 25khz, and 1khz with the same result. Hard/soft PWM also has no effect. I have checked the system load in Mainsail, but the host and MCU are both under 10%. I also tried setting baud rate to 500k, but that had no effect either. Though unsupported here, I have also tried Kalico firmware, but that has the same problem.

This problem is only visible on raster engravings where there are a lot of PWM updates. Cuts turn out very good at 3mm/s and have zero problems, so I know it is an update rate problem.

While I know LaserGRBL and Marlin exist, Klipper makes things much easier. If I need to, I could switch, but would rather get Klipper working instead.

2

Welcome Clinery,

interesting problem. Could you post pictures of your raster engravings?

3

Here is a video the slow part of a raster I did yesterday uploaded to my youtube (very large video file size from my phone): https://youtube.com/shorts/y3aMfIpWJM0

1 Like
4

Could you upload your .svg, .dxf, or whatever file you used for that engraving in the video?

5

I’m not sure I quite follow what is happening.
But:

So, whatever is happening here, it is not the MCU side issue, and it is not a steppers can’t keep up with update events.

Where hardware PWM is cheaper from the MCU perspective, at this rate (10k events per second on this chip CLOCK_FREQ=180000000 MCU=stm32f446xx ), it should not matter at all.

I think the G-code example and/or emergency shutdown M112 during the event (and log of that shutdown) can help.
As far as I understand, from the current PWM_TOOL code, there are no movement pauses.

Hope that explainssomething,
-Timofey

For example, if I run Klipper in batch mode and try to schedule 2 PWM updates:

G1 Y140 X0 F740
SET_PIN PIN=laser VALUE=0.5
SET_PIN PIN=laser VALUE=0.4
G1 Y280 X0 F740

It will produce this:

queue_step oid=3 interval=3041 count=654 add=0
queue_step oid=6 interval=3041 count=654 add=0
queue_digital_out oid=0 clock=1506863796 on_ticks=3000
queue_digital_out oid=0 clock=1506863796 on_ticks=2400
queue_step oid=3 interval=3040 count=556 add=0
queue_step oid=6 interval=3040 count=556 add=0

So, there is no pause, motors are still moving, and 2 updates are scheduled.
Where 2 PWM updates are placed in the MCU’s queue, along with scheduled steps, and they will be applied one by one, and I guess, it will crash in this case.

6

You mentioned LaserGRBL. Did you try this engraving with LaserWeb?

7

Turns out this was actually user-error, but thanks for the help and suggestions as they helped me arrive at the solution. I looked at the generated microcontroller commands and see that it does queue the PWM between step commands, but those have wildly varying intervals, which I assume also means wildly varying speeds, and thus the gcode is commanding different speeds.

I am using RayForge to generate the gcode and it outputs G1/G0/G1/M4/G1/M5 sequences for each raster segment. I replaced each G1/G0/G1 sequence with a single G1 and that solves the problem. It did not slow down even once with the high PWM updates, and I even did a faster run (about 400mm/s) and it didn’t falter.

Example of problematic gcode segment:

...
M5
G1 X127.22 Y38.393 F12000
G0 X127.24 Y38.333
G1 X126.744 Y38.333 F12000
M4 S698    ; SET_PIN PIN=laser VALUE=0.698
G1 X125.436 Y38.333 F12000
M5         ; SET_PIN PIN=laser VALUE=0
...

Example of good gcode segment:

...
M5
G1 X126.744 Y38.333 F12000
M4 S698    ; SET_PIN PIN=laser VALUE=0.698
G1 X125.436 Y38.333 F12000
M5         ; SET_PIN PIN=laser VALUE=0
...

LaserWeb might be able to generate better gcode, but I am already familiar with RayForge and have it setup mostly properly. Also, it does good beam width compensation so my cut parts are more accurate.

2 Likes