FYI, the latest Klipper code now has improved reset ordering of FIRMWARE_RESTART commands for “bridge” mcus (commit 751bff7d). It does require upgrading and reflashing the mcu.
-Kevin
FYI, the latest Klipper code now has improved reset ordering of FIRMWARE_RESTART commands for “bridge” mcus (commit 751bff7d). It does require upgrading and reflashing the mcu.
-Kevin
i found (i think) a bug, if i select pins PB13, 12 (Skr pro v1.1 or Fly Gemini v2) to use as CAN, just not work, but if i choose PB8, 9 Can works fine. I dont know if have any reletion but reading datasheet (Stm32F407 and F405) PB13, 12 is listed as CAN_2 and PB8, 9 as CAN_1
Would it be possible to Enable PB8/PB9 on the STMF32103 for USB to CANbus Bridge?
I would like to see if it’s possible to use an SKR E3 V2 as a CAN bridge with a MCP2551 CAN Transceiver on the PB8 /PB9 pins. If it works a plug in module for the EXP1 port could be developed.
As Kevin noted in the original post in this thread, the F103 doesn’t support simultaneous CAN and USB, so it’s not possible to use it as a bridge.
I missed reading that… You are correct… Thank you
I have a identical issue. Did you resolve it at all?
There was a low-level error in the stm32f446 build rules when selecting “usb to canbus bridge” mode. It should now be fixed. Octopus Pro Canboot & CAN Bus Bridge
-Kevin
I have 2 machines, 2 pi’s. I testes the Ebb36 on the bench with Octopus 446 standard and worked properly.
Installed it on another machine and CAN0 will not show. I used the command :
sudo ip link set can0 up type can bitrate 500000
and the CAN comes up and klipper working/connected. But when I restart firmware there is no CAN via ifconfig and no connection.
I take my PI from another machine that I used to set it up and put SDCARD in other machine. Booted up, connects, and restarts firmware properly.
The board in the main machine is Octopus Pro 446.
Any ideas?
I have had to add the command below to the /etc/rc.local just before exit 0 to insure the can0 bus gets started before Klipper.
sudo ip link set up can0 type can bitrate 500000
I ended up doing a fresh install and it works without adding the line you suggested.
On another note, have you tried to use the ADXL? I am getting timer too close alarms. If I use the RPI for ADXL is works properly. Is there a bandwidth issue from EBB to USB-CAN bridge?
I am using with HUVUD (latest variant with ADXL345 built in), no issues with accelerometer. (RPi4 with Octopus-Pro-446 in CANbus bridge mode)
Running input shaping with the ADXL pushes the CAN bus pretty hard. At 500kbps it fills the bus 70-80%, if you run slower it will not work. The CAN bus itself has no problems at all with a near full bus, at 80% full there is still room for any lower priority traffic.
MCP2515 based HATs will not handle that properly. Klippers CAN bridge or other USB CAN dongles worked fine when I tested it, with multiple boards on the same bus.
My VZBot has been running a waveshare CAN hat at 500k with zero issues at all, including resonance measurement.
My Sapphire-S is now running an MCP2515 board (basically a breakout board instead of a HAT, but same chipset) at 250k and also has zero issues running resonance measurement.
The only thing I do different is assigning a larger buffer, i.e.:
up ifconfig $IFACE txqueuelen 1024
instead of the 128 listed on the klipper docs.
Hi everyone
I have an interestig question about this topic.
I have modified my Creality 4.2.2 to the point it can be considered custom board.
I bought EBB in hopes of getting it working but now i see that this needs some emulation on USB front.
My setup is made so that Raspberry Pi is connected via serial connection not USB, PA09/PA10 is for serial port to raspberry and PA11/PA12 were freed from sdcard reader duties for CAN.
At work we use different MCUs to communicate via CAN, Serial you name it.
I have hoped that Klipper on main pcb acts as Master to the system and CAN nodes would be Slaves to that main board. Would it be possible to make Klipper do it this way?
@koconnor I remember seeing a reply somewhere on the internet but can’t find it anymore.
Someone was asking about using a UART / serial connection from the Raspberry Pi to Octopus board and then trying to use the USB to CANbus bridge communication mode for direct connection to a CAN toolhead.
I’m pretty sure this is not possible. Can you confirm?
No need to ping Kevin for an answer. It’s called USB to CAN bridge for a reason. UART is not supported and likely won’t ever be supported. Simultaneous USB and CAN connections are a hardware feature on certain STM chips.
Yeh I know that. But apparently having it spelled out in the name isn’t good enough proof for others.
New to here, I just registered for this post, as I can confirm the USB to CANbus bridge mode works well on Fysetc spider 2.3 with the proper can bus transmitter, which was sold separately.
Since I didn’t have a usb to can adapter on hand when I did the test, I used a fystec canbus tool head board as an adapter, because as it also had a microusb port so why not? And it worked without problem.
An error was found in the CAN2 handling on stm32f4 boards - see MKS SKIPR CAN Bus - #80 by koconnor
-Kevin
So I’ve been thinking about this a bit, and I think I got a proof of concept working in my branch here: GitHub - terraphantm/klipper at canflash
I added a “make canflash” target to the make files for the STM32 and rp2040 Makefiles, updated flash_can.py to the latest version (which adds the -r option), and added a “flash_can_helper.py” (which borrows a lot from the existing flash_usb.py) to invoke a reboot into CanBoot, detect if a CanBoot serial device is now present, and then use the latest version of flash_can.py to flash either in CAN or Serial mode depending on what’s found. I’ve tested it on rp2040 and stm32 devices so far with good results.
Syntax to use it is
make canflash UUID=[uuid] BUS=[can bus (can0, can1, etc)]
Issues I can anticipate:
I will not make a pull request because
A) I don’t think I can make code at the quality expected of the klipper project, and
B) I would rather not associate my real name with my online persona and therefore cannot contribute to the project per the contribution rules.
If someone wants to take the code or concept to package it into a klipper worthy merge, feel free. I make no claims to the code (which really can’t be called my own in the first place with how much it borrows from the original code)