# Delta - multi MCU endstop/probe: Communication timeout during homing xxx **URL:** \ **Category:** General Discussion\ **Created:** [June 29, 2022, 10:34am UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305 "2022-06-29T10:34:36Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Strolch](https://avatars.discourse-cdn.com/v4/letter/s/41988e/32.png) [@Strolch](https://klipper.discourse.group/u/Strolch)\ **Post date:** [June 29, 2022, 10:34am UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/1 "2022-06-29T10:34:36Z")
My setup: - **mcu** : Robin Mini - hosting endstops, z-probe and extruder - **supernova** : rp2040 w 3x TMC2209 - hosting stepper\_{a,b,c} - **bluepill** : - hosting ADXL345, MAX31865 - **z-probe** : Precision Piezo Orion This setup immediately leads to “communication timeout during homing” when trying the initial G28. So I moved the endstops over to **supernova** , now at least normal moves are working. However, automatic z-probe still doesn’t work when z-probe is on **mcu**. I always get “Communication timeout during homing probe", no matter if I use ‘[probe]’ or ‘[smart\_effector]’ as probe type. Currently, moving the probe over to **supernova** is a no-go because of cabeling problems. @koconnor wrote > [@Single MCU vs 3xMCU step rates on a Delta](https://klipper.discourse.group/t/single-mcu-vs-3xmcu-step-rates-on-a-delta/2636/4): > > No - multi-mcu-homing works fine in that case. The current limitation is that you can’t have multiple Z MCUs and a separate endstop/probe MCU. If all the Z steppers are on one MCU then you can have a separate endstop/probe MCU. -Kevin ---
**Author:** ![Strolch](https://avatars.discourse-cdn.com/v4/letter/s/41988e/32.png) [@Strolch](https://klipper.discourse.group/u/Strolch)\ **Post date:** [July 2, 2022, 2:56pm UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/2 "2022-07-02T14:56:13Z")
Did some further investigation. It looks like a bug(?) in klipper. On start, Klipper creates the supernova mcu configuration with endstop objects for each stepper. ```auto MCU_endstop: MCU mcu, pin PA11, OID 1 MCU_trsync: MCU mcu, OID 2 MCU_endstop: MCU supernova, pin gpio0, OID 4 MCU_trsync: MCU supernova, OID 5 MCU_endstop: MCU supernova: add_stepper: stepper stepper_a MCU_endstop: MCU supernova, pin gpio7, OID 7 MCU_trsync: MCU supernova, OID 8 MCU_endstop: MCU supernova: add_stepper: stepper stepper_b MCU_endstop: MCU supernova, pin gpio9, OID 10 MCU_trsync: MCU supernova, OID 11 MCU_endstop: MCU supernova: add_stepper: stepper stepper_c ``` It also creates the probe object for mcu ‚mcu‘. However, when the mcu ‚mcu‘ gets created also endstop objects for mcu:stepper\_a,b,c are created and a phantom probe (oid=12) on Supernova. ```auto MCU_endstop: MCU mcu: add_stepper: stepper stepper_a MCU_endstop: MCU mcu: add_stepper: stepper stepper_a: append trsync for MCU supernova MCU_trsync: MCU supernova, OID 12 MCU_endstop: MCU mcu: add_stepper: stepper stepper_b MCU_endstop: MCU mcu: add_stepper: stepper stepper_c MCU_endstop: MCU mcu: config_endstop oid=1 pin=PA11 pull_up=0 MCU_trsync: MCU mcu, config_trsync oid=2 Configured MCU 'mcu' (1024 moves) Configured MCU 'bluepill' (1024 moves) mcu 'bluepill': got {'oid': 1, 'clock': 1380777748, 'query_ticks': 484, 'next_sequence': 0, 'buffered': 0, 'fifo': 255, 'limit_count': 0, '#name': 'adxl345_status', '#sent_time': 176531.553619945, '#receive_time': 176531.554013019} MCU_endstop: MCU supernova: config_endstop oid=4 pin=gpio0 pull_up=1 MCU_trsync: MCU supernova, config_trsync oid=5 MCU_endstop: MCU supernova: config_endstop oid=7 pin=gpio7 pull_up=1 MCU_trsync: MCU supernova, config_trsync oid=8 MCU_endstop: MCU supernova: config_endstop oid=10 pin=gpio9 pull_up=1 MCU_trsync: MCU supernova, config_trsync oid=11 MCU_trsync: MCU supernova, config_trsync oid=12 ``` Attached are klippy.log, running `G28;G0 Z10;PROBE`. When probing the phantom probe is responsible for the timeout. [Testprobe.log.txt](https://klipper.discourse.group/uploads/short-url/A0ZUgwxwONRuELNgaNjPj2bvmdv.txt) (123.4 KB) [mcu\_patches.diff.txt](https://klipper.discourse.group/uploads/short-url/8CuBSxaHR4xjy6doxg0FGeMQRlO.txt) (4.4 KB) ---
**Author:** ![koconnor](https://avatars.discourse-cdn.com/v4/letter/k/aca169/32.png) [@koconnor](https://klipper.discourse.group/u/koconnor)\ **Post date:** [July 3, 2022, 4:08pm UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/3 "2022-07-03T16:08:15Z")
I’m not sure what the cause of the problem is. However, the round-trip-time to your main mcu is very high (an `srtt` of 10ms). That could cause issues as there is only 25ms total time permitted between mcu acknowledgements. Also, it’s unclear what type of host machine you are using. Consistent scheduling latency of the host is also critical for good multi-mcu homing/probing. -Kevin ---
**Author:** ![Strolch](https://avatars.discourse-cdn.com/v4/letter/s/41988e/32.png) [@Strolch](https://klipper.discourse.group/u/Strolch)\ **Post date:** [July 3, 2022, 5:07pm UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/4 "2022-07-03T17:07:50Z")
Host is a RPi 4b. IMHO the problem is the phantom device which is created during setup. ```auto MCU_endstop: MCU mcu: add_stepper: stepper stepper_a File "/home/debian/klipper/klippy/reactor.py", line 310, in _dispatch_loop timeout = self._check_timers(eventtime, busy) File "/home/debian/klipper/klippy/reactor.py", line 156, in _check_timers t.waketime = waketime = t.callback(eventtime) File "/home/debian/klipper/klippy/reactor.py", line 48, in invoke res = self.callback(eventtime) File "/home/debian/klipper/klippy/klippy.py", line 176, in _connect self.send_event("klippy:mcu_identify") File "/home/debian/klipper/klippy/klippy.py", line 264, in send_event return [cb(*params) for cb in self.event_handlers.get(event, [])] File "/home/debian/klipper/klippy/extras/probe.py", line 317, in _handle_mcu_identify self.add_stepper(stepper) File "/home/debian/klipper/klippy/mcu.py", line 164, in add_stepper for line in traceback.format_stack(): MCU_endstop: MCU mcu: add_stepper: stepper stepper_a: append trsync for MCU supernova MCU_trsync: MCU supernova, OID 12 MCU_endstop: MCU mcu: add_stepper: stepper stepper_b ``` handle\_mcu\_identify creates steppers on mcu and a probe located on supernova. ---
**Author:** ![Strolch](https://avatars.discourse-cdn.com/v4/letter/s/41988e/32.png) [@Strolch](https://klipper.discourse.group/u/Strolch)\ **Post date:** [July 6, 2022, 11:32am UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/5 "2022-07-06T11:32:13Z")
@koconnor Fixed it by setting `TRSYNC_TIMEOUT = 0.05` in mcu.cfg. ---
**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:** [September 4, 2024, 11:23am UTC](https://klipper.discourse.group/t/delta-multi-mcu-endstop-probe-communication-timeout-during-homing-xxx/3305/6 "2024-09-04T11:23:57Z")