Bridge perimeters printed with perimeter speed

[JohK]

Hi,

in 0.9.2 bridges fail a lot for me.
I have set my perimeter speed about 2.5 times (100mm/s) higher than the bridging speed (40mm/s).

This happens:

1. First the perimeter is printed at perimeter speed, where the bridge will be this causes ripping of the string.
2. When infilling, the printer tries to hang the bridge on the collapsed perimeter.

Shouldn't the perimeter be printed with the same speed as the bridge?

Truncated file with failing bridges at z=7.4mm (also at 3mm but I somehow expected that to fail): http://pastebin.com/yS3AUpcN

Cheers,
JohK

[alranel]

It's not just about speed, it's the whole bridging math that isn't applied to perimeters. This is for a number of reasons, including that it requires a look-ahead capable firmware to work properly. However, I want to experiment with it some day in the future.

(Isn't there already an open issue about this?)

[alranel]

Okay, this is now implemented. Enjoy!

[llluis]

I've just tried this feature and while it uses bridge speeds on perimeters, it seems that the bridge flow is not being used (on the perimeters).
My bridge flow is 0.8 and the bridge lines were very good. However, the perimeters sagged badly.

[kefir-]

What part are you printing? Could it be that your print is doing a retract just before the bridge perimeters? That usually doesn't happen on the rest of the bridge, because it's printed in one go.

I think a fast retract --> move --> fast forward --> bridge can cause that bridge to sag, because high pressure inside the nozzle takes some time to even out, and causes less controlled flow (ie too much plastic) on that bridge extrusion.

[alranel]

@llluis, can you provide something? At least a G-code file?

[llluis]

@alexrj
Sorry for the incomplete message.
Please see the STL, gcode and ini files here: https://dl.dropboxusercontent.com/u/4637549/bridge_llluis.zip

@kefir-
It's the default bridge torture test 50mm.
I'm not sure if there is a retract before the perimeter, but I believe it's not related to retract as I have 2 perimeter (4 lines in total) and all of them sagged, even being printed in one go.
But I will try to disable retract to test it.

[llluis]

Hi guys,
I did a bit more testing and confirmed that the perimeters are not being affected by bridge flow ratio. They are, however, affected by the bridge speed.
I've generated several gcodes using the files I provided changing one parameter at a time and comparing output.

The bridge layer is at Z10.200.
When changing the flow ratio, the firsts lines of this layer, which describe the perimeters, remains unchanged. When changing the bridge speed, the bridge movements (which will be in the air) obeys the selected speed.

[kefir-]

I can also confirm that gcode.ws shows different flow rates on the bridge perimeters and the bridge itself. If you load the gcode and colour by "mm extrusion per mm move" under 2d rendering options, and then flip to layer 50 (z=10.2mm) the bridge perimeters get a different colour than the rest of the bridge. (I haven't verified the calculations.)

[alranel]

@llluis, thank you for reporting that. It was fixed in the linked ticket #1407.

[JCT250]

Did the fix make it into 0.9.10b or was that released before it was fixed? Only reason being I'm running 0.9.10b and still seem to have bridge perimeters being printed at perimeter and not bridge speed

[kefir-]

The fix is not in 0.9.10b. It's on track to be released in 0.9.11.