Alternate Pi <-> Printer communication methods?

Zero development experience with Octoprint so please bear with me if this is a dumb question. I've used Octoprint for years with the typical USB->serial connection between Pi and printer so am at least familiar with how that all works and can imagine this is a fundamental feature of the code.

How much of an overhaul would it require to add additional methods of communication? For example, say a printer had an Ethernet port or wifi connection, with a possibly closed-source, not-documented communication protocol that nevertheless might be simple enough to reverse-engineer. Printing to that machine might require uploading the whole sliced file all at once using the Ethernet protocol between Octoprint server (Pi let's say) and the printer, followed by sending a couple g-code commands to initiate the print.

So I'm imagining that Octoprint would need to:
a) manage the ethernet connection, in an analogous interface to how it manages the serial connection now but you are dealing with a couple of IP addresses - one on the Pi and one on the printer - instead of a TTY.
b) implement the reverse-engineered Ethernet communication protocol.
c) integrate all that with the rest of the features - webcam, etc.

There might be other obstacles but right now I see communicating with the printer as the main one. Would adding support for something like this either directly, or in the plugin environment (I doubt it) be in the realm of consideration?

I think that would be possible in the realm of a plugin, but would take a boat load of time to figure out, especially if you have to reverse engineer network communication. My MyMiniFactory plugin communicates externally to other network addresses as well as all my smart plug plugins.

Here's a post I made on rfc2217 which is a possible solution to printing over Ethernet/wi-fi.

1 Like

The two previous answers did not deal with the implementation in OctoPrint. The current OctoPrint is tied pretty much to serial port communication and doesn't really have hooks for other types of communication.

@foosel has been working for a long time on a "communication layer" which - among other things - could make other types of communication possible. This will likely be part of OctoPrint 1.4, which will take at least until the end of the year.

1 Like

@fieldOfView, Well you could always learn about socat. Create a virtual serial port. Redirect some TCP/IP ports to it. Then tell Octoprint to use that port. Assuming that the device takes raw text data over it's wifi interface and not some weird binary compressed protocol, it could work.

1 Like

I think OP is aiming at a printer that has a protocol that does not behave like a serial port:

1 Like

That's basically what I'm talking about. Follow the links. I did some benchmarking of the technique.

The current OctoPrint is tied pretty much to serial port communication and doesn't really have hooks for other types of communication.

@foosel has been working for a long time on a "communication layer" which - among other things - could make other types of communication possible.

That's sort of what I was expecting the answer to be. The fact that @foosel is working on a comm layer is really good news. I accidentally know she owns one of the printers about which I'm speaking (resin, if you didn't figure it out already), so this may work out in time.

The rest of my post was not theoretical. A couple of clever folks have already reverse-engineered at least the key upload/download and g-code sending parts of the Ethernet protocol. I haven't looked under the hood (and not sure I'm smart enough to understand the networking bits if I had) but have tested it and it works from their little native windows applet thingy. Even over my VPN, which is cool. The manufacturer's own software doesn't even do that because of the brain dead way in which they do printer discovery - they have to be on the same LAN as the computer running their software.

The question now is do we reinvent the wheel by developing a full-featured application around that protocol, or spend that effort plugging it in to something mature like Octoprint.

So, an Anycubic Photon would be my guess.

1 Like

That and any other printer based on the ChiTu platform. There are many.

Just for the record though, OctoPrint's focus is and for the foreseeable future will continue to be FDM.

Which is why I prefaced the initial tweet about getting a photon with this not having any indication on the direction of OctoPrint's development at all :wink: I own that printer purely for hobby purposes.

Which is why I prefaced the initial tweet about getting a photon with this not having any indication on the direction of OctoPrint's development at all

Ah, thanks for the reply. I knew about the Photon from your activity on my Thingiverse page. Didn't see the tweet, I don't do Twitter :wink:

Ah, now I put 2 and 2 together, sorry it took me a bit :see_no_evil:

1 Like

Being pedantic here...
It's unlikely that the printer and Octoprint actually need to speak Ethernet. More likely they would use some protocol on top of TCP or UDP. This matters because if you really mean just Ethernet then wifi and other transports won't work.

1 Like

Correct, I used lazy language - thank you for the correction.