Closed MattByczko closed 2 years ago
MattByczko
commented
3 years ago What could lead to high host buffer readings? I ran a htop command on the rpi while I triggered the error and nothing out of the ordinary was reported... Leads me to believe the issue is not as you mention in other issues (being a high usage process on the rpi).
Generated with graphstats.py
Attached is the shutdown logs generated with logextract.py klippyshutdown.log.zip
MattByczko
commented
3 years ago Digging deeper I can only replicate this with the heater on, and moving the axis. I cannot reproduce with just movement + fan.
I recently upgraded to a 50w heater cartridge but have had about 5 successful prints with this setup including a <20 min benchy on the exact same config that this error is reproduced on. Digging down this rabbit hole I reduced the max_power for the extruder to 0.5, No luck. I also tried that in conjunction with cycle_speed 0.2 for the cooling fan. Also tried was the extruder microsteps = 8. No luck.
I made sure my power cable between Pi and Arduino was not transmitting 5v, I cut the red wire. No luck. I added a jumper from gnd on the Pi to gnd on the RAMPS (shared with arduino) No luck.
I switched between different usb ports on the Pi - no luck. I switched the Pi to transmit in USB 1.1 speeds in the case of the above linked issue. - no luck. I used a different 12v PSU (also earth and gnd connected) - no luck I used a different 5v source to power the Pi - no luck I checked Pi for throttled voltage but that returned 0x0 which is no issue.
I did a complete wipe of Pi and reinstalled the OS + Klipper (master) - no luck. I checked out a previous commit from end of July 2021 - no luck
I have been through 7 pages of search results on the Klipper Discord - no luck.
The sheer amount of people who have this issue is astounding - it is not dependent on Raspberry Pi as there are instances of people with it occurring on different units. I can't imagine the people who are NOT reporting the issue, but still face their machine being useless on Klipper.
I post this trial log on the ticket in the hopes someone may have one of these issue and it resolve their specific issue. This will not be suffice for the majority of users facing the issue similar to mine.
TL:DR : No solution yet - found many people who have printers that just don't work on Klipper anymore.
KevinOConnor
commented
3 years ago That is unfortunate, but ultimately someone will need to track down the root cause of this issue. If you're looking for help with that, best to reach out to the community on the Klipper Discord and/or Discourse servers.
-Kevin
github-actions[bot]
commented
3 years ago It looks like this ticket is a request for help (or similar). Many helpful people will not see your message here and you are unlikely to get a useful response. Instead, see the contact directions at: https://www.klipper3d.org/Contact.html
We use github to share the results of work done to improve Klipper. We don't use github for requests. (In particular, we don't use github for feature requests, to answer questions, nor to help diagnose problems with a printer.)
Please follow the directions at: https://www.klipper3d.org/Contact.html
This ticket will be automatically closed.
Best regards, ~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
MattByczko
commented
3 years ago Update: I've just bought a new Raspberry Pi 4B and tried again, no luck. Problem is not a hardware issue with the Pi. I'd like to keep this ticket open or at least allow me to comment on it and update future readers that may come across this issue and want to know how to solve it. Regards, Matt
FuG
commented
3 years ago I am also consistently running into this issue. I ended up monitoring my top 5 processes using top and noticed that my klippy.py cpu usage continuously climbs for no apparent reason. After a clean reboot of the rpi, I'll start the printer and see that the klippy.py process starts at around 10% single-core cpu load. Every few seconds it will increment by 0.1%. I have watched it climb to 70%+ before. Can you monitor your klippy.py process to see if you also have the same issue?
FYI: I am using mainsailos + moonraker + klipper combo on an rpi 4B and an SKR mini e3 1.2 mainboard.
juhjar
commented
3 years ago Hi,
I do also have "Timer too close" errors.
My setup has been running very old fw from early 2019, on Rpi3+, Arduino Due (genuine), 3pcs TMC2130(X,Y,E, SPI) and 2pcs DRV8825 (Z1,Z2). I have printed 20+kg on this setup, during years.
Yesterday, updated to Fluiddpi, Moonraker and Klipper, latest versions of that day. Timer too close errors keep coming always during JOG movements, during print, homing some times(when Z starts to move).
X/Y jog movements does not trigger "Timer too close"-error, not even with 0,1mm steps while clicking button rapidly. But on Z-axis with 0,1mm steps, "Timer too close"-error is pretty much instant.
juhjar
commented
3 years ago Update:
In my case it seems to work now!! In past Rpi3+ was connected to Due directly via GPIO pins, not with usb (forked Klipper install). Now with latest Klipper version + Fluiddpi, I need to connect Rpi to Due via usb.
When connected into Due's programming port, I can flash Due, but Timer too close errors appear, when moving axis or trying to print.
But, if I flash it by setting "Communication interface ---> USB" and after flashing, move usb cable to Due's native port (change address in printer.cfg / [mcu] no more "Timer too close" errors. Printing right now.
While I was searching "timer too close" at Discord channel, noticed that different hw setups had same issues, so could some usb/serial chip cause the problem?
If I use genuine Arduino Due, via programming port, comes "Timer too close errors", but on native port no problem. But my friend has clone Due and there is no problem while using programming port. But, he will run further test.
@KevinOConnor
MattByczko
commented
3 years ago UPDATE: Well, I've successfully printed one XYZ calibration cube. I am 95% sure the issue is to do with fake FTDI chips which convert the USB signal on some boards to serial which the MCU reads. Below is what I did to fix it on a Arduino Mega2560.
All this fix does is bypass the onboard "fake" FTDI converter for the usb signal. If you have another port like @juhjar then it is very worth trying the other port. We bypass it by having our own external FTDI converter and sending signal to the arduino directly with tx and rx signals. Easy fix.
AUX1 image of 5v and gnd on ramps (from here https://reprap.org/wiki/RAMPS_1.4#Wiring_2):
I re did menu makeconfig and selected the UART device to be UART2 for the above wiring. (here is a link to the page of other serial connection possibilities: https://reprap.org/forum/read.php?219,393089,393094#msg-393094) Flashed using default usb to usb connection because mine works to flash new firmware just fails to consistently communicate when priinting. The MCU serial: config in my klipper software did not change because it still used the pi usb connection. You can sub out the usb connection with a straight serial -> serial connection from the pi to the arduino but i didnt know what i was doing so i left it.
Message or respond here and I will do my best to provide more details on this.
@KevinOConnor I would really appreciate it if you added something to a troubleshooting section or even to the install page as a FAQ about timer too close issues. To note is that the fake FTDI chips will work! They just will fail eventually. Mine stopped halfway through a print, then 5 mins into a print then 10 seconds into a print then i could send jogging commands to trigger it. It is a hardware issue that will sneak up.
I'm happy to close this once there is an addition to the installation or troubleshooting pages - possibly linking to this issue ticket or even describing a fix for the FAKE FTDI chips.
github-actions[bot]
commented
3 years ago Hello,
It looks like there hasn't been any recent updates on this Klipper github issue. If you created this issue and no longer consider it open, then please login to github and close the issue. Otherwise, if there is no further activity on this thread then it will be automatically closed in a few days.
Best regards,
~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being.
Hi All,
The issue: Last night things worked great, printed a XYZ Calibration cube. This morning I used the same settings from Cura on a larger object, loaded into printer and it threw the Timer too close error about 30 seconds in to the print. I tried the XYZ Calibration cube from last night (same Gcode) and it caused the issue again. I pulled the most recent version of klipper, moonraker, fluid, and flashed my board and it still occurs.
My setup: Brand new Pi 4b 4gb with nothing other than fluid and klipper set up. Pi powered by a ipad wall socket to usb power. ATMega 2560 connected with TMC drivers in spreadcycle via uart for all XYZE 12v power supply to a RAMPS 1.4.
Reproducer I can use to replicate 100% of the time:
At this stage the error occurs. I am at wits end because I can't even print anything...
I was looking through klippy.log for anything I might be able to diagnose and it seems that bytes_ready=10 is about the point that it gets triggered. Could be unrelated, just an observation.
To note: The log file attached was produced from just heating the hotend, fan on, home all axis and then sending a command to move z up 10 mm. klippy (4).log