Laser randomly missing lines in both cut and engrave operations

[seabeepirate (David Bitecofer)]

Hello, I recently replaced the nano board in my omtech K40 with an MKS DLC32 v2.1. The documentation I was able to find says that this controller ships with GRBL 1.1f. I’ve uploaded both my project and the machine settings I’m using.

The problem I’m having is sometimes the laser turns off during both cutting and engraving leaving me with incomplete shapes or cuts that don’t go all the way through the cardboard.

Here you can see where the laser turned off halfway through the cut and some weird crosshatching.

Another incomplete cut and the crosshatching is one directional.

Here the crosshatching looks weak on the left and incomplete on the bottom of the flower.

Some more incomplete crosshatching.

So far I’ve tried various speeds and power settings thinking I wasn’t running it hard enough to trigger the laser coming out of corners but no luck on that front. I tried changing my S-min from 0 - 50 - 100 - 150. This didn’t seem to make any difference except that I started having issues with the cardboard catching fire. I switched to 1mm plywood for a few tests so the material wouldn’t burn as easily but even with higher power settings there were sections that the laser wasn’t firing. In the project I uploaded the cut power is lower than I’ve been running, I was up to 22.5% and on my most recent attempt I turned it down to 15% and ran multiple passes. My blue layer runs at a faster speed and a lower power setting than my normal settings for red and black and it doesn’t seem to be missing anything. It doesn’t seem to be related to my power setting or the S-min setting but I could be missing something.

I’m using the shielded USB cable omtech sent me with the laser and before I replaced the nano board this was never an issue. I took some time to clean up the wiring to the control board and moved the stepper wires as far from the usb as I could then moved the board as close to the opening as I could so as little of the USB cable is with all the wiring inside the case as possible. As it is I have less than 1" of USB cable sticking into the machine to try to reduce any noise it might pick up from the other wiring.

Here’s where it gets weird. On multiple pass operations like my cut lines(red) I noticed that sometimes the laser DID fire in the sections where on previous passes it had not fired. It’s intermittent though and I don’t have a way to tell if it will fire or not on subsequent passes. I ran the cut lines for a total of 6 passes and still it’s missing bits so extra passes as a workaround won’t work.

There are a few other quirks since I replaced the nano board that may be related but I don’t know.

I have to draw a box around the entire job or the cut and engrave layers don’t align when the job is finished.

Sometimes after I change machine settings I lose connection with the control board and have to restart LightBurn, the machine, or both.

Sometimes when the job finishes, LightBurn just keeps on counting the job time and it says the laser is busy until I hit the stop button. There are no new messages in the console for clues when this happens but I don’t lose connection and it doesn’t seem to be hurting anything so I haven’t worried much about it.

On a handful of occasions the laser has just stopped with no alarm or message of any kind. The machine status reads ready when this happens to me. I can home and start from the beginning again but I have no idea if there’s a way to start the job again from where it left off. Because this is practically impossible to reproduce at will and doesn’t happen very often I’m not focusing on it but I wanted to share in case it’s related.

Any help would be greatly appreciated.

Roses Heart.lbrn2 (2.7 MB)
omtech K40 machine settings.lbset (5.9 KB)

[seabeepirate (David Bitecofer)]

