[Request] Network Connected Printers

[savorywatt]

@foosel

I've been looking at how to have octoprint control a printer over the network that exposes a network addressable end point that can accept GCODE commands and file uploads. I think with minimal changes to printer.py an implementation of a network connected "_comm" for Printer that mimics the MachineCom in util/comm.py should be feasible.

Then there would have to be some UI changes to display the new options (IP to connect to) and an agreed upon handshake process. Arthur Wolf (Smoothieboard) is interested in this feature and should be able to help with any firmware changes to do it (they already have an endpoint for sending gcode and a lightweight web control panel that lets you upload files so they should have everything). Smoothie had all the parts last time I checked (when I helped with some stuff during their kickstarter).

Ideally there would be some easy discovery and handshake but that would require firmware changes on smoothie so a bigger project but a nice next step.

I wanted to run the idea by you before I dug much deeper as it is a pretty core change.

@arthurwolf

Oh and "I love cookies"

[foosel]

One step ahead of you :) Take a look here and here.

Protocol and transport layer have been split. People are already using that branch, the only reason why I haven't merged it onto devel yet was a bug in Marlin I had to fix first which made command lifecycle tracking impossible (commands were not acknowledged in the same order they were sent) which caused big problems with the queue handling. I still have to build a workaround protocol implementation specifically for Marlin installations which run an older version than the one which contains my patch, and protocol/transport configuration aren't yet reflected in the UI (config.yaml only atm)

Nevertheless, the basic idea is to be able to not only use serial communication, but also TCP, or HTTP-over-pidgeon if you are so inclined - the only thing the protocol layer cares about is being called by the transport layer when something is received and being able to send something via the transport layer, and of course connecting and disconnecting.

[arthurwolf]

Note : we don't only support http, but also telnet, which may be an easier first step when moving from serial.

On Fri, Jan 16, 2015 at 9:18 AM, Gina Häußge notifications@github.com wrote:

One step ahead of you :) Take a look here https://github.com/foosel/OctoPrint/tree/commRefactoring/src/octoprint/comm/transport and here https://github.com/foosel/OctoPrint/tree/commRefactoring/src/octoprint/comm/protocol.

Protocol and transport layer have been split. People are already using that branch, the only reason why I haven't merged it onto devel yet was a bug in Marlin I had to fix first which made command lifecycle tracking impossible (commands were not acknowledged in the same order they were sent) which caused big problems with the queue handling. I still have to build a workaround protocol implementation specifically for Marlin installations which run an older version than the one which contains my patch, and protocol/transport configuration aren't yet reflected in the UI (config.yaml only atm)

Nevertheless, the basic idea is to be able to not only use serial communication, but also TCP, or HTTP-over-pidgeon if you are so inclined - the only thing the protocol layer cares about is being called by the transport layer when something is received and being able to send something via the transport layer, and of course connecting and disconnecting.

— Reply to this email directly or view it on GitHub https://github.com/foosel/OctoPrint/issues/721#issuecomment-70221277.

Courage et bonne humeur.

[savorywatt]

Well, fine go and make life easy @foosel. RE the Marlin bug, I remember you mentioning that earlier, hope that gets merged upstream soon. You could do a simple workaround that says anything that does not report its version -> old printer/transport layer and anything that does report its version correctly checks it is high enough to support the feature.

[vuokko]

Also another way around would be nice. Start TCP service so that some other host program can connect to it within timeout and maybe some IP filtering and when connection is closed, control to serial port is given back to webUI and Octoprint. Maybe forcibly connection would be good feature.

Has this communication and protocol development progressed in last 15 months?.

[markwal]

@vuokko a lot. In fact, this could probably be done in a plugin now using the serial factory hook. It'd best be done by a dev with such a printer though so it can be tested properly. You?

[vuokko]

I can test and maybe add some small things. Python is one of those languages, I have never used.

[KjellVerb]

@foosel Is there any progress in making TCP connection an option? I have semi-succesfully worked around the lack of it it by forwarding a virtual serial port to TCP using socat. However, given that octoprint waits for an OK, my print is very jittery as this type of communication adds some delay.

