This image shows how the cut was going fine with Air Assist and then stopped. In subsequent tries, the Air Assist stops in another random place and not at the same area as previously.
Thank you.
1 Like
In case you missed it, weāre going to be very busy for the coming days with LBX, so there may be a bit of a delay in resolving your issue. Iām setting up a reminder to look into it again after the event travels are done with.
I have a similar, but slightly different topic. For me air assist and fume exhaustion are working when doing a material test. But when using the best settings from the test for cutting with air assist on, neither air assist nor fume exhaustion are working.
After reading this post, I tested using 1.7.08 and now air assist and smoke exhaustion are working fine. So something was changed when changing to 2.0.1. I also checked the generated g-code in 2.0.1 and the M8 commands were before every shape I wanted to cut.
Is M8 the command to start or stop air assist for you?
Please keep in mind that my OP is still unsolved. Thank you.
I realize. And Iāve tried to understand why it isnāt working. Iām still confused by the output being generated. Any new data point on this problem is helpful.
I have observed that when cutting the project (which is all cuts) the Air Assist stops after completing a cut and moving onto the next cut. For instance, there are some small windows that are cut out. The first window is cut and at the next cut it begins with the air off.
Another try had it completely cut all the windows and cut another large region and during the move to the next cut the air turned off. So, with the same file it doesnāt always happen at the same coordinates as the previous iteration.
Note that this only occcurs with v2.0.x.
To further test this, I created a grid of small squares to see if I could replicate the problem. But so far it only seems to do it with the particular file for the original project.
Thank you.
1 Like
@birnenpfluecker @TrajoMarx so the initial halloween.gc file output shows the M9 command (to stop air assist) only at the end of the file, not anywhere else.
Iāve noticed this when trying to replicate it locally as well, saved gcode output does not seem to show any difference with that saved from 1.7.08.
Any chance either of you can share your lbrn2 file with me so I have a known-bug causing file? I can then try and stream it to my test rig and debug through it to see whatās happening.
happoween.lbrn2 (164.5 KB)
Thank you.
no, thank you! Now I can get to the bottom of the problem 
Ok this is a really stupid check, but I think itād be good to do anyway.
Because streaming it I donāt see anything unusual - no M9 is emitted. But Iām seeing a few G1 S0 while youāre in constant power mode. We put that G1 S0 in to make sure we turn off the laser - some controllers didnāt if we didnāt add that in.
To make sure we eliminate the obvious, can you please try to run from the console:
G0 X0 Y0
M8
G1 X40 Y40 F600
G1 X10
G1 Y10
G1 X40
G1 S0
And let me know if the air assist turns off?
If it doesnāt, you can do it manually by sending M9 afterwards.
Iām just wondering if it could be something happening when the GRBL coprocessor is busy controlling motors and the G1 S0 being mis-interpreted. It shouldnāt, but Iād rather make sure.
The air assist stayed on.
Thanks. Ok I need to get some other colleagues to look at this, because I am at a loss as to whatās happening.
1 Like
One other thing I forgot to mention: I run Lightburn on a Mac (Intel CPU) if this is of any relevance for you.
Ah interesting.
@TrajoMarx are you also on a Mac?
@TrajoMarx See, if āEnable DTR-Signalā in the Device Settings helps.
I recently had access to the Falcon A1 Pro where it was needed. It may help in your case, too.
I enabled DTR-Signal and had high hopes. But the Air Assist stopped again midway through.
Thanks.
Thanks for confirming. It was worth a try. 
We created an internal bug report and will get back to you once a Dev could take another look at it.
Thank you.