Communication timeout during probing
I don't understand why this is happening.
Moreover, the connection with the toolboard is not lost, temperatures, and other information are transmitted correctly and without errors.
BTT EBB36 V1.2 , Manta m8p
USB cable - Baseus USB C SUPERVOOC 6.5A 2m, in principle a good cable with an internal mesh screen along the entire length. The first noname cable died after 6 hours of printing.
Maybe there is some script to check the stability of the connection to the toolboard?
27 Replies
probable-pinkOP•2y ago
https://github.com/Klipper3d/klipper/issues/4861
I read this post, but I don't quite understand how to fix this on CB1, because there are no necessary configuration files, or if there are other files that are a replacement, then there are no necessary lines at all.
GitHub
Communication timeout during homing probe (multi-mcu probing) · Iss...
I am running multi-mcu probing in a setup with a couple of separate SAMD21 mcu boards - and occasionally I get a "Communication timeout during homing probe" error during a probe run. USB ...
CB1 uses
/boot/system.cfg for the overlays, but I don't think they are enabled by default. I would reach out to @bttuniversity or @youtian_su for help as maybe the USB ports are causing the issue?probable-pinkOP•2y ago
Disabling HDMI and reducing the speed of movement from 200 to 100 when auto-leveling, I was able to build a map of 20x20 points without any problems, taking into account the triple touch at each point. When hdmi is connected (the usb of touchscreen is disabled at this time), a timeout occurs at about 8-12 points.
and sometimes even when moving to the X or Y limit switch, while the connection with the board is not lost, the temperature and so on are constantly transmitted, and there were no problems during printing, I calmly printed the part for 12 hours.
I would really like to do some kind of usb connection speed test, or a stability test, I think. In Linux CNC it was possible to check delays, but this applied to the ltp port
Side note:
The first noname cable died after 6 hours of printing.That's a clear indication that you do not have appropriate strain relief at the connector. Please fix that, or you can potentially damage the USB connector on the EBB itself. Normally i recommend the 42 as the 36 has a super awkwardly positioned usb connector.
probable-pinkOP•2y ago
[157669.233730] usb 2-1.4: USB disconnect, device number 10
[157669.603617] usb 2-1.4: new full-speed USB device number 11 using ehci-platform
[157669.834599] usb 2-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[157669.834630] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[157669.834640] usb 2-1.4: Product: stm32g0b1xx
[157669.834648] usb 2-1.4: Manufacturer: Klipper
[157669.834655] usb 2-1.4: SerialNumber: btt-manta-m8p
[157669.837760] usb 2-1.2: USB disconnect, device number 9
[157670.195628] usb 2-1.2: new full-speed USB device number 12 using ehci-platform
[157670.430356] usb 2-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[157670.430390] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[157670.430400] usb 2-1.2: Product: stm32g0b1xx
[157670.430408] usb 2-1.2: Manufacturer: Klipper
[157670.430415] usb 2-1.2: SerialNumber: btt-ebb36-12
[266822.257444] usb 2-1.4: USB disconnect, device number 11
[266822.611683] usb 2-1.4: new full-speed USB device number 13 using ehci-platform
[266822.823058] usb 2-1.4: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[266822.823088] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[266822.823099] usb 2-1.4: Product: stm32g0b1xx
[266822.823107] usb 2-1.4: Manufacturer: Klipper
[266822.823114] usb 2-1.4: SerialNumber: btt-manta-m8p
[266822.825702] usb 2-1.2: USB disconnect, device number 12
[266823.179747] usb 2-1.2: new full-speed USB device number 14 using ehci-platform
[266823.410439] usb 2-1.2: New USB device found, idVendor=1d50, idProduct=614e, bcdDevice= 1.00
[266823.410472] usb 2-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[266823.410481] usb 2-1.2: Product: stm32g0b1xx
[266823.410489] usb 2-1.2: Manufacturer: Klipper
[266823.410496] usb 2-1.2: SerialNumber: btt-ebb36-12
Sems all normal, but i'm trying to find a way to test connection
Yes, but there the problem was rather that it was the cheapest possible cable, just for testing, and it may not have died, but I had the same error with the loss of waiting during table calibration. I thought that it had broken because my corrugated channel was broken.
Also
I'm noted
T: Bus=02 Lev=02 Prnt=02 Port=01 Cnt=01 Dev#= 14 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS=16 #Cfgs= 1
P: Vendor=1d50 ProdID=614e Rev=01.00
S: Manufacturer=Klipper
S: Product=stm32g0b1xx
S: SerialNumber=btt-ebb36-12
C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
T: Bus=02 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 13 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=02(commc) Sub=00 Prot=00 MxPS=16 #Cfgs= 1
P: Vendor=1d50 ProdID=614e Rev=01.00
S: Manufacturer=Klipper
S: Product=stm32g0b1xx
S: SerialNumber=btt-manta-m8p
C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=100mA
I: If#=0x0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm
I: If#=0x1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm
So USB speed is only 12mb/s
probable-pinkOP•2y ago
probable-pinkOP•2y ago
So, Data transfer rate via CAN can be 1Mbps, USB connection goes through CDC_ACM , whose speed when using 64 byte chunks is ~400Kbps RX and ~250Kbps TX
@miklschmidt what do you think .
STM32g0b1 only support 12mb speed (Full speed), STM32F4 can do a High Speed...
probable-pinkOP•2y ago
probable-pinkOP•2y ago
That my lattest log
probable-pinkOP•2y ago
So i don't see any problems
probable-pinkOP•2y ago
/home/pi/klipper/scripts/graphstats.py /home/pi/printer_data/logs/klippy.log -m toolboard -o /home/biqu/loadgraph1.png
That's one was generated for toolboard, its just strange error , i don't see any problems in connection
probable-pinkOP•2y ago
https://klipper.discourse.group/t/canbus-communication-timeout-while-homing-z/3741/68
It is strange that this error occurs both in people with CAN and in people with USB, and as a rule this is solved absolutely chaotically.
Klipper
CANBUS Communication timeout while homing Z
Could you explain, how you decide, if a Klipper installation is modified? What should a user of your wonderful SW check, before asking?
probable-pinkOP•2y ago
Stats 278089.9:
toolboard: mcu_awake=0.019 mcu_task_avg=0.000016 mcu_task_stddev=0.000011 bytes_write=67289 bytes_read=126357 bytes_retransmit=9 bytes_invalid=0 send_seq=5584 receive_seq=5584 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=63999496 adj=63999206
Communication timeout during homing probe
Stats 278090.9:
toolboard: mcu_awake=0.019 mcu_task_avg=0.000016 mcu_task_stddev=0.000011 bytes_write=67344 bytes_read=126547 bytes_retransmit=9 bytes_invalid=0 send_seq=5590 receive_seq=5590 retransmit_seq=2 srtt=0.000 rttvar=0.000 rto=0.025 ready_bytes=0 stalled_bytes=0 freq=63999495 adj=63999152
So i don't see any lost bytes and communication problems
I've modified a mcu.py a little, changed TRSYNC_TIMEOUT from 0.0250 to 0.05 and i've successfully build a map 16x16 points
if you are having to modify klipper code you probably want to hop onto their discord and ask about your problems there
rising-crimson•2y ago
I had same issue with MCU timeout when probing, only happened when probing over 300mm/s so I slowed and it was fine then randomly stopped. I didn’t see any communication errors etc just stopped. Finally swapped to new usb3 cable and no issues since.
This is not a great idea. You've doubled the error in Z accuracy when probing.
There should be virtually no delay when using USB
I have never had this problem on my toolboards, so you're most likely doing something wrong somewhere.
probable-pinkOP•2y ago
I do a triple touch at each point to be more precise. But the deviation between the points is around 0.005mm, even after modifying this parameter, but now I don't get this error. For someone on the Klipper forum, this error was solved simply by replacing one board with another, it didn’t work in any other way, even Kevin didn’t know what to do with it.
But i have good cable now, that have excellent communication speed, i've tested it with my ssd.
if the cable was bad, there would probably be data transfer errors. or not ?
Strange!
This means nothing, klipper needs negligible speeds. They’re basically roundingerrors on the usb 2.0 spec. Latency is important though.
probable-pinkOP•2y ago
what does usb 2.0 have to do with it, if the maximum speed of stm32g0b1 is High Speed USB, i.e. 12 Mb/s, and the driver allows you to transfer everything at a speed of about 0.5 Mb/s
Nothing, i was trying to make a point that throughput is a non-issue.
12 Mbps is usb 1.1, highspeed (480 Mbps) is 2.0 btw.
not that it matters
probable-pinkOP•2y ago
I made a mistake in terms, but g01b has Full Speed USB built in, F4 has High Speed built in, but that's not the point. Just judging by the code, if only one MCU is used, then the timer limit will be 0.25, when using two mcu, the limit is 0.025, although it is not clear why the error may at some point just check the limit before the data is resent .
That’s because more than 25ms latency causes sync problems between MCU’s. With a single MCU there’s no such issue.
harsh-harlequin•2y ago
I had the same issue today. I had frequent undervoltage warnings. As I changed the power supply of the pi the problem was gone. Not sure if there could be any correlation
Issues are back:
10:09 Communication timeout during homing probe
10:09 Communication timeout during homing probe
10:09 Communication timeout during homing probe
Setup:
BTT Octopus v 1.1, Superpinda connected to EBB42. EBB42 connected to octopus via USB.
you need to connect the EBB to the PI and not to the Octopus
assuming you use USB
harsh-harlequin•2y ago
My fault. It is connected to the Pi not to the octopus…
probable-pinkOP•2y ago
By the way:) I've updated all, and I have this problem again, in principle, the problem is mainly only in the process of homing. There are 2 problems here 1) Or sometimes a large homing error, 2) Or Communication timeout during homing probe.
But I have a Manta M8P with CB1, I understand that the problem is most likely in CB1 - because. this single-board module is rather weak and perhaps something is missing.
Though I don't understand how it could be missing something when it's sending miserable kilobytes over the wire.
Maybe some microfreeze in the system itself?
If I raise the timer limit again, the timeout problem goes away.
probable-pinkOP•2y ago
Sometimes i see something like this on graphs
