Infamous "Timer Too Close" on Fluidd Reload

General Discussion
1

Hi

I have an Ender 5 plus with BTT SKR mini E3V3 paired with a raspberry pi 4 8GB and a cartographer 3D. I don’t print super often, maybe have projects once a month.

But since a couple months, I’m really struggling with “Timer Too Close” issues. First time it happened is when I opened up mobileraker on my phone, crashed the mcu ( and the print ). Thought it was a fluke so restarted the print and everything went fine with mobileraker.

Then few days later, same thing, loaded mobileraker, “Timer too close”. now it’s starting to bug me up. Cloned my SD Card to a new one (a U3/V30). Did the same thing.

I thought it was a mobileraker issue that would be fixed in a few updates. So didn’t bother too much and stopped using it. But today, 7 hours into a 16 hour print, loaded fluidd on my mac, “Timer too close” AGAIN…… Next step is reinstalling the os from scratch but I really wonder what would be the issue, I see people running klipper on raspi zero 2w….. which is supposed to be A LOT slower than my raspi 4b 8gb…… So i doubt a reinstall will to the trick….

I don’t know where to look other than that…. I may be looking to buy a USB3 to sata adapter to boot from an SSD, but again… can’t see why i would need to do that when people get away with a raspi zero 2w…..

Any way i can pin point the issue or other logs i should upload?

Thank you in advance!

klippy(5).log.zip (928.8 KB)

2

Weird.
Blindly, I would suggest doing:

~/klippy-env/bin/pip install -r ~/klipper/scripts/klippy-requirements.txt
...
# If this string is present, msgspec is installed; otherwise, it will be installed
Requirement already satisfied: msgspec==0.19.0 in 
...

I guess it is simply because you have enormous bed meshes (one of them has 6000 points).
Frontend upon connection requests klippy state - including config, and those bed meshes.

Received 290591.832955: b'{"id": 4068053584, "method": "objects/subscribe", "params": {"objects": {"gcode": null, "webhooks": null, "configfile": null, "mcu": null, "mcu scanner": null, "gcode_move": null, "print_stats": null, "virtual_sdcard": null, "pause_resume": null, "display_status": null, "gcode_macro CANCEL_PRINT": null, "gcode_macro PAUSE": null, "gcode_macro RESUME": null, "gcode_macro SET_PAUSE_NEXT_LAYER": null, "gcode_macro SET_PAUSE_AT_LAYER": null, "gcode_macro SET_PRINT_STATS_INFO": null, "gcode_macro _TOOLHEAD_PARK_PAUSE_CANCEL": null, "gcode_macro _CLIENT_EXTRUDE": null, "gcode_macro _CLIENT_RETRACT": null, "gcode_macro _CLIENT_LINEAR_MOVE": null, "exclude_object": null, "stepper_enable": null, "tmc2209 stepper_x": null, "tmc2209 stepper_y": null, "tmc2209 stepper_z": null, "tmc2209 extruder": null, "bed_mesh": null, "probe": null, "temperature_sensor cartographer_coil": null, "heaters": null, "scanner": null, "filament_switch_sensor RunoutSensor": null, "temperature_sensor Cartographer_MCU": null, "heater_bed": null, "heater_fan my_nozzle_fan": null, "controller_fan my_controller_fan": null, "fan": null, "gcode_macro BED_MESH_CALIBRATE": null, "gcode_macro START_PRINT": null, "gcode_macro END_PRINT": null, "gcode_macro M600": null, "query_endstops": null, "motion_report": null, "toolhead": null, "extruder": null, "idle_timeout": null, "system_stats": null, "manual_probe": null, "history": null}, "response_template": {"method": "process_status_update"}}}'
Received 290591.839516: b'{"id": 4056548352, "method": "objects/query", "params": {"objects": {"print_stats": null}}}'

Update of the Python/System could also help.

Hope that helps.

3

Hi @devwiz ,

Looking at your config, you have:

[bed_mesh]
...
probe_count: 50, 30

That’s huge for a 360x360mm print area.

Are you sure you need a mesh that dense? I would decrease that to around 10,10 then slowly increase it if you start having first layer inconsistencies.

4

Thank you both for your response.

Thats the thing, i really have trouble with first layer consistencies. sections of the bed are way underextruded and some other i need to bring the flow down to 50%…. Thats why i added a Cartographer3D and brought up the bed mesh that High. I can turn it back down and make some test. But you think the bed mesh would make the mcu “crash” when loading mobileraker and fluidd? As i’m writing this, i can of understand why it would make it crash, i even went WAY higher on probe points and the mcu would crash just after probing the bed when starting to build the bed mesh visualisation. So you might be right, bed mesh probe points to high, I didn’t think it would put that much stress on the pi. Any way, with those probe points, i don,t even get a better first layer…

I will lower the probe points and try it out. Thanks!!!

5

Sorry for the dumb question, but i’m not used to work with python. How would i go about updating it. I’ve read that klipper creates it’s own virtual environment.

System is fully up to date, raspbian bullseye. Maybe i need to update to the new release?

6

Yes, a new release could be a simple solution.

Generally, on Debian systems, it is done with APT: Upgrading RaspberryPi OS from Bullseye to Bookworm - Raspberry Pi Forums
But according to official documentation, it was not supposed to be that way for some reason: https://www.raspberrypi.com/documentation/computers/os.html#upgrade-your-operating-system-to-a-new-major-version

7

Well, bringing down the probe points didn’t prevent the “Timer Too Close” error…. Was printing fine for a couple hours, then went back on my computer to check fluidd, fluidd refreshed and crashed the MCU…..I will make a brand new install of raspbian 32bit and reinstall klipper using KIAUH, let’s hope it fixes it….

klippy(6).log.zip (1.3 MB)

8

You did not remove your existing enormous bed meshes :slight_smile:
(Check your config/logs).

9

Ho you mean even from the printer.cfg, even if its not loaded like the actual bed mesh that the printer is using, it can burden the MCU? I did not expect that.

I will delete them also then. It was from when i was shimming my PEI sheet with blue painters tape to help first layer inconsistencies. Still, I’m preparing a new SD card with a fresh install of raspberry pi OS Lite pixie (32bit).

Will try to remove de bed mesh and try to crash it before starting another day long print.

10

It does not burden the MCU.
It is decoded and loaded into memory.
It is encoded in JSON and carried over the socket to Moonraker → fluidd (or mainsail).
Without msgspec, it can take some time to encode that and send it over.
That time in your case, about 500ms.
That is enough to make the host deliver things later than it should.

So, the MCU crashed, because it was asked to do things in time, with time that is already in the past.
(You can’t enable your electric kettle a minute ago if I asked you to do that now, you can enable it now or in N time in the future. Same concept with MCU, it can enable a heater or make a stepper step in the future, or now, but not in the past.)

1 Like
11

gotcha, removed them, will restart the print and try to make it fail as much as possible. There’e no more save bed mesh in the config. and only a 10 x 10 adaptive bed mesh. Will report back. Thanks A LOT for your help and detailed explanation.

12

yep, did the trick, no more mcu “Timer Too Close”!!! Thanks a lot! I didn’t think that saving stuff in the config file ( by stuff I mean ginormous bed mesh) would put too much pressure on the cpu. I thought since they we’re not loaded, they would be harmless.

Thanks a lot again!!!

13

If you feel the large mesh gives you better results you could remove the mesh display from the Fluidd dashboard. That would (probably) allow Fluidd to restart without needing to “see” the mesh data.

Don’t forget to mark your issue “solved” in the post above.