test.gc (35.2 KB)
I’m trying to parse this gcode to determine what commands are being sent to the printer that should be turning off the laser for traversal moves. They’re not being followed, and I’m trying to determine if it’s my error in Lightburn or if it’s something controller-specific I’ve got to run down. Any thoughts?
Well, it’s a brand new rig, so I’m hoping (but not absolutely certain) that it’s not a problem with a dying PSU. I am using the Laser Mode console entry, and that is part of the gcode I posted, so at least that’s not the problem, as best I can tell.
I’m also waiting for some feedback from the manufacturer, but I’m doing what I can to try to nail down any possibility of a software issue while I wait for them.
The GCode doesn’t have this command. This is in the machine firmware. In the console window in LightBurn type $$ and press enter. Look in the results for the $32 command. It will probably say $32=0. If that’s the case type $32=1 and press enter. Then type $$ again and verify that it changed. That should solve your issue.
Hmm, it’s definitely in laser mode.
I’m going to keep working on the hardware side of it, I’m just trying, at this point, to chase any software-side problems.
It’s pretty possible that this is a problem in either the PSU (as was mentioned before) or the controller, but at this point I’m just trying my best to eliminate every possibility that I can manage on the software side while I wait for the manufacturer to get back to me.
Just to confirm, M3 as a command entered into the Lightburn console should have the laser shut off, right?
In traditional CNC programming (i.e. on industrial CNC machines) M3 is spindle clockwise, M4 is spindle counter-clockwise and M5 is spindle stop. This has been slightly modified on GRBL laser machines to be (I believe) such that M3 is laser enable (constant power mode), M4 is laser enable (variable power mode) and M5 is laser disable. If the laser is in the enabled (M3 or M4) state the controller will keep the laser off until one of the ‘feed’ moves is issued (G1, G2 or G3) but as soon as a move command (G0) is issued then the laser will turn off (if $32=1 is set i.e. laser mode). The laser will again come on with the next feed move. An M5 is issued at the end of the program to disable the laser for safety.
I used to be a CNC programmer but that was over 30 years ago and everything was hand coded, none of this CAM stuff! I’m not very familiar with the particular dialect that GRBL uses so someone might be able to correct anything i’ve got wrong above.
Hope this helps
So you confirmed that $32=1?
For non-laser stuff, it’s basically the same as LinuxCNC:
https://linuxcnc.org/docs/stable/html/
The GRBL doc on Laser Mode:
Yes, I have confirmed that in the console.
So, right now, the laser comes on immediately when the controller is powered on and fires continually. No combination of M3/M4/M5 commands fed to the Lightburn console (when connected) appears to control that (and as Tim suggested, I did confirm that the system was in $32=1 mode).
It’s actually doing this even if no gcode or connection to lightburn are enabled, which does not seem like intended functionality and leads me more to believe that I’m dealing with some sort of hardware defect. And also doesn’t seem terribly safe, of course.
So the laser comes on as soon as you power it up without a file being run? Does it appear to be full power or low power, like for framing? Has it ever worked properly?
I’m not sure what power the always-on “mode” is at, because this thing is so new that I don’t have a full scope of what full vs. low power should look like and I haven’t been shoving things in front of it to see. It seems to be a fairly high one and might just be full power.
As far as I can remember, it has always done this. I suppose I hadn’t considered that this might not be working as intended, as I was more focused at the time on trying to troubleshoot why it was frying every image gcode I tried sending at it. In that light, I’m definitely leaning more toward the bad hardware explanation unless the manufacturer is able to point out that I’ve installed something wrong and am just bone stupid.
If the laser is always on it’s definitely a hardware issue. Whether manufacturer created or user created, I can’t tell, LOL. It should sit there forever without firing until a command tells it to do something else. Think about it, this would be a huge fire risk if it was the norm.
I would get in contact with the manufacturer.
1 Like
When the laser is always on while power is on, then there is a hardware issue. First, check the connections to the laser head (are we talking about a diode laser?) Be aware that the PWM signal pin may not be floating, then the laser will arbitrary fire. It needs to be pulled low for it to be turned off. Maybe the signal cable was connected to the wrong connector?
There are G0 moves in the GCode that should shut the laser off (in laser mode).
For milling with a spindle, the approach is to not shut the spindle off fully as it moves between shapes or paths with a G0 command.
In your Profile it says you’re using a Creality Falcon 10W.
I’d be interested to know the firmware revision number.
They made a change to the laser controls.
2 Likes
All issues have been resolved, and I really should have seen the solution coming: it was, in fact, a bad-on-delivery unit incapable of regulating the laser. A quick exchange with the seller and everything is working fine straight out of the box.
3 Likes