An observation was made years ago that PWM base frequency settings can greatly effect cutting and engraving with different base frequency settings producing optimal results at very different frequencies.
I’m testing LinuxCNC/Remora on my K40 and setting up the spindle control so getting deep into what type of PWM(PDM vs PWM) is needed and configuring the frequency of the PWM. So now I’m looking into ways to dynamically change the PWM frequency during a single job. Either using a special M code injected into the GCode or dynamically by setting thresholds on the tool movement average velocity or maybe a threshold on laser power itself. LinuxCNC lets you do those types of things.
Does anyone know if this effect of PWM frequency changes @Ben_Myers Ben_Meyers and @donkjr found and discussed are K40 LPS specific or generally useful to all laser cutters? LinuxCNC/Remora should be able to run on all LPS1768/1769 based boards like Smoothie, Cohesion, SKR, etc so maybe this is of interest to other K40 users.
This might explain what was going on when I was doing a test pattern of dithering and grayscale on white tiles and my grayscale patterns went from white right to black instead of the gray scale and I’ve been using dithering ever since.
Hi Jack, in the thread I posted a link to, the guy did testing of different base frequencies for his PWM input to this laser power supply(LPS) and he found different base frequencies resulted in better cutting at one end and better grayscale variable power etching at the other end.
No controller or controller software I know of allows for the base PWM frequency to be varied. It will be possible with LinuxCNC/Remora to do this soon. So I was wondering if anyone has done any further testing of this?
I showed the tile testing because that’s how you figure out your best power/speeds for the colors you want in your design and in this test, the rectangles on the far right column were grayscale and you can see they are black and then go to white when they should have been graduated gray scales. I think I was running at 5KHz base PWM frequency to the LPS.
Great, that’s two different reports of the same results for the K40. So at the vary least, having the capability to switch the base PWM frequency on the fly in GCode would benefit at least the K40 users.
The software developer of Remora says the change to the code to handle variable frequency PWM is very doable. Once he’s got the fixed freq capability into the config.txt file I will validate what you and the others showed to see how pronounced the effects really are. Then I’ll look into how best to implement variable freq feature into user space.
Actually, check out this screen shot of LightBurn in the one of the line control tabs.
I had wondered about that when I first saw that my Ruida controller supports a user changeable PWM frequency. The documentation states that ‘if using an RF laser…,’ so I kind of blew it off, but it had occurred to me. However I’ve found that when it’s available in LightBurn software, it’s operational. I will have to figure out how to use it.
PWM is frequency independent.
Most of the good and bad things happen when you get a frequency/harmonic around resonance, just ask Nikola. I’m sure it’s related.
Yeah, this seems quite simple on the firmware side; stuffing a new value into a timer register is pretty easy. “The two hardest problems in computer science are naming things, cache invalidation, and off-by-one errors” — this feels like a “naming things” problem as in the hard part is how to represent this in gcode, especially in a way that can be consistent across multiple implementations. Would it be a new M3 setting? LinuxCNC docs for M3 only mention that you can provide an S argument but I don’t see a complete list of settings that could be used to find an unused setting for PWM base rate. Or maybe I’m missing something…
This is more of a design flaw, it’s as you say more than doable. It probably never crossed the designers mind to do that. I’m sure the code wouldn’t be too great, if that’s an issue. I loaded it on a Nano, but can’t recall how big it was. The controller software for grbl code on micros is pretty incredible, especially when you consider the price.
One thing that could be an issue is most of the clocks are derived from a base clock. If the initial division is used to control other clocks to control or monitor ‘real time’ events such as motors or something, it could hose those clocks up. I’m not that intimate with the grbl code but I’ve spent lots of time programming them or I should say debugging my code on them… This type of modification is where the phrase “fix a bug, a bunch more come to the funeral” originated.
cool, so at least Ruida users have a way to easily experiment and select optimal PWM frequency values for their machines. While not as handy as being able to get this in GCode, still very handy. Smoothie and others require shutting down the controller, changing a config.txt file on the uSD and restarting or worst, changes to source code, recompile, upload.
I’d always wrote off Ruida controllers because of the proprietary software required to run it and damned if I don’t insist on choices more than anything. FYI no Windows here. Check out what Don posted about his research before you do any tests.
Scott mentioned initially just setting up a fixed frequency PWM capability which would be defined at the pin level in the config.txt file which is basically the same capability as in Smoothieware. Right now, the PWM in Remora operate as PDM type signals. These are fine for D2A conversions for VFD’s and his implementation has an SP(Signal Path?) message for setting the PWM percentage( 0-100 ). That would be how the fixed freq implementation would work too but he’d mentioned the next step could be to add another SP path for each PWM pin for setting the frequency period.
It would be great to leverage existing M codes like turning on the laser 10%( M3 S100) using the defaulted base freq AND also setting the laser on at 10% power at a 2.5KHz freq with M3 S100 F400.
I don’t know anything about remapping but there’s a doc I just found on this so it can be a new user-defined M code or something like you were thinking as an extended standard M code: http://linuxcnc.org/docs/html/remap/remap.html#cha:remap
Yes it’s probably not a ‘feature’ many considered important other than providing a single fixed freq setting as there was always a way to find a ‘good enough’ setting which provides acceptable results. Given Don’s amazing research into this on his K40(Don's Laser Things: Engraving and PWM Control) I would think people doing fine detailed and delicate laser work like multi-layered painted white tiles would love this tuning ability.
I’ve never heard that quote but I can see how it would be true depending on the ‘bug’.
This was the kind of thing I had in mind. I wasn’t sure if there were already defined an appropriate word or one would have to be defined. My knowledge here is weak and limited…
I’m in the same boat as you and just figuring this stuff out. I only went down this PWM channel because Remora implemented PWM for typical CNC use which is to drive spindle controllers(VFDs) which use a 0-10V analog signal. I told the developer of Remora my interest started off looking for a way to control all my digital machines with a consistent software control system and I’d be doing 3D printers, laser cutters and CNC routers.
Most of the Shapeoko CNC users I know have added lasers to their CNC routers and controlling the spindle or the laser is somewhat of a kludge so it’s always on my mind how this stuff will work and if it can be made to work with a smoother workflow.
I just found the remapping feature of LinuxCNC when you posted the idea of extending the M3 command and I like it better than creating another custom M code because it really belongs within the M3, M4 and M5 command set. This might not win friends though since standards might be broken by doing this. But will provide an easy way to test and users can define their own solution if they want.
I switch to linux back when Apple went to Intel processors. Loaded it on my machine, what a pain… Much better today. Generally I don’t purchase software either. With the laser upgrade it came with the Ruida controller and I was aware of the costs involved. I’m sure you know the problem of everything runs on Windows… The supplied software for the Ruida (RDWorks) and is free but is windows bound. I have used it, but I dislike windows, mainly because it obfuscates where it puts things. Of course I’m not a user of it anyway. It’s around because my wife is a member of one of the Microsoft committees and her work uses it.
One of the facts of life is that we are going to have to pay for things if you want them, especially in the information age. I send 100 bucks to Ubuntu yearly, do you? It helps support development and keeps the platform alive. Now we have to pay for Internet information that we used to take for granted as free. Times they are a changing.
I’ve used Lightburn for about 3/4 of a year and it’s the most intuitive and encompassing package I’ve ever used. Used it originally with an led laser. When I upgraded I knew there’d be sticker shock. The Ruida key is about $40 bucks added to the yearly Lightburn cost. Lightburn also has excellent technical support.
I pay for few programs and even less if they are Windows bound. However I have a speeds and feeds calculator that I wouldn’t know what to do without that’s also windows bound… Take care
In LinuxCNC the hal definitions will use SP.0 and SP.1 for the example config item above.
remora.SP.0 is defined for the PWM pulse widths and remora.SP.1 is for setting the freq/period.
This could not be a slider or buttons on the GUI to adjust these along with M codes can be used.
I should soon have my K40 operational with this and can do some freq tests for cutting and engraving.
Taking a minute to mention …
The Epilog lasers I was using about 10 years back had a PWM dialog box that could be changed in the job settings.
The only time I recall it being needed was for engraving wine glasses.
In the standard default setting the glasses were exploding.
You could see the glass vibrating from the laser pulses.
The vibration reduced by adjusting the frequency down to better match the glass properties.
Wish I could remember all the setting details …
Depending on the firmware it will be complicated or impossible to implement a gcode configured PWM period, because the timers usually are configured at startup.
For example: In Grbl-LPC you can set the PWM frequency with a $ command, but not in the middle of a job, because $ settings have to be written to the flash memory, which makes the firmware unresponsive for a short period, which would destroy step/direction and PWM timing.
In Grbl for ATmega328 (Arduino Uno, Micro, Nano, Mini) the PWM frequency can only be set very roughly by timer prescalers. This way you can only reach base clock divided by 1, 8, 64, 256 or 1024. Not very usefull for this case.
I’ve been working with LinuxCNC on rPi connected to my K40 LPC1768 based controller board.
LinuxCNC is quite configurable and the firmware on the LPC1768 allows realtime control of most things it does including PWM frequency setting and pulse duration setting. I can remap GCode or use custom GCode Mxxx codes to set things in GCode or outside of GCode.
So far I’ve heard the Epilog and possibly Ruida controllers allow direct control panel configuration of the PWM frequency.
I have LinuxCNC/Remora engraving on my K40 having done both dithering and grayscale on an unedited image(LightBurn changed to grayscale only ).
I also did a quick/dirty test of changing the PWM period from 200uS to 400uS and it can be seen in the light band in top engraving down towards the bottom of the image.
The bottom engraving is using Stucki Dithering 5% power 200mm/s 200uS(5KHz) PWM pulse period.
The top engraving is using Grayscale 10% power 200mm/s 200uS(5KHz) PWM pulse period and short test of 400uS(2.5KH) pulse period changed dynamically during the engraving.
