search

moggieuk / Happy-Hare

MMU software driver for Klipper (ERCF, Tradrack, Prusa)
GNU General Public License v3.0
482 stars 121 forks source link

Timer too close error at Unload sequence #280

Open Ambilights opened 6 months ago

Ambilights commented 6 months ago

I am having an issue where i get "timer too close" at unloading sequence. Print is running fine for a couple of hours with many toolswaps and then suddenly i get this error, always at unloading. I'm running easybrd can on ercf, sb2209 and IDM-scanner on toolhead, U2C-USB. mmu.zip klippy+mmu.log.zip

Marucci87 commented 3 months ago

I shoud add both my pi4 b and pi5 are the 8gb ram versions

igiannakas commented 3 months ago

One more thing to check in general (not specifically for your case but maybe…) is whether you have any neopixel failed to update messages in your klippy log. If you do you need to do this: https://klipper.discourse.group/t/issues-with-45-led-neopixel-chain/4026

d0m1n1qu3 commented 3 months ago

done already 😊

igiannakas commented 3 months ago

Bugger - just had a TTC error again myself. Neopixel code update was done too. I'm using a Pi4b so it shouldn't be that.

I'm suspecting that maybe the LED Effects plug in is tripping it over the edge.

I'll try again without the LED effects plugin enabled. Maybe that is the culprit?

Deadleg commented 3 months ago

I've had it on both a BTT Pi 1.2 and 2.

I noticed that journalctl has a bunch of logs from KlipperScreen with [printer.py:init_temp_store()] - Temp store:. I'm using a Siboor 2.4 kit with a cartographer which isn't picked up by KlipperScreen when it does some initializing. This increases the load on Moonraker and, for me, contributes to TTC. Have created an issue here https://github.com/KlipperScreen/KlipperScreen/issues/1441.

Removing anything that adds to the event loop will help. So disabling led-effects, removing temperature sensors, unused MCUs etc.

d0m1n1qu3 commented 3 months ago

just to be sure. are you using all here 64bit oder 32bit linux on the rasberry?

Ambilights commented 3 months ago

64-bit bookworm on rpi 5, not a single TTC since I started this thread and swapped out rpi3B. I'm running led effect plugin.

igiannakas commented 3 months ago

Pi4b (CM4 with emmc) running 32 bit os. For me the issue begun re appearing with led effect. Maybe the 4B doesn’t have the horsepower for this.

appleimperio commented 3 months ago

@d0m1n1qu3 I have to replace my 3B+ for a 4B and using the 32bit OS. I try the 64bit but the problem persist. But I have no LED attached to the ERCF

d0m1n1qu3 commented 3 months ago

@appleimperio is your 4b also a 8GB Ram version?

Marucci87 commented 3 months ago

Im using 64 bit bookworm with my pi5 and was on pi4 b 8gb, to be fair I put about 30 hours on the pi4 and did not see the issue, I did not test it long term. I did change back all my steppers to 32 microsteps, all my leds are works, 17 on the ercf, 10 on the sb, 44 for the case light, webcam is connected, running the entry and toolhead sensor, pt1000, tap, x endstop to the toolhead board, I have done over 2300 filament chages without a issue, a few miss loads but no timer to close errors anymore. I also added a U2C when trying to fix the error but that did not help so I kept it on the printer when I switched to the pi5, also put the octopus pro usb to the pi. TB and MMB are on the can network. I have the U2C going to btt's new CEB, then from there to the TB and MMB....with the 120rs jumped at the toolhead board and the mmb nowhere else, I read having more then 2 120sr are just as bad as having none.

appleimperio commented 3 months ago

@d0m1n1qu3 4GB Ram version

jlama commented 2 months ago

Not sure if this will help, but I think what you are all experiencing is simply a fundamental design issue in Klipper.

Klipper expects real-time guarantees from USB bulk transfers during homing procedure. USB bulk transfers are not meant for real-time sensitive use and cannot guarantee anything. It's a best-effort thing. Sometime the reply arrives on time. Sometimes it gets stuck in the USB RX queue for slightly too long and you get a "Timer too close" error.

Nothing you can do about it except redesigning the way Klipper works. Otherwise something that might work reliably is using a good SPI CAN adapter instead of USB ones. Note that I would not call the popular Microchip MCP251x good - they are full of bugs.

deathfrozen commented 3 weeks ago

It is suspected that during long-term prints with a huge number of tool changes, due to the friction of the filament on the PTFE tube, a large potential for static electricity may accumulate and this problem may occur during electrical breakdown. Maybe it's worth trying to remove the potential from the filament to the grounding - I want to try this. Do you have any ideas how to implement this constructively?

dooodking commented 2 weeks ago

Hi all. I noticed something, the larger the file, the faster I get the error. tests run well even with 8 colors. Large files 20+ mb - Klipper lost metadata, I fixed it. Afterwards I had an MCU EBB error, I was able to fix it, then MCU"MCU", now this error is MCU"MMU". It very obviously appeared when I installed Blobifier. Logging level: -1 prints for about an hour, if level 1 or more, even before printing starts I get a TTC error, I’m already in despair.