Connecting OctoPi to a separate RPi

Get Help
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
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.