Lightburn software mistake

LightBurn Software Questions
1

When I cutting with LaserGRBL, the G-Code commands are issued in the correct order.
First , the laser is switched off with S0 and M5. Only then ist the cooling switched off with M9.

LightBurn is doing this incorrectly!
Here, the cooling is switched off before the laser. This causes an airflow alarm, Error 4.
Additionally , the Creality Falcon2 switches the laser module from normal mode to precice mode!
The laser then no longer operates at a maximum of 40 watts, but only at 22 watts!
The laser must then be manualy switched back to normal mode on the laser module

2

Can you show us the GCode of both programs?

There was a firmware issue with some Falcon lasers, where the air assist was misbehaving. Does yours turn off immediately when you send the machine the M9 command?

5

I had the same model, but the 60W version. I did not have those issues.

First, the air assist should always directly turn on and off when the command is sent. That’s correct. It’s different from the cooling fan. The cooling fan is controlled by the firmware and should run 20-30 seconds after the laser firing. The air assist is the external pump.

The switch between normal and precise mode is not possible via firmware, to my knowledge (at least back then when I had it). If this happens, this sounds again like a firmware issue.

As Aaron mentioned, I’d first flash the latest firmware version and then try again. Maybe the cooldown period is set incorrectly as well, this is an available firmware setting.

1 Like
6

@hobbysaeger Thank you for your clear report and sending us the GCode files via email.

Here’s a screenshot of both codes:

image
image788Ă—500 24.8 KB

I believe, it’s the second G1 S0 that throws the airflow alarm you mentioned.

I’m not sure why this command is being sent before and after the M9
Maybe, @goeland86 has an explanation?

7

@hobbysaeger Can you export your device profile and send us the .LBZIP file, please?

8

Only if it’s the only thing sent.

LightBurn sends commands in order to be executed in a buffer, for smooth execution. So no, the bug was the fact that M9 was executed the moment it was received, and not in the order or should be.

It could very well still be the issue you’re facing.

9
English version

I am trying to upload the file.
I have the latest software version for both the Falcon2 and the 40Watt laser module.

The commands in a G-code file are ALWAYS processed serially, i.e., one after the other. Even if the commands have been loaded into a buffer! If this were not the case, the behavior of a machine would be completely unpredictable!

This is precisely why the order of the codes is so important!
So first the command that stops the tool must come, and only then can the coolant be turned off!
LightBurn does this clearly wrong in my version.
I have LightBurn Core 2.0.05

I was able to partially work around the error by turning off AIR monitoring in Falcon with the command $153=0. But that doesn’t make sense in the end.
In addition, I have now entered the M8 command for restarting the cooling system under “Device Settings” - “G-Code” - “GCode Exit.”
This at least causes the laser module to return to “Normal Mode” when the laser has reached its zero position.

Ich versuche die Datei hochzuladen.
Ich habe die letzte Softwareversion sowohl vom Falcon2 als auch dem 40Watt Lasermodul.

Die Befehle in einer G-Code- Datei werden IMMER seriell, also nacheinander verarbeitet. Auch dann, wenn die Befehle in einen Buffer geladen wurden! Wenn das nicht der Fall, dann wäre das Verhalten einer Maschine völlig unvorhersehbar!

Genau deshalb ist die Reihenfolge der Codes so wichtig!
Also muss zuerst der Befehl kommen, der das Werkzeug stillsetzt und erst danach darf das KĂĽhlmittel ausgeschaltet werden!
LightBurn macht das in meiner Version eindeutig falsch.
Ich habe LightBurn Core 2.0.05

Ich konnte den Fehler teilweise umgehen indem ich die AIR-Ăśberwachung im Falcon mit dem Befehl $153=0 ausgeschaltet habe. Das ist aber letztlich nicht sinnvoll.
Zudem habe ich jetzt unter “Geräteeinstellungen”-“G-Code” - “GCode Beenden” die Anweisung M8 zum nachträglichen Wiedereinschalten der Kühlung eingetragen.
Das bewirkt zumindest, dass das Lasermodul wieder auf “Normal-Mod” geht, wenn der Laser seine Nullposition erreicht hat.
Device Falcon2 E-Brill.lbzip (4,5 KB)