[foosel]

@KjellVerb nope. Had to basically scrap the original work on the commRefactoring branch since it made a bunch of assumptions that on further looking into current firmware implementations turned out to be incorrect (mostly thanks to bugs). New attempt was started earlier this year with the commRefactoringNG branch which also supports TCP, but that's not yet ready for prime time and on top of things I first had my hands full with some tricky work related things, then a never ending cough, then losing my job and struggling to fix the resulting funding crisis for OctoPrint.

Current plan is to get it into 1.4.0 (so 1.3.0, current devel, first needs to get out of the door for this to happen).

Out of interest, what printer are you using?

[KjellVerb]

@foosel I'm very sorry to hear about your personal problems, I hope it's all good now and that you are motivated by the enthusiastic user base of Octoprint! Thanks anyway for your quick response.

I'm wondering whether it's a viable alternative option to turn off the "wait for OK before sending a new command" feature (aka ping pong communication) and let the TCP protocol (that I can reach thanks to socat) handle the flow control. I'm just asking here because my Python experience is close to none, so finding out for myself or modding is not an option unfortunately.

The reason for my requests is that I'm running Octoprint on a RPi that's sitting behind the TV as a KODI media center, unable to be moved due to the HDMI cable. I don't think it should be necessary to buy another RPi or equivalent and physically connect that one to my 3D printer, and that's where Octoprint to TCP comes in...

My printer was originally a Hictop 3DP11, a Chinese Prusa i3 clone. Being an engineer, I wanted to go for a relatively cheap printer and then mod it to my taste. In the mean time only the frame and the electronics are still (mostly) original, the rest is adapted to my preferences. I'm now getting results out of it that are close to or better than my colleague's Velleman K8400. The wireless communication is implemented using an ESP8266 (microcontroller with built-in wifi) as a TCP to serial bridge.

[foosel]

The reason for my requests is that I'm running Octoprint on a RPi that's sitting behind the TV as a KODI media center, unable to be moved due to the HDMI cable. I don't think it should be necessary to buy another RPi or equivalent and physically connect that one to my 3D printer, and that's where Octoprint to TCP comes in...

Actually that's a setup I'd strongly recommend against. A Pi is not that expensive, but somewhat underpowered (even four cores of ARM are still ARM). Running anything concurrent to something that necessitates high I/O throughput (like streaming GCODE to a printer) is a bad idea thanks to a user space program not having much say in OS scheduling. So if your KODI server decides to do a media scan at the wrong moment, there goes your 12h print job, regardless of direct of wifi connection of the printer. In general you should keep the connection between the printer and the host as simple and "short" as possible. The whole point of OctoPrint is to put the host next to the printer and still be able to access it remotely.

Not saying that I still don't want to get TCP working, but your specific setup actually sounds like it's bound to cause issues regardless of if that's an option or not.

I'm wondering whether it's a viable alternative option to turn off the "wait for OK before sending a new command" feature (aka ping pong communication) and let the TCP protocol (that I can reach thanks to socat) handle the flow control.

Not really. That's basically built deep into the current communication layer. I mean, you could in theory rip it out and replace it, but you'd need a bit of python experience for that. What might help is having a bunch more virtual oks available than is actually the case, but no guarantees how that would end... in any case, to play around with that, change https://github.com/foosel/OctoPrint/blob/master/src/octoprint/util/comm.py#L275 to something like

self._clear_to_send = CountedEvent(max=10, name="comm.clear_to_send", value=3)

(note the added value). That way it will have a running window of 3 additional oks, somewhat defusing the ping-pong. Might be worth a try. Alternatively instead of modifying the code you could also see if you can achieve more fluent communication by hitting the "Fake Acknowledgement" button in the advanced options of the terminal tab a couple of times.

Hope this helps.

I hope it's all good now and that you are motivated by the enthusiastic user base of Octoprint

It's definitely getting there thanks to the latter being quite supportive in the Patreon campaign :)

[KjellVerb]

Alright, seems like there is enough to try out for me, thanks for your advice and your time (and the fair warning!). Good luck keeping up the good work!

