I have a strange issue with this mode… with slow speed the power of laser grows instead of decreasing and viceversa. No problem with M3… the S value is interpreted correctly.
Thanks
Alex
That sounds like a bug in the firmware you’re using. There’s nothing that LightBurn could emit that would cause that behavior.
Are you running GRBL 1.1f in the controller firmware?
My understanding of GRBL and the Duty cycle is that the PWM signal is active-high. At 75% power the duty cycle of the PWM signal is 75% on (high) and 25% off (low).
Some digital controls activate a switching transistor in the ground path so calling for 75% power requires an inverted PWM signal. 75% off (grounding) and 25% on (idle).
Depending on how it was ‘Heavily modified’ it could be that, or perhaps your engraver is pulling power at higher speeds.
What speed are you asking of the controller (speed in Cuts / Layers window) and what is the maximum speed that the controller allows? (Machine Settings)
The variable power / motion planner will cut power if the commanded controller speed exceeds the ‘maximum’ values set in the settings. This will brighten the laser output as it decelerates or as the speed decreases below the set ‘maximum’.
I’m running 1.1h. (MKS DLC 2.1 that usese a mosfet to invert the PWM signal on output)
Yes… I was suspecting that there was a problem related to the duty cycle interpreted in reverse. But the strange behaviour is that with M3 it’s working fine, the value of power is interpreted correctly. I would expect it to always be interpreted backwards even with M3, right?
max x/y speed rates are set to 1500mm/s and the tests never exceed 200mm/s.
With 20mm/s the laser fire at high power (if max set at 100%) and with 200mm/s the power is greatly reduced (always at max 100%)
I’ve checked the pwm output with an oscilloscope and the behaviour is coherent with the signal I see. The “low” time (fire on my PSU) increase in M3 (constand mode) if I increase the power value and viceversa. In dynamic power mode the “low” time of pwm signal decrease when I increase the speed.
Is it remotely possible that one or more of your speed values is in mm/minute instead of mm/second?
Have a look at the definition of $110 here.
Here my current settings:
$0=10
$1=255
$2=0
$3=3
$4=0
$5=0
$6=0
$10=0
$11=0.010
$12=0.002
$13=0
$20=0
$21=0
$22=1
$23=0
$24=100.000
$25=750.000
$26=250
$27=1.000
$30=1000
$31=0
$32=1
$100=80.000
$101=80.000
$102=250.000
$110=2000.000
$111=2000.000
$112=500.000
$120=300.000
$121=300.000
$122=10.000
$130=590.000
$131=280.000
$132=200.000
This issue has no sense! I’ve tried with a new MKS DLC 2.1 (a spare part I have) mounted on the bench only with a serial cable ad an oscilloscope hooked to D11/TTL port … uploaded the new grbl 1.1h… resetted all parameters to default with $RST=* then enabled only homing and laser mode ($22,$23). If I use the “fire” button in Lightburn… changing the power from 0 to 20% the PWM signal is correct!.. the duty cycle is coherent with the power value.
If I try to send an M4 follewed by G1 X503.203S1000F6000 or G1 X503.203S1000F1200 the command with the lowest feed rate (F1200) value produce a greater duty cycle on the PWM 
Going from a duty cycle of about 5% with F6000 to almost 50% with F1200
Is there a reason why you are inverting the PWM signal on output?
Have you tested duty cycle without the inversion?
Have you tested duty cycle against M3? I’m guessing it will work correctly. Fire button I believe uses M3.
Finally, have you tested with M4 with Laser Mode disabled? If that works it might be something isolated to variable power.
What version of GRBL are you using? Was this pre-built or something you built yourself? There may be something in the compile-time configurations that were changed or that may need to change for this to work correctly. The root of the issue is almost certainly the pwm inversion but curious as to why the behavior is different in the various modes.
Yes… my PSU fire at 0V not 5V. but this is not a problem related to my PSU… I’ve now tested this on the bench (nothing connected to the controller, not even stepper drivers).
Yes M3 works as expected… the fire button on lightburn uses M3.
I’v tested both 1.1f and 1.1h… nothing changed.
With $32=0 I don’t see a PWM signal… it goes high for the time neccesary to “cut”, is it normal? should there be a pwm signal even not in laser mode?
I don’t think. I’ve uploaded directly the .hex available on github
I’ve tested without inversion directly on pin D11
I don’t believe this is normal. PWM signal should correlate to power level. However, I don’t believe you’ll get variable power for speed changes.
Which repo are you using?
How have you wired the controller to the laser?
this Releases · gnea/grbl · GitHub
forget about the laser … I look directly at the PWM signal coming out of the controller (not inverted)
I understood. What specific pin header are you looking at?
If I’ve understood everything correctly I don’t see a reason why this shouldn’t be working.
Just to make sure I understand the current situation:
- You are measuring PWM directly off of J26 pin D11.
- You are using pre-compiled GNEA GRBL builds (1.1f and 1.1h)
- All M3 commands scale PWM duty cycle correctly
- With M4, slower feed rates result in higher duty cycle
A few things to look at yet:
Your max feed rate is 2000 mm/min.
At least in this comparison you are using a faster feed rate than your max. You may want to retest within your limits.
The thing is, variable PWM should not even come into play at steady speeds. It should only be a factor at acceleration/deceleration.
This and the fact that you’re not getting PWM in non-laser mode makes me thing something more fundamental is going on, perhaps an issue with the board.
@berainlb your recap is totally correct!
maybe it is I who am having a useless paranoia, I don’t understand 
I’ve tried this last test with $110/$111 set to 60000. With G1 command, feed rate 1000 I see on the oscilloscope that the duty cycle ramps up from 0 to 100% then stay steady to 100% until finished.
The same command with feed rate 50000 gives a tiny duty cycle that ramp up to about 10%… then ramps down to zero near the end. My question is… is it normal that near the feed rate limit the maximum duty cycle is a fraction of the max? I expect that going faster I need more power to make the same incision as when the head is moving slower … is this targeting wrong?
Interesting. So you’re saying that at speed ranges well below the max value that PWM scales appropriately but begins to decline when approaching top speeds?
I think I recall @JohnJohn making mention of something like that in a different post but I wasn’t familiar with this. This may be something intentional or perhaps a side-effect of the variable power logic in GRBL. Hopefully John can provide some insight.
Yes, exactly (with a feed rate of 10000 the ramp stops at 50%)
I think I know what’s going on here. I’ll dig into the units of the of the G0 and G1 speeds later to confirm.
I believe that you have mixed units and exceeding the feed rate in mm/minute is putting you into reduced power.
The controller understands that 6000>2000 therefore it will accelerate up to 2000 mm/min -it will begin to cut power as it accelerates- then it will travel at 2000 mm/min with a cut-power-strategy equalling 1/3 of output via pwm to deposit the correct number of photons. When decelerating, it will slowly release the cut-power requirement.
PWM can be a factor at continuous speed - if one tries to engrave at a higher speed than allowed - power is reduced to compensate. I had my units wrong and chased this confusion for more than a week.
I haven’t fully dismantled the power-cut strategy and i’m still working on it but I believe the confusion here is related to mismatched units.
Limit 60,000 mm/min = 1000 mm/sec : feed rate at 1000 mm/sec : no power cut
Limit 60,000 mm/min = 1000 mm/sec : feed rate at 50000 mm/sec : travel at 1000mm/sec and apply overspeed power cut strategy
1000/50000 = 1/50 PWM power output applied.
I will verify the units of the G1 Go-speed later today.
Interesting hypothesis and seems to fit the symptoms.
This seems like madness to me. So if true then that means that max speed limit constrains speed but not PWM scaling. I’m trying to think of any situation where this would be the right thing to do. Seems like a bug to me. But perhaps this is storage constrained in which case better to have the ability even if there are potential gotchas than not having it at all.