Connecting OctoPi to a separate RPi

Get Help
11

The marriage of OctoPrint and the "software" side of Klipper was not an OctoPrint project, but was a Klipper project.

You have asked the OctoPrint community if it is possible to daisy-chain OctoPrint and I believe we are implying "it is beyond the scope of this project" by offering alternative solutions that would not involve (significant) modifications to OctoPrint. This community has a hard time just saying "No" :slight_smile:

Quoting from https://www.klipper3d.org/FAQ.html#do-i-have-to-use-octoprint:

The Klipper software is not dependent on OctoPrint. It is possible to use alternative software to send commands to Klipper, but doing so requires Linux admin knowledge.
Klipper creates a “virtual serial port” via the “/tmp/printer” file, and it emulates a classic 3d-printer serial interface via that file. In general, alternative software may work with Klipper as long as it can be configured to use “/tmp/printer” for the printer serial port.

Folks with the Klipper project https://www.klipper3d.org/Contact.html might provide some better answers to your question.

If I were in your situation, I'd order an RPi 4 with 2 or 4GB of memory and "push the problem further out" :sweat_smile:

1 Like
13

@b-morgan: Just my thoughts

14

Yes, OctoPrint was designed to stream gcode directly over a serial connection straight to an Arduino + RAMPS board combination (the typical Marlin-based 3D printer rig).

Hypothetically-speaking, one could purchase another good UART for the Zero, a 40-pin header (soldering this on), and then have a Pi Zero platform which could be used as a man-in-the-middle configuration with two working serial cables on either side. Once you've added the cost of the parts, the extra power adapter, the extra serial cable, the extra mini-USB adapters... you've got a higher price tag than the original upgraded Pi I suggested before. The only use for something like this is to show off at local talks within the Maker space, to be honest. It's worth +3 Geek Points, I'd suggest.

I'm one of those crazy people who will temporarily invest in spare parts just to try some interesting scenario, like streaming gcode over wifi instead of the standard USB cable. This does require patching your OctoPrint install in a small way and a fair amount of ninja—I.T. skill in the Linux space.

Raspi3B :arrow_right: ZeroW with rfc2217_server.py :arrow_right: Mega2560
rfc2217://10.20.30.66:2217 tcp 10.20.30.66:2217 rfc2217 port forwarding to serial /dev/ttyACM0 on microUSB with Type A OTG adapter cable USB serial cable Type B connector

Seriously though, there are easier ways of getting a working printer. Listen to b-morgan/Ewald. They are much saner than I.

1 Like
15

:+1: giphy

1 Like
16

Wait a minute...

Maybe I'm seeing a solution where there isn't one, but isn't this potentially useful for the purpose? I mean, it's writing to a "file" (which I'm taken to believe is a virtual file, otherwise it would kill the SD card in fairly short order) - can that file be addressed remotely? I don't know the correct Linux network string format, but if it were given network writing permissions and the OctoPi were instructed to print to smb://Klipper/tmp/printer (formatting withstanding, of course) as its "port"...

Or is that one of those "Seems like it should work but it doesn't" scenarios like putting a transistor in back to front?

PS Shame I can't mark multiple posts as solutions, assuming that's not a go. Understanding the reasoning behind a given answer helps.

17

I’m a little late to the conversation, but want to Toss my 2cents in.

This problem is not a Pi issue, not an Octoprint issue, not a Klipper issue, and not a printer MCU issue per se. The issue is inclusive of everything in the stack, hardware and software.

It you replace one item in the stack, you’ll get better results. I’ve seen it myself.

The issue is a combination issue, in my experience. 1) Pi hardware (CPU memory and USB speed)
2) Octoprint Comms. The community is aware of this thus it’s being addressed
3) MCU USB. This is also an issue. Many older AVR MCU’s have a slapped together USB to serial interface.
4) MCU clock rate.
5) MCU bit rate. Yes, 8 bit boards have limitations such as +100mm/s printing on CoreXY printers and Delta printers.
6) python version sun setting. This may have a factor albeit minor.

It’s possible that Octoprint 1.4.0 will fix it as there is a new communications solution being designed. This is still “vapor ware” as it’s not completed and in the hands of users, so we cannot comment yet.

Changing out Octoprint for something else has also resolved, or at least minimized the issue.

