As it is working for other testers, there is a high chance that something went wrong during your manual edit. @Cirromulus has already provided the recommended way here [Testers wanted] Laser Support - Fast PWM Updates - #34 by Cirromulus, which prevents errors in applying the necessary changes
1 Like
Oh. OkayâŠ
I will just try the instructions then if possible.
Seth
P.S. The only issue is that the board I use has a set image w/ a specific, altered Klipper firmware installed. So, I am not sure if this is even possible from my standpoint. I say that b/c I do not know how to alter the Klipper firmware on this board so far. I will have to research more.
Please contact me. I will use the same setUp as you and may we can plan triaös togeather.
Thanks and regards from NRW
Hi, maybe someone has a similar problem to me that only occurs when I cancel laser engraving, the next engraving or even G28 (HOME) causes mcu shutdown (almost every time and only after cancelling and only with this fast PWM enhancement - high_throughput mode). I use standard macro âCANCEL_PRINTâ .
Error message: âMCU âmcuâ shutdown: Missed scheduling of next digital out eventâ
MCU Information:
BIGTREETECH SKR mini E3 v2.0 - stm32f103xe (72MHz)
System:
Freescale i.MX7 Dual @1GHz (32bit armv7l with 2 cores)
Debian GNU/Linux 11 (bullseye)
small_test1.gcode (190.7 KB)
klippy_mcu_shutdown.log (639.7 KB)
This is most probably due to the command queue not flushing completely after aborting.
It then tried to issue the old schedule_digital_out later, but into the past.
How did you abort, via octoprint?
I suppose I have to look into the abort sequence for mitigating this behavior.
This is one of the things that come with âpiggybackingâ on the move queue instead of having an agnostic real-time channel.
Via fluidd web panel and it use this macro:
[gcode_macro CANCEL_PRINT]
rename_existing = BASE_CANCEL_PRINT
gcode =
TURN_OFF_HEATERS
CLEAR_PAUSE
SDCARD_RESET_FILE
BASE_CANCEL_PRINT
In pause_resume.py
def cmd_CLEAR_PAUSE(self, gcmd):
self.is_paused = self.pause_command_sent = False
def cmd_CANCEL_PRINT(self, gcmd):
if self.is_sd_active() or self.sd_paused:
self.v_sd.do_cancel()
else:
gcmd.respond_info("action:cancel")
self.cmd_CLEAR_PAUSE(gcmd)
In virtual_sdcard.py
def do_cancel(self):
if self.current_file is not None:
self.do_pause()
self.current_file.close()
self.current_file = None
self.print_stats.note_cancel()
self.file_position = self.file_size = 0.
UPDATE:
Iâve been trying to understand how this feature (and klipper) works, and I donât understand much yet, but Iâve discovered something. I tried the gcode with long moves (simulating cutting something, not rasterization). And I got another mcu shutdown error: âTimer too closeâ.
For testing I commented out (disabled) maximum_mcu_duration in the config file and everything works as expected, canceling âprintâ too.
Gcode:
test_calibration.gcode (181.4 KB)
Logs:
klippy.log.config0002.cfg (7.5 KB)
klippy.log.config0001.cfg (7.2 KB)
klippy.log.shutdown01524.txt (61.8 KB)
1 Like
I have tested this patch #5975 and confirm that it solves the print cancellation problem. Maximum_mcu_duration also works as expected.
Great to hear!
I did not get around to rebasing the PRâ, as a lot of conflicts happened in the MCU code.
This might also help the issue of not being able to use maximum_mcu_duration in long-running moves.
Will test this out soon.
Edit: Just rebased it: 319e4e4.
1 Like
Good morning
How to test this version? I currently use klipper on a 3d printer that I designed, 2 removable heads, and I have a laser that I will fit on it.
(sorry for my English, Iâm French and I use an automatic translator
I am currently in the R&D process of Co2 Laser cutter / engraving machine. Is this suitable for raster engraving yet using Klipper? The board I want to research is the MKS SKIPR 1.0. It will be a 100w Co2 laser.
Hi!
It should be suitable, but there is still room for improvement.
I would suggest trying it out.
There was a user with a CO2-Laser, but I donât know whether he actually tried it out.
The PWM update rate could be a limiting factor (Would be up to a test; I greatly appreciate any reported measurements!), and the laser power proportionaly feature is not yet implemented. Depending on your planned acceleration values, this could have an impact on quality which can be solved by inserting blank in- and out moves in laser raster mode.
With a 100W laser power, you probably sometimes want very low power runs. Depending on your board, the resolution might not be perfect. Most boards use only 8-bit resolution, which starts to degrade if you limit the power to letâs say 1%. But most other firmwares are not better in this regard. Depends more on your HW-Board and the configuration.
2 Likes
Thank you for taking the time to reply to my questions 
Much appreciated
1 Like
Hi do you Know why i have this error?
AttributeError: 'MCU' object has no attribute 'lookup_command_tag'
This in My config
[output_pin TOOL]
pin: !PB15 # use your fan's pin number
pwm: True
#hardware_pwm: false
cycle_time: 0.001
shutdown_value: 0
#maximum_mcu_duration: 5
high_throughput: True
# Default: 0 (disabled)
# Amount of time in which the host has to acknowledge
# a non-shutdown output value.
# Suggested value is around 5 seconds.
# Use a value that does not burn up your stock.
# Please note that during homing, your tool
# needs to be in default speed.
[gcode_macro M03]
gcode:
{% set S = params.S|default(0.0)|float %}
SET_PIN PIN=TOOL VALUE={S / 255.0}
[gcode_macro M04]
gcode:
{% set S = params.S|default(0.0)|float %}
SET_PIN PIN=TOOL VALUE={S / 255.0}
[gcode_macro M05]
gcode:
SET_PIN PIN=TOOL VALUE=0
i implement in my fork
I am not sure how I can help you with the fork of a fork of something seemingly unrelated to my work on the Stepcompress system, with no log or explanation whatsoever
1 Like
The error occurs when I add high_throughput: True. I synchronized your fork with mine because I have an idex. I wasnât concerned about the fork but why this mistake comes. Is it possible because I am up to date with the original klipper?
Hello,
I hope people are still interested in this idea. I fell off, i.e. sort of. Anyway, I got a cheap-o, depot laser (DIODE) and some xy movement ready for this release of your branch.
Sorry it has taken so long.
Seth
P.S. Here is what I understand so far:
git remote add cirromulus https://github.com/Cirromulus/klipper
git pull --all
git checkout cirromulus pwm_sync_channel
If something breaks, git checkout master.
Okay!
I will get to it soon w/ a Recore. Heads up, still trying here! Times and times.
Update
Is there a way to have Stepper_Z fixed w/out causing errors?
What do you mean by fixed stepper_z?
What errors?
But nice to hear.
2 Likes
Hello @Cirromulus ,
It seems this error creates my instance of errors:
Option 'step_pin' in section 'stepper_z' must be specified
I comment out extruder and it works but when I comment out stepper_z, I receive the above error.
Seth
P.S. Here is the klippy.log:
klippy.txt (25.9 KB)
If you see where I am making mistakes, please let me know.
Could you please post the printer.cfg
1 Like
Hello,
I will update the image and get closer to updated ideas. I am updating the image now. I will report back once I get updated and current.
Seth