EBB 36 v1.2 pressure advance Timer to close

Also to reinforce @nefelim4ag’s input - see:

Might be or might not be related. YMMV

1 Like

I couldn’t solve this problem today. Thanks a lot for your help, tomorrow I will try to put the 3d printer in order and continue the diagnostics (today the mks servo42d arrived, I decided to work on them after work)

WIsh a nice day! I reworked my Tevo with shielded cable (Profibus) and removed threshold. It didnt helps me :(. But I’m sure it has nothing to do with the cable or its connection. I printed different models in different locations and the stop time is about the same.

1 Like

klippy (4).zip (2.4 MB)

1 Like


klipper sees the EBB, but query says, that no uuids. I read somewhere that this is normal

It would be nice if you would edit messages and append them.
This will highly increase the amount of information that fits on one screen.

Gcode errors: Unknown command "G17’, “G3”, “EXCLUDE_OBJECT_START” are simple.

[gcode_arcs]
# Lower does not make sense,
# I think the radius of a nozzle is a minimal adequate value here.
resolution: .2 
[exclude_object]

About the log above, I saw you have disabled stealthchop.
But the problem remains the same: retry, retry, high RTO, death.

It may be helpful to flash U2C with klipper and configure it as an MCU.
Maybe it will add some useful information to the log.

default qlen 10

You probably want adequate qlen, which is 128 by default and in the docs.
Or something like 32 will also do, for one toolhead.

After reworking line with profibus i have errors without PA. :frowning:
klippy (5).zip (1.1 MB)
So qlen is 128, it not works… waitin for repairing other host (Orange PI ZERO)

Dear nefelim4ag! I read bigtreetech’s manual and found this:


There is configuration for u2c. But in Klipper documentation is 500r bitrate and txquelen is 128, сould this be the cause of an unstable connection, or is it only important to correctly configure the firmware according to the adapter configuration?

Thank you! The reason was my misunderstanding of the CAN diagnostic function. The fact is that the buffer length setting was not applied from the etc/interfaces.d/can0 file. To solve this problem, I had to:

  1. Create
    sudo nano /etc/systemd/network/80-can.link with the following parameters:
[Match]
Type=can

[Link]
TransmitQueueLength=1024
  1. Create
    sudo nano /etc/udev/rules.d/99-canbus.rules
# set tx queue size for canbus
SUBSYSTEM=="net", ACTION=="add|change", KERNEL=="can0" ATTR{tx_queue_len}="1024"

source: klipper_canbus/extras/systemd-networkd.md at main · maz0r/klipper_canbus · GitHub