Communication timeout during homing

[humble merlin]

So getting this awful annoying fault quite regular atm.
Faults on probing Z with Beacon. Happens 1 in every 2 Z probes. Supper annoying. The beacon seems to be working fine I can get it to z tilt and mesh but then the next job there is 50/50 itl throw this .
Changed to running direct 5v to the Pi with the 4 gpio pins, 15a available.
Tried unplugging the nozzle cam and got no difference.

Happens on both my printers with beacon, not sure what to do next. Any help appreciated

[sick light]

Started having this issue as well. Swapped new cable and new beacon, still having the same issue.

[humble merlin]

Has been happening on both my printers since I swapped to Beacon,

[sick light]

It was working fine for the past few months, the issue started few days ago.

[next plinth]

Also having this issue....

Any fix know?

[next plinth]

Anyone know where to adjust the time after which an error is given?

[ruby needle]

Pretty sure that isn't adjustable and is in the klipper source code

[next plinth]

Gasoline it is then..

[humble merlin]

I fixed it by getting rid of my nozzle cam. seems like a Pi3 isnt powerful enough for both Beacon and a Camera.

either or works fine on its own

[next plinth]

where can i find the TRSYNC_TIMEOUT in ratos?

[ruby needle]

https://klipper.discourse.group/t/allow-changing-trsync-timeout-in-printer-cfg-or-permanently-change-it-to-0-05/10467

[next plinth]

I found this but i could not find any of the same functions.
/usr/share/klipper/klippy/mcu.py

if it put it in the config file like this:

[mcu]
TRSYNC_TIMEOUT 0.050

its not acepted

[ruby needle]

it is changing it in the actual klipper code - nothing to do with ratos
https://github.com/rootiest/zippy-klipper_config/blob/master/scripts/mcu_timing.sh#L68

[next plinth]

ahh okay thanks

[rough sandal]

Sorry for necrobumping this, but since this comes high up when searching for the issue I thought I'd share my solution in this thread. Instead of patching mcu.py, which is annoying and breaks updates, you can use some Jinja2 hackery to update the variable via a delayed_gcode macro:

[delayed_gcode _FIX_TRSYNC_TIMEOUT]
initial_duration: 0.00001
gcode:
    {% set builtins = printer.__getitem__.__globals__["__builtins__"] %}
    {% set exec = builtins.exec %}
    {( exec('''
    import mcu
    mcu.TRSYNC_TIMEOUT = 0.05
    ''', {}, {}) or True) and ''}
    RATOS_ECHO MSG="Fixed mcu.TRSYNC_TIMEOUT"

I've used this approach more extensively in this project which allows running arbitrary Python code via Klipper g-codes without modifying Klipper: https://github.com/depau/unklipped/