#Timer Too Close Error

1 messages · Page 1 of 1 (latest)

ruby flicker
#

Just got round to using my boxturtle for filament changes not just a fancy storage unit. At random points I get klipper shutdowns with timer too close errors. It's happened on 4 separate occasions printing the same thing all at different points in the print.

I'm running the latest version of AFC and kipper v0.13.0-464-g47f0b3ca. All running off of my pi 4b 4gb.

It happens after it does the blobifier routine sometimes as it brushes and sometimes as it goes to do the small purge block I'm running. I've also added a M400 onto the end of my blobifier clean macro.

My logs don't seem to show anything much to me to jump out at an error.

undone laurelBOT
#

<@&1304550334839918672>

undone laurelBOT
thin frigate
#

ther'e are so many different things which can cause the error 🙁

several folks have found success by replacing the sd card or upgrading to an ssd instead of an sd card, as sometimes the writes to the disk are actually what back up the system.

#

will see if anyone else has some bright ideas as folks wake up

a copy of the debug script output would be helpful

#

don't run it while printing.

blazing spindle
#

reduce loading/unloading speed. and enable trsync in your settings

#

if that doesn't help - Change SD Card to something better - Sandisk A3

ruby flicker
#

Will run the debug script when I get some time tonight been a busy day today

ruby flicker
blazing spindle
#

Trsync_update - true

#

That helped and then changing the microsd to a3 resolved fully

ruby flicker
#

Ran the debug script

fervent willow
#

You should start by uncommenting these lines

# trsync_update: True           # Uncomment this value to update Klipper's trsync value automatically
# trsync_timeout: 0.05          # Uncomment this value if timeout needs to be greater than the default of 0.05
# trsync_single_timeout: 0.250  # Uncomment this value if single_timeout needs to be greater than the default of 0.250
ruby flicker
fervent willow
#

It gives a little more margin for klipper's scheduler

ruby flicker
#

Gotcha will give it a try with it enabled

ruby flicker
#

All gone wrong now xD

image.png
fervent willow
#

Looks like you created a typo

#

Do you need help locating it?

ruby flicker
#

Not sure whats up looks ok to me

image.png image.png
fervent willow
#

Go ahead and run the debug script again, let's see what it looks like there

ruby flicker
#

one mo

fervent willow
#

You've got spaces before the trsync lines, I think you have scrambled the parser's brains with those

ruby flicker
#

ah ok let me take thrm out

#

That was it lol

fervent willow
#

Also as JimmysDIY mentioned above, a slow or old/failing SD card can also cause problems, so if you've got any doubts about what you're running, get another one of those on order

ruby flicker
#

Forgot to check that will try remember to after this print

ruby flicker
#

Do far so good 38 took changes down the most it's done till now

ruby flicker
#

Had a clog which meant I had to end the print but I managed to do 150 tool changes no errors so I think the tr sync helped

#

Is this normal? Not been inside here after this many changes before

IMG20260210100731.jpg
quartz fog
#

Personally can’t say but looks like the effects of the double cut

ruby flicker
#

It does do a double cut yeah presses against the pin 2x

#

Least I'm finally getting somewhere

ruby flicker
#

Unfortunately had more errors this morning one whilst brushing and the other was whilst printing it just lost communication with the mcu

quartz fog
#

@sand blade maybe this is a test candidate?

ruby flicker
quartz fog
#

He has an idea for TTC in the area you just described

ruby flicker
#

Ah gotcha hopefully can get to the bottom of this I am gonna order a new SD card just incase , the second error was just mid actually printing lost communication with Turtle MCU rather than a TTC so wondering if I need a new cable also

sand blade
quartz fog
sand blade
#

Could try it but the lost communication with mcu leads me to believe this may be something different.

ruby flicker
fervent willow
#

I think maybe we should get a new log here

undone laurelBOT
ruby flicker
#

One mo I'll turn it on and run it

sand blade
ruby flicker
#

Not sure if makes odds but I am using a blobifier port not sure if I've mentioned that before or in my original post

sand blade
#

Oh… if your not running these macros then disregard. Sorry i did not read up at all

ruby flicker
#

No sweat appreciate your input anyways. ☺️

fervent willow
# 
Traceback (most recent call last):
  File "/home/klipper/klipper/klippy/gcode.py", line 471, in _respond_raw
    os.write(self.fd, (msg+"\n").encode())
BlockingIOError: [Errno 11] Resource temporarily unavailable
...
b'Got EOF when reading from device'
Timeout with MCU 'Turtle_1' (eventtime=418697.072523)
Transition to shutdown state: Lost communication with MCU 'Turtle_1'

