Coast Velocity Ramp

[CCS86]

I really think the coast feature would benefit from a linear deceleration of the print head, rather than a fixed percentage of speed. As the extruder drive stops, flow rate is a function of pressure, and it will be bleeding off throughout the coast move.

For me, the parameter would be "coast distance" (as an alternative to volume). At a point, the coast distance away from a rapid move, the print speed begins to step down linearly. I believe this will better match the coast extruder flow, and allow you to bleed off more nozzle pressure, without leaving a void.

Thoughts?

[BagelOrb]

I hoped this wouldn't be too much of a problem. I hoped that an average speed over the coasted piece could work well enough. Are you seeing that this is a problem?

A more principle problem to your idea: if we try to release all pressure from the nozzle, and couple the movement speed to the flow corresponding to the pressure at a given time, then the last few coasted moves will become very slow - so slow that the printer might seem to be stuck.

[CCS86]

That is true, but surely a lower end cut off could be implemented to prevent stalling out.

Maybe you can educate me on how coasting is currently working. To me, it seems to operate oddly:

It seems to stop normal print moves some distance from the rapid move as expected). but at this point, it does the retract first, performs the z-hop, then does the coast move to complete the print segment. Having the retract and z hop moves preempt the coast moves, seems counter productive, and out of order.

[BagelOrb]

Oh that is indeed a bug.

Ideally it should start retraction at the same time as it moves along the last piece of the segment and after that perform the z-hop.

Currently it performs a retraction and a z-hop, then moves along the last piece of the segment and then travels.

This is a bug.

[CCS86]

Can I suggest that the coast move happen before the retract? This would allow the pressure to bleed first, and allowing for less retract before the rapid.

[CCS86]

It would be awesome to try out the velocity ramp idea that I had, while someone is revisiting that code. :)

Happy to help out in brainstorming implementation ideas, but I don't consider myself a great programmer.

[BagelOrb]

I agree that it would be better to retract after coasting. I am viewing this as a bug, so this is on my TODO list.

The velocity ramp idea is a bit more complex and is currently out of scope.

[CCS86]

Just a thought... I haven't played with how per-line acceleration settings work, but would it be possible to leverage that for a similar effect?

If the end velocity was looked at as 0, because of the transition from print move to rapid, then a very low acceleration commanded for the coast move could serve to provide this velocity ramp.

Is this crazy?

[BagelOrb]

Yes that is crazy. Good thinking! Very out of the box.

This is treading very much into the domain of what the firmware should handle. Setting the acceleration to a specific value for the one move would be quite a nice hack, but then setting it back again requires knowledge of the firmware, which Cura doesn't have...

[CCS86]

I was hoping that like feedrate, you could attach a max acceleration to a given line of code, leaving the default acceleration intact for subsequent lines.

[BagelOrb]

Nah. See http://reprap.org/wiki/G-code#G0_.26_G1:_Move

[BagelOrb]

I'm moving the retraction coasting bug to https://github.com/Ultimaker/CuraEngine/issues/280

[CCS86]

:+1:

[BagelOrb]

Coasting is not supposed to be used for compensating the hysteresis effect introduced by the bowden tube. I've been talking with some colleagues and concluded that we need a new feature to compensate for the 'bowden delay' apart from coasting.

I hope we will find the time soon to implement such a new feature. I think that with that feature this enhancement request will be eliminated.

[CCS86]

Interesting. What is the intention for coasting then?

I'm all for a more purposeful feature to let the extruder "lead" the print head though. Happy to help brainstorm ideas for that to balance complexity vs benefit.

On Wed, Mar 9, 2016, 4:44 AM Tim Kuipers notifications@github.com wrote:

Coasting is not supposed to be used for compensating the hysteresis effect introduced by the bowden tube. I've been talking with some colleagues and concluded that we need a new feature to compensate for the 'bowden delay' apart from coasting.

I hope we will find the time soon to implement such a new feature. I think that with that feature this enhancement request will be eliminated.

— Reply to this email directly or view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/274#issuecomment-194235515 .

[Ghostkeeper]

It's just to reduce oozing, as I understood. Since even if you retract, the oozing doesn't immediately stop due to the volume of molten material still in the nozzle.

[CCS86]

It seems to me that the oozing is a result of the residual nozzle pressure, from the elasticity of the filament and the bowden tube. You either retract far enough to dump all elastic compression and tension, plus a little more to create slight negative pressure. Or you bleed some off first with a coast. It all seems linked to me.

On Thu, Mar 10, 2016, 3:30 AM Ghostkeeper notifications@github.com wrote:

It's just to reduce oozing, as I understood. Since even if you retract, the oozing doesn't immediately stop.

— Reply to this email directly or view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/274#issuecomment-194752372 .

[BagelOrb]

The idea of coasting was to combat the part of oozing caused by the last bit of plastic which cannot be retracted because it's already melted and comes loose from the material which is retracted.

However, this effect might be very small and even negligible. Perhaps the idea of coasting should have been to combat the hysteresis effect all along.

The idea and algorithm are simple: a slowdown and speedup at the end and start of extrusion. The problem is determining the length of the speedup. The advance (in mm extruded) corresponding to a given flow (cubic mm per second) is quite a simple formula, but I'm not sure we can rely on it to compute a decaying movement speed for a decaying advance.

Firstly, without making everything depend upon Bowden pressure it's difficult to ensure the correct pressure for a given extrusion segment has been reached.

