Remote connectivity and monitoring 3D printing firmware / controller options

on the heels of this hijacked thread, I have an SKR 1.4 turbo board to put in my ender3 and based on the previously linked thread and this one, I now have an interest in souping up my 3d printer in prep for possibly printing lowrider parts. What I really want is more print speed, and I realize this board isn’t the direct answer to that, but I’ve had this board for several months and I’m going to put it in. Along with that install, the choice of firmware becomes an option. I have long used Marlin/Octoprint (rpi 3B+) and octoeverywhere for remote connection and monitoring, but I am wondering if there is something better to try. These are the 3 I have learned a little about and I’d like some feedback on why you all like or dislike these options and if you experienced severe limitations from them (in no particular order):

  1. Klipper
  2. Reprap
  3. Repetier

Each option has a version compatible with the hardware I have, so it should work, but I only have time to try 1 before going “back.” if I doesn’t work out. What would you suggest and why?

There is the wifi and ESP3D route. Some controller boards (including your SKR v1.4) now have the capability to add a wifi module (ESP-01s) as a serial port and use ESP3D firmware to connect from your PC to the controller to download your gcode files to the controllers SD card and commence printing remotely. The transfer rate is not going to win any prizes in a speed contest but it is reliable and does away with the Pi.

But the fun of the single board computer sans power switch is now a customary inconvenience…

the slow transfer sounds like the time I used octoprint to store the gcode on the sdcard… reminded me of dialup days.

If these 32 bit controller board manufacturers would use a bulk transfer or raw HID or dual usb enumeration to expose an sd card as a mass storage device, this transfer issue would go away instead of emulating a serial port for primary communication. They just need to make the transfer communication protocol standard so pcs will communicate with them properly. My microcontroller programming is limited to the cypress psoc, now nxp I believe, but they had built in usb drivers for the 8 bit micros and some could do otg acting as host or device and you could have one device show up as a gamepad/keyboard or a storage device and hid or whatever. The requirement for USB-seiral is lost on me at this point in time, but this line of musing is off topic I suppose. Would spi make it fast enough to be viable?

No experience with Reprap and have only used Repetier to interface with Marlin over USB. All my machines run Klipper/Mainsail except my LR2 which has Marlin.

My favorite thing about Klipper is the editing/updating of settings. It is all in easily editable *cfg files. Very fast tweaking and testing ability. Lots of resources. Octoprint supported. Easy to install/backup.

1 Like

Even so, you would still have the serial nature of wifi transmission limiting the data rate and the latest gains in wifi data rates are hardly likely to be available using ‘cheap-as-chips’ ESP01s type adapters! Presently 802.11b will support around 2 to 3 Mbps, less the overheads (which can be considerable) and I can’t see much changing in that area for some time. at the end of the day 3D printing is a slow (some would say painfully slow) process so the extra 30 seconds or so to get the file into the controller pales into insignificance really.

1 Like

Wifi is much faster than the serial interface. The gcode serial interface is especially slow. My experience is mostly trying to use octoprint and sending the files over serial could easily be 15 mins, vs. seconds to a pi (and this was a long time ago, on an older pi with a wifi adaptor). Maybe the esp3d is already faster than the gcode one.

My average transfer times are around 15 to 30 seconds for 3D printer jobs, that’s over wifi using ESP01s modules and ESP3D… not as fast as ethernet to an Orangepi zero running Repetier Server but fast enough…certainly not minutes!

right. My point is that the serial interface to the printer is the bottleneck. The pi can print by feeding line by line over the serial to the printer, but again, serial is the bottleneck, not the wifi. My comment was meant to say that the pi to printer connection could be a true usb connection and not an emulated serial connection. We don’t need and FTDI or similar chip between them since the high end micros can natively do usb… but this is ancillary to the original question and I pushed the discussion this direction.

So I hear Klipper and mainsail might be a good option

1 Like

Gotcha :slight_smile:

With the caveat that I have not used Klipper in several years, I did try it with my very first printer, an MP Mini Delta. I was able to get it working, but for my needs at the time (I was trying to improve quality), it wasn’t substantially better than the stock firmware (which I think was some version of Marlin, but may have been heavily customized). I also found it easier to find info about the stock firmware, so I went back to stock, and have been using Marlin ever since.

Nearly four years later, there are probably more resources available for Klipper, particularly for a printer as mainstream as the Ender 3, so if I was starting from where you are, I’d definitely look at it.

Would strongly recommend CNC Kitchen as a great resource for printing fast, as Stefan does a nice job of testing various parameters meticulously. He’s also got a number of really good videos on printing stronger parts.

1 Like

I have a little wifi board that allows the Duet Web Control to run on SKR boards. I think Teaching Tech has a video on installing RepRap firmware on SKR.

I use RRF on both V1 machines, and my printers except the Repeat (as soon as I have the new one up, I’ll be switching that one too.) The “gcode everywhere” approach means I can manage complete reconfiguration of everything without a recompile, and even try different things like homing routines without so much as a reboot. I can even break out the axes to individual motors and move them independently.

With any firmware change though, it is a learning curve.