This looks like a USB disconnect and is most likely a physical/electrical problem and not a software issue. I'm guessing you'll see the USB device go away in your dmesg logs, any more hints in there?

This could be a cable problem, EMI, or something going wrong with a USB hub. Can you run lsusb -tv here so we can see how things are connected?

ruby flicker
#

Course one mo

fervent willow
#

Oh that's the on-board hub of your system isn't it. Yikes, you lost a whole bunch of them at once

ruby flicker
#

Run them all off the built in ports on the pi. Yeah absolutely no idea what happened

fervent willow
#

The only possibility seems to be bad power to the pi

ruby flicker
#

It shouldn't be it's run off a separate power brick to the wall

fervent willow
#

And what is the power rating of that brick, and do you have any sort of guarantee of its quality?

ruby flicker
#

None at all lol other than it's been running for about a year

fervent willow
#

And now you're loading the system more and talking to more devices

ruby flicker
#

Only thing that's changed is I am now running the pj off an extension lead with a Google home and a router aswell

#

Had no disconnect issues before so maybe that's not helping

fervent willow
#

pj?

#

oh pi

ruby flicker
#

Pi sorry fat fingers 😂

fervent willow
#

sorry got it

#

Well, I think an extension cord shouldn't be a problem. You could try installing an external USB hub, and see what that gets you, but if there's doubt as to the quality of power to the pi, I would try to tackle that first

#

Though I guess not the extension cord directly, but maybe spikes from other devices on there are not getting filtered well by the supply you're using

#

so moving that connection might be the easiest thing to try first. Or powering the pi off a 5v buck connected to your printer's power

ruby flicker
#

Looks like it's a generic usb brick to be honest

fervent willow
#

Make sure you've got something of known quality with a reasonably high power rating

ruby flicker
#

I never had a buck converter with my kit originally the orange pi was powered off the ports on the spider board but when I changed a ras pi 4 I changed it

#

It's a juice 2.1 a unit

fervent willow
#

Ok, well choose your adventure, you've got my input

ruby flicker
#

First things first I'll swap to a different power supply see where that gets me and a different plug on the wall just incase

#

It's definitely strange as a week ago same set up I ran 2-3 8+ HR prints in a row no issues 🤷‍♀️

#

Also after they lost communication I didn't restart the pi or anything to get them back just a firmware restart in the gui

fervent willow
#

Maybe it was just a glitch from the utility?

#

And you're just an unlucky winner lol

ruby flicker
fervent willow
#

Voltage coming into your house can droop randomly (ever see the lights dim in your house out of nowhere) or similarly can spike. It's why filtered UPSes exist.

#

So if you want to be really serious, hook your stuff up to a UPS.

ruby flicker
#

Can't say I've seen that in a seriously long time here to be honest we do get cuts in bad weather but that's about all to be honest

fervent willow
#

Your printer's power supply has big capacitors that are going to filter a bunch of that stuff out, it's why when you turn your printer off it can take a second for all the lights to go out. But the little wall adapters don't typically have enough space to have much of that kind of filtering.

ruby flicker
#

Yeah makes complete sense, maybe the MCU disconnect was just random then , the TTC error on the first try of the print definitely was the same as the other though😅

fervent willow
#

Yup, and oh did I miss a new TTC since you put in a mitigation?

ruby flicker
#

So I tried to run a different print after yesterday's sort of success with 150 tool changes or so and it made it 2 before a TTC then I ran it again made it halfway through the whole print and MCU disconnected in the middle of a layer not tried again since

fervent willow
#

I just noticed all of your mcus are on klipper v0.12 but your host is is on v0.13. I think you should definitely get these synced up, as that can have an impact regarding the TTC issues

#

Er not all v0.12 but your turtle is, and your main MCU is not

ruby flicker
#

Was meant to do that last week but completely forgot 🤦‍♂️

#

Will investigate that tomorrow

ruby flicker
#

Wish I'd never started trying to update the MCU now 2 hours down can't seem to get the main MCU to play ball it says file downloaded successfully but once you reboot after that it won't show up with lsusb at all

ruby flicker
#

Ah got it !!!!!

blazing spindle
#

is this solved?

ruby flicker
#

I haven't been able to deal with anything for a while now been in and out of hospital will try again next week ☺️

versed zealot
#

Just a thought, I had issues with my Turtle for a while trying just about everything, and the fix ended up being putting some ferrite chokes on my USB cable. What you're having happen sounds similar to what mine was doing.

fervent willow
versed zealot
#

It would show as both TTC and MMU disconnect, randomly picking between the two

#

It would show as TTC when the USB had too much EMF noise and the host couldn't keep up with filtering the errors. If the host was able to keep up with filtering the errors but it decided it wasn't a good enough connection it would show as MMU disconnect.