Make the 3D printers available in the network

[NitramLegov]

It would be pretty nice to have our 3D-printers available through our internal network. While discussing with different people (mainly @emka and @Pakue95), the following considerations came up:

• out of the box software: Octoprint or Repetier Server
• • Repetier Server supports multiple printers with one instance
• • Octoprint is known better
• Starting a print via the network should ideally be prevented for security reasons
• Webcam support would be pretty nice
• The main focus should be in monitoring the printer status
• • add a "overview board" with some LEDs to the common room?
• • status broadcast via mqtt?
• • Some app support?

When doing some further research, it seems that the printers offer a serial connection via USB. There is even some software which already uses this interface: https://github.com/kliment/Printrun Interesting is that this software even creates a network service publishing the printer status (see section "RPC SERVER") https://github.com/kliment/Printrun/blob/master/printrun/pronsole.py In this script (starting from line 872), a basic status checker is implemented.

If we write our own software, the following page describes the available GCodes: https://github.com/prusa3d/Prusa-Firmware/wiki/Supported-G-codes for us, the following sound interesting:

• M25
• • Pause SD print
• M27
• • Get SD status
• M31
• • Show time from print start.
• M105
• • Returns current temperatures.
• M112
• • Emergency stop

For me, the following points should be discussed:

• Which features are supposed to be available (pausing / stopping a print might be nice)
• Which status do we want to see (printing yes/no, temperatures?)
• Do we write our own software (e.g. providing a webinterface and publishing updates via mqtt?)

[NitramLegov]

I started a basic repository for this: https://github.com/comakingspace/3D_Printer_Status This is just a copy of previous projects I have been working on. It´s done entirely in python, which I would very much like to keep. Basically it starts a small webserver using web.py Since web.py is not yet released for python 3 (only a development release), we should possibly change this to another framework (django? flask?) Do we have any python enthusiast here?

[NitramLegov]

I just connected my computer to the printer using Putty and had the following observations:

• If a print job is running when you are connecting to the serial interface, the print stops and cannot be resumed.
• • The python script should therefore only attempt to open the connection when the printer is starting (so when the USB device becomes available). In case of a lost connection, it should not try to reconnect!
• The serial interface is quite slow. We should not pull for updates every second, but every few minutes.
• While printing, the printer outputs "echo:busy: processing" in certain intervals (I think every minute, but this has to be tested)
• During heating, it sends temperature updates in the following format: " T:145.38 E:0 B:59.1"
• M25 Pauses the print, but this takes quite long
• • M24 Resumes the print
• M27 returns the current status in the following format:

FlipDotDisplay Mount v3.gcode SD printing byte 234078/1224695 00:03 ok

• M31 returns the following:

echo:4 min, 34 sec ok

• M105 returns the following:

ok T:217.4 /215.0 B:60.0 /60.0 T0:217.4 /215.0 @:0 B@:36

With this I think we can start the development

[NitramLegov]

We discussed this further. There seems to be a general issue with opening the serial connection provided by the usb port: https://github.com/johnnyr/Mini-Rambo/issues/5#issuecomment-331730695 Therefore, the current idea is to use the testpoints available on the back of the control board. We would solder some cables to the TX/RX Test Points and connect a ESP8266 to it. The ESP would then broadcast the status of the printer via MQTT to our network (of course, there would be no possibility to actually control the printer).

Is it OK to modify the printers in such a way? @emka @LukasFreeze @Pakue95 @beanobeano Is there any reason why we should not do this?

[Johannes09]

Pinout von dem Kabel das aus dem 3D Drucker 1 rauskommt Die dunkelblaue Markierung ist zwischen 5v und TX +5 TX RX GND

+5 ist auf Drucker Seite nicht angeschlossen

[emka]

@beanobeano is fine with testing improvements on P1. Please ask him again before modifying P2-P5.

[NitramLegov]

Ich habe heute mal die USB-Serial Converter aus dem E-Raum unter Windows zum laufen gebracht und wollte die nutzen, um die Drucker anzusteuern. Das ist leider genauso schief gelaufen wie der Versuch, die über einen ESP anzusprechen.

Ich habe dann auf das Board geschaut und auch die Kontroll-LEDs blinken entsprechend nicht.

Mein Vorschlag wäre daher zunächst mal zu testen, ob das ggf. besser wird, wenn wir auch 5V anschließen. @Johannes09 kannst du das mal testen?

[beanobeano]

The proposed solution to this issue is beyond the limits discussed in person when we met in August. To be clear - it is not acceptable to modify the 3D printers (that are on loan to our space) in the manner indicated above. There is no justification to continue with this project in this direction.

[NitramLegov]

In the meantime, we have received new information regarding the possibility to open serial connections to the printers without resetting the print. For details, please see https://github.com/prusa3d/Prusa-Firmware/issues/1000

Basically, we would need to send the following command to the printer once: ;C32u2_RMD

After this, the printer should not reset anymore when a serial connection gets opened and we could continue with this issue.

From a software perspective, some of us have in the meantime started working with homeassistant. Maybe somebody is motivated to implement this with ESPHome. A brief research showed that this might need a cutom implementation thoug: https://esphome.io/components/text_sensor/uart.html?highlight=uart

[NitramLegov]

I don´t think this is worth it anymore :)