10

For GRBL, some commands bypass the execution queue and are executed immediately.

This is the case for !, \0x18, ? and a few others commands, and are called “instant commands”. In the original Falcon firmware, there was a bug where the M8 and M9 commands were incorrectly treated as instant commands.

I still think this is the problem you’re facing, and not an issue with a second G1 S0 entry.

We had another user with the same error, and until we diagnosed it as a firmware problem with Creality, we could not resolve it.

Please verify that you have the latest firmware update on your device.

1 Like
11

Hello. I programmed a 5-axis machining center for many years, back when we only had a teletype. We also trained everyone in our department in CNC machine programming. We programmed G-code by hand. Before an expensive milling cutter could start, the coolant had to be running. Switching off the coolant before the cutter had come to a complete stop would have destroyed the tool! There’s a very clear sequence for commands to a CNC machine: 1. Turn on coolant. 2. Operate the tool. 3. Switch off the tool. 4. Switch off coolant. The free program LaserGBRL does this correctly. Lightburn, unfortunately, does not. Furthermore, Lightburn seems to lack the awareness that it’s outputting the commands in the wrong order. A real shame! My Falcon 2 has the latest software for both the controller and the laser module. I will still continue to use Lightburn, however, because it’s otherwise a really great piece of software.

12

The air assist on a laser is not always turned on.

In some cases when engraving, you turn it off so as to not drag soot across the top surface.

What is correct on a 5 axis cnc and a laser engraver is different.

You can use the custom gcode tab in the device settings to modify the end of job squeegee to suit your preferences /needs. I still am not clear what’s causing that error message, because G1 S0 on older grbl was the best way to set the power to zero, and M5 would disable power to the tool as a whole.

I respect that you’re familiar with gcode and machining. But we have to take multiple different machines and gcode firmware versions into account. We do our best to make it safe and sane for as many devices as possible out of the box. But we’re often playing catch up with the various custom changes of manufacturers who decide to create another “standard” and do not document or consult others in the field.

1 Like
13

With Air Assist activated, Lightburn switches on M8 as needed before activating the laser in the next step. The Falcon then has the following information: The air pump is running, and also the laser. This combination is monitored. If the air pump is now switched off, an error occurs because the Falcon’s controller still has the information that the laser is switched on. Only in the next step is the laser power set to zero with S0. This comes too late. And M5, to switch off the laser, comes again one step later. This is clearly the wrong sequence. The controller in the Falcon behaves according to the standard. If the controllers of other lasers do not adhere to the standard and do not recognize this error scenario, this does not indicate that these devices are functioning correctly.

14

I don’t want to continue this discussion, as they are clearly primarily looking for faults in others. They are not considering their own mistakes.

15

I mentioned you can, and should, modify the Job End section of the Custom Gcode profile:

image
image491Ă—621 9.28 KB

I don’t know if your default is M2, or something else.

At present I cannot say why the firmware is throwing this error.

This is the first and only report of this issue so far.

The gcode files emitted do not tell us how you have configured LightBurn to work with your device, and saying we’re not listening, is inaccurate.

It is common for users who have cut and engrave layers in the same job to turn air assist on and off several times. The firmware of the A1 would prevent that if it is indeed behaving as you report.

Therefore I suggest that the issue - again - is not in the defaults that have worked for millions of other laser users, but with this particular configuration and device.

I do not have the device, nor the LightBurn configuration bundle to be able to further evaluate if the software is indeed doing something wrong.

Compatibility with various vendors, again, is a complex dance, and I apologize if you feel like your voice isn’t heard - that is not the case. I’m simply saying that we need to look at how to tell LightBurn to correctly talk to your device. And at the moment, I can only tell you what has been done as a sane default for the use-cases our other users successfully use.

If we need to tweak the configuration for the A1, then I’m happy to help you do so. But I can’t do so in a vacuum without enough information to go on. Saying that because a firmware error is thrown while comparing gcodes of 2 different software only tells us the superficial effect.

