Is there a way to diagnose CAN cable?

General Discussion
1

Basic Information:

Printer Model: Voron 2.4R2 350^3
MCU / Printerboard: BTT Octopsu Max + Btt EBB CAN SBB2209
Host / SBC BTT Pi
klippy.zip (6.9 MB)

Issue:

Hey, some time ago I started experiencing “MCU ‘mcu’ shutdown: Timer too close” issue. I went thru what I could find on forums and ended up with 3 option: card issue, some strange resource hording process or CAN cable. Unfortunately my knowledge of klipper log analysis is zero :frowning: I hopped someone could help me validate how likely it that I have a broken cable:

  1. I checked system for rouge processes, and it looks fine
  2. I changed nice of klipper process as sugested
  3. I checked queue txqueulen (1024) of can and can speed (1000000). ifconfig show same txqueuelen.
  4. System logs are empty, no errors (especially regarding SD card)

bytes_invalid= is 0 thru all the log. “ip -details -statistic link show can0” showed no errors nor bad packets.

so it’s either something in logs I can’t read (performance hit on system), or broken cable that I have no way to diagnose and will be a really big pain to replace :frowning:

ps. I tried to move / bend can cable in all suspected points, and riding gantry up and down (most errors happened during final down movement of z homing just before printing, however never on other z homings, now it started to happen randomly during printing)

2

I’m not sure which suggestions you are following:

Going over 128 is usually not recommended, and if so, only in well-dosed increments.

TTC errors and their potential solutions are described in Timer too close

Unfortunately, there is no easy way to diagnose this error, as the error itself is completely unrelated to its potential causes.

3

If you suspect the CAN cable, why don’t you describe how you put it together (ie loose wires or a cable designed for the purpose) and post some images of the connectors as well as how you mounted the cable and provided strain relief for it. You should also describe

CAN is very robust but there are a few rules that need to be followed, violations of which can be determined with a description of the set up and seeing how it was implemented.

4

CAN-bus-phyical-layer-debug.pdf

1 Like
5

I’m sure I saw it in some tutorial when I was setting up can. It was like that from day one. Will gladly reduce it :slight_smile:

6

I have a dedicated combo cable from btt. It looks quite robust. It’s plugged to toolhead with screwd element that keeps plug in place, then cable goes along nitinol wire to gantry and then to dragchain. Not many places where it could break apart from spot where it bends to enter dragchain from beneath. I tried to move this wire wherever it has any place to move to trigger this error but without success. I really hope it’s something else and someone here will be able to spot something in the logs :frowning:. I will definitly shorten queue length and go thru mentioned tutorial.

7

Ooo… I definitely have to check that termination. My toolboard uses smallest of all possible jumpers for enabling it :slight_smile:

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.