Discussion of Snapmaker 2.0 Firmware Updates

I haven’t had 1, but have had 2 (whether I select new file or same file)
Go back to 1.10.0 and occasionally have 3d prints get stuck at 99% or go back to 1.9 which is the most stable.


From discussion on this forum, I believe that the 99% issue relates to comments in the G-code that follow the last actual command.

You should be able to remove the trailing comments from the file before sending it to the SM, which should stop the 99% issue from occurring.


I’ve seen both of these issues. If I manually move all 3 axes by 20mm away from home BEFORE selecting another file to print though it seems to ‘fix’ it.

Thanks a lot @zauguin

Hello @JKC20. and all of you guys,
is there a GitHub repo for the Snapmaker FW code? It would be great to have also the FW GitHub.

I have a feature request:
Is it possible to add on the info page, or a new maintenance page, of the touchscreen the total working hours of the machine? I think it will be very useful if we could have the n. of the hours the machine worked (printing, CNC, laser…) so that we can see if some maintenance is needed or not.
Also a reset button will be fine so that we could reset after maintenance or cleaning up or…

What do you think?

There isn’t an official one yet. but @ITmaze has created one including a commit per published firmware on this forum to make it easy to track changes:

originally posted here:

@Edwin also announced that a publication by Snapmaker would happen this month (November). I assume this would be on Github:

Hi @AirMonk,

Excellent idea.

If you can create a GitHub issue for that suggestion, we can keep this kind of idea all in one place and when SM release their firmware source, we can update their issue tracker.


NP! Just created a new issue on ITmaze GitHub repo.


1 Like

In case you have missed it, the official source code on github is online! Kudos to Snapmaker team!


Well I’m one of those who missed it.

1 Like

ITmaze must have made them nervous :stuck_out_tongue:

Edit: On a serious note, that looks like a good repo, good job Snapmaker.

I think the source code for the Android app is the final piece of the puzzle? And also the module firmware? Although I guess Snapmaker is not required to publish the source for them, unlike the main Marlin fork

I’ve just added the two issues from my repo onto the SM repo to kick things off.

Also: https://github.com/Snapmaker/Snapmaker2-Controller/blob/main/docs/Hardware-Link.md

This is the first block diagram I’ve seen on the matter.


Insofar as I can tell, this is the source for the firmware in the main controller. It does not include any of the source code for the firmware inside the work heads. For example, temperature regulation for the FDM hot end is in that controller. PID parameters can be changed over CAN, but control is local. Per docs/Hardware-Link.md, there’s an upgrade module command over CAN for firmware changes. I’ll note that naming this “upgrade module” rather than “replace firmware” is just so replete with enuthusiasm.

So, no, it’s not the final piece. If they’re to open source all the firmware, it needs to include all the module firmware as well.

I was just looking at this file as well. For all the promise that this is a CAN-based machine, it’s only partially so.

  • The linear modules of stepper motor has control signals going over dedicated wires, but the limit switch signal goes over CAN. <sigh/> One of the promises of this design, as a CAN machine, is that you could get rid of non-CAN control wires.
  • The laser module uses one of the stepper signals for power control. So presumably power control is done with PWM over this wire, rather than controlled locally. (Should be easy enough to verify.)
  • The laser module has a whole second UART bus, reusing a pair of stepper wires. That’s just insane. You can put two CAN devices on the same physical bus; why didn’t they?
  • There’s Bluetooth in the camera inside the laser head?? Why a second channel?
  • The CNC module has nothing listed about reporting state back to the controller, not even, say, a motor stall condition.

I believe that uses the same PWM pin used for the laser PWM. It doesn’t, it uses CAN.


I think that’s a mistake. The bluetooth MAC for the camera is read via CAN, and I believe that’s reported via UART local in the toolhead mcu. It’s not read via CAN, it’s serial.

I think CAN doesn’t have the bandwidth. It goes straight to the HMI and is why you can’t use camera calibration via USB.

Spindle speed is reported via CAN. However, the controller doesn’t check for stall conditions at the moment - it’s something easily added though and I’d like to give a shot at implementing soon-ish.

The block diagram doesn’t have all the answers, and it’s not all 100% correct, but it’s a good start.

1 Like

I’ll start by saying I’m just reading the documentation. I certainly won’t claim that the documentation as published by this manufacturer is correct.

It may well be. That same section in Hardware-Link.md does say that it uses three analog pins. Presumably one is for filament feed. Another might be PWM power control. It does also say, however, that PID parameters can be set over CAN. Perhaps both are involved, gating with PID start/stop control a PWM signal that sets average-power-when-on; that seems like it would be rather an unnecessary overcomplication.

The documentation seems to say otherwise. The source code should provide an answer; I haven’t looked there.

CAN doesn’t have a single specified bandwidth; it depends on what physical layer you’re using. The high speed standards are for 1 Mbps or 5 Mbps. Low speed is up to 125 kbps, as fast as an ordinary high-speed UART. I don’t know which physical layer or electrical interfaces are in use in this machine, though. The popular and inexpensive MCP2551 is 1 Mbps; the current MCP2561FD goes up to 8 Mbps. If they didn’t put in at least a 1 Mbps bus, it’s just shooting themselves in the foot. It’s barely more expensive than a low speed bus and you’re not in an automobile wiring harness picking up spark plug noise.

Is it? Are they reporting actual speed from a tachometer sensor or back-EMF sensor or the like, or are they just returning a stored value?

After further looking, there is a serial channel, mapping back to USART3 on pins PB10 and PB11. PB10 is also used as the extruder stepper direction pin, and PB11 is the extruder stepper enable pin. (The extruder STEP pin is also the same PB14 as the laser PWM).

Yes, the motor has an FG frequency generator pin, presumably it comes from there.

1 Like

“Spindle speed is reported via CAN. However, the controller doesn’t check for stall conditions at the moment - it’s something easily added though and I’d like to give a shot at implementing soon-ish.”

@brent113: Can you please explain me what do you like to implement? I’m just wondering what will happens if working on CNC the bit get stuck on the material or for instance trying to make a hole the bit can’t drill the material (too hard or…). Are these the cases you’d like to manage?

I think that is his intention. This way you might be able to save a few bits by stopping the machine before they break.