I’m not a firmware developer.
From a purely technical point of view, I cannot know all the nuances of how the firmware works.
I am a user. I did the legal things (sliced it in the Orca 2.0 slicer, sent it to print) and got an unrecoverable error.
In my opinion, at a minimum, the firmware should safely stop printing if it sees a problem.
For example, pausing (keeping the bed and position warm if it looks safe), doing preliminary code analysis, and reporting problems before printing.
In this situation, it turned out that everything was fine with the slicer, everything was fine with the hardware. Even according to the logs:
print - ok
print - ok
Error…
It took me a day and half a kilogram of plastic to understand the essence of the problem.
For example, there is a connection with a firmware error and upcoming bytes for sb2040.
I’m typing now and monitoring this parameter. It’s no more than 1000 now. Is it safe to finish printing?
Will it cause an error if the task is 90% ready? If strictly zero, Orca has big problems.
All fine, but then it might be wise to ask questions and trust the responses of more experienced folks instead of adamantly insisting on opinions that you cannot substantiate.
No. Such errors are not recoverable.
Since Klipper does not know the reason (remember it cannot distinguish between legit / important commands and meaningless commands) it needs to go into a safe condition and this is a shutdown.
I have never understood this strange reflex of many users that the firmware needs to eat all sort of dirt and by all means is not allowed to error out, because it might spoil the precious print.
If there is no systematic issue in Klipper (none is known currently), then Klipper’s shutdowns are all legit and point to an underlying problem that needs to be fixed. Be it:
See the answer above: MCU ‘sb2040’ shutdown: Timer too close - #8 by koconnor
OK. This is not a bug issue. The problem is different:
I still don’t understand what exactly caused the problem. And how can I avoid similar mistakes in the future?
Before I came here I tried
find the source of the problems. Found this thread.
And as far as I understand, there is no solution.
The only thing I see is upcoming_bytes is much greater than zero.
I even came up with a test code generator to reproduce the problem.
Only when printing, an error occurred at upcoming_bytes~40,000 in the test case - more than a million.
ready_bytes were zero before the error occurred.
Here is my opinion:
“kick_start_time: 0.1” is the limitation of a hw fan. According to this setting, Klipper should report a warning if the gcode request much faster than this time.
Also if the gcode commands request over Klipper’s capability (limited by: kick_start_time: 0.1), it can allow user to enable a “protection mechanism” like “ignore floody commands: 1”. Then drop M106 request silently.
We just want a easy way to know what’s wrong in this situation.
I find this root cause by doing a lot of experiments, that really waste time & materials.
I dont see this in docs
kick_start_time: 0.100
Time (in seconds) to run the fan at full speed when either first
enabling or increasing it by more than 50% (helps get the fan
spinning). The default is 0.100 seconds.]
(Configuration reference - Klipper documentation)
As i see: if Now fan run at zero speed and recive M106 S128 klipper must give full power for 0.1S before it give half of full power
If we skip small comands it can give bad result:
I want shot start fan with 1/2 speed and turn it off
M106 S128 // Run half speed
G4 P1 // wait for 1 ms
M106 S0 //i wnat turn it off, but in your way we ignore this Comand
G4 S3600 // wait for hour
What will make Kliper - it will run 100 ms with full spped and after that turn off fan for hour
And what we have with your way? Fan will run fan with half speed for all time
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.