Laser not shutting off between profiles

[elnino (Andrew)]

I have a Gravoraph C02 (RF) laser that I have replaced the controlling hardware with a MKS Tinybee running FluidNC.

For this specific laser, there is a shutter, and the laser does not work until 5 seconds after the shutter is opened.

For this, I am currently using the ‘Air assist’ or M8 with a setting in fluidNC that delays the machine for 6 seconds before moving:

coolant:
flood_pin: gpio.14
mist_pin: NO_PIN
delay_ms: 6000

(arbitrary example)

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:

1. I believe LB is the cause - Between profiles, the code generated does not issue an ‘S0’ command, the laser stays on.

2. 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?

Example output from LB.

; LightBurn 1.3.00
; GRBL device profile, current position
; Bounds: X0 Y-3.7 to X12.7 Y0
G00 G17 G40 G21 G54
G91
M4
; Cut @ 5 mm/sec, 90% power
M8
G0 X9.626Y-1.477
M3
; Layer C01
G1 X0.147Y0.272S90F300
G1 X0.196Y0.236
.......
; Cut @ 5 mm/sec, 90% power
M8
G0 X-6.475Y-0.183
; Layer C00
G1 X-0.033Y-0.322
G1 X-0.093Y-0.301
G1 X-0.147Y-0.272
.......
M9
G1 S0
M5
; return to starting pos
G0 X-3.188Y1.639
M2

[berainlb (PY)]

@elnino

G1 S0
M5

Not quite following.

I see an S0 here as well as an M5. Both of these should effectively stop the laser.

[elnino (Andrew)]

Yes, but not BETWEEN profiles, only at the end of the job

[berainlb (PY)]

When are you changing profiles that’s not occurring between jobs?

[elnino (Andrew)]

When for example you want to cut holes in an item and then cut an outline, to cut the part out. Controlling cut order so to speak.

Perhaps my terminology is not correct - In the Cuts/layers part…

Not that I think it matters since even changing parameters (speed/power) it still does not produce an S0 between profiles.

There is another post here with a similar subject but with no solution. That seemed specific to the M8 commands but even removing the AA, it still omits an S0 between profiles.

[berainlb (PY)]

Got it. You’re talking about Layers.

Your laser should not be cutting without an active G1 command with positive S value. After the G1 is complete laser should not be firing. G0 should not fire the laser.

If it is, this is a configuration issue in FluidNC.

[elnino (Andrew)]

Ok, that makes some sense. So what you’re saying is S0 is implied because there is no G1 movement at the time right?

I don’t see anywhere this would be a config item in FluidNC. It’s in laser mode and the only other areas that would be applicable are
S0_With_Disable and
Disable_With_S0

Neither of which are really relevant here that I can tell.

I can only think that it’s a bug with FluidNC itself. I’ll post something over there and see what the response is like.

Thanks for the help

[berainlb (PY)]

@elnino

So what you’re saying is S0 is implied because there is no G1 movement at the time right?

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)

@elnino

It’s in laser mode and the only other areas that would be applicable are

I’m not super familiar with FluidNC configuration but make sure you’ve got the Laser spindle tool number activated.

@elnino

I can only think that it’s a bug with FluidNC itself. I’ll post something over there and see what the response is like.

Are you running a release version or did you compile yourself?

[elnino (Andrew)]

From what I can tell, with FluidNC, once you define a Laser, it puts it in Laser mode, it’s not like grbl where you can swap between the two settings with $32=0/1.

It’s defined as tool 0 but I can’t find anywhere in LB to set a tool anyway.

Laser: 
  pwm_hz: 10000
  output_pin: gpio.2:pd
  enable_pin: NO_PIN
  disable_with_s0: false
  s0_with_disable: true
  tool_num: 0
  speed_map: 0=0.000000% 100=95.000000%
  off_on_alarm: true

I’m running standard release 3.7.1

[berainlb (PY)]

From the FluidNC Wiki:

You change spindles by issuing the GCode command “M6 Tn”, where n is the tool number.

Is the 10000 Hz the expected frequency for your laser power supply?

Also, in the speed_map, you have the top range at 100. What have you set for S Value Max in Edit->Device Settings?

You have enable_pin set to NO_PIN. I’m not familiar with RF lasers but do you have a separate pin for enabling output on high or low?

[elnino (Andrew)]

Yes, my laser is a Synrad unit. It’s complicated, it has it’s own enable but that is activated by a capacitive sensor on the shutter.

I activate shutter, it activates EN line. PWM can be up to 25khz

I meant tool setting in LB itself but I guess that if no other spindle is defined then there is only that option. I guess I could manually add it and see what happens.

And yeah, i have 0-100 in LB as well

[berainlb (PY)]

@elnino

I meant tool setting in LB itself

LB is not tool aware. You could put this in the “Start gcode” field in the G-code tab in Edit Devices if you wanted to always ensure laser spindle.

@elnino

I activate shutter, it activates EN line.

So is it a continuous on? Not an “on” for when the laser should be firing?

[elnino (Andrew)]

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

[berainlb (PY)]

Thanks for the explanation. So basically a bunch of work to get the point of it being enabled but basically continuous at that point.

[elnino (Andrew)]

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.

[elnino (Andrew)]

So I tried manually setting the tool, that made no difference.

I’m pretty sure this is a FluidNC bug. I’ve posted over on their GitHub. We’ll see how it goes I guess but that’s the downside of FOSS.

[elnino (Andrew)]

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.

From https://github.com/gnea/grbl/blob/master/doc/markdown/laser_mode.md

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.

Link to the FluidNC Github thread: Problem: Laser Stays on during M8 delay_ms · Issue #1027 · bdring/FluidNC · GitHub

So, the workaround is, don’t use constant power mode (which admittedly was an oversight from when using my Vinyl cutter that needs me to use this) but ultimately the issue is bad gcode from lightburn.

[berainlb (PY)]

@elnino

Basically, it boils down to Lightburn not generating the right gcode when using M3 (Constant power mode).

Not really following this. When did M3 come into the picture? All previous discussion on this was based on M4.

@elnino

but ultimately the issue is bad gcode from lightburn.

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.

[elnino (Andrew)]

@berainlb

Not really following this. When did M3 come into the picture? All previous discussion on this was based on M4.

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.

@berainlb

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.

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.

[berainlb (PY)]

@elnino

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.

Yes, indeed, you are correct. I misremembered and missed it on review.

@elnino

As you can see, it’s quite a specific environment that this issue shows up.

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.

Let’s ask @LightBurn to comment.