Don’t hijack somebody else’s thread.
Please start your own General Discussion query.
1 Like
Okay, I’ve been printing with PLA and PETG all day. Yesterday I tried printing with ABS, lost connection to can0 again…
There are still no LED effects for my nozzle LEDs.
For high-temperature materials like ABS, I use four bed fans to heat up the chamber. Maybe the PSU is also a problem?
After the second attempt, I measured the power with only 24V consumers active. The hotend was at 260°C, the bed fans were at 80%, and the cooling fans were at 50%. The motors were active but not moving. I measured around 90-100 watts. The measurement is from a smart plug, so it’s not going to be exact.
I ordered a MeanWell LRS-350-24 yesterday; maybe that will help.
Here is the Klippy file with the two instances of lost communication from yesterday. I deleted a few lines from the previous successful print with PLA because of the file size.
klippy 3.log (5.2 MB)
Edit: New PSU same error…
Since you are quite new here. Do you understand the requests from the guys above to be able to help you?
You may read here https://klipper.discourse.group/t/the-dirty-flag-and-the-teams-position.
In the Esoterical’s CANbus guide, he writes in the Getting started section (https://canbus.esoterical.online/Getting_Started.html
There is a known issue with Raspberry Pi operating systems where ‘Bullseye’-based distros (version 6.1.something) and 64-bit systems can cause very strange timing issues, which can lead to ‘Timer Too Close,’ ‘Missed Scheduling,’ or other errors.
I have version 6.1. So I decided to start over and set up a new SD card. No SSD anymore.
It took me the whole weekend to get everything up and running. The biggest problem was flashing the Octopus. I also changed the CANBUS speed to 500k.
I’ll start a print this evening. Hopefully, everything will work, and it was worth the effort.
As of right now i have no “dirty flag”… just installed the bare minimum.
2 Likes
Well, I lied. Klipper is already dirty because of the cartographer. But that’s something i need…
The print wasn’t going to work either: klippy(30).log (2.3 MB) 
When you look at your log:
- The communication gets unstable around 8 seconds before the crash, with a rising error count and invalid bytes
- Invalid bytes usually point to serious errors, like hardware issues or being caused by kernel bugs in versions below 6.6
1 Like
I’m on version 6.12 now.
I just had a crash as I logged into the Pi through SSH to send the command “uname -a”.
Could my Pi be the problem?
klippy(32).log (7.3 MB)
I don’t think it’s an issue with the Pi; I can always access it after the communication error.
Yesterday, I found that my Cartographer is not the one I ordered. I ordered the LIS2DW version, which should have a CAN termination built in, but what I got was the ADXL version. With the ADXL version, you have to solder a connection to terminate the line, so I thought I had found the error and soldered the connection for the CAN termination. Now I have 60 ohms on the CAN line, but the error is still there.
What I haven’t done is replace the Pi, the Cartographer, and the Octopus. But they are all pretty pricey.
I’ll double-check the umbilical cable today; maybe the new cable or the connector is faulty.
I’m so close to switching from CAN to USB.
The print crashed or the RPi crashed?
As always: lost communication to can0
Sorry, I don’t think I specified it well enough.
Did you try:
- Different CAN rates like 500k or 1M?
- Ensuring the same CAN rate is used throughout all settings, i.e., boards and OS
- Replacing the U2C with, e.g., a Canable (if you want to stick to the official Candlelight firmware then avoid STM32G0 or G4 series MCUs) or an Odrive USB to CAN
Before I switched to the new python version I had 1M. Now I’m on 500k.
I followed the esotherical Ganbus guide to set all up. Do I have to do set up the 500k somewhere else?
I already replaced the U2C. No result. Now I run can over the octopus via can bridge mode.
Today I soldered the can cable directly to the EBB36 because I thought the connector might be a problem. Also no success.
Wait what? The EBB36 has a STM32G0B1.
The main Candlelight firmware has STM32G0 or G4 series MCUs not implemented and in open discussion for ages, and it never landed due to apparently unresolved topics.
Clones like BTT or Makerbase have adopted their own interpretation. This does not mean that they are bad. It surely means that the non-STM32G0 or G4 strands are more battle-tested.
The STM32G0 or G4 series support higher data rates, which is no added value for Klipper since it is not supported and not needed. AFAIK, the clone firmware implementations also do not support the CAN FD rates.
Okay, what would you recommend? To be honest, I don’t want to switch from the EBB36.
I just read that the 32-bit OS is better for CANBus because of timing, synchronization, etc.
I installed the newest 64-bit OS, version 6.12. Would it be worth trying the 32-bit version?
Generally, it is a bit of stabbing in the dark. I’d try a different CAN adapter and verify the points above. Maybe a Canable, but not the 2.0 one, as it is again an FD device.
I think I’ve made a little progress:
- Printing with only extruder heating –> OK
- Printing with only bed heating (100°C) and closed chamber –> loosing communication
- printing with only bed heating (100°C) and opened chamber –> OK
–> Seams to be a temperature issue?!
I also ordered a new Cartographer and flashed the appropriate CAN firmware, but it lost communication as well. (closed chamber 100°C bed)
I also changed the cable from the EBB to the probe, but that didn’t help either.
Currently, I’m running the probe in USB mode, and the printer is running.
Looking at the latest log, it seems that the Cartographer MCU temperature is becoming unstable at the same time as RX and TX errors occur. The temperature at which the temperature becomes unstable is around 62-64°C. With USB, it got up to 66°C with no problems.
I’m just not sure if that’s the cause or an effect of the unstable connection.
klippy(41).log (7.9 MB)
beautiful printer, great show, I had problems like that, try reducing the Z motors, you don’t need much, 1.1 is a lot, I think 0.6 for the extruder too, and adjust the pwm timer of the loads according to your electrical network, as when using abs, the headmcu board locked, too much heat for it, I think, and it can lose steps due to high temperature and high accelerations and speed in retraction / extrusion abs temperature table higher and chamber temp makes mcu head extruder high temp, check if it is not too high. Reduce the heater’s PWM power to 0.8 or 0.7, lots of details, anyone can freeze something… hugs… send more pictures
Lots of things with these little boards,
my example
[temperature_sensor head_mcu_temp]
sensor_type: temperature_mcu
sensor_mcu: head
min_temp: 0
max_temp: 80 #too low ?#[temperature_sensor TH_on_M36]
#sensor_type: Generic 3950 #EPCOS 100K B57560G104F
#sensor_pin: head:PA2
#pullup_resistor: 10000 #this need verificação analize circuito
#min_temp: 0
#max_temp: 80 #? toolow?
My Z-steppers are now at 0.8A. The extruder is at 0.5A.
I adjusted the PWM according to my 50 Hz grid frequency.
I changed the controller board to the BTT Kraken.
The weird thing is that after I switched to the Kraken, I couldn’t even home my printer. After connecting the Cartographer via USB, I could print PETG, but ABS didn’t work.
What I also tested:
- 32-bit OS –> Error
- Canable with official candlelight FW –> Error
- Raspberry Pi 4b to Pi 5 –> Error
- changed umbilical cable another time –> Error
I’m slowly running out of options. Everything is new except for the 5V power supply. But I don’t think thats the problem…
What I could do:
- Run the hotend heater over the Kraken
- Run the extruder over the Kraken
I think i may have to switch to USB…
latest log with Pi5:
klippy(47).log (1.9 MB)
Edit: out of curiosity i tried another print without case light and nozzle leds. An it worked. How can these damn nozzle LEDs cause the CAN bus to collapse???
I only set the white leds once at startup. No effects, nothing:
[neopixel xol_leds]
pin: can0: PD3
chain_count: 2
color_order: GRBW,GRBW
initial_RED: 0.0
initial_GREEN: 0.0
initial_BLUE: 0.0
initial_WHITE: 0.8
EDIT2: Nevermind. Its the caselight. I have the daylight on an stick connected to a heater out of the kraken. Can the pwm cause EMI? My umbilical cable is sometimes pretty close to one of the lights.