Hi all, I try to laser engrave text. The gcode is self-made. Everething looks fine in Luban and Elstam. I engrave from the controller to avoid wifi-problems. Still there are a few lines not printed. It looks they are done with 3%-5% power, like M3 starts too late or the laser is switched off to early. Any ideas?
I have also noticed some issues, even when doing a calibration. To me it looks like the laser is trying to stabilize or something, don’t really know. Planning on experimenting more with it tonight to try and isolate the problem.
I just did a couple calibration patterns on a piece of paper that isn’t perfectly flat. The engraving starts at the bottom and travels up.
less flat:
more flat:
It should be flat across the bottom, and it’s not.
But, even though the paper isn’t flat, the tops are straight across.
I think the conclusion I’m coming to is the laser can be on the verge of engraving, but just not quite enough to get the burn started (not enough power, focus just slightly out, slightly too much speed). It takes a bit for it to actually get enough heat to start the burn. But once it’s started, it has no problem continuing and won’t drop out - there’s a lot of hysteresis and would require a large change.
Another user was using WiFi. I wondered if the issue is latency and wonder if you see a different result if you do this via USB cable or USB memory stick.
I also wonder if the issue might be related to how the laser is switched on and off. I haven’t looked at any of the SM supplied examples, but I’m wondering if lightburn is switching power on/off (like say turning the spindle on a CNC on and off), rather than either doing something like a z-hop or turning the power level down and up again.
This is all speculation, but from a computing perspective it looks like some form of latency.
In my case, touchscreen built in calibration routine. You can see the laser turn on, but it doesn’t burn at the start of the line, and when it starts burning it visibly changes how it looks.
i believe @brent113 is correct, if i remember right from my physics classes there is a threshold for burning similar to friction. it takes more energy to start then to continue. think of trying to push a heavy cart, it takes more energy to start the cart rolling then it does to keep it rolling, and it takes more energy to start pushing books across a table then to continue to push the books across the table. the same would be true for the laser. we normally choose to ignore this transient period because it is relatively short and difficult to model but when running a laser at high speeds it has an effect. it needs to impart more energy to start burning the wood then it takes to continue so there would be some small lag at the start of each line.
I made a test, not alternating between M3 and M5, I toggled between M3 P35 S89 and M3 P2 S5. It got worse. The PWM is not synchronized with the next G1 command. This should be a small mistake in the sources. When they get released?
Thanks, is HAL_LaserPwm_STM32F1.cpp the file for setting the timer1 PWM up?
In the documentation is written:
As the preload registers are transferred to the shadow registers only when an update event
occurs, before starting the counter, the user must initialize all the registers by setting the UG
bit in the TIMx_EGR register.
Could you please control the way you set up the PWM with M3. It should start with the high part, to let the laser start. With the pulse, not with pause.
I’ve also been digging into the firmware, but I don’t have any previous experience with these gigadevice ST clones, or ST chips in general. Sounds like you might?
Are you thinking the HAL_LaserPwm… call to TimSetPwm should contain a call to timer_generate_update(__) from HAL_timers… to set that UG bit?
From my initial look at the documentation, that seems like it might be an oversight from the developers, as that timer_generate_update function is called in the temperature PWM and stepper motor functions.
I am having difficulty calculating the PWM frequency - if the preload register isn’t immediately written how long will it delay? It should be 1 PWM cycle, right? From there it should be easy to tell how much impact this is having on the engraving in mm travelled. My guess is this is only accounting for a very small part of the startup delay.
In another thread people were talking about the laser PWM frequency, and guessing it was around ~1kHz. If that is true then even a substantial preload register lag of 10cycles, even at a travel speed of 50mm/s, would manifest as a turn on delay of just 0.5mm. At 1kHz, and 5mm/s, 1 cycles delay -> 0.005mm.
Of course this is just random guessing without knowing what the actual PWM is. Even in the HAL_LaserPwm I don’t even recall seeing a register prescaler or anything that would dictate timing. Must be set elsewhere in the program.
In HAL_LaserPwm is a comment //100HZ ，255 Level
and two entries: GPIO_Speed_50MHz and TIM_Prescaler = 1862;
50MHz/1862 = 26,85kHz with 255 level= 105Hz
Sounds realistic. Max 10ms delay. With 400mm/m=6,67mm/s it would be 0,06mm. My characters are 4mm in height, error is around 1,8mm. 30 times more. Next step is analysing gcode.cpp.
I switched back to M3 and M5. The errors are random. M5 switches the laser off, but M3 switches it on with 2% or 3% and later too the value set, here 35%.
The laser just doesn’t work.
also forgive me if you have answered this and i just missed it (or forgot) but what speed are you running the laser at? and what is that your engraving on? looks like some kind of heavy plastic? is it PVC by chance?
ITMaze
Yes, not perfectly aligned, the errors are more or less at the same position. But not perfectly.
Atom
I run the laser with 400 and 200, with power P35 and P17. I replaced G0 by G1, so no speed change. I added P17 to every M3, hoping that this would bring a change. All send from controller, no delay by WIFI or USB-stick.
The laser starts and stops like given by the gcode. Just the start is often around 2% or 3%, it looks like this. It takes more or less time until the laser reaches full power. Visible from one moment to the other, not slowly. Are the PINs and cables open source? Where to put an oscilloscope?
speed looks good, is it always in the same position between runs (as in if you run the code on two separate plates will they look (almost) the same? or will it drop out at different points?
