Timer too close after tool change - running happy hare (reproducible)

General Discussion
1

Basic Information:

Printer Model:

  • Voron 350 (LDO kit)
  • ERCF V2 running happy hare

MCU / Printerboard:

  • Octopus 1.1 (MCU)
  • SB2209 (toolhead)
  • Cartographer 3d (probe)
  • MMB 1.0 (ERCF)

Host / SBC

  • Pi 4b 4Gb

klippy.log
klippy (35).log (6.4 MB)

Describe your issue:

I (like many others) have been plagued with TTC errors running happy hare - I have been trying to track down the source of my errors and I noticed in my case it always happens in the first moves after a toolchange. Not during the “homing” part of the change like many others seen to experience but in the first move(s?) following (after HH has restored the toolhead position).

I had a poke around the HH code to see what it is doing after the load is complete and position is restored - and one thing really stood out to me - the saving of the variables to the mmu_vars.cfg file. Could a write that took longer than klipper expected be messing up the timing of things in the queue? we are kind of at the mercy of the file system/os on that one - but do we need to do something special to handle the timings of a subsequently queued move like we do for homing? (I am no expert on the planner and motion code, but I might be able to take a look in the next few weeks if no one picks this up)

In order to reproduce, I did a little experiment, a simple single colour print with 2 cubes intersecting. Works as expected - no surprises there.

Then I added a bunch of save_variables to the the layer change gcode in my slicer (orca) and viola - I can reliably reproduce this timer too close error. The layer change gcode I used (104 entries because that is the random number of cells I dragged a formula down to in google sheets):

SAVE_VARIABLE VARIABLE=layernum1 VALUE={layer_num}
SAVE_VARIABLE VARIABLE=layernum2 VALUE={layer_num}
...
SAVE_VARIABLE VARIABLE=layernum104 VALUE={layer_num}

Link to my discord help thread: Discord

1 Like
2

This would be on @koconnor to evaluate.

My general feeling: It is known that flooding Klipper with commands will lead to TTC errors. This seems conceivable, since Klipper needs to process them.

Following this logic, it rather looks like a HH issue than a Klipper issue.

3

To be clear - happy hare isn’t really flooding it, it only saves a handful of variables, all of which seems reasonable to me.

The flood was just my easy way to reproduce it, I have got it to error with as few as 10 save_variable calls in my layer change gcode.

1 Like
4

To be equally clear: Apparently, it does it in a way that makes Klipper error out.
You are modifying Klipper with some thousands lines of unofficial code and it does not work. Now it seems to be on Klipper’s side to fix a case that main-line Klipper does not have or need.

I’d propose reverting to the HH project with your analysis and ask them to rework their system to be compliant with the needs of Klipper main-line

5

I raised this thread here because I can reproduce it without any involvement from happy hare.

Saving ~10 variables during a print doesn’t seem to be an unreasonable flood of commands, it doesn’t always result in the error, but it often does.

1 Like
6

Even more clarification:

I’ve seen users without Happy Hare have the issue, so it can’t be argued it’s a Happy Hare issue

Klipper needs be more resilient to being “flooded” with commands

I’m seeing more are more users encountering the Timer too close error on the various Voron discord channels and are becoming, understandably, very annoyed after spending sometimes $1000’s to find they can’t use their printer reliably due to random Timer too close shutdowns

7

Refer to Timer too close for reason of this error. According to my experience, this “flooding” scenario is by far the least frequent issue and the rest are local issues in the setup that indeed needs to be fixed.
So, as long as you do not know the root cause / circumstances of this error, this generic statements are quite pointless.

Maybe. As I said, this would be on a developer to judge.
In my view, this command is meant to persist states accross the reboot of a printer. Using it and its associated IO impact to manage runtime states seems inefficient and a misuse of its original intent.
Also compare to Save/Restore state for G-Code moves, which indeed is intended to manage runtime states.

8

Yet that is exactly the example used in the documentation:
https://www.klipper3d.org/Command_Templates.html#save-variables-to-disk

So you could understand why a developer would consider this a reasonable thing to do.

1 Like
9

I know the reasons for the error, I keep pointing users on the Voron discord channels to the causes and possible resolutions

To me this is an issue with Klipper, and just telling users “sorry, it’s your fault not ours” isn’t helpful

It’s like buying a new car and then being told, “sorry, the issues you’re facing is because you’re driving faster than 30MPH, keep it below 30MPH and you won’t have any issues”

10

I would likely say there is more than one issue at play, some might be in HH, some might be in klipper. In this case the fact I can trigger it be saving as few as 10 variables I think there may be an issue in klipper. This is not like the flood of fan commands that was seen from orca which would be considered unreasonable.

Surely it is in all of our best interests to work together and try and resolve issues such as these cooperatively - rather than stonewalling. If the problem is with happy hare then yes I will raise it with them, but I see nothing in the docs that suggests saving ~10 variables in the way described should cause an issue.

1 Like
11

That certainly seems surprising. If you can reproduce the error on a pristine version of Klipper I’ll take a look at it. (Make sure there are no external code modifications (nor additions), reproduce the error, and attach the full unmodified log here.)

Unfortunately, I wont be able to help with issues from modified versions of Klipper. It’s too easy for those modifications (adding files is a modification) to destabilize Klipper in hard to debug ways.

Cheers,
-Kevin

12

I would like to +1 the comment of resolving issues rather than stonewalling. It has become much more prevalent in the last few years of the different communities surrounding 3d printing of doing this. I recently brought up an issue in a different community where the unload macro was causing a clog in the boden tube between extruder and hotend, and was told that’s not a bug, you need to change the macro. So yes, we do need to stop immediately blaming someone/thing else, and instead of saying “it’s their fault”, at least come up with a game plan of how to fully find out what is the issue.

13

Sadly I don’t have a printer which can run pristine version of klipper as I have a cartographer probe. And the majority of users I have talked to are in the same boat - there is at least one extension they need to run their printer.

If anyone does have a machine that fits the requirements I’d love to work with them.

14

Test Cube attempt 3 klippy.log (1.3 MB)
Test Cube attempt 4 klippy.log (2.7 MB)
Test Cube attempt 5 klippy.log (1.6 MB)
Test Cube attempt 2 klippy.log (1.6 MB)

Few more logs - it seems I have more than one issue going on, I will try to chase down the Error running mmu encoder handler: '__MMU_ENCODER_RUNOUT' with @moggieuk

15

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.