Please publish some technical drawings

I would love to make some small accessories like a cork “heat-shield” for the lower side of the heated bed. Getting a drawing of the platform would help a lot.

Additionally – a dimensioned drawing of the CNC carving platform would help us to make our own locally instead of shipping them all over the world.

Thanks for considering


Keep in mind this is a commercial business, the CNC carving platform drawing would deny Snapmaker sales. You can always measure one up yourself and make one.


1 Like

Sure, I do understand. But will Snapmaker ever release a set of cork plates to isolate the lower parts of the heating bed? Probably not… Also, if I can measure the dimensions myself why not publish them?

IMHO Snapmaker is an important member of the DIY community and I really hope they also open up their specs like CAN protocol, cable pinout and much more. This will help to grow the ecosystem around Snapmaker.

Who knows… dreaming is still allowed :slight_smile:


That is not a dream. That is actual goal of our team that we are striving to achieve. :slight_smile:

Like you said, we will not only open source the protocol of CAN communication between modules along with the firmware code, but also well-document it.

Snapmaker Luban will be the pioneer project for our team to explore and learn how to manage and develop a healthy open source project. Then firmware and hardware will follow. Let’s see what we can achieve together after we fullfill all our backers first.

But, for now, the highest priority, is to optimize and fix bugs according the feedback of early adopters. Hope you can understand that. You can open a support ticket ask for help, we can handle it case by case for now.


You are doing well. Hope you are coping with the growth pains

YES! I agree with Doug, you ARE doing well. I look forward to the docs.
One question I have is how hard is it to implement features that exist in Cura into Luban?

1 Like

any chance that those technical drawings could be released yet? i mean you have to have some kind of drawings for these things in order to mass produce them so how much work is required to simply post some of them? or is it a matter of intellectual property? I would understand that and will drop the topic if so. that said, It would make it far easier to modify the heat bed and extruder head if i could get even basic drawings for the hot end and build plate.

@Edwin @JKC20 is this somthing you could help with? Especially a drawing or 3d model for the proprietary plug would be very helpful.

I took apart one of the splitters, i have a pic or two for the pinout, but knowing what manufacturer or where to get a connector to have the option to extend the Modules would be usefull info.

I couldnt find the pictures, ill upload them somewhere if i can. The connectors are facing up and down in that picture. IMG_20200414_210012_9|281x500
Also what ive found sofar, the CAN lines arent used for the movement atleast. Didnt check the toolhead pins as i havent taken a toolhead to bits yet.

1 Like

I don’t have mine yet, but if you post pictures of the other side so I can see the connector, I might be able to find it. Preferably pictures of both the male and female sides.


The male sides are on the Cables and im not going to butcher them as i still need them ;D
As for the Top of the connector board:

Im taking appart the Lasermodule currently, and im surprised. The Processor inside is controlled via CAN. The Camera is hooked up to a ESP32-S board and the black sticker ontop of the module is a Antenna which is connected via a small ULF connector to the ESP32-S. Can should be fast enough to be able to transmit a camera picture but i guess the WLAN solution is faster to develop.

I agree can should be more than fast enough for sending a picture. Unless they are using a super slow baud rate? Or like you said the WLAN was faster to develop. But I find that hard to belive given how much manufacturing uses vision over CAN.

Do you know the Resolution of the Camera? ive seen a post about a Car related backwards driving camera and they mentioned that CAN is to slow for that and has a massive overhead. plus you’d have to run a separate Bus to prevent the Camera spaming the Main CAN network where everything is on.

Let me say that I am really glad that Snapmaker plans to open source the technical details of SM2! Thanks for informing uns on the plans @whimsycwd!

So, i had the nag today during work to see if i can tap into the CAN bus and do some mischief. Turns out yes, i can.!
As the CNC module was in my Opinion the least dangerous, i had a look at that.

U1 is the CAN transceiver (TI SN65HVD230 family), the Pads of R1 is where ive ended up connecting my Analyser.
There are a couple IDs i know the function sort of, and a couple which do apear once at homing and are “silent” after that.
For the CNC module, ID 21 with the value 0x00 - 0x64 changes the RPM, the ID 1556 is either sending 0x00 every 501ms or reports the Spindle RPM (in this test case).
If your going to try it yourself, take everything from the Module which might fly off. 12k RPM was max but still, better be save then sorry.
Also, the GND plane is HUGE and takes lots of soldering iron heating, i ended up putting a Breadboardlead into the GND connection in hope ot reference the CAN analyser that way.


@Streupfeffer thats great work! You should create a topic specifically for you experimentation with the can communications. I think it would get alot of interest. I know I would follow it :slight_smile:

@Streupfeffer, that is really a finding. Which FW version are you running? I’m looking around the last FW version ( 1.10.1 ) and already got where the CanBus commands are located and trying to correlate with your findings. The first thing is that you nailed it as the CNC is by far the simplest one :slight_smile:

Let me make a summary of what is there:

  • The main CNC controller commands are in Marlin/src/libs/CNCExecuter.cpp and the part to set the PWM says:
 * SetCNCPower:Set CNC power
 * para percent:Only Support 50-100 int
void CNCExecuter::SetPower(float Percent) {
  uint8_t Data[2];
  if(Percent < 50)
    Percent = 0;
  percent = Percent;
  Data[0] = Percent;
  CanModules.SetFunctionValue(BASIC_CAN_NUM, FUNC_SET_MOTOR_SPEED, Data, 1);

The BASIC_CAN_NUM is 2 ( Marlin/Configuration.h).

According to this the minimum value to run of 50% of rpm, anything lower will shut down the motor.
This correlates very nicely with your findings as the motor PWM set would be:
0, 50-100 ( in hexadecimal 0x00, 0x32-0x64 ), that looks great :smiley:

I also got the function values (Marlin/src/libs/CanDefines.h) :

// FuncID defines
typedef enum {
  FUNC_REPORT_LIMIT          ,  // 0
  FUNC_REPORT_PROBE          ,  // 1
  FUNC_REPORT_CUT            ,  // 2
  FUNC_SET_STEP_CTRL         ,  // 3
  FUNC_SET_MOTOR_SPEED       ,  // 4
  FUNC_SET_TEMPEARTURE       ,  // 7
  FUNC_SET_FAN               ,  // 8
  FUNC_SET_FAN2              ,  // 9
  FUNC_SET_PID               ,  // 10
  FUNC_SET_CAMERA_POWER      ,  // 11
  FUNC_SET_LASER_FOCUS       ,  // 12
  FUNC_SET_LIGHT_COLOR       ,  // 14
  FUNC_REPORT_TEMP_PID       ,  // 16
  FUNC_PROOFREAD_KNIFE       ,  // 17
  FUNC_SET_FAN_MODULE        ,  // 19

Which would mean that the function number is 4 ( 0x04 ) so that does not directly correlate, so I went further. To send a packet through CAN bus this is the underlying function (Marlin/src/module/CanModule.cpp):

 * SetFunctionValue:Post Value to the specific Function ID Modules
 * Para CanNum:The Can port number
 * Para FuncID:
 * Para pBuff:The Pointer of the data to be sent
 * Para Len:The length of the data,nomore than 8
int CanModule::SetFunctionValue(uint8_t CanNum, uint16_t FuncID, uint8_t *pBuff, uint8_t Len) {
  int i;
  for(i=0;i<MsgIDCount;i++) {
    if(MsgIDTable[i] == FuncID) {
      CanSendPacked(i, IDTYPE_STDID, CanNum, FRAME_DATA, Len, pBuff);
  return 0;

So according to this, there is a table mapping from FuncID to a MessageID which needs to be found. This MsgIDTbl is an array of 512 values ( Marlin/src/module/CanModule.h) but the filling up of the array is not so straightforward :thinking: and there are multiple pieces of code related (mostly in Marlin/src/module/CanModule.cpp )
The core parts are:

  //Reserved 20 for high response
  MsgIDCount = 20;
  //Mark the start MsgID
  m = MsgIDCount;
  //Fill MsgID Table
  //Save the first Funcid to the MsgID list
  LastFuncID = ~FuncIDList[0];
  for (i = 0; i < FuncIDCount; i++) {
    if (LastFuncID != FuncIDList[i])
      MsgIDTable[MsgIDCount++] = FuncIDList[i];
    LastFuncID = FuncIDList[i];

I’m not expert in CAN bus so I just can post what I can interpret from the code with the help of Wikipedia but this is how it looks:

  • The first 20 msg IDs seem reserved for the Linear Modules as a high priority, the rest as module IDs
  • The assignments from Msg IDs to Function IDs also depends on the CAN Bus ID assignments and interrogation, so quite difficult to report them from code.
  • But when starting the machine, it reports it in the serial debug channel:
  // Bind Function ID with the message ID
  // for MsgIDTable[], index is message ID, and its element is function ID
  SendBuff[0] = CMD_M_CONFIG_FUNCID;
  for (i = 0; i < ExecuterCount; i++) {
    SendBuff[1] = 0x00;
    k = 2;
    for (j = 0; j < FuncIDCount; j++) {
      if (ExecuterID[i] == MacIDofFuncID[j]) {
        for (n = 0; n < MsgIDCount; n++) {
          if (MsgIDTable[n] == FuncIDList[j]) {
            // fill Msg ID
            SendBuff[k++] = (uint8_t)(n >> 8);
            SendBuff[k++] = (uint8_t)(n);
            // fill Func ID
            SendBuff[k++] = (uint8_t)(FuncIDList[j] >> 8);
            SendBuff[k++] = (uint8_t)(FuncIDList[j]);
            SERIAL_ECHOLNPAIR("MsgID:", n, "-FuncID:", FuncIDList[j]);

… so that should be the way to get the proper binding.

One step more forward :slight_smile:


As Atom Suggested ill start a new thread to not spam this one with CAN related stuff

1 Like