Secondly, pressure advance should be incorporated in the firmware, since extrusion speed fluctuates within single extrusion segments because it slows down to accommodate sharp corners.

On the other hand our printers have been working quite happily without Bowden hysteresis compensation. I suspect there to be a modulatory effect on the the way the Bowden pressure translates to flow depending perhaps on the move speed.

If the advance scales linearly with the flow in mm per second, what formula should movement speed follow during the slowdown while stopping extrusion and keeping constant flow? And what about the speedup? The movement speed then also decays linearly wrt the distance traveled, right?

I think that means that we should make the length of the slowdown coast move depend on the requested flow.

It would be better to retract during the coasting move, so that the slowdown takes up less time.

We should also be cautious not to let the speed drop too much, cause then the last bit of the slowdown would takes ages. I'm thinking of having a setting to control the percentage movement speed at the end of the coasting slowdown...

Are you following me? This stuff is very hard to discuss over mail.. Op 10 mrt. 2016 14:56 schreef "CCS86" notifications@github.com:

It seems to me that the oozing is a result of the residual nozzle pressure, from the elasticity of the filament and the bowden tube. You either retract far enough to dump all elastic compression and tension, plus a little more to create slight negative pressure. Or you bleed some off first with a coast. It all seems linked to me.

On Thu, Mar 10, 2016, 3:30 AM Ghostkeeper notifications@github.com wrote:

It's just to reduce oozing, as I understood. Since even if you retract, the oozing doesn't immediately stop.

— Reply to this email directly or view it on GitHub < https://github.com/Ultimaker/CuraEngine/issues/274#issuecomment-194752372> .

— Reply to this email directly or view it on GitHub https://github.com/Ultimaker/CuraEngine/issues/274#issuecomment-194852735 .

[CCS86]

The idea and algorithm are simple: a slowdown and speedup at the end and start of extrusion. The problem is determining the length of the speedup. The advance (in mm extruded) corresponding to a given flow (cubic mm per second) is quite a simple formula, but I'm not sure we can rely on it to compute a decaying movement speed for a decaying advance.

I think of it more a a decoupling of print head to extruder position/speed during acceleration.

I've tested Slic3r's pressure advance feature, and wasn't able to get good results. I think that in order to leave printhead speed unaffected, the extruder moves required can get pretty aggressive, and cause problems. Possibly not though. It might have just been that I didn't land on a good setting value, or the implementation is flawed.

Firstly, without making everything depend upon Bowden pressure it's difficult to ensure the correct pressure for a given extrusion segment has been reached.

Bowden pressure is certainly a driving force here. But it's my hope that only with the knowledge of the gcode, and maybe a few tunable coefficients, that you can approximate it closely enough to reap the benefits, without truly knowing the pressure.

It would be super cool to cut the bowden in half, and couple it back together with a strain sensor. You could then have the print head motion driven off of this signal in the firmware. Big dreams :)

Secondly, pressure advance should be incorporated in the firmware, since extrusion speed fluctuates within single extrusion segments because it slows down to accommodate sharp corners.

I agree that it would ideally live in the firmware. I think part of the concern with that for our printers, is the lack of overhead in the Arduino. Unless the algorithm is very light, it could be the straw that breaks the camel's back.

The benefit of it being slicer based, is that it could be a bit more complicated, and preprocessed offline. If you simply input your machine's max XY acceleration into the slicer, shouldn't all the relevant info be there?

I wonder if it couldn't actually be implemented as a post processing script?

On the other hand our printers have been working quite happily without Bowden hysteresis compensation. I suspect there to be a modulatory effect on the the way the Bowden pressure translates to flow depending perhaps on the move speed.

I agree that this isn't a make or break feature. It's really something that could just help take print quality to the next level. It could really help to reap the benefits of a direct drive extruder, without the weight penalty. It could help reduce the required retract move to almost nothing, which reduces dwell time at that point, and the blemishes that creates. It could help perimeter seams almost disappear. and it could prevent that little bit of under-extrusion at the start of a fast print move, which can contribute to a bed adhesion failure. It can also help facilitate a bigger difference in print speeds between areas. In the past, having infill speed set significantly higher than perimeters, was a recipe for extrusion problems. I haven't tried that in the latest Cura though.

If the advance scales linearly with the flow in mm per second, what formula should movement speed follow during the slowdown while stopping extrusion and keeping constant flow? And what about the speedup? The movement speed then also decays linearly wrt the distance traveled, right?

I think that means that we should make the length of the slowdown coast move depend on the requested flow.

My thought was to do some experimenting first and see how simple a correlation we can find. We could write some code which would draw a start and finish line, then extrude between them, with an overshoot area. Like this:

This could be repeated some number of layer high, and then physically measured to see what the distance/volume was before full width was achieved, and how much distance/volume was in the overshoot region. We could test this across multiple machines, and at different volumetric flow rates, and try to find the simplest correlations. It could then be used to test any theories of code modification for effectiveness.

It would be better to retract during the coasting move, so that the slowdown takes up less time.

I agree with this. Maybe at a slower retract speed than is typical.

We should also be cautious not to let the speed drop too much, cause then the last bit of the slowdown would takes ages. I'm thinking of having a setting to control the percentage movement speed at the end of the coasting slowdown...

Sounds good on this too.

[CCS86]

Any thoughts on my suggestion?

[BagelOrb]

I'm sorry to say that we are simply too swamped to implement this in the near future.

I do hope to get this done at some point. I don't know whether it will be this exact change, or a complete overhaul of coasting, but as coasting is now it isn't really helpful.