Use SSDP Standards

Bambu Lab X1 Series
1

This also applies to the P1P, however why on earth are these devices utilising SSDP, but via non-standard ports?!

https://wiki.bambulab.com/en/general/printer-network-ports

Here we see they use 1990 and 2021, rather than the standard 1900 port for SSDP.

The use case here is mainly for people building integrations, in this example, Home Assistant, but it just goes against a lot of logic, which seems to be a repeating occurrence.

I get you guys have made this proprietary, and that’s fine, but why deviate from a standard that already exists :confused:

2

It may be that their “device discovery” is not using the published SSDP protocol. If this is the case, putting it on another port is probably a good idea.

But the question them becomes: why didn’t Bambu use the published standard?

3

They’re using some butchered SSDP protocol i think? The messages sent are SSDP format

Host: 239.255.255.250:1990
Server: Buildroot/2018.02-rc3 UPnP/1.0 ssdpd/1.8
Location: 192.168.1.64
NT: urn:bambulab-com:device:3dprinter:1
NTS: ssdp:alive
USN: <serial>
Cache-Control: max-age=1800
DevModel.bambu.com: 3DPrinter-X1-Carbon
DevName.bambu.com: MrSlinky
DevSignal.bambu.com: -30
DevConnect.bambu.com: cloud
DevBind.bambu.com: occupied

Interestingly, just checked a P1P on LAN Mode, and its coming through on 1900 as the source port, but not on the X1C

4

That’s very interesting! I suspecft the SSDP stuff is handled my the controller in the display, and between those two printers the displays are very different.

5

So the P1P gets a butchered version of MQTT but seemingly proper ssdp functionality, and the X1C gets the total opposite :rofl::see_no_evil:

6

::glares at dev team, in the way a mother would glare at her child for cheating on homework:: :wink:

7

Not the display itself, which has no logic, but the AP board which drives the display (among other things.) It does seem odd that they would have different implementations of a common function.

1 Like
8

You sure about that? In many, or even most other printers, the display unit has its own microcontroller to handle the UI, its own firmware updates, handles the SD card, and talks to the controller board essentially using the same g-code command set.

(All the Creality printers are definitely set up this way.)

9

Yes, quite sure. I’ve even printed with the display disconnected. Sure, the display has its own microcontroller, but it serves only to display what is sent by the AP board and to register button presses. The same is true for Creality printers. For the displays that have an SD slot (not all do), it just serves that over USB.

2 Likes
10

Oh, what I mean is… the display firmware handles the graphical interface and various button pushes send g-code commands to the controller board (what you might be calling AP board?). If your print is sending g-code to the USB interface on the controller board, then yes the display can be disconnected.

But… for systems that have internet connectivitiy… yeah… I think you’re right there, given I’ve seen controller boards advertise web functionality. I concede!

11

The AP board is the long, skinny board in the front upper left of the printer. Here’s the one in the P1P:

image
image983×733 94.7 KB

and the one in the X1:

image

There is no gcode sent between the display and the AP board - it’s all electrical signaling. The display is “dumb” in that it serves only to show what the AP sends it and send info about user button/screen presses to the AP (it also electrically connects the SD card slot). The AP board handles WiFi, the “AI” logic and is where firmware is loaded and run.

1 Like
12

Awesome info, thank you. On my creality printers, this board is part of the display “unit”, which is what I was talking about, and probably confusing things. Yes, the display itself has it’s own PCB separate from this board.