Connecting OctoPi to a separate RPi

Get Help
1

This is going to sound like a strange one, so I'll try to explain as best I can.

I recently began using Klipper on my printer. For those unfamiliar with it, this is a host/client firmware which effectively turns your printer's control board (now the client) into little more than a stepper driver while an RPi (the host) handles all the calculations. The results are quite wonderful when compared to an 8-bit Arduino-based solution like found on an Ender-2, even at modest speeds when using complicated models.

Problem is, my RPi2 doesn't like running both OctoPrint (OctoPi) and Klipper at the same time. It can, but with more complicated models (where the benefit is most significant) it can and does pause for multiple seconds every couple of layers. This leaves deformities in the model from the hot end, as you might expect. To get around it, Klipper supports a "Virtual SD card" which pipes through as you might expect a real SD card to, but using it negates most of the advantages of using OctoPrint in the same way that using an SD card in the printer would.

So what I'm hoping to find out, as someone inexperienced with Linux, is whether it's possible to connect one RPi to another through OctoPrint. This would allow me to get a second RPi (a Zero or second hand unit so it's cheaper) to actually run the Klipper host software, leaving my current RPi2 to just handle OctoPrint and its plugins. This has the added benefit of ensuring that both services are never competing for system time and resources, which would still potentially be the case if I switched in an RPi4.

Can this be done, or is it beyond the scope of this project?

2

Wouldn't it be easier to remove the microSD from the Pi2, put it into a Pi3 and call it a day? (US$35)

You'd then have the Pi2 leftover for other projects.

1 Like
3

Hi I had the same problem when i tried to use my old raspberry pi, my solution to the problem was to use and old PC. I use i one of core 2 and the load on it is like max 25%

4

I appreciate you both taking the time to reply, but I feel as though neither really answers the question I've asked.

Before responding, though, I'd like to preface this by saying that I've heard back from the Klipper people and the suggestion is that OctoPrint 1.4.0 should solve the issue even on my existing hardware. Something to do with how the present version handles large amounts of detailed geometry in quick succession which is supposed to be resolved, rather than an issue of resource contention. I guess I'll have to wait for it to launch to find out for sure.

This feels like it's just moving the problem further out, rather than solving it. I've read similar reports of RPi3 hardware doing the same. The "logical" conclusion given that is to use an RPi4 instead, but that will inevitably encounter the same under the right circumstances (higher speeds/precision, more plugins, etc). I'm after a more permanent separation of load.

Having the spare RPi2 also wouldn't be of any interest to me. This is the first RPi I've owned and I've had it less than 3 months, having gotten it from my brother who bought it to use as a RetroPi before finding out he really wasn't interested either and shelving it for a year. I don't have other projects, nor do I foresee having any which would be suitable (please don't offer suggestions for such as I've likely already considered them, and it's outside the purpose of this thread).

Originally I had a similar thought to this. I had intended that when my current system was upgraded the leftovers would go to make a server which includes OctoPrint. Upon discovering Klipper, however, I know full well I'm not good enough with Linux to make such a setup work. I could probably find instructions somewhere, but I question which would be easier to learn and implement.

5

Is it because of software issues or because of the calculation power the RasPi2 provides?

6

That's the million dollar question, really. I've no idea - my experience with both the hardware and the software (OS and services) is fairly limited, so I wouldn't even know how to find out which it is.

One would imagine the RPi2 has plenty of power for what I would consider to be fairly straight forward operations. It's basically operating as a glorified calculator, working off a static input list to generate a static output list - hardly supercomputer-grade stuff, considering half the job can normally be done by an Arduino at barely 1% of the clock speed. But with everything running through Python, overheads from the OS and such...? Yeah, I just don't know.

All I know for sure is that asking it to do one or the other doesn't show any issues. It's only when both are trying to happen that it crops up.

7

A RasPi 3B+ is the better choice for OctoPrint with additional software running. A RasPi 2 is already hard on the edge with OctoPrint alone.
Chris Riley installed Klipper to a RaspI 3B+ with OctoPrint as it seems without issues.
Keeping in mind, that the processer of the 3B+ is including the the higher clock rate almost as twice as fast as one of the RasPi 2.

1 Like
8

I've no doubt that an RPi3 would perform better in isolation, likely only very rarely showing a problem. And an RPi4 would be better again. But that's really not an answer to the question that I've asked.

Consider the following question: How can I run an RPi from an existing 12V power supply? I know the answer is not "You can't" because I'm already doing exactly that. The answer is not "Obtain a 5V power supply" because the intent is clearly to use something already in possession. The answer is "Use a 5V DC-DC step down converter", which is precisely what I've done to hook my RPi2 up to my printer's 12V PSU.

With that in mind, my question is not "What can I replace my RPi2 with to allow OctoPrint and Klipper to run in harmony?" It's "Can OctoPrint effectively be daisy-chained from one RPi to another in order to run an RPi-based printer, such as one using Klipper?" If the answer to that question is genuinely "No, it can't" then I'll start looking at replacement hardware (assuming 1.4.0 doesn't actually solve the problem; whenever it comes out).

9

I personally considered a daisy-chain project involving a 3B -> Zero -> controller board for the purpose of inline/realtime decryption of DRM information in the gcode file. And when I say "considered" I mean "rigged this up and decided that it wouldn't work well".

  • The Zero only has one core and only one available USB connector for communications
  • Both Pi computers have only one good UART each; in the case of the Zero this starts to look significant as a problem
  • So one side of the Zero can talk 115200 baud or better and the other one was limited at 2400 (from the GPIO pins)
10

So if I'm understanding that... the Zero only having a single USB port represents a physical problem. However, even if I were to obtain an Rpi with more ports (anything other than a Zero) to bypass that, I would still encounter a problem due to the UART configuration, ultimately crippling the entire setup by killing bandwidth on one side. It's probably more nuanced than that, but that's roughly the situation.

This would mean that, because OctoPrint was designed to communicate via serial (RS-232? COM? What is the right term there?), even if I were to somehow manage to bodge something up that worked it would be merely an academic experience - not a useful one. And because the target devices (ie the printers) of OctoPrint don't (presently, anyway) use any other means of direct communication (eg native USB, BlueTooth, etc), that's likely to be the way it stays.

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