Printer Model: Tevo Tornado
MCU / Printerboard: MKS GEN L v1.0
Host / SBC OrangePI One
klippy.log
klippy (2).zip (1.2 MB)
During printing, a shutdown occurs with the Timer to close error. It’s strange that this error only occurs when using PA.
Make sure to use the same CAN speed everywhere and also to have set up your interfaces according to CANBUS - Klipper documentation, particularly the txqueuelen setting. (Ref. to CANBUS Troubleshooting - Klipper documentation)
Dear Sineos! Thank You for replying!.
In my settings i used 500K bitrate (It is configuration of EBB bin, can0 file and 80can-network file.
txqueuelen setup is 2048.
This is definitely CAN releated issue.
b'Got error -1 in can write: (105)No buffer space available'
Stats 2995.7: gcodein=0 mcu: mcu_awake=0.108 mcu_task_avg=0.000272 mcu_task_stddev=0.000283 bytes_write=356244 bytes_read=117725 bytes_retransmit=9 bytes_invalid=0 send_seq=9148 receive_seq=9148 retransmit_seq=2 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=43 upcoming_bytes=591 freq=15999854 canstat_EBBCan: bus_state=active rx_error=0 tx_error=0 tx_retries=0 EBBCan: mcu_awake=0.021 mcu_task_avg=0.000013 mcu_task_stddev=0.000022 bytes_write=347052 bytes_read=139879 bytes_retransmit=109600 bytes_invalid=0 send_seq=8229 receive_seq=8226 retransmit_seq=8228 srtt=0.003 rttvar=0.002 rto=0.025 ready_bytes=479 upcoming_bytes=0 freq=63997740 adj=63995994 heater_bed: target=85 temp=85.0 pwm=0.016 sd_pos=129157 sysload=0.08 cputime=85.446 memavail=858300 print_time=2864.972 buffer_time=2.874 print_stall=0 extruder: target=230 temp=230.1 pwm=0.465
b'Got error -1 in can write: (105)No buffer space available'
Stats 2996.7: gcodein=0 mcu: mcu_awake=0.108 mcu_task_avg=0.000272 mcu_task_stddev=0.000283 bytes_write=358355 bytes_read=117967 bytes_retransmit=9 bytes_invalid=0 send_seq=9183 receive_seq=9183 retransmit_seq=2 srtt=0.003 rttvar=0.000 rto=0.025 ready_bytes=48 upcoming_bytes=1136 freq=15999853 canstat_EBBCan: bus_state=active rx_error=0 tx_error=0 tx_retries=0 EBBCan: mcu_awake=0.021 mcu_task_avg=0.000013 mcu_task_stddev=0.000022 bytes_write=347675 bytes_read=140054 bytes_retransmit=110526 bytes_invalid=0 send_seq=8240 receive_seq=8236 retransmit_seq=8237 srtt=0.003 rttvar=0.002 rto=0.800 ready_bytes=49 upcoming_bytes=2205 freq=63997740 adj=63996288 heater_bed: target=85 temp=85.0 pwm=0.069 sd_pos=130108 sysload=0.08 cputime=85.516 memavail=858300 print_time=2866.702 buffer_time=3.603 print_stall=0 extruder: target=230 temp=230.1 pwm=0.440
...
MCU 'EBBCan' shutdown: Timer too close
clocksync state: mcu_freq=64000000 last_clock=165266030077 clock_est=(2962.779 163162631480 63997740.349) min_half_rtt=0.000185 min_rtt_time=2887.262 time_avg=2962.779(891.560) clock_avg=163162631480.531(57057816783.416) pred_variance=12552893.820 clock_adj=(279.606 63997100.546)
Dumping serial stats: bytes_write=347733 bytes_read=140143 bytes_retransmit=110717 bytes_invalid=0 send_seq=8241 receive_seq=8239 retransmit_seq=8240 srtt=0.003 rttvar=0.002 rto=1.600 ready_bytes=2202 upcoming_bytes=0
...
RTO is high, bytes retransmitted is increasing.
There is no information about your setup, so it is hard to guess, but:
The queue length of 2048 is too much anyway, which will only lead to high buffer and retransmit times in case of retransmission.
About why, there is an issue with transmission - I don’t know.
It maybe helpful to add information about your CAN bridge.
In addition, the log even shows bytes_invalid, which may point to a Kernel issue. Try upgrading to a Kernel >= v6.6 and make sure you CAN adapter is using a recent firmware.
Also, review your wiring and connectors.
may be i need to remove hub from my topology, then use micro USB?
Try it. USB-Hubs can be a salvation or a curse.
Generally speaking, your CAN setup seems not stable and it could as well be missing termination, bad cables, bad connectors, bad adapter firmware etc.
if i remove option PA, error is gone… strange things
i get u2c firmware from this repository before setting up EBB.
This could be related to the “stress” and amount of data going to the toolboards. It is absolutely possible that it made the error just less frequent with this.
@Esoterical’s stuff is good, and the firmware should be OK.
I use cable with no shield, but in my exp, i have no such EMF with my 3d printer… I use the insulated balcony of the apartment as a room. I don’t have a ground wire here, just 220 volts without a ground connection. Could this be the reason?
I see in this sketch that you close both ends with a 120R resistor, isn’t this supposed to be just one one side of the bus?
I am not a specialist, but this catched my eye…
Regards,
M
Both ends of the bus need to be terminated with 120 Ω. This results in an overall impedance of 60 Ω, as per the applicable CAN bus standard. For more information, see CAN Basics
you’re right… my bad
reworked cable with shield. but it not twisted wire. Not works. Stops the same.
It would be nice if you could describe how power is connected and where the GND cables go.
Also, it would be nice if you could add updated logs each time when you make a change and reproduce.
But maybe right now it does not make a lot of sense.
My hypothesis is that PA cause fast motor movements, which in the end, causes excessive current on the GND line.
Which in the end could cause EMI and/or communication issues.
There should be a good enough power connection between EBB and U2C.
Maybe an increase of power voltage could decrease the current that goes back from EBB.
If you flash U2C with klipper and configure as MCU.
Most probably in the logs you will see a TX errors to the EBB.
You can check that hypothesis if you want.
Anyway, I think it looks like an electrical issue.
So, Electric schemes and photos of wiring and connections could help.
Also, maybe it would be just enough to not use stealthChop:
[tmc2209 extruder]
uart_pin = EBBCan: PA15
run_current = 0.650
stealthchop_threshold = 999999
Both Spread and Stealth use sort of PWM signal to control the motor.
But stealth are more aggressive, and try to work as voltage source.
Which I would expect to make a higher frequency and more noisy noise if it is applicable.
Spread on other hand, should try to balance motor current inside the target boundaries, and I want to believe that it should create less noise in the end.
The shield should be connected to the ground on one end, probably around U2C.
I’m not sure if it can help, with this specific issue.
It would decrease the EMI observed outside, but probably has a negligible impact on the noise inside.
Anyway, there should be a scheme and photos for that.