Hi there!
As perhaps some of you already saw, some progress on using klipper as a CNC laser was made (sync channel for fast move_queue population by Cirromulus · Pull Request #4128 · Klipper3d/klipper · GitHub).
Well, it is now in a pretty much usable state, and I would be glad if we could find more people with different hardware to test this. Currently, it produces usable results for at least three people (including me). See in the PR for some raster-engraving results.
A special focus for testers I would like to see, is if normal printing operation is not impacted. At least for my Geetech A10 I can hot-swap laser and printhead, with no changes to the code.
Reported PWM-Change frequencies are between 500-1000 Hz (Note that this is changes in PWM value, not the PWM frequency itself).
When we have enough testers, we can finally merge this, and I can address the two last issues: Proportionality (during acceleration phases) and perhaps a systemic improvement of the Update rate, together with move splitting (to prevent false-positives on the safety timeout).
Hi!
Glad to hear that.
If you only use this as a laser platform (which you probably will), then marlin may be your best option as marlin supports the proportionality feature during acceleration phases. This is not yet supported by my changes.
The klipper laser support is mainly to enable both printing and lasing in one system.
That being said, in long term klipper may outperform marlin in terms of speed and accuracy, so knowing your way around klipper won’t hurt. Also, I am interested how many PWM updates per Second you archieve without timer-too-close errors.
Hi, with GrblHAL at this moment with grayscale engraving i can get to 30mm/s with 254DPI if i try it faster laser head is stopping.
But it should be possible to run faster, dont know where is a problem.
You can check last post here: https://github.com/grblHAL/LPC176x/issues/14
I just installed cohesion3d cluster firmware (smoothie fw). I test it without laser, only the motors and it looks much faster.
The main goal of this post was to test this new firmware for its use in both laser and printer configuration.
So if the printing capability is not impacted by the new code.
The maximum PWM update rate is not yet the focus of this pull request, as there are still some factors that can be optimized.
That being said, the rate will be strongly dependent on the MCU processor you use; the more RAM the better. As the updates are buffered, the update rate can be higher in peaks.
The Hosts CPU speed will also play a role, but less so.
Do you plan to add support for more than one high_throughput pin?
At the moment I am testing printer with laser, but for my setup it is necessary to use one PWM pin for laser power and second one activates/deactivates laser (On/off signal). At the moment I still use standard output pin, but it is limited to 0.1 s, so I see that for some smaller cross sections laser is still on while moving to other zone. How I understood at the moment it isn’t possible to configure second high_throughput pin ?
I am planning to, but I won’t start until the initial PR has been merged.
You will probably not need it, though.
The high_throughput will only be needed for your PWM input. Usually, your ON/OFF signal is used only for longer off-durations (E.g. on for start of Job, off afterwards. See my MACRO-Example), so the normal mode is very much enough.
If it is still (slightly) on during a move, there are multiple possibilities for a cause.
You have configured a minimum PWM value in either klipper or your laser CAM software
Your Laser control board is simply too slow for changes to react. Especially if you cut the Power regularly (M5) instead of setting PWM to zero, the laser will be in an undefined state in the ramp up/down phases.
Laser which I use is designed to control it with two pins. Even if you adjust power to 0 % it is still ON, it doesn’t burn anything, but to control it properly you have to switch it off with second pin, when you finish segment.
Do you have a link to your laser?
How long is one segment? If the time between switches is > 0.1s, it should be OK using the ON/OFF-Pin as a normal pin.
Ok, with 10% minimum Power at 200W this is Pretty significant
This is currently not supported. In some weeks I can have a look at it for a workaround in your special case. The Problem with this is that there are flushing problems in some cases, so I limited the System to one pin.
If you want to try it out in the meantime, you can comment out the Check in klippy/mcu.py.
Indeed. I still have to reproduce a reported error in the pull request on github.
But aside of that, the other features have to wait until the PR will have been merged by kevin.
My work is a pretty heavy change and needs to be checked, but he does not have the time to invest the needed thoroughness.
I can’t reasonably work on further features while i have to rebase and follow all newly merged changes on klipper master.
Also, a whole blob of different changes are unlikely to get merged as it is not good to maintain.
But I really do like the topic and I will continue my work beside my daytime job when things move forward.
I am also am happy for every tester (did you check out my branch and use it for your normal printer operations?) as more success-stories will get the needed attraction from klipper maintainers
Just wanted to chime in here and say your patch works perfectly, at least for my engraver (Sovol on SKR E3 Mini v3.0) - I haven’t tried regular prints yet, but will be shortly!
This is interesting
I have been using grblHAL for my dedicated laser setup
But now I`m involved in a project where we make a new CoreXY setup and plan to test if it is possible to get a multi use plattform using Klipper
We startt with 3D printing and Laser
I`m working on a corexy project where one goal is to test if this is possible using Klipper
This should be possible, yes.
I use a nested configuration, spread over multiple files with shared settings.
When switching between laser or printer, one just starts klipper with a different main file that includes common settings.
I don’t know about lightburn, you will have to write your own Macros if it uses different G-Codes than in my example.