[KjellVerb]

By the way I've preordered 2 C.H.I.P.'s (https://getchip.com/pages/chip) and if it turns out that the setup I've described above is too unstable, I might end up trying to get Octoprint running on one of those.

PS: another reason why I'd like TCP communication from Octoprint towards my printer is that I will be adding more CNC machines in the future (router, laserplotter, second 3D printer built from scratch, ...) that will not all be located in the same room. They don't have to work concurrently, but I don't want to move the RPi running Octoprint around and I don't want to spend $40 extra per machine by adding a RPi to each. That's why I'm looking for a sub 10$ per machine solution for wireless printing.

Anyways, best regards and thanks again for your elaborate and quick responses.

[sareph]

I would also vote for this.

MKS SBASE (Smoothieware) has build-in ethernet port and can use telnet (basically raw TCP) protocol for communication. It would be really helpful if I could separate my NAS from printer.

[derpicknicker1]

@KjellVerb I own two c.h.i.p's and can confirm that octorint is runnig fine. I haven't tested a print until now, but the interface is running very well.

[KjellVerb]

Ok thanks for the input! None of my attempts solved the jittery printing when using socat, so for now I moved my RPi to the printer. When my C.H.I.P.'s arrive I will use those as my sub-10$ solution.

[Adesin-fr]

Hi there, Any progress on this Request ? I also bought a MKS Sbase for my printer, to be able to drive it faster than with a Atmega/ramps. I'm a bit frightened about driving it via usb/serial, and I think the TCP way could be the best ?

[eimix]

I want this too! Is this branch https://github.com/foosel/OctoPrint/tree/commRefactoring/src/octoprint/comm ready for modifying and adding custom transport layer TCP/UDP?

[foosel]

@eimix no, that one's abandoned due to crippling firmware bugs that scrapped the whole approach. commRefactoringNG is probably going to be the new comm layer, but it's by no means ready for prime time yet either and I might still run into something that forces me to scrap that approach as well.

[AlexStarFL]

Hi @foosel, How hard is to implement an option where only non time-sensitive g-codes sent by TCP? In this case it's very easy to extend any board to add more extruderes, fans, add have more powerfull heatbed that main board can handle. Extended board will have only MOSFETs, ADC and low cost MCU like ESP32. The thermostat board will respond via telnet only to g-codes related to temperature control and ignore others.

[foosel]

@AlexStarFL I'm not entirely sure I understand your idea correctly, but in any case considering that OctoPrint's whole connection concept currently relies on a 1:1 connection I'd probably call it "hard". But you might already be able to experiment with stuff like that by implementing a custom serial factory that doesn't actually speak serial but TCP if you feel like it.

[Adesin-fr]

I think this idea could be more easily addressed by a "proxy node", which could be an ESP32, and would receive either Serial or TCP data, and then route it to other "hosts" (which could be TCP or serial hosts) according to a custom routing table... ie : MXX1 would be translated by proxy host to "turn off heater on host TCP host 1" MXX2 would be translated by proxy host to "send all extruder moves to TCP host 2" MXX3 would be translated by proxy host to "send all extruder moves to TCP host 3" etc...

[AlexStarFL]

Completely agreed with @LemarinelNet. If OctoPrint can use TCP connection to 3D printer and COM ports at the same time then another huge possibility is open: Android version of OctoPrint Server with minimum development effort. I tried to build OctoPrint on smartphone and it works well. I installed GNURoot Debian and and was able to build and run OctoPrint and Cura Engine. The issues starts to grow if the phone is not rooted. GNURoot works well on non-rooted phones, but there are no way to grant permissions to /dev/ttyXXX to any other users. I'm not talking about top smartphones like Pixel 2XL or Samsung Galaxy S9+. Any $10-20 cell phone from Tracephone/Net10 have at least 4 cores and it is more powerful then Raspberry PI and have screen, touch pad, camera, etc. Some phones can easily be rooted, but some of them are not. Some phones able to use USB OTG, but some of them (like Nexus 5x) are not.