![Screen Shot 2022-04-28 at 3.55.36 AM|429x499](upload://feMIwC31PCHXLZXQzOTn04gMeDM.png

[seabeepirate (David Bitecofer)]

[berainlb (PY)]

Is there a reason why your S Value Max in Device Settings is set to 500? That’s an unusual value. This should match the value of $30 in machine settings.

Can you provide 2 things:

1. Push Devices button in Laser window and take a screenshot
2. Enter these commands into Console and return results:

$I
$$

[seabeepirate (David Bitecofer)]

I set S Max to 500 because as I understand it this is a scale from 0-1000 which limits the pwm signal and this allowed me to globally limit laser current. I set the machine settings to match when I set it up. At 1000 my machine was firing at dangerously high current levels.

$$

$0=10

$1=25

$2=0

$3=1

$4=0

$5=0

$6=0

$10=1

$11=0.010

$12=0.002

$13=0

$20=1

$21=1

$22=1

$23=3

$24=300.000

$25=3000.000

$26=250.000

$27=5.000

$28=1000.000

$30=500.000

$31=0.000

$32=1

$38=1

$40=1

$100=626.866

$101=626.866

$102=520.000

$103=100.000

$104=100.000

$105=100.000

$110=18000.000

$111=18000.000

$112=6000.000

$113=1000.000

$114=1000.000

$115=1000.000

$120=1000.000

$121=1000.000

$122=500.000

$123=200.000

$124=200.000

$125=200.000

$130=370.000

$131=250.000

$132=50.000

$133=300.000

$134=300.000

$135=300.000

ok

$I

[VER:1.1.2022011201:]

[OPT:MPHSW]

[MSG:Using machine:MKS DLC32]

[MSG:I REMOVED NETWORK INFORMATION HERE]

[berainlb (PY)]

@seabeepirate

I set the machine settings to match when I set it up

I don’t believe that’s how this should work. If you set $30 to 500 and set S Value Max to 500 you should get the equivalent power level to if you had both se to 1000. The values for $30 do not represent an absolute value. It represents the index value for max power. Basically what is the value that will send 5V to the PWM line. If you wanted to attempt to limit current this way you’d have to set $30 higher than S Value Max.

However, this is not an ideal way of trying to manage current as you’d be reducing your addressable resolution with this route. The better approach would be limiting current from your LPS.

I think you might be able to retain resolution if you set $30 to 2000 and change S Value Max at 1000. That would limit your power to 50% of “full” but also give you 1000 steps.

One issue I see is that you’ve setup your device type as GRBL-LPC rather than GRBL. You can edit your current configuration and change this.

Retest after doing that.

If you get no change, try running a test using “Constant Power Mode” enabled in cut settings. It should now be available to you with the device type change. If this works it indicates that the root of the problem is in variable power modulation. GRBL in laser mode attempts to modulate power to prevent burning when the laser slows down. However, since CO2 lasers have a minimum power required to energize the laser the requested power level may be dropping below that threshold. Constant power mode will basically disable that feature.

If you find that the variable power is the culprit you’ll need to up your speed and or power to compensate.

You could try increasing $31 minimum power but I think that will end up leaving lines during traversal moves.

[seabeepirate (David Bitecofer)]

@berainlb

If you set $30 to 500 and set S Value Max to 500 you should get the equivalent power level to if you had both se to 1000

If it’s supposed to work that way then the software does not function properly. I found the info I used to determine this setting on this forum but I’ll have to search for it again to reference it here. I didn’t guess at that number, I incrementally reduced it until the max current was under control. My power supply does not have a separate power modulation control so unless I disconnect the controller from the pwm line I have no way of setting it’s power level independently of the MKS, this would also leave it firing at whatever power setting I manually put it on 100% of the time since I would have to remove the controller to do it.

I don’t believe this is a minimum power problem because the blue layer in my design runs at lower power and higher speed without issue.

With the device set to GRBL it will not connect to my controller, I found that GRBL LPC would connect through trial and error.

[berainlb (PY)]

@seabeepirate

lower power and higher speed

The higher speed makes this not apples-to-apples I suspect. But deserves review based on testing.

@seabeepirate

If it’s supposed to work that way then the software does not function properly

This would break a lot about known GRBL behavior if true. Definitely share the Topic if you can track it down. How are you measuring current based on this?

And to make sure I understand. You were running tests at 100% power in LightBurn while clocking down both S Value Max and $30?

Here’s the excerpt from GRBL site for how this should work:

$30 - Max spindle speed, RPM

This sets the spindle speed for the maximum 5V PWM pin output. Higher programmed spindle RPMs are accepted by Grbl but the PWM output will not exceed the max 5V. By default, Grbl linearly relates the max-min RPMs to 5V-0.02V PWM pin output in 255 increments. When the PWM pin reads 0V, this indicates spindle disabled. Note that there are additional configuration options are available in config.h to tweak how this operates.

So I suppose it’s possible that some other configuration values were tweaked in the build but again, these aren’t meant to be absolute values.

@seabeepirate

With the device set to GRBL it will not connect to my controller, I found that GRBL LPC would connect through trial and error.

Where did you get your firmware? If it’s not working on GRBL then there’s likely something else wrong.

You could potentially still test for constant power by either trying to switch to GRBL-M3 or generating g-code and swapping all M4 for M3. You may need to disable $32 if you use GRBL-M3.

@seabeepirate

My power supply does not have a separate power modulation control

Could you potentially add one? A hardware solution for this is probably better.

[seabeepirate (David Bitecofer)]

@berainlb

And to make sure I understand. You were running tests at 100% power in LightBurn while clocking down both S Value Max and $30?

Yes. I used the laser test function in LightBurn and had to stop the operation the first few tries because the current on my ammeter was jumping way too high. The M2 nano that I replaced had no qualms with overpowering the laser and the digital controller was the only way to set it’s power but I removed that to use it’s pwm line on the power supply with the MKS. As far as I know there aren’t readily available go between boards to handle this so I’d have to make something myself and since I didn’t finish my electronic engineering degree this is not ideal haha.

@berainlb

Where did you get your firmware?

The firmware is what came shipped on the board so I’m leaning more and more towards this being the problem. MKS say’s it’s GRBL 1.1f but since the GRBL setting in devices doesn’t connect I’m suspicious.

@berainlb

I suppose it’s possible that some other configuration values were tweaked in the build

Since I didn’t flash the firmware myself I have no idea what may have been tweaked, this could explain why I get unexpected behavior from reducing the S-Max and $30. It might also explain the other quirks I mentioned in the first post. I’ll try getting it from GitHub tonight and see if that fixes it.

[seabeepirate (David Bitecofer)]

I’m not sure where I read that this board runs GRBL 1.1f. I don’t think it does now. MKS also makes an 8 bit version with a similar name that pops into my search results a lot so maybe I read the wrong page. Looks like I’ve got quite a bit of reading to do tonight.

[berainlb (PY)]

@seabeepirate

As far as I know there aren’t readily available go between boards to handle this

Take a look at these posts from Cohesion3D for a perspective on this. These ideas might be applicable to your setup.

LaserBoard LPSU Connection Guide - Cohesion3D

Cohesion3D PWM Control and Potentiometer vs ‘Digital Panel’ - Cohesion3D

@seabeepirate

Yes. I used the laser test function in LightBurn and had to stop the operation the first few tries because the current on my ammeter was jumping way too high

This is kind of messing with my mind and could break my entire model for how this was supposed to work if this plays out. Do you have a meter that you can use to test the PWM voltage? If voltage changes at 100% depending on $30 value then what you’re seeing would play out.

@seabeepirate

Since I didn’t flash the firmware myself I have no idea what may have been tweaked

What’s odd is that what you’re running seems to be a pretty current version but I can’t find that specific version on Github.

I don’t see anything in the “[OPT:MPHSW]” list that would affect max power interpretation but I may be missing something.

[seabeepirate (David Bitecofer)]

What I think I have found is that this is not exactly GRBL but maybe a Chinese version? MKS has it’s own firmware preloaded on the board, when I finally thought to search the menu on the screen I tucked away inside the box I found it’s running firmware V2.08(8M. H35. 20220112) so definitely not GRBL 1.1f. I’m gonna have to start bookmarking things so I can find them again because I couldn’t find anywhere that said this was running GRBL.

I found this in the GitHub section about parameter configuration

I think MKS is doin their own thing here. The firmware is not currently open source so aside from knowing that I have the most current version I know practically nothing about it. It appears the firmware version on my board is newer than the newest build on the GitHub page. Not that it does me any good.

I think the firmware is the most likely source for my trouble.

[berainlb (PY)]

There are others using your board without incident so it’s not likely something that can’t be overcome. I’ve never heard of anyone using your board having to use GRBL-LPC.

As far as your original problem, have you tried running a modified g-code that’s swapped out M4 to M3? That will at least isolate if the original issue is related to power modulation.

As far as the description for $30 in that table, I don’t think it’s necessarily different than standard. Just more vague. It defines the value for 100% duty cycle.

[seabeepirate (David Bitecofer)]

I know others are using the same board but I’ve had no luck with searching for their device settings. The auto detect did not find my board which I guess isn’t a problem for most people? I haven’t run a modified g code yet but I can try that next time. Something else I think I have set wrong is frequency which could be totally unrelated, I read that for CO2 lasers frequency should be set to 20khz I think?

[berainlb (PY)]

@seabeepirate

The auto detect did not find my board which I guess isn’t a problem for most people?

It’s not uncommon for “Find my laser” not to to find a laser so that by itself is not likely something to be too concerned with.

@seabeepirate

I read that for CO2 lasers frequency should be set to 20khz I think?

I don’t know if that’s a “should be” situation but I believe that’s the default frequency for Ruida controllers. In either case I don’t see that being the cause of your original issue but you never know. I believe PWM frequency is a compile-time configuration so you’d have to create a custom build.

[seabeepirate (David Bitecofer)]

OK, after a little break I read this all again and went back to why my device wouldn’t connect on the regular GRBL device setting. I couldn’t remember if I had tried the GRBL-M3 setting either. When I created the new GRBL device the console gave me a message, " Waiting for connection…

Port failed to open - already in use?"
I get this message every time I create a new device in device settings. I close LightBurn and restart it and it works! I’m gonna blame it on too many late nights.

But I still have the original problem on regular GRBL. So I set S-value Max to 1000 in both places and I still have the OP. I went into the layer settings and tried constant power mode and it hangs immediately after starting. No error messages and it’s not disconnected, it just stops moving and the job timer keeps on counting.

Finally, I think it was the frequency. I noticed when I was fiddling with the S-value max that at 500 I had more complete lines but much lower power output. My analog ammeter was reading 2mA at 500 vs 6mA at 1000. None of that made sense to me so it made me wonder if there was some kind of resonance or feedback causing problems. I typed $28=20000 into the console, it responded OK, I hit play on my test and it worked perfectly. I don’t know why the frequency would cause the incomplete cuts for sure but I can reproduce most of these quirks to make videos if it’s helpful at all.

[seabeepirate (David Bitecofer)]

I really appreciate your patience, you gave me all the info I needed to get this working. It’s really been driving me nuts.

[berainlb (PY)]

@seabeepirate

I typed $28=20000 into the console, it responded OK, I hit play on my test and it worked perfectly. I don’t know why the frequency would cause the incomplete cuts for sure but I can reproduce most of these quirks to make videos if it’s helpful at all.

I wasn’t aware of $28 setting. Apparently it’s a custom settings that some modified GRBL firmware have adopted to set frequency. After doing some research it looks like this may be more about LPS regulation. Apparently some LPS struggle when not running under ideal frequency ranges so not properly energizing the laser.

Glad you were able to push through and get this sorted out. This will be good for the next person coming around with a similar setup.

[husche (Hub Schenk)]

@seabeepirate

So far I’ve tried various speeds and power settings thinking I wasn’t running it hard enough to trigger the laser coming out of corners but no luck on that front. I tried changing my S-min from 0 - 50 - 100 - 150. This didn’t seem to make any difference except that I started having issues with the cardboard catching fire. I switched to 1mm plywood for a few tests so the material wouldn’t burn as easily but even with higher power settings there were sections that the laser wasn’t firing. In the project I uploaded the cut power is lower than I’ve been running, I was up to 22.5% and on my most recent attempt I turned it down to 15% and ran multiple passes. My blue layer runs at a faster speed and a lower power setting than my normal settings for red and black and it doesn’t seem to be missing anything. It doesn’t seem to be related to my power setting or the S-min setting but I could be missing something.

I’m using the shielded USB cable omtech sent me with the laser and before I replaced the nano board this was never an issue. I took some time to clean up the wiring to the control board and moved the stepper wires as far from the usb as I could then moved the board as close to the opening as I could so as little of the USB cable is with all the wiring inside the case as possible. As it is I have less than 1" of USB cable sticking into the machine to try to reduce any noise it might pick up from the other wiring.

Here’s where it gets weird. On multiple pass operations like my cut lines(red) I noticed that sometimes the laser DID fire in the sections where on previous passes it had not fired. It’s intermittent though and I don’t have a way to tell if it will fire or not on subsequent passes. I ran the cut lines for a total of 6 passes and still it’s missing bits so extra passes as a workaround won’t work.

There are a few other quirks since I replaced the nano board that may be related but I don’t know.

I have to draw a box around the entire job or the cut and engrave layers don’t align when the job is finished.

Sometimes after I change machine settings I lose connection with the control board and have to restart LightBurn, the machine, or both.

Sometimes when the job finishes, LightBurn just keeps on counting the job time and it says the laser is busy until I hit the stop button. There are no new messages in the console for clues when this happens but I don’t lose connection and it doesn’t seem to be hurting anything so I haven’t worried much about it.

On a handful of occasions the laser has just stopped with no alarm or message of any kind. The machine status reads ready when this happens to me. I can home and start from the beginning again but I have no idea if there’s a way to start the job again from where it left off. Because this is practically impossible to reproduce at will and doesn’t happen very often I’m not focusing on it but I wanted to share in case it’s related.

Hi. This is indeed strange and difficult to reproduce. To be sure if the bug is software related (rather unlikely) or hardware related, I would recommend taking a simple pattern and generating the gcode first. This can be read with any text editor. If there are no visible interruptions and the machine still does not fire continuously, it is definitely due to the hardware. I can’t say where exactly because I’m using different hardware.