yes but in this way upcoming_bytes over 1,6M
Well, you can destroy about any firmware by flooding its queue with commands.
It is the duty of the slicer and of inventive macro authors to avoid creating floods of commands.
Even more so, when they serve no practical meaning like sending hundreds of fan speed changes per second.
- Every command needs to be processed and taking precious computation cycles
- Every command needs to timed and slotted innto the buffer / queue
Filling up either the cycles or the queue with repeated commands will inevitably cause the system to fail sooner or later.
This is a known topic and some slicers had bugs that would exactly lead to this (IIRC meanwhile all fixed).
Following this, I would not call this an issue in Klipper, but an issue in creating commands or input to Klipper.
1 Like
This script is synthetic, but the print code is generated by Orca. When printing a wall with an overhang and a lot of edges, it generates this kind of fan control
Then it is likely a slicer bug. Analyze the gcode and if you see fan speed changes in the form:
M106 S25
M106 S204
G1 X117.434 Y135.618 E.00739
M106 S25
G1 F6359.991
M106 S204
G1 X117.343 Y135.636 E.0027
M106 S25
M106 S204
G1 F6720.764
Then the slicer simply creates crappy gcode. The above is a real life example from Orca (quite old version) where on an effective printing move of some tenths of a millimeter, the fan changed 6 times.
This is more or less completely meaningless, since a fan as physical hardware will never be able to fulfill these command due to inertia and mechanical / electrical constraints.
On the contrary, this slicer behavior has to be considered detrimental as it will put stress on the fan hardware and on the system that needs to manage these commands, in this case the Klipper firmware.
I understand that the fan cannot physically change speed that quickly.
But Orca version 2 (the latest working one) generates exactly this code. Moreover, the printer even prints 1 part. The problem comes when I fill the table with these parts and print a lot of them.
It is not clear how to protect against this on the slicer side. On the clipper side, it’s fairly easy to add “throttling time” for the fan. And skip M106 commands if they come more often
Maybe your settings are different, here Orca sets M106 only on layer change and here and there on feature change.
What material?
i use Petg
Untitled.zip (269.5 KB)
Fill table with this part and slice
Problem is force cooling for overhangs
You are right, at some spots there quite a lot M106.
Curious thing is: It swaps between M106 S227 and M106 S229
BTW: OrcaSlicer 2.1.0 - beta
A thing that SoftFever and team have to work on and that should not be mended by Klipper.
But what about the protection of the equipment?
We can legitimately cause a firmware error.
Interesting view: The start of the process is producing crappy data and the receiver of the data is responsible to handle it.
My view is quite the opposite:
- The generator of the data has the responsibility to generate valid and meaningful data
- It would be highly messy if a firmware suddenly started “interpreting” the intent of the gcode and decide to silently drop certain commands because in its interpretation it COULD be meaningless
Klipper’s reaction to error out and thus point to an underlying problem is the correct one. If the analysis now shows that it is due to faulty input data, then this side of the process needs to be fixed.
2 Likes
BTW::
With this setting there is no excessive M106 generation:
I agree that Orca is to blame in this case.
But it seems to me that there is a problem with your logic.
What if we tell the recipient to heat the nozzle to 10,000C? Execute too?
Of course.
Here it is the duty of the machine manufacturer and / or operator to have sensible safety limits in the configuration. These limits need to reflect the capabilities of the respective hardware.
So if you set your max_temp (MANDATORY Klipper setting for each heater) to 10,000°C and you are convinced that your hardware will take it, then go for it.
But there is protection against overheating. And my task as a machine operator is to determine reasonable limits.
It’s the same here.
There must be protection against DOS attacks. Similarly, you can play with a bunch of parameters and cause an error.
Add issue to orca Fast fan speed change on cooling overhang · Issue #5776 · SoftFever/OrcaSlicer · GitHub
1 Like
To conclude this (at least from my side):
- Klipper has very strict timing requirements
- It constantly monitors these timing requirements
- Timing is affected by a lot of internal and external (that are beyond Klipper’s control) factors
- Only Klipper can decide when “much input” turned into “too much input”.
- When this happens and Klipper no longer can secure the timing or the timing is already violated, then it reacts with, e.g. “Timer too close”
There is simply no limit any user could meaningful determine. It needs to be managed by Klipper internally.
There have also been cases where users managed to DOS their printer with macros that would echo some information with a high frequency.
So, following your logic, let’s combine such a (faulty) macro with the faulty input of a slicer. What should Klipper do?
- Silently drop commands from the macro?
- Silently drop commands from the slicer?
- Silently drop something else?
All would lead into completely unpredictable behavior. To avoid this, Klipper errors out and tells you that it was “too much”.
This is a completely different scenario compared to the heater example. Here you can directly influence your hardware’s capabilities with choosing the right heater, materials etc. According to these capabilities, you can judge and set the appropriate limits and safety checks.