Ugh, yeah, luban 
I’m using my RPiZW (camera for my SM2.0) with VirtualHere to forward the USB port to my desktop (over wifi) and running lightburn. No issues so far and way more convenient.
One nice thing with Luban though is that it will tell you the focus point for the laser, so you can use it to get the info to feed into lightburn. This info is ONLY available when using WiFi to connect to SM2.0
I was slowly losing my mind troubleshooting in isolation… If you are going to take a look at it I’ll reflash my controller and try and refresh where I was.
Well, M7/M8/M9 works now, but I have to reset origin before I can do a trial run
Interesting, I had added a M999999 command on start, which will fail, but it didn’t trip up lightburn. Maybe it just resets its statemachine once startcode is done. Ah well, we’ll see if I can etch the entire project now.
Nope, connection lost after 5:50 … Hmm, maybe the snapmaker drops DTR? Data Terminal Ready - Wikipedia … Trying again with the DTR flag disabled in LightBurn.
Yupp, this time it worked. So might be related. But since I got the focus wrong, I have a chance to try again 
Well this is odd, the inline option in LightBurn has seized to work. it never generates a M03 command. If I switch from inline to M03/M05 it works, if I trigger the laser manually from the fire button, it works. But if I switch to inline, I don’t get any fire command, it just does the moves. I confirmed it by saving the gcode.
I’ve restarted the program without any difference, I’ve reenabled DTR and it didn’t make a difference either. The layer is active and the output is set to 75%.
Going to open a thread on the lightburn forum as well, since this most certainly isn’t a firmware issue
Very interesting, nice to have a fresh set of eyes looking into this. DTR is a great thought, never tried that. Wouldn’t be surprised at all if I was down a completely different rabbit hole that was wrong.
Actually, I just realized that inline laser is the I parameter, which for some reason is ignored. Still learning about Gcode and since it worked once, but then stopped, I’m guessing that something doesn’t get cleared when the program is stopped or you get a disconnect randomly. Trying to find where the laser power is adjusted in the code. Seems to be a parameter for G1?
If lightburn broke, it can be reset by hitting the jog to origin button. There’s something about issuing a G0 X0 Y0 Z0 command resets comms. No other command I’ve found will.
Couple ways: G1 ... P50 or G1 ... S128 will do it inline. Also M3 ... I will
If you’re using the firmware binary I posted, I can’t remember if that supports the S command. If you compile from my repo the current version does support it.
This is part of the gcode output:
; LightBurn 0.9.20
; Marlin device profile, absolute coords
; Bounds: X89.28 Y53.95 to X147.88 Y128.95
G21
G90
; Image @ 1000 mm/min, 75% power
M8
M05
G0X117.58 Y53.95 F0
G0 Z24.9
; Layer C00
G91
G1X0.1 F1000 I S1.5
G1X0.1 I S5.3
G1X0.1 I S1.5
G1X0.1 I S3.8
G1X0.1 I S6.8
G1X0.2 I S7.5
G1X0.1 I S6
G1X0.1 I S2.3
G1X0.1 I S0.8
G1X1.1Y0.1 I S0
G1X-0.1
It’s issuing G1... I S... where I is inline laser and S is the strength. Trying to locate how this is picked up in the parser, because it would seem that snapmaker doesn’t actually do any laser commands unless it’s M3/M5 … It’s as if the inline laser code isn’t there.
Did you push your changes? Because when I do git diff origin/main origin/laser_inline git says there is no difference.
I just realised since it was still a bit buggy I never pushed my changes to my repo.
The I in G1 is ignored. All motion inline commands (G1, G2, etc) call get_destination_from_command(), and that is where the power is parsed from the command.
Tonight I’ll try to push what changes I have so far.
Here’s where it’s located in the Marlin implementation: Marlin/gcode.cpp at 5ee1087959f88dc60386ff3caa21e75d9e20b128 · MarlinFirmware/Marlin · GitHub
Looking forward to the update. Curious to see how this works out.
All my testing yesterday after I got your repo was done based on your branch with emulated M7-M9 commands and the disconnect only happened when DTR was on in lightroom. The errors I used to get for M8 or M7 went away since they now “work” and turn on the fan (M106 P0 S255).
Did you get a chance to push your changes?
Not yet, it is now.
branch: GitHub - brent113/Snapmaker2-Controller at laser_inline_testing_in_progress
commit: Not sure where this was left off. · brent113/Snapmaker2-Controller@dd7cfea · GitHub
If you build using the VSCode built in tools, don’t forget to update SHORT_BUILD_VERSION each time you build. The build script parses that as the firmware version, and if it doesn’t change the touchscreen won’t update the firmware on the controller, it will look like it does but it won’t. Ask me how I know…
I should add, if the changes that make it inline laser power work aren’t obvious to you, I’ve spent a long time thinking about why they work and would be happy to help you understand how these changes affect the behavior. The key idea is instead of handling laser power at the time of parsing gcode, it’s moved into the block inside the planner and placed on the queue, so that when the motion ISR inside stepper.cpp executes the steps it changes laser power during that time.
Ok, I’m sorry, but can’t resist. How do you know? 
Hahaha, it’s nothing beyond the obvious: I spent a few hours troubleshooting something broken only to realize that I wasn’t updating the version number and it never actually got uploaded to the controller. It’s not a problem when using a debugger than flashes the chip every time, which I was accustomed to. But then I switched to using the touchscreen to upload and was wondering why it was behaving unexpectedly. I’d think I’d fix a bug, but then it would still persist. Ended up writing a new gcode that would write some unique string to the terminal when I issued it, and found out that calling that gcode was invalid - because the controller wasn’t running the latest firmware.
I think the touchscreen behavior regarding firmware updates is as follows.
I haven’t observed behavior that confirms that, but it’s the only way I could see if there was an update that changed critical behavior in all of the toolheads, how to keep them all up to date as toolheads are changed out after a firmware update. Like, what if you did a firmware update with the 3DP toolhead, then 2 weeks later installed the laser toolhead - it would have to update it, right?
Thanks for sharing the commit. I will try it out with my changes as well. The DTR option seems to be the ticket for connection lost, but haven’t been doing much grayscale since last, so I could be wrong. I’m also starting to get a decent setup in LightBurn including triggering fans and whatnot at start of a burn (and also disable the door sensor because that has tripped me up a few times). I still would like to figure out WHY it detects a disconnect. Thinking I might try wireshark and see if I can monitor the “serial port” and see what actually happens when connection lost is shown on the console in lightburn. Ideally I’d like to find and add a safety feature in the firmware which turns off the laser. But we’ll see. No promises 
I use Serial Port Monitor, if that is any help. It’s not free, but does have a trial.
Yeah, a quick search revealed wireshark not support com ports… so spoiled by it being able to look at everything else
A small update. This weekend was unfortunately a bust in terms of coding, family time came first But I did manage to add my m7-m9 changes and I also merged latest version snapmaker’s repo. I’ve also changed some of the enclosure door handling since there seemed to be an issue (checking the same variable for two different values will never be true).
Also learned that the firmware version is magically updated by every build and contains the build timestamp. Which means the issue mentioned earlier might be avoided now. The info can be checked by issuing M1005 which should show the info. Luban via serial does this automagically but we can always issue the command via console. Doing so in my case yields:
M1005
Marlin: SM2-4.0.0
Compiled: Feb 24 2021, 21:46:40
PACKAGE: Snapmaker_V4.0.0
Module Ver:
0xE031E354: v1.7.0.0-20032517
0xE031E486: v1.7.0.0-20032517
0xC050586A: v1.7.0.0-20032517
0xE0205950: v1.2.5.0-19112519
0xE031E090: v1.7.0.0-20032517
0xE031E0C4: v1.7.0.0-20032517
0xE031E350: v1.7.0.0-20032517
Machine Size: M
ok
Which is handy at the very least it’s easier to confirm that the update did happen
Alright, I’ve tested it a few times and it seems to work (nothing burned down yet). Anyone wanting to try it out can check out the branch here: GitHub - mrworf/Snapmaker2-Controller at laser_m7m8m9_merged
It has the latest changes from the main snapmaker repo (last commit dated Feb 9, 78b7d6e23bebd8f126088fe4709050590912a7ab ) and also the changes by @brent113 which enables the use of inline laser power (yay, grayscale).
To this I’ve added support for M7 through M9 (we don’t have coolant 
so I mapped it to fan control) and also some bugfixes for the door in the enclosure.
Testing is me running the laser via LightBurn 2-3 times today without any fires.
I’ve also filed a question on their forum because I did see connection lost, but it might, just might be something on their side. I reproduced the issue by running custom gcode start commands which turn on the enclosure fan and lights. These commands result in info messages and I’m starting to wonder if this throws off the lightburn parser.Anyway, it’s located here if you want to look at it: