Has something like this ever been done or theory crafted?
Maybe explain what your goal is. I am not sure what you are wanting to do. The host can support multiple MCU without a second SOC. You can do like I have done and put Linux on a Laptop and have multiple printers each with more than one MCU.
So, what are you trying to do?
The use case would be to use an external host, i.e. my linux running intel nuc, with the modern mainboards that have a host soc imbedded/ attached. These mainboards typically do not have any way to connect to the MCU for an external host, so you can’t just plug a usb cable into the mainboard to connect your external host. The MCU is hard wired to the SOC with no other connection method available. So to reach the MCU we must go thru the onboard SOC. I assume this is possible with some form of port forwarding configuration on the Soc software side i.e. in armbian or pi OS or whatever linux the soc is using but I don’t know.
Like has anyone ever tried usbip to forward the usb port over the local network to another machine?
I have found I can use socat to forward the UART mcu from one linux machine to another over my LAN. I have not attempted doing anything with the MCU yet, but it does connect in klipper.
I’m trying to understand what you mean by “an external host” and what you’re trying to accomplish here.
First off, Klipper has stringent timing requirements between the host and the MCUs to ensure a quality printing process. If you look through this site, you’ll see many people who have problems with losing the synchronization between the “Host” and the “MCU(s)” with the error coming up most often being “Timer Too Close”.
I’m saying this because having devices connect to one another doesn’t mean that the printer will work for any length of time. Looking at your screenshot, I’m quite confident that 115.2kbps will not cut it when it comes to communicating with multiple devices - you will be having errors essentially immediately.
I also have to point out that it can be extremely difficult to get a PC running Linux (Mint, as you use, probably being the most common distribution used in this case) working reliably as a Klipper host.
Finally, I don’t know how familiar you are with Klipper, but I don’t see the value in adding an “external host” at all. When you run Klipper with Mainsail/Fliuidd/Octoprint, you have a front end that provides you with a control interface to your printer as well as the ability to upload/download files.
What issues are you looking to resolve by adding an additional layer of hardware to the current Klipper architecture?
Thanks for your reply. I too am skeptical about the connection speed and integrity, in the next days I’ll do some testing to see if it’s viable.
As for using Linux mint on a pc for host, i have to disagree with it being difficult at least for me. I’ve been doing it for years, and it requires no special setup. The extra processing power to host multiple klipper instances is wonderful. I’ve been running 3 klipper host instances to control 3 printers for awhile, and it’s not even a burden on this Intel NUC, including 1080p webcam streams and filament changer systems.
The goal here is mainly just for fun and science but also personal preference. I prefer all my printers be on one host for simplicity. I also don’t like RPi’s. This started because i have one printer with a host integrated mainboard on which the soc is unable to process a niche request in a timely manner resulting in TTC shutdowns. Its also just… slow… and annoys me. So instead of turning the mainboard into ewaste I’m looking at alternative ways to still use it, issue being there is no easily accessible usb connection to the mcu on this board. So to reach the mcu i must go thru the soc. This is common on host integrated mainboards which are becoming more popular and common every day(BTT manta, mks skpr, mellow has similar, and lots of the new OEM boards like Creality use). And that puts us where i am today.
I also plan to try some other connection methods instead of LAN which might result in better connection speed, but we’ll see.
To be clear the aim is to NOT use the onboard soc of the mainboard as klipper host, only as a Linux machine(armbian) so that the uart serial devices(mcu’s) hardwired to it can be accessed by another, more powerful, Linux machine running klipper as host.
This is absolutely not necessary and will not provide any benefits. Klipper and associated services are designed to run on a Raspberry Pi 3 and above (even on lower models if necessary). Again, it will not provide any benefits.
On the contrary, a stable, direct, undisturbed, and low-latency connection is much more important. So, please do not post any Timer too close or similar errors in such a setup, as they will not be followed up in any way.
1 Like