I see this error occurring more and more often on social media recently- and having had the problem myself i sympathize with those who also have this issue.
What i think is really, really strage - is the reluctance to do anything at all about trying to resolve the issue unless it is a “pristine” installation of klipper.
Telling people to talk to the developers of happy-hare about the problem - but when u talk to H-H DEVS they state that the issue lies within the way klipper is written. Plus i see this TTC error happen on other systems not running happy hare - using a beacon probe for example.
Instead of passing the blame onto each other and trying to make it somebody elses problem - why not work together with the developers of happy-hare and beacon/cartographer to sort this timer too close problem out properly - once and for all.
The whole thing seems a bit childish to me. And after following this issue for well over a year now i have seen my fair share of posts and replies about it - always gets shrugged off or ignored until the thread is automatically shut down due to inactivity.
C’mon man - u can surely do better than that. Klipper is awesome, happy hare is awesome. Make them work together properly to be sure awesome!!! Klipper2.0…
Fast, easy to modify printers were draining to setup before klipper came along
Self built - Multi material printing was really f$%n hard before H-H came along.
Work with each other - not against each other. Its counter - productive
I see this error occurring more and more often on social media recently- and having had the problem myself i sympathize with those who also have this issue.
This is sad to hear, there is always a place where you can get help, either in Klipper’s local communities, the discourse, the discord & etc.
What i think is really, really strage - is the reluctance to do anything at all about trying to resolve the issue unless it is a “pristine” installation of klipper.
This is pretty simple, to be able to help with modification, you should be at least familiar with them. This is not a someone full-time job, this is open source and community, where people do something for themselves and possibly useful for others.
To be able to help with each modification, you should have the will, time, and knowledge to do so.
Telling people to talk to the developers of happy-hare about the problem - but when u talk to H-H DEVS they state that the issue lies within the way klipper is written. Plus i see this TTC error happen on other systems not running happy hare - using a beacon probe for example.
TTC can happen in a pristine system, but that does not always mean that it will be easy to help with that. People always forget how complicated the world around them is.
The difference is, that when it is a clean system there are people who know for sure how it works and what it is doing at which moment.
If you have a will to contribute, you can spend time, get a grasp of how things work, or take a peek at the “Knowledge base” which can give some answers, to how things work and what can cause issues.
Instead of passing the blame onto each other and trying to make it somebody elses problem - why not work together with the developers of happy-hare and beacon/cartographer to sort this timer too close problem out properly - once and for all.
The only possible way to sort it out once and for all is to use a system on MCU, like RRF/Marlin, where there are different architectures and it is maybe not possible to get such issues. (I’m not sure because RRF AFAIK has expansion boards, which technically can lead to similar issues).
Klipper is a very complex piece of software due to its nature and unique capabilities, such as controlling various distributed MCUs.
Klipper is very timing critical to achieve the functionality mentioned in point 1 and to offer high quality for high-speed printers.
Klipper, without third-party modifications (like beacon or HH), is working reliably for thousands of machines.
From points 1 and 2, it is naturally required to know exactly what you are doing when you start hacking around in Klipper.
There are enough third-party contributions that make Klipper unstable.
There are ones that simply double Klipper’s memory footprint by adding a single feature.
There are ones that allow Klipper to destabilize if not configured carefully.
There are ones that can kill Klipper with a single command.
In my view, your allegations that Klipper is “childish,” “unwilling to cooperate,” and “blaming others” are quite insolent and not true. Additionally, it is a role reversal of victim and perpetrator.
Aside from the fact that Klipper is constantly improving its resilience against such errors and enhancing its core functionalities (as @nefelim4ag has posted), your requirements against Klipper are:
Buy hardware and install third-party modifications to debug unknown software partially with a lot of lines of code and fix their shortcomings.
Identify the edge cases these modifications are creating in an otherwise working Klipper and improve them.
Do this for free and in your free time, purely for the fun of debugging someone else’s code.
In fact, all of this would be the responsibility of the third-party modification. Instead, your position and seemingly their position sound like “Hey, I hacked Klipper, now it stopped working. Stupid Klipper, fix this.”
I strongly suggest rethinking your mindset and tone here.
I would hardly call beacon surface scanner a “hacked” modification. Its a probe ffs lol. Would u call a endstop or bltouch a hacked modification as well? Thats honestly laughable.
Yea i understand all of what u say - but the thing is - when people ask for help, all they seem to get is snarky replies (just like ur one, and ive seen many of ur replies before too in this forum btw - and u seem like a really arrogant guy lol, people are just asking for help, they dont need to be spoken to/written to like they are a toddler) or blaming “3rd party” modifications or developers, instead of trying to implement a fix. At least the developer of HH takes time to try and mitigate this TTC issue by increasing trysync_timeout etc etc and helping people try to sort it out on a case by case basis. He spent hours with me personally testing to try and work out the main cause of my TTC error. Instead of just blaming another developer or setup/3rd party “modifications”. Which btw - is all i have ever seen from the klipper devs when asked about this VERY COMMON TTC error. Ive seen hundreds of people complaining about TTC on facebook and have had friends in my town who have also had this same error. So its not as uncommon as u claim. At the end of the day - klipper is primarily used for people who are building custom printers. So you would think that developers of klipper or any other “3rd party” would work to find a fix for such issues instead of just passing the blame off on each other.
U also say multi-mcu is one of the main reasons for shutdown because of timing issues - ok then - so how do auto manufacturers write their code so 20+ mcu can all talk together without timing errors causing shutdowns?
Dont get me wrong - i think klipper is great. I just think that the way errors like this one are handled is really childish/lazy. I stand by my previous statement sorry.
Also you talk about klipper having its memory footprint doubled when using some modifications like HH.
So what? Thats not the cause of these specific TTC errors - with HH at least lol. Ive seen people running klipper on a pc with 5x as much memory as a rpi and still have this same error.
And once again i refer to automotive electronics and how they dont just shut down when data has to wait in a que for too long.
Why cant klipper have a larher buffer for timing specific data? Or at least just throw an error or implement some other code to make the machine pause if klipper is overloaded instead of just shutting down.
Yea - but how do auto manufacturers have 20+ control modules all sending data between themselves without any issue that causes the car to just shut down unless there is a actual physical fault - and in that case - has to be a SERIOUS fault to cause the vehicle to just shut down.
Yes i know there are alot of variables with a open source firmwarethat is used in many different setups - but surely over time those variables can be taken into account.
Like i said before - dont get me wrong - i think klipper is awesome. I just think that some problems with it are ignored or the blame passed onto someone or something else instead of trying to implement a fix for said problem.
See, statements like this are exactly why I’m perceived as arrogant. You apparently have not the slightest idea what you’re talking about, yet you come with very strong opinions or rather unfounded assumptions.
The beacon scanner consists of:
Around 4,000 lines of 3rd party code modifications to Klipper
A custom firmware that appears to be closed source but interfaces with Klipper
The rest of your allegations show two things:
Again strong opinions that unfortunately lack any kind backing up by facts or knowledge
A demanding attitude (now an assumption from my side) without probably ever substantially contributing to OSS or similar projects
Sorry, but I don’t think that is a good way to deal with Fevafeav’s opinion or knowledge of Klipper.
This should be an open minded forum to discuss opinions and knowledge of Klipper. Shutting someone down is in my eyes discrimination (maybe the wrong word!).
My impression is, Fevafeav didn’t understand the problem here. His example from the “auto manufacturers” shows this. I don’t agree with Fevafeav and don’t like his kind of language, but we should civilized discuss this!
Oh but i do understand the problem with timer too close -
TTC error im talking about occurs when the host sends a message to the MCU, scheduling an event at a time that is in the past. High system load of the host, High disk activity of the host, Swapping due to low free memory Disk errors / dying SD card, Unstable voltage, or Other hardware hogging the USB bus, other system resources Running in a Virtual Machine, USB, UART or CANBUS wiring faults leading to extremely delayed messages. ElectroMagnetic Interference (EMI) affecting proper signal could also be a cause. The host only needs to experience a tiny period of high load so as u can imagine- watching an average load meter doesn’t tell the whole story. Also, as we drive additional functionality on our printers we are always inching closer to this annoying error.
Sometimes increasing TYRSYNC_TIMEOUT from 0.025 to 0.05 can help. But its not a sure fix.
Also a known communication delay has been found in some of the latest operating systems that can result in a message from a mcu being delayed beyond the limits set in Klipper.
I think i may have got around this by using a legacy version of lite bullseye to build my klipper image. I no longer have TTC errors when tool changing which is the main thing. I still get TTC errors when beacon begins bed mesh occasionally. In my eyes - as long as im not wasting filament thats a win.
Also i would still like to make myself clear - im not hating on klipper. I think klipper is awesome and i do appreciate the developers hard work alot. I just wish issues like this were looked into instead of just ignored or not cared about because of them being caused by “3rd party” “modifications”.
In reality- these so called “modifications” are common place on many, many custom built 3d printers - and to me - that just sounds like an excuse. Anyways im over this now. Peace
First off, you piggybacked onto an issue that was responded to by the person who leads the Klipper project seven months ago. This buries the original issue and discussion and makes it harder for people to search on it.
Reading your original post, it doesn’t seem clear that you actually have this issue, just that you’ve “had the problem”, but used this topic as a springboard to raise your concerns about Klipper support philosophies.
If you actually have this issue, then I suggest that you start a “General Discussion” thread with all the information regarding your printer (including your klippy.log)? This will provide context as to how you personally are being affected by the problem and provide a clean thread people can respond to.
Secondly, there are processes in place to accept new code into the main branch - if somebody has a potential solution to what they perceive is an issue with Klipper, then they can put in a Pull Request, which will be evaluated. A significant part of the evaluation process is to understand the impact the issue is having at the population at large - if it is one person, then don’t expect an immediate response, if it is dozens/hundreds then it will become a priority.
Thirdly, when I saw this:
I don’t think you understand that the reason why cars can have 20+ (Actually, on most modern cars it’s 60 or more) devices communicating without issue is because the environment is locked down.
If you try to add something to a car’s network (either hardware or software) and, regardless of whether or not it works, you have voided the vehicle’s warranty and if you have problems with changes, or with something else in the car, then you’re totally SOL.
I don’t understand why you think that Klipper (or any other piece of software/hardware) can be changed and it is the originator’s responsibility.
Fourth, this is just my personal opinion, Klipper is an operating environment; if somebody has something to add to it, then it is their responsibility to have it working within the operating environment without modification. I’m pretty sure Linus Tovalds would tell you to go ESAD if you approached him and demanded Linux support for hardware and functionality that was never part of the operating system’s specification.
People involved with Happy Hare can complain that there was a design error in Klipper (and they may be right) but, if they want to work with Klipper, I think the responsibility lies with them to conform to Klipper not the other way around.
You can wish. But I hope you have gotten the message that simply raising a complaint won’t get things moving in the direction that you want.
Again, if you have an issue that you feel needs to be addressed:
Start with posting it as a “General Discussion” thread with all relevant information (including your klippy.log). Don’t piggyback onto somebody else’s thread - it’s not helpful and obfuscates the actual discussion.
Explain the scope of the problem. If this issue affects just one person you’ll get a reply here saying “Sorry to hear you’re having problems, have you tried…” If this affects many people and can provide an accurate list, then you will see the issue being given priority.
If you have what you think is a fix, put in a Pull Request.
Be ready to respond quickly and comprehensively to any queries about the Pull Request.
Yea ok whats the point of that? - when explaining the problem you get told to reproduce it on a “pristine” copy of klipper with no modifications. Um ok then…thats kind of not the point here. So u end up going around in circles with no productivity towards actually fixing the problem. Yes - there are hundreds of people it is affecting - all you have to do is look on social media or do a google search to find discussion about it in forums. Does that mean that these people are going to open a new discussion here every singe time? I highly doubt it. Its a hassle enough just having to sign in for one. Forums like this are a thing of the 90s in my opinion. Most people cant be bothered going through all the steps required just to ask a question or make a response.
Same thing with github or discord.
Anyways - like i said b4 - im over this dumb conversation, looks like the TTC error is here to stay until someone else smarter than everyone ive spoken to about it comes along and fixes the code relating to it.
Oh and as far as the car thing goes - yea 20 + (emphasis on the +) means just that - 20 PLUS MODULES. So yea 60 or even more than that. Why even bring that up? Trying to make out that u know more than me about the subject or something? Seens a bit weird that you try to correct me on something that didn’t need correcting.
And wtf are u on about “locked down”? Pffft - Hardly. You can add extra peripherals to a vehicle electronics system no problem. Might cause fault codes - but the car doesnt just error out and shutdown/stop running when something goes wrong - again - unless it is a physical failure or something that has a fail safe section in the program - in which case a proper description is given for the error not just “Timer too close”.
If ur talking about being “locked down” as in you “cant” make any firmware changes, then thats wrong too - sure u can, u just need the right tool/s, knowledge and software to read the firmware file, edit the hexadecimal code with software that is made to read/edit it and re-flash mcu with modified file.
It seems like ur doing the same thing as ur friend was - trying to discredit what i am trying to say by saying that I don’t understand anything- when in fact i understand a lot more than what i can explain.
But whatever you think what u like buddy
Again
Bye felicia
Before now closing this thread for good, there is one more thing I want to add, because I think this is important and is hurting the entire Klipper ecosystem overall.
As I tried to convey already, Klipper is very sensitive to changes in the code. The changes need to take due diligence on:
Where, how, and when certain functions are executed
In which context they are executed
It even goes so far that on the assembly level, it is checked if the compiler, interpreter, or finally the CPU/MCU might be reordering instructions in an unwanted way
Now, what is happening today:
New features/functions are developed. This is great and appreciated.
The developers mainly focus on their feature and less on how this impacts Klipper’s internal workings.
You can very clearly see this in countless PRs where the lead developers are providing feedback in the sense of “do not do this here,” “can’t be called in this context, because…,” etc.
The feature developers are surely not neglecting this on purpose, but you also cannot simply change a highly complex system and hope it will be okay.
For similar features, there are multiple implementations, e.g., Happy Hare, AFC, ECRF, etc.
It is neither possible nor economical for Klipper to run after all of them and check where things might go wrong in each individual case.
It remains the responsibility of the modifying party to ensure that all concurrent requirements are met.
So, if you want to go out on such a crusade, contact the individual feature developers of MMU systems and have them team up:
Define one open and stable API for MMUs.
Develop this API.
Hand in a PR to mainline Klipper.
I’m quite sure that this will not fall on deaf ears and can eventually get merged (though it might be a tedious process up to that point).
This would have multiple benefits:
Relieving the individual feature developers of caring for the basic interface.
Making sure that the interface is well-tested, scrutinized, and stable.
Offering it to the users without the need to install third-party code.
Ensuring that the interface will not break on mainline Klipper updates.
Ensuring long-term availability because even if the individual project dies, the interface in Klipper will remain.
