Connecting OctoPi to a separate RPi

Get Help
22

So just touching back on this... I decided to use an Ubuntu VM in place of a second RPi for experimentation purposes. Following about 5 different guides I was unable to get it to properly communicate to a remote port using ser2net/socat. I could get the port to show up, get it to connect, but at best I could get it to receive little more than gibberish. eg "Recv: z� \x14T �� 0!-\x1f�� \x10�!\x0f�� 0�" (it contains high ASCII, which I'm taken to believe it shouldn't for this kind of communication)

Remember what I said about being a fan of easy? Yeah, 5 guides with no real success doesn't qualify. So this has basically put me off the idea of trying to daisy-chain devices. I've no doubt now that it can be done, but it's probably better done by someone with more Linux experience than I have.

However, it may have opened up at least a short-term alternative. A 4-core, 4GB Ubuntu VM running on an overclocked R7 1700 should surely have the power to run both tasks, right? So I managed to get Klipper installed on the VM as well (tip: use the OctoPi setup script - the Ubuntu one ran but didn't seem to do anything) and it's connecting the two together. Now I just need to get the machine physically connected to the printer for a torture test to see if it works (and if it can still cope when running a 16-thread ffMPEG encode and a game at the same time as printing).

*ed: It's also easier to set up OctoPrint in Ubuntu if you have a user called "pi" for it to run in. But you can edit enough files to get around that limitation if you, say, don't know how to create a new user with the right permissions.

23

You say 'The results are quite wonderful', and 'where the benefit is most significant' - may I ask, 'wonderful' in what way? And, what is the 'benefit' of Klipper?

24

On the brochure itself, Klipper's main claim to fame is to help people with 8-bit controller boards who are trying to run a Delta-based 3D printer. (Too much math is required at the last moment for that board to do its job right.) The thought then is to do the math up front on the Pi and let the controller board be more of a grunt slave.

25

Thanks. So no benefit to users of cartesian printers?

26

Some were getting blobbing but one could argue it's because they're trying for too-small segments in curves in their slicers.

27

Many thanks for clearing that up. I heard about Klipper some years ago, but although I well understood what it was doing, no-one could actually tell me why it was needed.

28

It's probably easier to show you than to describe it.

20190824_162642
20190824_162642.jpg4032×3024 2.25 MB

This is the Akantor from Thingiverse, uploaded by Unmentioned. Specifically "AkantorStandingHighPoly" printed at 3,000% (the STL is tiny). Both are printed on the same Creality3D Ender-2 and OctoPrint install (no virtual SD for Klipper) using 3DFillies grey PLA+ at a 0.2mm layer height using a 0.4mm nozzle, 2x 0.44mm walls with alternating extra, and 20% cuboid infill. Because of the size of the result (~40mm tall or 200 layers) these both took the same roughly 2 hours to print as there's no long lines for speed to really build up. Ignore the missing feet as that's my fault (at this size they come off while removing the supports real easy) and there's still a few scraps of the supports remaining.

On the left is the best results I'd gotten from Marlin 1.1.9 - 50mm/s maximum speed, 500mm/s² maximum acceleration, 8mm/s² jerk, 0.2mm maximum resolution, with Linear Advance enabled at K0.8. I also had to simplify the model from its original 500K+ polygons down to about 45K using MeshMixer. S-Curve and Junction Deviation had to be disabled else they just made things worse.

On the right is Klipper - 100mm/s max speed, 1,500mm/s² max acceleration, 0.05mm maximum resolution, and pressure advance at 0.8. It's taken from exactly the base model with zero advanced features disabled.

Now, I appreciate that this isn't the greatest picture. I've also deliberately used rather harsh lighting to make the differences stand out a little more. And this model is particularly unforgiving given its large number of very small edges. But it does rather clearly show the difference it makes even on a budget cartesian printer under the right circumstances. The colour difference is not as pronounced in-hand, so that can probably be blamed on my impromptu setup more than the firmwares.

*ed: For reference, this model at 6,000% was where I was experiencing the stalls when trying to use OctoPrint to feed Klipper on the RPi2. Between the base model and the tree supports it just wasn't happy. I'm yet to confirm if the VM shows the same.

29

Touching back again.

I've reached the conclusion that multiple devices is not going to work for me. I did manage to get it to work (user error - I was trying to connect to the physical port on the "driver" machine, not the virtual Klipper port), but I reached a conclusion with how the software works that means it's not suitable. Partly because I'd need a way to resynchronise the port every time the systems start up (could probably be scripted), but mostly because my RPi2 seems to keep losing its network connection (I've read this could be power related, but the power supply checks out fine even on a scope).

