This halts the code for delay_ms so my laser works fine.
However, when I created 2 identical profiles, with the same power/speed to create inner and outer cuts, there are 2 issues:
I believe LB is the cause - Between profiles, the code generated does not issue an ‘S0’ command, the laser stays on.
Probably a FluidNC issue - Because there is another M8 command in the second profile, the machine then delays for another 6 seconds between profiles. With the Laser on, this means it burns a hole in my work.
Surely LB should be issuing an S0 at the end of each profile?
I wouldn’t quite put it this way because S is stateful. Any subsequent G1 command will reference the last S value state. So it’s probably better to state that S value is irrelevant when no active G1 is in process (or even G2 or G3 but LightBurn doesn’t generate arcs)
I’m not super familiar with FluidNC configuration but make sure you’ve got the Laser spindle tool number activated.
Are you running a release version or did you compile yourself?
So is it a continuous on? Not an “on” for when the laser should be firing?
Like i said, it’s complicated!
The laser has a mechanical shutter for safety. This is activated with a solenoid, in my case, with the AA/Flood output. Once the shutter is open, this activates a capacitive sensor, which controls the EN signal to/for the laser (Internal laser controller function). Between receiving an EN signal and being able to fire the laser with a PWM signal, there is a 5 second delay. i.e it Ignores all PWM until 5 seconds after the EN signal is received.
Once the 5 seconds has passed, it will happily work like any other TTL/PWM laser as long as the shutter, and therefore the EN pin remains active.
I’ll try adding the specific tool setting with some test cuts a little later on and see if it makes any difference
Spot on. Part of the reason for the mechanical shutter is also because it has a visible laser in the path for alignment. Shutter off, there is a mirror that reflects a red laser down to the head.
I do have the option of decoupling the shutter/en features but this makes the most sense to me at the moment to keep it as is. I think the original controller had the ability to control EN directly and then just controlled the shutter before a cut because it did not have a 5sec delay. It’s 99% working fine, it’s just these few bugs i’m ironing out.
So I’ve spent some time over on the FluidNC github and the developers have cleared up some stuff with me. Basically, it boils down to Lightburn not generating the right gcode when using M3 (Constant power mode).
If i swap the M3 (constant power) for M4 (variable power), it operates as expected but in M3 mode the GRBL software needs to be instructed to turn off the laser:
Constant laser power mode simply keeps the laser power as programmed, regardless if the machine is moving, accelerating, or stopped. This provides better control of the laser state. With a good G-code program, this can lead to more consistent cuts in more difficult materials.
Basically, Lightburn should be including a G0 before the M8 command to make sure the laser is off. For a lot of people, this would not even be apparent unless their machine has a delay on M7/8 commands, as the M7/8 command would be interpreted and instantly move to a following G0 command where the laser would be commanded off at the controller level.
Not really following this. When did M3 come into the picture? All previous discussion on this was based on M4.
Ignoring for a minute the confusion on how this became a discussion about M3, does this mean that FluidNC is backing away from their claim of backward compatibility with GRBL? M3 profile and Constant Power Mode work without fuss on traditional GRBL systems.
More like when wasn’t it - As you can see in my original post, it uses M3 (although there is a random M4 at the start.
Not at all. I think this is more of a ‘perfect storm’ type issue. Mainly because M7/8 delay_ms does not exist in the original grbl firmware. So yes, it’s still backwards compatible as such. This is something that has been implemented specifically in FluidNC. Even for those running FluidNC, there is probably not many that would be using a delay, or at least not anywhere near as long as what I am so might not even know the issue exists.
I even run FluidNC on my Vinyl cutter (driven by LightBurn), and didn’t even really notice it because who cares that the cutter stays down for a bit between layers (I use Coolant control for suction fans on that, but with only 0.5 sec delay)
As you can see, it’s quite a specific environment that this issue shows up.
Yes, indeed, you are correct. I misremembered and missed it on review.
I read through the discussion on Github. It sounds like the argument is that since M3 is intended to run irrespective of motion state that the laser should stay on after the completion of a G1 until a G0, S0, or M5 is issued. The complication comes when an M8 with a delay is introduced between a G1 and subsequent G0. With no M8 delay the time between G1, M8, and G0 is so small that the laser turns off almost immediately. However, the issue becomes apparent when M8 with delay is introduced which causes the laser to stay on from initial G1 until subsequent G0.