Printer Model: Klipper based DIY astronomical telescope altitude/azimuth mount
MCU / Printerboard: RPI to FSYETC UCAN over USB to multiple EBB42 MCUs on CAN bus klippy.log (16.0 KB) printer.cfg (17.4 KB)
Inquiry: Am using RPI as Klipper host computer connected via USB 2.0 FS to FSYETC UCAN running candleLight_fw (presents can0 to RPI, no serial device presented to RPI) with CAN bus to multiple EBB42 (don’t get focused on fact that this is an astronomical telescope mount and not a 3D printer, am doing INDI astronomy to Klipper/G-Code mappings in INDI drivers to Moonraker to Tornado to Klippy). UCAN presents can0 and no serial device. There are no Klipper connected peripherals on UCAN USB-CAN adapter. All peripherals are on their own EBB42 instances on the CAN bus.
Klipper query script shows all four EBB42 MCUs running Klipper (altitude, azimuth, zoom, focus) so I know that CAN device type network interface (can0) on RPI is working, CAN bus is working, and all 4 EBB42s are working (running Klipper as MCUs). Question is how to configure Klipper primary [mcu] section on RPI host computer when there is only can0 and no serial device to satisfy Klipper primary [mcu] section requirement for serial reference. Also, since the UCAN is a USB to CAN host adapter acting as the CAN bus master there is no UUID for it.
FSYETC UCAN supports USB 2.0 Full Speed (FS) at 480Mbps. UCAN has a dedicated STM32F072 for handling CAN bus 2.0 at full 1Mbps. UCAN device is plug and play on the RPI, Linux (RPIOS/Debian 5.15.32+ #1538) automatically loads both USB (appears as ID 1d50:606f OpenMoko, Inc. Geschwister Schneider CAN adapter) and CAN network interface drivers (can0). Not SPI/I2C so no /etc/boot/config.txt changes. UCAN comes preloaded with candleLight_fw. CANBOOT and loading of Klipper onto UCAN should not be required. UCAN presents CAN network device (can0) on RPI, Klipper query script proves it. RPI is a single core, but astronomical commands are dynamically generated maybe one every 0.5 seconds per EBB42, a far lighter Klipper load than running G-Code files and using UCAN the CAN bus real time responsiveness has its own dedicated MCU.
This is not quite the same as the existing USB to CAN bus bridge-mode development branch article as there are no peripherals on the UCAN adapter. The UCAN PCB simply provides the RPI with a USB abstracted (fully buffered, performance offloaded) CAN bus network interface. It offloads the real time response and buffering to support a high speed CAN bus without dropping packets. I have also tried a Waveshare RS485 CAN HAT (not full CAN 2.0 due to reduced speed, drops packets).
How do I configure a Klipper host running on an RPI to work with a FSYETC UCAN USB to CAN adapter running candleLight_fw? The UCAN exposes no serial interface, only a CAN network interface. Klipper primary [mcu] section generates an error if there is no serial interface. And yet the Klipper script query successfully finds all four EBB42s on the CAN bus.
MCU bridge mode is for connections to other than the Klipper host to the CAN bus. It does not eliminate the Klipper host configuration requirement for a serial port in the primary [mcu] section of Klipper host configuration. Candlelight firmware based FYSETC UCAN USB to CAN adapter presents only a CAN network interface (can0) and does not present a serial port. As proven by the Klipper query utility CAN network interface over USB is present (can0) and working and can communicate with my CAN bus connected multiple EBB42 instances (returns their UUIDs and state of running Klipper). Why does Klipper still require the serial port in the primary [mcu] section?
Sorry are you trying to add the Raspberry Pi as a 2nd MCU? The RPI won’t interact with the Fysetc UCAN adapter. The primary [mcu] should be one of your EBB42 boards and not the RPI as a 2nd MCU.
No. RPI is Klipper application host (Klippy). RPI connects to CAN bus via FYSETC UCAN USB to CAN adapter running candleLight_fw. There are four secondary MCUs (EBB42 running Klipper MCU firmware) hanging off CAN bus and they respond as expected (UUIDs, application Klipper) when using Klipper query script referencing only the CAN network interface (can0) without use of a serial device on the RPI side. Why can’t Klipper host do the same as its own utility script? Klipper config requires a primary [mcu] section and that section must contain a serial reference.
You must designate one of your micro-controllers as the “primary” micro-controller (configured as [mcu]). That primary micro-controller should specify the canbus_uuid. It is not necessary for the primary micro-controller to be controlled via serial, but one must designate a primary micro-controller.
I did try that before reaching out to the group. Primary [mcu] section required serial reference, unless that requirement has been dropped in Klippy in the last couple of weeks. Klippy mandates serial, but query script successfully sends/receives over CAN network interface (can0) with no serial requirement. Guess I’m looking at moving this discourse item to a feature request of Klipper host only CAN, no serial. Klippy could probably branch how query script uses CAN interface logic from serialhdl. Some core rip up and lay down to dynamically support serial or CAN based upon configuration. Query script hints at how to do that. Once configuration drops the serial requirement barrier it could autodetect which interface to use based upon content of primary [mcu] section. If it sees serial then serial and flag any CAN references as config error. If it sees canbus_interface and no serial then only CAN network interface (default can0) and no serial requirement. If there is canbus_interface and no canbus_uuid specified then Klipper host CAN interface is the CAN bus master with no UUID required, just as successfully done in query script. Accessing CAN network interface over USB 2.0 FS should offload serial and CAN frame processing to candleLight running on MCU (FSYEYC UCAN) and the built-in CAN interface of the ST32 MCU. Maybe then Klipper host could run CAN at full 1.0Mbps on lower cost host processors without drop/sync issues.
Many people including myself have run Klipper with the primary MCU connected via CAN. I don’t believe a serial device for the main MCU has been required since CAN support was merged 2 years ago.
Removed serial reference and uplifted mcu config section of one of the 4 EBB MCUs to the primary MCU [mcu] and included its UUID as well as the interface which is can0 which is the default which I added for completeness.
Some success. No longer getting missing serial during config verification. Now getting unable to connect in web interface. Would like to provide a klippy.log, but since there is no longer config error and the error is connection the klippy.log file is not being produced. All I have are the older archives which are not current. Yes, I do rm the klippy.log file when doing trial & error to minimize noise. Once I take a closer look at the connection error by way of running query script I’ll get back. First need to stop Klipper before running query else none of the MCUs appear in query results.
Many thanks to those who assisted. RPI as Klipper application host now talking to multiple EBB42 instances on CAN bus through FYSETC UCAN USB-CAN adapter. For the astronomical telescope mount I’m implementing multiple peripheral integrations per MCU and not in their traditional 3D printer roles (filament heater of one MCU controls current to imaging camera Peltier cooler and fan cools heatsink of Peltier, to keep optics free of dew filament heaters of other MCUs controls dew heater pads with temperature sensing so as to not melt things, fan on another MCU used to disperse telescope tube thermal currents that otherwise distort view). As one of my named MCUs has been uplifted to the primary MCU section to replace serial I’m now redoing the previously named mcu prefixed signal name references. That and now that Klipper is mapping dictionaries from the MCUs I can now for the first time correct my long time incorrect pin references. Three steps forward, maybe one-half steps back. Thanks again.
I’m also interested to connect more than one device to one CAN bus.
I’m unsure, what you currently achieved.
Unfortunately there is little documentation for your FYSETC UCAN. I couldn’t find schematics.
The right termination of your UCAN should have something to do with this (just the ellipse on the right)
Sorry, got dragged off onto another project. I have 4 EBB42 instances on my CAN bus. The termination and ability to configure and index the individua EBBs was not my original issue (I figured out the termination jumper location). The issue was that the UCAN was a USB to CAN adapter that needed to be configured as if it were a CAN bus device instance when it is the CAN bus host interfaced by USB not CAN. Just the way they chose to do it, I guess. Got past that thanks to the group. My last worked issue was with an I2C timeout on one of the EBBs which I have yet to circle back around to work.