So that leaves me with one viable option for my situation: a single, more powerful machine to handle both duties. Whether this is an RPi3, RPi4, or some kind of desktop PC remains the only real point of contention. This will hinge on what happens with R9 3950x next month, as I'm hoping it drops the price (and increases availability) of R9 3900x.

For anyone else who might be wanting to try this using systems that don't have my particular issues or requirements, it can most definitely be done using ser2net and socat. The two configurations I used were as follows:

ser2net: 3333:raw:600:/tmp/printer:115200 8DATABITS NONE 1STOPBIT
socat: pty,link=/tmp/klipper,waitslave,user=pi tcp:klipper:3333

OctoPrint then just connects to a port at /tmp/klipper at 115200 baud. 250000 baud isn't an option with these tools.

The port (3333) can be whatever you please as long as it matches between the two and isn't already in use. You can also choose a different port to share it to (/tmp/klipper) if you like. But you'll want to make sure the user (pi) is correct for the active user running OctoPrint (without this if you install socat as a service you'll get "permission denied"), and that the IP/name of the Klipper device (tcp:klipper) is correct for your setup.

2 Likes
30

OK! It's been a few months, but my experiment has yielded about all the results its likely to give. Firstly, it turns out that 3950X got delayed long enough that I got impatient, but it also turns out that it worked out better in the end.

Chaining two Pis: Can be done, but it limits the maximum baud rate (using the tools I know about) and potentially requires re-establishing the connection. The lower baud rate may or may not cause problems with Klipper due to the nature of its communication layer, but I didn't personally see any. Marlin could be run the same (why though?) likely without potential issue as it's designed to use the lower baud rate.

Chaining any two Linux machines: Again it can be done, with all the same tedium and restrictions.

Using a more powerful Pi: Definitely works. I now have a 2GB RPi4, but with the loads I'm seeing the earlier suggestion of an RPi3 would definitely be viable. I'm seeing a 1-minute average load is peaking at around 50% of a single core, while the 15-minute average is below 15%. Memory usage is also under 512MB, including buffers/cache.

Using a Linux x86 machine: Also possible. It's no different to using a Pi without a pre-compiled OctoPi image - install everything manually, set permissions, and away you go. Naturally this requires some hardware you can dedicate to it, which I don't have, which lead me into...

Using a Linux VM under Windows: Not at all recommended as the printer host. Perhaps this is just with a Windows host, but my experience with either VirtualBox or VMWare was that it would be hit and miss. Strictly speaking it did actually work. However the USB device (ie The printer) can disconnect at any old time, halting the print entirely. I've no idea why this is and I was completely unable to either predict or stop it.

This does mean you could use it in a two-machine setup as the OctoPrint machine, since that relies on network rather than USB.

Using Windows natively (via WSL): Not recommended. I've been able to get OctoPrint to work, and get Klipper to install. However I couldn't get OctoPrint to talk to Klipper, nor could I get Klipper to talk to the printer. So this, at least for someone of my abilities, is not viable; though I could see it potentially running just OctoPrint (I never did check if it could talk to a Marlin printer, but everything was theoretically ready for it).

Some will argue that the answer was already known from early on. But now I've got some results to back it up which, in my opinion, makes the time spent worthwhile. And the final cost to me has been basically the same either way (though I could have saved a few quid getting an RPi3 instead).

31

I will say that it also depends upon how much you like to watch the job via the web interface and if you like to press the Reload/Refresh button on your browser a lot. The Pi4B has enough power to make everything run smoothly, to load/stream the webcam should you include one, etc. You can add a Class 10 microSD card and it will read/write faster than the 3B would. If you've invested this much time into the project, then why cheapen the experience by trying to save a few bucks/quid on the Pi you choose?