What really matters is how LightBurn is configured so that it created the gcode that caused the error. I would appreciate the configuration bundle of your device so that we can help you fix it.

3 Likes
16

I think he is talking about this (generated with the standard grbl profile):

; LightBurn Pro 2.0.05
; GRBL device profile, current position
; Bounds: X0 Y0 to X101 Y155
G00 G17 G40 G21 G54
G91
M4
; Cut @ 600 mm/min, 90% power
M8
G0 X0Y85
; Layer C00
G1 Y70S900F600
G1 X101
G1 Y-70
G1 X-101
; Cut @ 1500 mm/min, 80% power
M9 <===============================
G0 X29Y-15 <=======================
M3
; Layer C01
G1 X71S800F1500
G1 Y-70
G1 X-71
G1 Y70
G1 S0
M9 <===============================
G1 S0 <============================
M5
; return to starting pos
G0 X-29Y-70
M2

These two should be sent the other way around. The AA is turned off first, then the laser is turned off. I can follow the arguments and suspect he is right here. It’s only that the standard grbl firmware does not have the functionality to check the AA status while running. It simply doesn’t care. So to speak, the Creality firmware is more advanced, and the safety check is correct to throw an error, though the next command should make the error obsolete, but the firmware won’t do a lookahead before throwing it.

(be aware in the gcode above, the second object didn’t have AA activated).

17

Thanks Melvin!
It’s good that someone finally sees the problem. Programming in G-code is internationally standardized according to the ISO 6983-1 standard for all NC controls. This also applies to the sequence of certain commands.

18

Yes, this might be the case in industry, but we are in the maker community here. The firmwares available for most lasers are not written by professionals and I guess 90% of all those firmware and protocol developers have never heard of any ISO standard :grinning_face: Most laser manufacturers copied their base firmware from one small project that was never meant to drive thousands of different lasers (and is discontinued since many years).

So on the one hand, there are standards, but you can’t rely on them here. That’s why nobody noticed this issue before, because none of the other firmwares cared about it.

But still, changing the command order should not break the other firmwares and enable more strict ones. So it would be a good bug to fix.

1 Like
19

Exactly what I was trying to explain, but a better way to phrase this is :
There are now as many standards as there are manufacturers.

This has been our experience trying to write GCode sending systems.

Also ISO standards for industrial 4+ axis machines simply don’t apply here - 99% of the machines we are sending gcode to come from code that started as hobby open source projects like GRBL, GrblHAL or FluidNC. The hobbyists never paid attention to ISO standards because why would they?

I’m not saying the logic for Creality is wrong as far as safety or sanity checks are concerned. I’m just worried about how to make sure we don’t break all the other machines’ behavior by changing something for 1 new machine type.

Our experience, unfortunately, is also to see manufacturers creating new firmwares for new machine series, with little to no cross-compatibility between the gcode definitions they created.

LightBurn, therefore, has to be extermely flexible in the gcode it can generate and send to various devices. You’re saying we’re wrong, but maybe it’s a matter of changing some configuration parameters to match your device instead of a completely general error. LightBurn does not simply speak one gcode standard, it has a whole host of possibilities to tweak it as needed for the wide range of differences.

SO. @hobbysaeger can I ask you to please export the device configuration for your device? This will help me see what

2 Likes
20

This ist the file

Device Falcon2 E-Brill.lbzip (4,5 KB)

1 Like
21

If this file is not sufficient, then I can take screenshots of all the settings and upload them.

22

Thank you. The file is perfect, it has all the required settings in it.

It appears you’re using a grbl device profile, which makes a number of assumptions about the firmware. I’m not entirely certain that is the correct device profile type to use for this machine, as it is not a standard GRBL firmware, but a custom version written by Creality.

@Aaron.F you’ve played with the A1 before, do you remember if you used a GRBL or Custom Gcode device profile?

Or were you playing with the A1 Pro? (which iirc has yet another firmware spec…)

1 Like