Graph buffer usage or similar.
Could a graph like this one that is generated with klipper be incorporated?
The goal is to detect prints that are faster than the usb connection can transmit. empty buffer.
As repetier cannot access the firmware of the printers, perhaps a graph with the speed of sending lines of code could be useful. If a print comes out with empty buffer signs, we could check the values reached on the graph to take them as a limit and try to reduce them in the laminator.
I have copied the console log for a few seconds and extracted the amount of instructions per second arriving at this graph.
50 instructions per second. Quite far from the 250 that the connection tests indicate, but from the printing tests that I have done, it is close to the limit that the printer supports.
50 instructions per second. Quite far from the 250 that the connection tests indicate, but from the printing tests that I have done, it is close to the limit that the printer supports.
Comments
Our speed test uses different commands - one quick one that finishes immediately to test what is possible, if we do not get throttled by waiting for moves to finish. So you can not directly compare this.
Actually server can normally handle 1000lines/s and more if there would be no communication latency. That is why we have a model to disable ping pong allowing to send multiple commands. It increases speed by reducing latency effects. But has limits due to target buffers.
Anyhow, not sure such a throughput graph would be of any use as its speed depends on the gcodes being send and not on technically possible speeds. On long moves you may even drop to < 1move/s just because the commands take that long. And that is no error, but how to describe that to all novice users complaining about low "speeds" when they see such a graph?
The bottom looks great so you have constant speed with constant extrusion and extruder has no problems heating filament consistently at that speed.
When you increase speed several things can happen.
1. Extruder can not heat properly. Changes in thickness and sooner or later you see parts missing and underextrusion, filament slipping. The faster the more heavy the effect gets.
2. Transfer bandwidth problems. Print gets short stops as moves run out. Often causes tine blobs where pauses happen.
3. Wall thickness changes due to acceleration/deceleration. To me the top looks like that. This kind is not as prominent. Not sure how Klipper works internally, but I know how marlin and repetier work. They compute speed such that they can slow down safely if no further moves will be send. This needs some distance accoring to s=0.5*a*t^2 and v = a * t you can compute how many mm (s_min) you need to stop at x mm/s. Distance increases with speed. Now as long as for the current printed segment you know there will s_min more mm to print you can keep steady max. speed. If this condition is not valid, firmware needs to decellerate to a safe speed. But on deceleration/acceleration you get unregular extrusions. Something advance tries to compensate more or less successful. s_min is sum of all queued moves and that length depends on sizes from slicer but also on the move buffer size used in the printer firmware. So both together define the speed limit at which the speed gets non constant and hence the surface will not look as great as with constant speed. This is actually no bandwidth problem at all - it is just a math problem based on the way move speeds get computed.
Solution is obvious:
- increase segements buffered
- decrease speed
- increase segment size
- increase acceleration (migt cause new effects like ghosting)
Any of these increases the speed limit. Trick is to find a balance that works for all outer walls. For infills the effect is not as important and at least with linear infill also not relevant as moves are longer. Just infills like gyroid may suffer from same effect, but since they are not visible not as hard. But would limit infill speed.
4. Max. join speed. Between 2 segments you have a direction change causing a shock, This is limites by jerk or yank in firmware. If your speed exceeds the allowed jerk it will reduce speed as well. But that is pattern between the segments and not as irregular as here visible.