I was referring to the “dirty” modules.
Untracked files: klippy/extras/cartographer.py, klippy/extras/idm.py, klippy/extras/scanner.py
Not stepcompress. I should have been more specific.
I’m not the one who noticed that,
But I will forward it - it seems that there is no issue.
Transition to shutdown state: Shutdown due to webhooks request
It seems that someone or something asks Klipper to shut down, and everything else is just the consequence of that.
Hope that helps.
Ok, that is an explanation I can relate to, thank you for the clarity of your reply.
That is what I will do next, even though their stance in the past to others who tried to get somewhere has been less then supportive, which is unfortunate.
I always thank those who contribute to some level of understanding of what is going on, that is why I mention the facts, perceived wrongly or not, by myself, and stay as open as possible while focussing on the issue rather than on the person. This way I can learn something new, like others, and collectively find the way out. Unfortunately if the problem is random or unpredictable, it becomes hard to accept certain conclusions, for the simple fact the realworld experience does not show the explained reason every time.
But if my wording was too factual, I apologise to all on the receiving end.
Thank you hcet14, but which folk did you mean? This seems a long complicated thread about the subject matter of my error but I cannot find anybody who I might contact for it. As far as I understand this is the developpers talking to eachother about the codes but I think I should contact Cartographer who sold me my scanner. This is what is my next step even though I am not holding my breath. One question to all, does klipper accept the beacon scanner without these issues???
Thank you, I think I understood and that is what I will do next.
Thank you, I had to E-stop it everytime the error happenend because the system does not abort itself. Since after the error the toolhead thinks it is where the code sent it to, but physically is somewhere totally different, it will joyfully ram itself against the frame with the next move. So this is why you can see the webhooks request everywhere.
Sorry if my previous rebuttal sounded offish, it was totally not the intention. I read what people suggest or conclude and compare it to what I see is happenening. From my point of view, with almost no knowledge of the code behind it, I saw inconsistencies. As sineos explained this could be exactly the result of what is described in
I read this section many times now, also in the past, and I have to say it is slowly cementing itself in my head that it is always better to stay away from aftermarket hardware that do not comply with this. Maybe we should compile such a list for people so in the future they can decide what they want to buy. (Maybe it already exists but I did not know?) I did not know the Cartographer would give me such headaches. Maybe a Beacon would be better, I will investigate this.
Anyway your contributions are always appreciated, like all other’s. Unfortunately this problem is not so easy to eradicate and might never end in a nice proposition.
OK, back to start. It seems we misread the logs and followed a red herring.
As @nefelim4ag noted:
- In each log the initial shutdown reason (and only this counts) is
Shutdown due to webhooks request. As you noted, initiated by yourself - The
stepcompresserrors are a consequence of this and are to be disregarded
→ There is no Klipper relevant error
Further:
- The Cartographer probe seems pretty unproblematic, judging from the reports here
- Klipper is very sensitive when it comes to violating its axes limits when properly configured. See Move out of range: X Y Z [E]
- You noted something about a strange noise. This would rather point to a mechanical problem
This is a big change in how to look at this prblem and where a possible solution might come from! Yes the noise I mentioned seems to be a different tone of the stepper motor itself, different in pitch I mean. It does not sound like a mechanical scraping or something is struggling, but that said I will have to try to get it to go wrong again before I may say with certainty it is a stepper motor noise rather than something else.
Fact is it is always during the A and B motor moves, thus X and Y axis, and both at the same time.
Also I recall at least once that the move attempts to go to position, but with that strange noise, then falls short of its position by lots, and once it then made a short motion, few mm only, in a completely random direction. At that point I hit the E-stop.
Questions I now have:
Why would it always be after homing correctly, then it finds the center of the bed correctly and then it errors either on the move from the center to its first corner for QGL, or again after homing correctly, the first move from the center to find the start of the bed mesh sweep? The problem has never, yet, occured at any other time.
Why did this start exactly after a mayor update of klipper systems?
Ok what I will do tonight is check mechanical issues on that far quarter of the bed, since the error is only happening from the middle to the far front corner moves.
I will do manual homings and try to manually move as the QGL or bed mesh sweep would do, with various speeds to see if I can repeat the error manually.
This is becoming much like a wild goose chase but if it gets found out what it is, all is well.
Thanks.
This is almost surely a local issue on your side. If the v0.13 strain created something like this on a broader scale, this place would be full of reports.
On a cursory look at your config, I did not notice anything seriously amiss.
1 Like
Once satisfied I do not have an intermittent mechanical issue I will research how to roll back the update. Never done something like that before so that will be interesting too.
Just a simple observation. apologies if youve already looked into this.
But going back to basics
The mass of the head has likely been increased, im seeing a probe added, a hotend change, a runout sensor added.
Your talking about positions not been in the intended places, the head hitting the frame of your printer and your using sensorless homing based on your config in the log files.
To me, this sounds like the sensorless homing might be giving false detections, watch when the printer is homing, does it make it all the way to the endstop positions or does it stop early?
Might be worth running through the steps here on checking/setting the driver_SGTHRS values.
Thank you for your reply, it is a valid point but it is homing perfectly.
The total weight change is minimal and it did not affect the sensorless homing.
Ok so here is the situations as of now.
- I checked gantry movement by hand for roughness, it seems ok everywhere.
- I did manual homing, QGL and bed_mesh_calibrate commands from the mainsail terminal. It was starting to look ok until after 6 or 7 tries the error happened also in manual commands.
- I tried reprinting all the old files, noting if they had failed or succeeded before. Again it looked ok until after maybe 5 or 6 tries one file that succeeded before now suddenly gave the error.
- I rolled back the klipper commit by one and restarted klipper.
- printed the last failed file and it succeeded.
Question now is how many times would it need to succeed before I can trust it again?
Also, was it something of a quirk and can I update again or would it be wiser to not update for a while and hope for a reworked version?
Then lastly would it be appropriate to ask the developer team to have a quick look into this?
What I am thinking now, wrong or right, is that it was something in klipper after all. Maybe something unpredictable, like what they warn us for in the “dirty” explainer, or unrelated and just a bug. For now it is running.
Again a thank you to all who commented trying to shine a light on this.
I will keep this thread open for a short time, seeing if the printer remains “friendly” and if so I will close this as solved.
If not I will be back with more information, and crying!
Since you needed 5 or 6 attempts to make the whatever unintended behavior show up, then printing one file and yelling “success” seems optimistic.
For both questions: Pretty unlikely:
- No evident Klipper error except a (vague) description of something not working as intended and a prematurely killed Klipper
- Extent of the unintended or believed unintended behavior is not clear (at least to me)
- Modified Klipper version
1 Like
I think I will be watching it like a hawk for weeks to come to be honest.
I agree that there did not seem to be a klipper related error that caused the fail. I do not agree that I killed it prematurely. I know what it looks and sounds like when it slams into the frame and I rather stop it before that happening.
The unintended behaviour was very clear, and the same everytime it happened weather with QGL or the bed mesh. It buzzed or hummed or vibrated out of its normal tune when trying to move to the first point to check.
I agree with the modified klipper. This reminds me that I still think it would be a good thing to make a list of what works without making klipper dirty, and what not. Do we have such a list?
I will keep watching for a while and when I am kind of satisfied the error has gone away I will close this thread as solved. Thanks for all your time.
1 Like
Has anyone considered updates to Python as a cause of instability of the Cartographer scripts?
Also the host OS could have become “unstable”.
These things are way beyond my window of understanding. I think, like Sineos said, without a very clear klipper related error, or indeed any clear error message, we might never find out what went on.
All I can hope for is that it stays away now.
3 good prints later and the error came back. Exactly as before.
Before tearing into either the wiring or mechanics, I decide to try what @nefelim4ag suggested and reduce speed of what seemed the troubling moves down to a more mild level, so I set both the QGL and bed mesh speeds to 200. They were set at 500. (should not be a problem but what to do?)
I also noticed that my max accel was set higher then the standard cfg from Voron suggests. It was 9000 but the original cfg sets it at 4000. I set this one also back to 4000, even though I do not think this matters as much as the speed itself.
First print is good again so back to playing the waiting game.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.