# Communication timeout during **URL:** \ **Category:** General Discussion\ **Created:** [July 26, 2023, 3:49pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652 "2023-07-26T15:49:32Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 26, 2023, 3:49pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/1 "2023-07-26T15:49:32Z")
### Basic Information: Printer Model: Voron 2.4 MCU / Printerboard: Octopus, Canable, EBB36 [klippy.log](https://klipper.discourse.group/uploads/short-url/yQzEWknP7kgUuru3X5bsRK8nvE7.log) (1.3 MB) Recently reflashed my pi, eb36, and octopus. I’m getting pretty frequent communication timeout during homing errors. I’m using a cannable for my toolhead, just usb for the octopus. Issue comes up about once every other print I want to say? Always during qgl or mesh leveling. I’m running 500,000 bitrate on the canbus, terminating resistors, a twisted wire of a standard length for a 2.4 300mm with cable chains. Any ideas what I can do to get this reliable again? ---
**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\ **Post date:** [July 26, 2023, 4:21pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/2 "2023-07-26T16:21:33Z")
Please have a look on these: > [@Timeout with MCU / Lost communication with MCU](https://klipper.discourse.group/t/timeout-with-mcu-lost-communication-with-mcu/6639): > > Timeout with MCU / Lost Communication with MCU Background This error occurs when the Klipper host receives no response from a connected MCU to its regular “heartbeat” or other command messages for several seconds. It often appears in conjunction with the [Got EOF when reading from device](https://klipper.discourse.group/t/got-eof-when-reading-from-device/6638/1) error. warning Important: Klipper only detects the symptom - a communication loss. It is not capable of determining the root cause, which may lie outside of Klipper’s control (e.g., hardware faults, power i… > [@Mcu: Serial connection closed / Timeout on connect / Wait for identify\_response](https://klipper.discourse.group/t/mcu-serial-connection-closed-timeout-on-connect-wait-for-identify-response/6645): > > mcu: Serial connection closed / Timeout on connect / Wait for identify\_response Background The printer-board / MCU did not respond to the connection attempt of the Klipper Host until finally the serial connection timed out and was closed. Often, these 3 errors will go hand in hand in the klippy.log Reasons Hardware issues between the board and the SBC, e.g. USB port, USB cable etc Wrong parameters during make menuconfig when building the firmware for the board Firmware not correctly flashed to… ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 26, 2023, 4:59pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/3 "2023-07-26T16:59:09Z")
Hi, I didn’t find any shorts, all my connectors are looking fine, and the printer is able to print for hours at a time so I don’t think there’s any problems in `make menuconfig`. The issue comes up when the heaters are off so I don’t think it’s a main power supply issue. The printer also stays on and I’m able to move the toolhead after one of these errors. Klipper isn’t shutting down, it’s just canceling the probing move. Charles ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 26, 2023, 5:12pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/4 "2023-07-26T17:12:33Z")
See [Search results for 'timeout homing' - Klipper](https://klipper.discourse.group/search?q=timeout%20homing) There are various reports with different solutions. Maybe on fits your case. ---
**Author:** ![ogmaker](https://avatars.discourse-cdn.com/v4/letter/o/43a26b/32.png) [@ogmaker](https://klipper.discourse.group/u/ogmaker)\ **Post date:** [July 26, 2023, 9:17pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/5 "2023-07-26T21:17:26Z")
There has been considerable discussion of this issue in the github issues list. Most people have resolved it by running bitrate at 1M (1000000), setting buffer to 1024, and failing that, changing to 32-bit version of Bullseye on their pi. It can be tough to chase down. I also personnally mitigated the problem on my 2.4 by not running loads of RGB leds via CANbus while probing/QGL. I’m running pi4, Octopus 1.0 in bridge mode, and Fly SB2040. ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 27, 2023, 7:02am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/6 "2023-07-27T07:02:02Z")
I see in one of these threads, Kevin refers to the srtt, rttvar, and rto values, but I can’t find any information about what units these are in or what they are. When the timeout happens these values appear to be: srtt=0.001 rttvar=0.000 rto=0.025 Which seems pretty low given the number of significant figures logged, regardless of what the units are. Nonetheless, is there anywhere that details what all the items in the log are and their units? ---
**Author:** ![Maturity](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/maturity/32/287_2.png) [@Maturity](https://klipper.discourse.group/u/Maturity)\ **Post date:** [July 27, 2023, 3:42pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/7 "2023-07-27T15:42:11Z")
I feel your pain, I had a similar problem and improved, but did not fix things by the following: -updated the communications speed from 500K to 1M -increased the canbus transmit buffer size in Linux -stopped any neopixel updates when probing I tried basically the same config with a Pi3B+, PiZero2W and an i5 and oddly enough the Pi Zero seemed to not exhibit the problem (huh??). My solution now is to just run the probe connection directly back to the Octopus. It seemed to be some timing issue between the probe detecting and Klipper coordinating it with the z movement. I should add that I tried both an EBB42 and a FLY-SHT42 and with the SHT42 connected via a USB CAN adapter and directly to the Octopus pro CAN connector and the result was the same. ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 27, 2023, 5:31pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/8 "2023-07-27T17:31:16Z")
> [@charlespick](#): > > When the timeout happens these values appear to be: > > srtt=0.001 rttvar=0.000 rto=0.025 I’m not an expert on these numbers, but they look similar to the values in my logs, so likely not the issue’s root cause. ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 27, 2023, 7:23pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/9 "2023-07-27T19:23:51Z")
I was able to get the timeout to occur by bed probing twice in a row, failed about halfway through the second run. I ran the M112 right after and exported the log but I have no idea how to read the log. Can someone tell me if there’s reordered messages or lost messages here? [klippy shutdown after failure.log](https://klipper.discourse.group/uploads/short-url/8eV9HNyxrWIfSNEfJYk9eonaxZj.log) (284.7 KB) Thanks, Charles ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 27, 2023, 9:05pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/10 "2023-07-27T21:05:22Z")
If you don’t mind checking for me, how many bytes\_invalid do you get during a sequence of 75 probes or so? I would assume 0 would be ideal but maybe it’s normal to have some? ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [July 28, 2023, 12:12am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/11 "2023-07-28T00:12:36Z")
See [CANBUS Troubleshooting - Klipper documentation](https://www.klipper3d.org/CANBUS_Troubleshooting.html) . Your log indicates you have an incrementing `bytes_invalid` counter. That is an indicator that something on the canbus is reordering packets (either the canbus adapter or the linux kernel). This must be fixed - the printer will continue to be unstable until it is fixed. -Kevin ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 28, 2023, 12:45am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/12 "2023-07-28T00:45:28Z")
Hi Kevin, When it says 1. Some Linux kernel builds for embedded devices have been known to reorder CAN bus messages. It may be necessary to use an alternative Linux kernel or to use alternative hardware that supports mainstream Linux kernels that do not exhibit this problem. what builds are susceptible to this? I am running `Debian GNU/Linux 11 (bullseye)` (64bit) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [July 28, 2023, 1:55am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/13 "2023-07-28T01:55:42Z")
> [@charlespick](#): > > what builds are susceptible to this? I don’t know. The kernels for embedded devices are all over the place. To the best of my knowledge the mainstream [kernel.org](http://kernel.org) kernels don’t have this severe CAN bus networking bug (though I’ve never explicitly tested it). I haven’t seen the issue on my devices (standard rpi kernels). -Kevin ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 28, 2023, 2:06am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/14 "2023-07-28T02:06:13Z")
This is different from the kernal _version_ right? How do I tell what build I’m using? I flashed RpiOS using Raspberry Pi Imager. I’m going to try connecting the usb cables to another computer, although that’ll be a vm which might introduce other issues. Never hurts to try ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 28, 2023, 3:10am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/15 "2023-07-28T03:10:32Z")
Well, that didn’t work. The communication timeout happens almost immediately when running klipper in debian with python3 in a vmware vm on a m1 macbook, plus an additional usb hub and new cables. That’s alot of different pieces so I’m not sure what is causing the problem. Interestingly however, when running in this setup, there are no bytes\_invalid, even during the short time when the probe function is running. Does this indicate a problem with the host OS on my pi, or the usb cables going to the octopus/canable? [klippy-VM-Debian-Python3.log](https://klipper.discourse.group/uploads/short-url/jakA50pYsRqFEZ8foeGpDGI45z5.log) (263.9 KB) ---
**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\ **Post date:** [July 28, 2023, 5:01am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/16 "2023-07-28T05:01:42Z")
> [@charlespick](#): > > The communication timeout happens almost immediately when running klipper in debian with python3 in a vmware vm Running Klipper in a VM is not supported, and errors like such are to be expected. See [Running Klipper in a Virtual Machine (VM)](https://klipper.discourse.group/t/running-klipper-in-a-virtual-machine-vm/6325) FWIW there are multiple reports that a 32bit Kernel works better than a 64bit one. ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 28, 2023, 5:17am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/17 "2023-07-28T05:17:41Z")
I see… I’ve never had issues running audio software in vmware, (I have in other hypervisors) but I guess the proof is in the pudding. Next up I was going to try 32bit mainsailos instead of building my image myself. Will report back on that. Still really curious if the log tells you about the mcu latency though, and if so, how you can read it. ---
**Author:** ![EddyMI3D](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/eddymi3d/32/1981_2.png) [@EddyMI3D](https://klipper.discourse.group/u/EddyMI3D)\ **Post date:** [July 28, 2023, 5:54am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/18 "2023-07-28T05:54:25Z")
Audio software is a different pair of shoes. There the stream is just pushed out or sucked in. With 3d printing things are time sensitive. The host has to react to occasions in a very short time. The more things you have between the hardware and the managing software, the greater the risk that the data comes in too late for a proper process. ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [July 28, 2023, 6:26am UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/19 "2023-07-28T06:26:31Z")
While this is getting pretty off topic, DAWs often recommend against running in a VM for the same reasons as Klipper. Despite this, I was running Ableton in a Windows VM for quite a while and never had an issue with MIDI timing. I’m doing more research about it and it appears as if the implementation for virtualization on Apple Silicon isn’t as good at timing as VMware’s Intel hypervisor. VMware actually has many features explicitly for latency and timing sensitive tasks across their various products but it appears as if the Apple Silicon version of Fusion has none of them now. For example you used to be able to enable " Scheduling Affinity" to ensure that the CPU core was always available to the VM, and only that VM. I would’ve expected Klipper to work in this scenario. ---
**Author:** ![charlespick](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/charlespick/32/610_2.png) [@charlespick](https://klipper.discourse.group/u/charlespick)\ **Post date:** [August 2, 2023, 10:54pm UTC](https://klipper.discourse.group/t/communication-timeout-during/9652/20 "2023-08-02T22:54:37Z")
Adding to the reports that a 32bit kernal on a raspberry pi seems to be just better. Testing was done on another pi with different cables so now it’s time to reflash the pi inside my printer and go from there. [Next page](https://klipper.discourse.group/t/communication-timeout-during/9652.md?page=2)