# Timer too close, yet another. Pretty sure this is a bug **URL:** \ **Category:** General Discussion\ **Created:** [February 14, 2024, 9:46pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115 "2024-02-14T21:46:32Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Arakon](https://avatars.discourse-cdn.com/v4/letter/a/f1d935/32.png) [@Arakon](https://klipper.discourse.group/u/Arakon)\ **Post date:** [February 14, 2024, 9:46pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/1 "2024-02-14T21:46:32Z")
### Basic Information: Printer Model: VzBot235 MCU / Printerboard: SKR 3, EBB36 `klippy.log` [klippy(2).log](https://klipper.discourse.group/uploads/short-url/b0gCqH9ymOBOE6xvEXwt3tUMUHc.log) (5.8 MB) ### Describe your issue: Getting random “Timer too close” only when meshing the bed or homing. I’m very sure that there’s a bug with the canbridge code or something, because: - Exact same setup, using an RP2040 Zero as canbridge with a TJA1051 transceiver: Zero issues. - Exact same setup, using an USB candlelight canbus adapter: Zero issues. - Exact same setup, but now using the SKR3 as a canbridge: Repeated issues. - Zero lost packages, zero retransmitted bytes, all hardware is basically snoring during this, then suddenly error. - Several prints once past the probing/homing stage: Zero issues during print, when speed and amount of controlled steppers is much higher ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/e/e595c0ea7fe98e677aadb73769cf550c2badd599.png) The little bump in the Klipper Load graph is when it was running a bed mesh. CAN speed is 1M, twisted wire. There’s no reason why it would suddenly repeatedly error out when only the CAN MCU changes, since the overall system load hasn’t changed, and the H723 has more than enough resources to easily handle this. ---
**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:** [February 14, 2024, 10:14pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/2 "2024-02-14T22:14:21Z")
Does it appear to happen with a clean Klipper install? ```auto ... Git version: 'v0.12.0-102-g9f41f53c-dirty' ... Git version: 'v0.12.0-104-g1b24f6a2-dirty' ... ``` Does it work with the genuine `BED_MESH_CALIBRATE` ? (Note: Adaptive Mesh is now provided by Klipper) * * * BTW: The printer.cfg appears to unstructured. Additional macros just put at random points. What I mean: It starts with `[stepper_extruder]`, then `[tmc2209_extruder]`, the `[stepper_x]`, then various macros (all of need?), then some other setup essentials, then `[stepper_y]`, `[stepper_z]`, then some other essentials, then `[tmc2209 stepper_x]` (now?), `[tmc2209 stepper_y]` and `[tmx2208 stepper_z]` (are you sure about the 2208?, maybe it’s the culprit). It’s hard for a supporter to keep track… ---
**Author:** ![Arakon](https://avatars.discourse-cdn.com/v4/letter/a/f1d935/32.png) [@Arakon](https://klipper.discourse.group/u/Arakon)\ **Post date:** [February 14, 2024, 10:27pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/3 "2024-02-14T22:27:54Z")
No idea why it would claim to be dirty, the install is fairly fresh, directly off the stock github, and it’s not reading as dirty in the UI, either. ![image](https://global.discourse-cdn.com/free1/uploads/klipper/original/2X/4/45775138f666fbec523651657a12620a584f6b26.png) There are no random macros, they’re in seperate files, all which are loaded via [include] at the beginning of the config. And yes, all needed. And yes, the 2208 is correct. It even happens when simply homing, no bed mesh calibration started at the time. None of your points would explain why it fails ONLY in canbridge mode on the SKR3, and never in canbridge mode with the RP2040 or with an USB CAN adapter. The config is exactly the same. ---
**Author:** ![flowerysong](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/flowerysong/32/10214_2.png) [@flowerysong](https://klipper.discourse.group/u/flowerysong)\ **Post date:** [February 14, 2024, 10:44pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/4 "2024-02-14T22:44:40Z")
The UI does show it as dirty, it just doesn’t display it exactly the same way. You’ve added three files that are not part of Klipper and could be doing almost anything. While it’s not **necessarily** related to your problem it’s best to test with unmodified Klipper. ---
**Author:** ![limefrog](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/limefrog/32/9762_2.png) [@limefrog](https://klipper.discourse.group/u/limefrog)\ **Post date:** [February 14, 2024, 10:49pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/5 "2024-02-14T22:49:07Z")
Not sure if this could apply here, but what [burned](https://klipper.discourse.group/t/strange-behavior-on-xy-movement-after-update/13499) me and drove me crazy: Is the firmware on the SKR3 compiled for the correct crystal frequency? ---
**Author:** ![Arakon](https://avatars.discourse-cdn.com/v4/letter/a/f1d935/32.png) [@Arakon](https://klipper.discourse.group/u/Arakon)\ **Post date:** [February 14, 2024, 11:20pm UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/6 "2024-02-14T23:20:11Z")
Crystal frequency is correct, yes. The three files are part of the autotune script (currently not being called by Klipper at all) and gcode\_shell\_command, which is very common. Again, these are always active with both the SKR in canbridge mode and another method of connecting CAN, so if they were interfering, they’d do that in both cases. I switched to the USB CAN board again now (since I kinda need a working printer), and it instantly works fine again, two full mesh runs with not a single hickup. [klippy(3).log](https://klipper.discourse.group/uploads/short-url/iHMVc08fF2QGUBaeAqhkB5JWkqq.log) (372.9 KB) ---
**Author:** ![lucan07](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@lucan07](https://klipper.discourse.group/u/lucan07)\ **Post date:** [February 15, 2024, 12:18am UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/7 "2024-02-15T00:18:25Z")
A debian bug has crept in some distros that should have been fixed in bookworm 11/12/23, it caused problems with /dev/serial creations may be connected just trying out on oct pro h723 now. ---
**Author:** ![lucan07](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@lucan07](https://klipper.discourse.group/u/lucan07)\ **Post date:** [February 15, 2024, 1:13am UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/8 "2024-02-15T01:13:05Z")
just spotted this may be relevant late now will look tomorrow [https://youtu.be/UNGrYuZdwXk?si=OYGQo49gHJZRZilN](https://youtu.be/UNGrYuZdwXk?si=OYGQo49gHJZRZilN) ---
**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:** [February 15, 2024, 6:43am UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/9 "2024-02-15T06:43:32Z")
> [@lucan07](#): > > just spotted this may be relevant late now will look tomorrow [https://youtu.be/UNGrYuZdwXk?si=OYGQo49gHJZRZilN](https://youtu.be/UNGrYuZdwXk?si=OYGQo49gHJZRZilN) See my answer at ['EBBCan': Unable to connect - After FW updates - #10 by Sineos](https://klipper.discourse.group/t/ebbcan-unable-to-connect-after-fw-updates/14107/10). Again, unrelated to this kind of error. > [@Arakon](#): > > None of your points would explain why it fails ONLY in canbridge mode on the SKR3, and never in canbridge mode with the RP2040 or with an USB CAN adapter. The config is exactly the same. This is an [error](https://klipper.discourse.group/t/timer-too-close/6634) due to timing mismatches between host and board. Even the slightest change in timing behavior can provoke this error. Unofficial modules MAY lead to such and are definitively a reason not to look further into such reports as it may be a total waste of time when finally the error is caused by such modifications. ---
**Author:** ![lucan07](https://avatars.discourse-cdn.com/v4/letter/l/3be4f8/32.png) [@lucan07](https://klipper.discourse.group/u/lucan07)\ **Post date:** [February 15, 2024, 8:41am UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/10 "2024-02-15T08:41:43Z")
got email late on phone got you mixed up with a discourse convo, but that bug did tke out my EBB42 after an update, my octopus pro h723 still showing as can adapter, but EBB42 no longer found. ---
**Author:** ![system](https://global.discourse-cdn.com/free1/uploads/klipper/original/1X/64419bf2aac6639e6ef5cef200dcd456b0a01ac3.png) [@system](https://klipper.discourse.group/u/system)\ **Post date:** [April 15, 2024, 8:41am UTC](https://klipper.discourse.group/t/timer-too-close-yet-another-pretty-sure-this-is-a-bug/14115/11 "2024-04-15T08:41:52Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.