Graph buffer usage or similar.

Zogar

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.

https://github.com/Klipper3d/klipper/issues/113</div><div><br/></div><div>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.

Repetier

Your measurement is wrong I think. It looks like you have moves around 1mm so with speed of 60mm/s (not visible what your print speed is) that means you get around 50 lines/s. Reason is that Klipper throttles the speed! We need to wait for "ok" from klipper so if klipper does not send it because it is waiting for the move to finish the bandwidth to klipper reduces.

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?

Zogar

Ok, I get something like that.

This are from https://teachingtechyt.github.io/calibration.html#speed

After what you comment, I think that the bottleneck is in the printer board that cannot process so many instructions per second.

I managed to fix it by lowering the resolution on the slicer.

Repetier

It is quite hard to say which effect comes from which problem.
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.5at² 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.