Hi, I have a problem with my printer. I decided to assemble the printer with CAN communication and I have a problem with it. I managed to install everything and then I stopped at configuration.
Currently, the error “Pin ‘PB12’ is not a valid pin name on mcu ‘EBBCan’” is displayed in Klipper.
If I go to printer.cfg and add # to the position where the PB12 pin is defined, another error will appear: “Pin ‘PA2’ is not a valid pin name on mcu ‘EBBCan’”.
All errors are related to EBBCan. I’m not a programming expert, but somehow I always manage to solve the problem through trial and error. In this case, I have no ideas, and the problem will probably be easy to solve. I am asking for help from someone more experienced.
I changed the lines referring to EBBCan to those from this page:
After a few corrections, I got rid of this problem, but now I actually don’t know what to do next because the message that appears doesn’t lead me anywhere.
I see the message:
mcu ‘EBBCan’: Unable to connect
Once the underlying issue is corrected, use the
“FIRMWARE_RESTART” command to reset the firmware, reload the
config, and restart the host software.
Error configuring printer
You looked wrong, this is just an example. There is no such uuid in my klinpy.log, which I placed at the bottom of the message, only the one read from the RPi.
To get the printer started, I should have removed the “#” inserted before
“canbus_uuid: faa2d84a6c24”. However, if I do this, the error "Pin ‘GPIO1’ is not a valid pin name on mcu ‘EBBCan’ " appears again.
I don’t know what to do next because the pin is set according to the EBB SB2209 CAN(RP2040) V1.0 documentation.
Hi, I’ve been away from home for a while, but I’m back now.
I admit that I have been struggling with the printer a lot over the last week. I installed various versions of operating systems recommended in the posts and practiced with various configurations of “menuconfig” settings.
I managed to start the printer but without RP2040.
The system sees MCU and U2C 2.1. CAN communication also seems to work.
The RP2040 itself is visible when I enable DFU mode.
I uploaded various configurations of the communication method (CAN, CAN bridge) but the system does not want to detect its UUID.
I am attaching to the post the current settings of the Octopus motherboard (Klipper and Katapult) and RP2040 (Klipper and Katapult), the printer.cfg file, Klippy.log and other readings from SSH.
Okay, now I stopped at this stage:
The printer was working but it didn’t see the CAN head.
I uploaded new software to U2C according to my G0B1 processor.
The Katapult UUID appeared, I changed it from Katapult to Klipper, as everyone does in many guides. From that moment on I see the UUID under the name Klipper.
The moment the printer noticed Katapult/Klipper it stopped working, it has a problem connecting to the motherboard MCU. It stopped working before I added [mcu EBBCan] to the printer.cfg configuration file.
I can still check its UUID in HSS, so it didn’t connect. klippy.log (453.4 KB) printer.cfg (10.4 KB)
Maybe I should add that, as I saw with everyone else, in SSH they saw two UUIDs, one Klipper, the other Katapult, after changing Katapult they already saw two Klipper UUIDs.
I didn’t have the first one, but the printer worked (when I deleted the printer.cfg file, the first Klipper was still not visible)
The quarry script is only for getting a UUID and not the way Klipper communicates via CAN.
They don’t have two UUIDs for the same device, they had two CAN bus devices, one mainboard, and the other EBB. One had katapult and Klipper and the other just katapult. When the script runs and reports it tells you the current running software.
Katapult is a bootloader, it runs then it runs the firmware that is located just after the bootloader.
If you know PCs then you can think of the bootloader as the PC’s BIOS, and Klipper firmware as the system OS.
Once you have the UUID don’t keep using the script over and over, the UUID doesn’t change for that device and it is not meant for detection but for ID of the device.
The katapult script tends to connect better than the Klipper CAN UUID script.
If you put the UUID in the printer.cfg or EBB config with Klipper running, Klipper will interfere with the script and the device may not respond to the quarry script so use it only to update katapult (via the deployer option) or Klipper to that device.
FYI, updating katapult via katapult, use the build depolyer option this creates a depolyer.bin, send this file via katapult as if you were updating Klipper.
This will load a run it where it wipes the unused flash space and replaces the current katapult with the update. So after, only katapult will be on the device, then just load Klipper back on the device via katapult.
The SB2209 PR2040 I haven’t had any experience with setting up katapult.
I do have a PITB V2.0 from China on the way to me that uses the RP2040 as its MCU so I will gain experience as I set it up. Expecting it within a week now that it is in the US.
But with that when using a U2C type adaptor it will not show any UUID since it is an adapter and not a CAN device. So with your setup, you will only see the UUID for your SB2209.
I understand, I won’t be here for a while either because I’m leaving.
Can you at least elaborate on the “build depolyer” issue? At what point should I enter it, or what should the command look like, an example? Maybe by some miracle I could get it working today.
I feel that I am close to the success of the mission.