Changing out your current Pi for something else WILL fix the issue. Many Klipper users who use a PC running Linux do not experience issues. Why? MANY reasons.

  1. Some Pi have 64 bit cpu but Raspbian OS is 32 bit.
  2. many Pi have 1GB or less RAM
  3. Pi RAM is cheap and S.L.O.W.
  4. Headless Pi installs run faster.
  5. May be using the wrong SD card in Pi
  6. slow USB chipsets are used
    I’ve upgraded my Octoprint to an Asus TinkerBoard it’s still 32bit, but CPU is 1.8Ghz, 2GB RAM and it’s faster. Better USB chipset. Higher quality SD card. All around a better option and this has fixed a couple issues. I have an Odroid X4U on my bench waiting to be configured.

MCU - many 32 bit boards have implemented a native USB to Serial interface. This is one bottle neck. Another is the amount of flash RAM on he MCU. Some 8bit boards have as little as 8k, which doesn’t leave room for much buffering. 32 bit MCU’s have more, way more and some 8bit boards have more too.

I hope I’ve shown that it’s a issue of the entire stack, and the more little issues you have in your specific stack, the greater chance you can induce the problem. Change one piece and you’ll get better results.

I’d suggest swapping out your current Pi for something else. Would a Pi4 work? I don’t know as I don’t have one. By the specifications, cheap components are in use.
I’m having good luck with the Asus, and I can send you installation documents. Some Klipper/Piper builders are using an AtomicPi with great results too. Other Klipper users are using an old laptop with a flavor of Linux like Ubuntu.

My personal opinion; a Pi replacement now and Octoprint 1.4 later will be the right long term solution. If you can toss in a 32 bit MCU upgrade as they are getting less expensive, than you will have a complete fix for the issue.

Many 32 bit MCU’s are still being developed in Klipper, so there are going to be some limitations, which are being addressed daily.

OctoPrint and Marlin has had similar issues. I’ve addressed it somewhat on my Anet A8 with a buffer increase while loosing SD Support due to limited MCU RAM.

I’m currently working on a Klipper configuration using an 32bit SAMD51 Adafruit Grand Central M4 with a modified RAMPS shield. The Grand Central has the same footprint as a Arduino MEGA and Due with 120Mhz clock that can be overclocked to 200Mhz

1 Like
18

@Asterchades,

Your OP has generated a lot of discussion and many suggestions (including this one from another thread, https://community.octoprint.org/t/can-you-connect-to-the-tft-sd-card/11387/12?u=b-morgan).

I believe you have enough information to make an informed decision on how to move forward. Choose an option, implement it, and let us know the results.

1 Like
19

Agreed, @b-morgan. I'm going to have to mull over this one for a little bit to reach a conclusion, but so far I'm basically working with the following:

  • Chaining two RPis. Possible, but potential source of many headaches (especially given the RPi2 lacks wireless).
  • Replacing the RPi2, either with an RPi3 or other higher-powered "IoT" controller like a Tinker Board or even Orange Pi. Known to work, possible it may encounter similar in the long term.
  • Replacing the RPi2 with a desktop PC. This is a massive overkill, but I have other uses for the same server (so long as I can run OctoPrint and Klipper either from Windows, WSL, or a VM).
  • Waiting for 1.4.0 and hoping the updated comms work.
  • Ignore it all and pop down to the Winchester for a pint. By that, I mean just use it as I have so far without the extra OctoPrint features.

I did just finish watching the "On Air #25" vlog, and it sounds like 1.4.0's defining release feature is the deprecation of Python 2.7, rather than the comms, since the aim is to have it out by year's end. So it's not certain those will make it in, nor is it certain it would help anyway. That same vlog also suggested that an RPi4 may not be a great idea given the temperatures it runs at, potentially causing many issues with throttling (and the side-effects there-of programmed into OctoPrint for safety).

Point blank, I'm prepared to admit I'm a big fan of easy. But I'm always prepared to put in a little extra effort if it means far better results (especially for less money). So, yeah... I'll get back to you when I make up my mind.

Incidentally, I did also just do a firmware update on my RPi2. That may also have an effect, so I'll need to wait for my new filament to come in to test that.

1 Like
20

I agree that 1.4.0 comm layer is a ways out and may not solve the problem completely.

I wouldn't worry about RPi 4 thermal problems as there are fan and heatsink solutions that should work. See https://community.octoprint.org/t/raspberry-pi-4-is-out/10332/147?u=b-morgan for an example.

21

You can use socat and ser2net to redirect serial connections over any tcp network. I'm using that to dockerize the whole stack in individual pieces (serial provider, klipper, octoprint)

Data path:
(1)

  • serial port
  • ser2net
    (2)
  • socat
  • klipper
  • ser2net
    (3)
  • socat
  • octoprint

where (1) (2) (3) are individual docker images.

I'm having some issues with (3) in docker right now, but on "bare metal" should work fine. You also have the DWC web interface which is easier on the pi2 than a full octoprint

1 Like
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?