OctoPi + Aftermarket TFT (28/32/35) Kits

What is the problem?
Trying to figure out if it's possible to get OctoPi working with one of those "drop in" aftermarket LCD kits such as the TFT32 or TFT35

I have a TFT35 hooked up to AUX1 on my SKR1.3 and OctoPi connected via USB to the SKR 1.3. OctoPi can control the printer just fine and send prints, but the TFT35 does not seem to recognize when a print has started, display current print status, temperatures, etc.

As far as I can tell this is primarily because these boards were meant to replicate most of the functions of OctoPi, so I'm not sure if it's possible to have them work WITH OctoPi rather than replace it. I love OctoPi and I have no intention of ditching it.

However I do NOT like the OctoPi Touch Interface that I've seen posted in other threads. It's expensive and doesn't seem to work as well as these purpose-built LCD kits since they run their own interface.

What did you already try to solve it?
Lots of googling. Hooking up my TFT35 to AUX1. It can control the printer. OctoPi can start prints, but the status of the current print does not show up on the TFT35.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
Not yet sure what logs to get because IDK what the problem is or if this kind of setup is even possible or not...

If the TFT35 is hooked to the controller board and not the Raspberry Pi running Octoprint, you'll need to see if the controller board maker has options to make it work. Wouldn't matter if you were running octoprint or any other print control software.

I've worked on a couple of TFT-on-the-Pi 3D printer projects: Robo 3D and OneClickMetal.

Robo 3D had a GPIO-based header which comes over to the TFT. It included the input device as well. I don't really love this approach because the 40-pin connector takes over all the GPIO pins, making it hard for you to use any for your own purposes.

OneClickMetal uses an elotouch.com display with separate HDMI and USB connections for display and touch input. It's probably around $200.

I've also had good luck with similar projects with Adafruit's 2.8" TFT and their version with extra buttons. To be honest, the cheaper resistive type are less "touch" and more "poke-it-with-a-sharp-object" in order to get any input going. At $44.95 that second one isn't cheap but you're not going to curse it either. I've also used their resistive version.

I've also had good luck with the SunFounder 10.1" version @ about $150.

I wasn't aware you could hook a TFT-kit to OctoPi instead of the control board. I'll have to investigate that.

I mean, I knew it was technically feasible, I just never considered that OctoPi could act as a relay for commands it received over UART, thanks for pointing that out.

Also just FYI the kit I'm using is the Makerbase MKS TFT35. The reason I mention this is that this LCD has a controller board and UI already built into it, it's not just a dumb LCD. It's nice because some of the features are ones I need (filament run-out sensor slot) but others are redundant to OctoPi (wifi, USB slot) and I much prefer OctoPi...

Unfortunately being a Chinese part the documentation is sub-par and support is hard to come by...

Yeah I'm going to try a PiTFT (Elecrow 5") because it has a fairly low profile and doesn't use the GPIO pins at all - it has a pair of 'u' shaped HDMI/USB adapters to pass A/V and Touch, so it's actually a pretty good solution that keeps GPIO free so that I can drive the Pi off the SKR still.

Thanks for the suggestions!

1 Like

Don't get me started on run-out switches. (I'm convinced that it's a partial solution at best.) I spent the weekend working on the spool movement detection plugin which I believe is the ultimate solution—assuming it works—for filament-delivery problems as well as clogging scenarios.

I'm curious as to what's wrong with filament run-out switches? Sure there are probably edge cases or problems with things like flexible filament, but I don't see why they're a problem for moderate printing and rigid filaments?

The first post I linked reasonably lists the causes for print failures I've encountered. A run-out switch won't tell you that your hotend is clogged and your print is soon going to be air-printing. A filament movement detection device could though, in theory.

I guess I'm saying that the industry just picked a solution which seemed to be easy but it's not a fix for the many ways in which filament delivery fails.

I can't even begin to count the number of times that dry filament has snapped somewhere on its path going to the printer. In the cases where this is after the run-out switch then that approach wouldn't have worked.

And then there are the times when the filament manufacturer hasn't kept the diameter of the filament within tolerances and it gets stuck in the PTFE tubing. Again, the run-out sensor wouldn't have told you this.