@brent113 how did you create this firmware? I cloned the ITmaze repo and managed to build without issues, but I’m unable to load the firmware unto my SM2.0, even after running it through the luban tool (using v3.13.1.
When using the export tool, I chose only a controller firmware and left module firmware blank.
Any tips is most welcome 
I have never worked with that repo. I know it’s several revisions out of date and was intended as a historical archive only. The build instructions on the current repo worked for me.
Oh, so the current repo has the laser fix for grayscale? 
Had the impression that the fix wasn’t in.
It doesn’t…but neither does itmazes
Okay, so now I’m confused, you’re showing an image from the etching which seemingly fixes the grayscale (ie, inline pwm change) but it’s not in the firmware you shared?
I’m confused…I didn’t share itmazes repo?
My own repository… And it still has bugs…
Also that’s a very old version, my public repo has the current code with minimal bugs, but still bugs
Where do I find the public repo?
It’s been awhile and I’m on my phone, I think laser_inline branch is what you’re after but I’d have to check the tree.
The main issues are a combination of these:
If you run from the touchscreen that gives the best results but it’s not perfect because of the buffer underflow issue that results in occasional stuttering. Running from Lightburn would be preferable however that is really not recommended now, it will stop moving with the laser still on occasionally. There’s some serial issue on the snapmaker that in trying to troubleshoot I lost the ability to upload firmware and I don’t have the drive to tear it down and reflash again… So it’s on pause.
Cool, the 2nd issue is what I’m running into (I think), since I keep getting 
and when I do, that’s it. No more etching. My plan was to map M7-M9 to M106/M107 to avoid getting the error, since I think that’s what borks it.
Thanks for sharing, I’ll take a peek (and yes, laser stuck on was my first experience )
I tried disabling the handling of the invalid codes and that did fix it, but it’s not the root cause.
I am tracing the quirks of the error handling that actually writes the text to the serial send buffer and I think that’s where the bug is.
I didn’t feel like just disabling handling of invalid gcode is the correct solution, just a workaround.
For a quick fix in the gcode handler that is the massive switch statement if you just remove m7 and company that fixes that.
I’m partially with you. The use of M7-M9 seems odd to me since it’s clearly intended for CNC. But the effect it’s trying to accomplish is cooling, and the snapmaker version for LightBurn swaps it out for M106/M107 but then I lose the grayscale.
I think both approaches are correct. The M7-M9 emulation should be if-def:ed so if you don’t want emulation, it will spit out an error, otherwise it will engage the fans. The other issue should also be investigated and should have a proper fix. But got to start somewhere 
Doing a NOOP for M7-M9 would be the worst though, so that’s out of the question
It’s a quirk of Marlin, I guess. If a particular machine doesn’t have a feature it’s supposed to respond with an error, and either Lightburn is not gracefully handling that or Snapmaker is sending subtly invalid response that breaks the stream. Since I can’t control Lightburn, I was trying to figure out how to manipulate the response such that it doesn’t break Lightburn.
Since this machine can never have cooling/air assist just NOOPing m7-9 isn’t really that bad of a solution if a work around cannot be found.
Snapmaker has so heavily deviated from the original Marlin intent I don’t even know why I feel compelled to maintain the Marlin style… It’s like I think I’ll PR to the upstream Marlin someday, when that would basically be impossible with how diverged the current codebase is…
Smells like a lightburn issue, because if you issue M7 by itself, all you get is “unknown command” but when you do it in a program, it borks.I’m guessing that the unknown command response is coming back to lightburn when it’s expecting data from another command. Essentially it comes out of sync with the responses (I’m guessing).
Nooping assumes that it will never be contributed back to marlin and will only be for snapmaker. Now, that might be true, but I feel that M106/M107 emulation is better than simply ignoring it. It’s as close as we can get and it’s what lightburn does if you use snapmaker.
Yes, I’m an idealist 
I agree that it’s root cause may be in Lightburn, however the developer Oz had stated he has no intention on further modifying the Marlin comm library for each individual derivation of Marlin, of which there are many dozens. And so far there’s only bug reports for Snapmaker and maybe one other variant… It’s been awhile, going off memory of that forum.
Alrighty then FW fix it is because your fw made my etching look awesome when using lightburn
Even weirder, the jog to origin macro in Lightburn resets the lock up. Something is super quirky for sure. I would like to get it fixed but I spent so long on it that I burned out and haven’t touched the machine in more than a month 
The 1st issue is probably due to their android version of the GCode sender, but since no HMI code is shared, I cannot even begin to look at that. Already complained
Yea. I tried to stream the gcode over WiFi from Luban but I can’t remember if it still stuttered…I think it did? Only tried once though on a night I changed about 50 things…
I don’t even remember if I played the file from Luban over serial…
