3D printer interface with automation system

Thread Starter


Joined Oct 3, 2010
Hello, I am wondering if anyone here has experience with Klipper controlled 3D printers, specifically with interfacing them to the outside world. I have two Qidi Xmax3 printers currently and may be acquiring more of them, so I would like to build a system that will automate part removal and filament changeover.

With "bed slinger" type printers the part removal thing is easy; just drop the tool head down and push the part off. But since these are CoreXY printers with enclosed heated chambers, something will have to open the door, remove the part, close the door, etc., and all that functionality is a bit much to ask from the printer controller considering it doesn't have any GPIO available. It will need to be a standalone system that communicates/coordinates with the printers.

The printers are network connected, so ideally they would speak some kind of industrial protocol (modbus TCP, Ethernet/IP, profinet, etc) so I could stay within my comfort zone of industrial automation by implementing PLC control over them. But the closest thing I have seen is the MQTT ability of Moonraker (which these printers have) and some PLCs are also MQTT capable (ex: AD Productivity line) but this is more of a home automation protocol and requires a server that both printer and PLC would subscribe to. Not a fan. Would prefer simpler, direct communication.

Another option I have found is a bit convoluted and involves sending gcode commands to the printer via HTTP POST as described here and triggering python scripts via gcodes to send messages out from the printer as described here. Both halves of that solution have been vetted by others and work, but I haven't seen proof of anyone having combined them into workable bidirectional communication, and it does not amount to a standard industrial protocol by any means.

Since the functionality to call scripts from gcode exists, my idea is to try implementing modbus via Python (PyModbusTCP) but that seems like a dark and deep rabbit hole where I need to be concerned with my motion controller being side tracked with comms tasks. I don't really want to step foot inside that rabbit hole until I am satisfied that all other options are exhausted.

So, anyone know of other options that I dont?


Joined Jan 27, 2019
One idea that immediately comes to mind is to use a small SBC, like an RPi, to act as a shim on the network connection to the printer. It would use firewall rules and deep packet inspection to consume or redirect particular G-code command(s) to a different device than the printer. This way you could have unlimited GPIO options on the RPi, or send things to a PLC, etc.

The advantage of doing something like this is being able to integrate the control directly into the print jobs. You can use your own commands in the G-code.