[4.2.1] Incorrect speed control in bridging (ignores effect of minimum layer time)

[tturpin]

Application version
4.2.1
Platform
Linux
Printer
Creality Ender 3

Reproduction steps
Slice the attached project with a 5mm/s bridging speed (and a higher wall speed)

Actual results
The first layer of the bridge is printed at a varying (decreasing) speed. It start with a faster speed (thus instantly increasing the previous speed), then slows down to 5mm/s. It is visible in the layer view with feedrate setting. This causes the bridge to print badly. The bridge handling seems to assume that the previous speed was equal to the "wall speed" setting, while in fact on this small model it is equal to the "minimum speed" setting, to account for the "minimum layer time". Coasting seems to have no effect on the issue.
Expected results
The speed should move from the actual previous speed (if different from the the wall speed setting) down to the bridge wall/skin speed.

Additional information
bridging_example.3mf.gz

[smartavionics]

That first bridge layer takes nearly 20 seconds to print so it's way above the minimum layer time and therefore can be printed at its normal speed.

FYI, when Cura is calculating the speeds for each layer it knows nothing about the speeds used on the previous and next layers so it cannot use the same speed as was in use on the previous layer.

[tturpin]

OK, so if I understand correctly, contrary to previous layers, the first bridge layer takes long enough (presumably because of the very low bridge wall speed) so that the "rest" of the layer can be printed faster ?
So in this case this would not be a bug in the bridge handling, but rather a bad side-effect of the overall speed / flow handling on this particular case:

• The first bridge layer start with "normal speed" (so in fact, instantly accelerates w.r.t. previous layer)
• Then it has to slow down (progressively to avoid excessive pressure) to the bridging speed, but since the pillars are very small, there is not enough distance on it to reach the bridging speed, so it starts bridging almost at full speed.
  I don't know how the deceleration is handled before bridging, but maybe in such cases the "start speed" of the layer should be reduced to make sure that it does not start bridging too fast ?
  Also, I don't understand clearly what "coasting" does: is it supposed to just slow down to the bridging speed a little sooner ? (which would explain that it does nothing here, because there is no time)

[smartavionics]

OK, so if I understand correctly, contrary to previous layers, the first bridge layer takes long enough (presumably because of the very low bridge wall speed) so that the "rest" of the layer can be printed faster ?
So in this case this would not be a bug in the bridge handling, but rather a bad side-effect of the overall speed / flow handling on this particular case:

Correct.

The first bridge layer start with "normal speed" (so in fact, instantly accelerates w.r.t. previous layer)
Then it has to slow down (progressively to avoid excessive pressure) to the bridging speed, but since the pillars are very small, there is not enough distance on it to reach the bridging speed, so it starts bridging almost at full speed.

I wouldn't have thought it would start the bridge too fast because your printer firmware should decelerate before it gets to the bridge region. In fact, it is unlikely that the nozzle ever got to the normal wall speed anyway because the supported wall isn't long enough. The firmware should have started to ramp up the speed at the start of the line segment before the bridge, if it could accelerate fast enough it would reach the desired speed and hold that before decelerating to the bridge speed. More likely, because the line segment is short, it never reached the full speed and so it would have started decelerating from whatever speed it had attained just past the mid point of that line segment. The exact behaviour would depend on how good your printer is at handing speed changes between line segments.

I don't know how the deceleration is handled before bridging, but maybe in such cases the "start speed" of the layer should be reduced to make sure that it does not start bridging too fast ?

As just explained above, it should not bridge too fast.

Also, I don't understand clearly what "coasting" does: is it supposed to just slow down to the bridging speed a little sooner ? (which would explain that it does nothing here, because there is no time)

No, coasting stops the extruder without (explicitly) affecting the nozzle speed. The idea behind coasting is that if there is a large drop in extrusion rate when the bridge line starts because either the bridge wall speed is much lower than the normal wall speed or the flow is much less, then by stopping extruding early you reduce the overextrusion that would otherwise tend to happen. It's caused by the time lag in the extruder. This is very obvious to see when it occurs, when the nozzle hits the start of the bridge segment, the filament spurts downwards very noticeably due to the excessive extrusion rate. The coasting lowers the pressure in the nozzle to get closer to the pressure that will be used for the bridge segment.

[tturpin]

Thanks for looking into this. For the "start speed", I'm quite sure that it immediately start with a high speed, and is still moving too fast for the first millimeters of the bridge (looking at the printer in action). For higher speeds, acceleration would probably take some time, but here I believe that the "jerk" control (either from the firmware or the slicer) allows it to start at a speed several times higher than the previous layer (maybe not the normal speed). I was assuming that the progressive deceleration was controled explicitly by the bridging planing, I didn't think that it could be the printer itself. So in this case this would mean that the behavior is not symmetric: it allows quicker acceleration that deceleration... More generally, the respective role of the slicer and the firmware for acceleration control is largely a mystery to me.

I'm affraid it will be difficult to understand everything without looking at the gcode :-(

[smartavionics]

Yes, jerk is going to influence how close the nozzle speed is to the desired bridge speed at the start of the bridge. The higher the printer's jerk value, the higher the nozzle speed will be (assuming that that the line before the bridge was being printed faster).

It's a very complex situation when you take into account the dynamics of the nozzle movement and also the dynamics of the extruder+hot end. The more I worked on the bridging implementation the more I realised how insanely complicated it is and that any solution is going to be a compromise. There are just too many degrees of freedom: model dimensions, speed/flow/temp/fan/accel/jerk in profile, printer firmware behaviour and parameters, material properties, etc.

And the walls are relatively easy, the hard part is getting good quality bridge skins!

[Ghostkeeper]

Cura specifies the maximum velocity in its lines, which the printer shouldn't exceed. It also specifies the acceleration and jerk rates (if acceleration/jerk control is enabled) but the printer itself then actually has to plan when to start and stop accelerating and at what speed it can go through the corner.

Cura does model all that though internally, to get printing time estimates.

[GregValiant]

I'm cleaning house.
Is this still a problem with current Cura versions (5.8.0 and up)? Can I close this?