Hello Klipper Community! I’m new to Klipper but not to 3D printing, electronics, or coding.
I’ve taken the plunge to build a RatRig V-Core 3 500 and while I wait for the printer itself I’ve been setting up the electronics on the bench but I’ve hit a wall.
I’m running a BTT Octopus Pro 429 and a BTT EBB42 for the toolhead but I’ll be damned if I can get anything to come out of the CAN bus on the EBB42. I’m hoping someone can give me an idea of where to look next.
Here’s what I’ve done/tried:
CAN H/L are wired using a twisted pair from a CAT5 cable
Terminating resistors are connected on both boards and the bus reads 59.9ohms
Updated both boards to the lastest commit on master
Tried the default 500,000kHz and BTT’s suggested 250,00kHz
Flashed the EBB as a CAN bridge and was able to get its UUID but still can’t get communication with it as a CAN only node
Put my scope to the bus and I’ve got nice square edges and good data being transmitted but no signs of life from the EBB at all, not even driving the bus dominant for the ACK bit
Also put my scope on the RX/TX pins from the CAN transceiver on the EBB and the signal is good on RX there as well, but absolutely nothing on the TX line
Yes, both boards work fine in bridge mode and I have the UUID for both (see below, the EBB does not respond when flashed with CAN firmware but does when flashed as a bridge), but the EBB never responds to the query from the Octopus.
Octopus as bridge I get its UUID from the query and I see the expected broadcast packet from the Octopus on the CAN interface (using oscilliscope). No answer from the EBB but I also probed the RX output of its CAN transceiver and I see the same packet.
I flashed the EBB as a bridge and got its UUID and put that in my config, but still the Octopus is not able to establish communication with it. I see a bunch of packets that actually contain data on the bus now, but still not even an ACK pulse from the EBB. My thought with getting the UUID was that maybe there was something wrong with the query broadcast not being processed correctly on the EBB but seems that wasn’t the case.
All I can suggest is to verify you have the correct pins configured when building the firmware for the EBB, and verify your wiring. H goes to H, and L goes to L.
Already verified it a few times while working on this. Though if it was backwards I’d be getting gibberish out of the transceiver on the EBB and I’m not.
This is probably way above my pay grade and I’m sorry for the potential naivety in my response, but I’ve got EBB41 1.0 talking to Octopus Pro F446 (at least on the bench, e.g. it may not be stable to print but at least I can control peripherals attached to EBB)… and I never flashed EBB as a bridge (didn’t even know it is possible) - and it should not be based on my limited knowledge. At least it seems to be working. Happy to share my menuconfig screenshots if helps.
Thanks for the input Alex. I only flashed my EBB as a bridge to test if I could get the UUID out if it via the can0 interface on my host pi, which did work. After that I flashed it back to the regular non-bridge CAN firmware.
I’ve got a v1.1 board though so maybe they changed something, I’ll take a look at the schematics and compare.
I’m not sure of the issue. It may help if you run make menuconfig for the EBB board (as you intent to use it), and attach a screenshot of that config. And then do the same again for the Octopus board.
Well it’s comforting at least that I’m not the only one stumped by this. Thanks for weighing in Kevin and thanks for this incredible piece of software!
Both boards currently have firmware built with these configs on them. can0 comes up without issue and the Octopus always responds to the query but the EBB never does except the one time I put the bridge firmware on it.
When I flash firmware to either board the dfu-util responds that it couldn’t reconnect to verify firmware, but that seems expected to me as the mcu seems to start the uploaded firmware after flashing and the board then does not come back up as the dfu device.
An interesting read, but seems to refer to an Octopus not an Octopus Pro and also to issues with 446 not 429 chips.
I did learn about canboot from it though, which I was previously not aware of and am now very interested in since it would allow me to update my EBB without having to get a USB cable plugged into it. I will try updating the bootloader on both boards to canboot and report back.
I’ve got it working! Not 100% sure but I missed something in the BTT docs that might have been the cause. They say to flash the program at 0x8000000 instead of the Klipper default of 0x8008000 (8KiB bootloader) so I guess there is no bootloader on it from BTT.
I flashed canboot setup for an 8KiB bootloader and it just worked right away, didn’t even have to flash Klipper again as it was already flashed at 0x8008000.
Thanks for the clues and the great software and support guys!
