Advance algorithm broken in 0.82

[llluis]

I was using the advance algorithm feature, including the quadratic term, since 0.80 (dev) successfully. However since 0.82, the feature is broken for me. I tough that it was a problem with my setup (motors, configuration, electronics, etc), however, I switched back to 0.81 today and everything is working again, with the same parameters.
The quadratic term can be observed during infill, in direction changes, as the extruder reverts the movement briefly. In 0.82, this didn't happen and suddenly, during a print, the extruder goes nuts, turning fast both ways and then continues. Sometimes just a stall is heard.

I don't know what kind of information I can provide to help you track this down, but, just let me know and I will send it.

Some initial information:

• Filament: 3mm
• Wades geared extruder
• 0.35mm JHead
• ABS
• Extr. 603 steps/mm (16x microstepping)
• Extr. Max Acc 3000
• Extr. Max Feed 50
• Extr. Start Feed 10
• Advance K factor 40
• Advance L factor 30

Thanks in advance.
Regards

[kyrreaa]

Are you sure this isn't related to the recently fixed #99 ?
The jerk setting was not calculated correctly on some angles of movement, especially sharp turning moves.

[llluis]

I believe it's related to the advance because if I disable it (setting both factors to 0 or during compile time) the issue doesn't happen.

[kyrreaa]

Are you sure you are not using the OPS as that is definately broken...
I looked in 81 version and 82 has definately new code for advance.

[llluis]

I never used the firmware OPS. It is compiled in, but configured with mode 0.
I've also had the same advance problem with OPS removed completely.

I've read the 99 issue and believe this one is not related.

[Medeirox]

Hello everyone! I just had the same problem and I'm using 0.83. During the print suddenly my extruder does some kind of "super retraction", spits the filament out and just goes on like nothing happened. Does any one have any clue to this?

I'm using 3mm filament, Wades extruder, OPS off and now Advance Off the board is a PrintrBoard. The problem was presented during the use of the Linear Advance.

llluis, are you using a Printrboard as well?

[repetier]

The problem is fixed in the 0.90 development version.

[kyrreaa]

Are you sure this is fixed?
Tested 0.92+ with latest adjustments to speed and it really doesn't do much at all.
Tested with advance L=0, 0.01 and even 10 and 25. Prints look identical and extruder makes funny screeching/ticking noises.

I have a suggestion though:
Why not remove the entire advance code and add it to the segment planner.
Efter all, each segment has a extruder motion and if the segment is part of accelleration then it will need some extra steps added. If it is part of decelleration, it needs less steps.
This way the step algo can focus on what it is supposed to do, step...
It will also ensure proper pulse shapes.

[repetier]

Advance is complicated and only works good with slow speeds/accelerations for direct drives. At least this is what I think. The higher your acceleration/speed/bowden length the higher the extruder change s get. And they get executed at max. speed which may still be to slow. That gives some clicking and erratic moves, especially on fast edged parts.

Your suggestion sound good on first glance, but requires a completely new path planner, where each line gets split into 3 lines for acceleration, const speed and decelleration. Each update then adjust the length of these areas. For deltas it would also need to add new transformation computations. It would not work on avrs cause of the higher memory usage. And it will not work with quadratic advance. But it would indeed be easier to control extruder speed and position. The current solution with lagging extruder interrupt is not as precise as I would want.

I think we need a third option that allows more control over extruder speed and timing without changing the motion planner. Perhaps moving advance steps inside the normal bresenham and limiting extruder steps to acceleration/decelleration steps even if advance would want more steps. That would at least limit extruder to a resonable speed.

[kyrreaa]

That was my point. Treat extruder as any other channel and let it's limits
be used correctly.
Simplify the step isr and make sure splits line up on acc/dec boundarys.
Memory use will not be much higher. Isr will be simpler and faster and
Cartesian and delta would share all step isr code.
Den 18. mars 2014 09:14 skrev "repetier" notifications@github.com
følgende:

Advance is complicated and only works good with slow speeds/accelerations
for direct drives. At least this is what I think. The higher your
acceleration/speed/bowden length the higher the extruder change s get. And
they get executed at max. speed which may still be to slow. That gives some
clicking and erratic moves, especially on fast edged parts.

Your suggestion sound good on first glance, but requires a completely new
path planner, where each line gets split into 3 lines for acceleration,
const speed and decelleration. Each update then adjust the length of these
areas. For deltas it would also need to add new transformation
computations. It would not work on avrs cause of the higher memory usage.
And it will not work with quadratic advance. But it would indeed be easier
to control extruder speed and position. The current solution with lagging
extruder interrupt is not as precise as I would want.

I think we need a third option that allows more control over extruder
speed and timing without changing the motion planner. Perhaps moving
advance steps inside the normal bresenham and limiting extruder steps to
acceleration/decelleration steps even if advance would want more steps.
That would at least limit extruder to a resonable speed.

Reply to this email directly or view it on GitHubhttps://github.com//issues/107#issuecomment-37908112
.

[repetier]

That is exactly the problem. After each inserted line the acceleration/decelleration boundaries shift or even disappear. So you need to add/remove lines in the middle or shift them around invalidating all previous delta computations. And that is what we need to avoid. But we could move the extruder interrupt code inside the stepper routine. That way extruder speed is more related to the move. But then we still have some other problems depending on the resolution of the extruder. Here higher extruder resolution is bad while we want high resolution for high quality.

[m4rc0d1]

It looks like advance is still not functional. I have a direct drive extruder mounted on the X carriage directly on the hot end. I've tried several combination of linear and quadratic advance values, from very small to ridiculously high values (up to hundreds), but I can't spot any differences in prints.
I carefully tuned esteps, but I continue to have a severe over-extrusion at direction change. This is particularly visible in the top layer infill. I'm working with low acceleration (600) and jerk (10) because of my printer's mechanic. It seems like the deceleration phase at the end of a segment is not reflected in the extruder, even with the advance turned on.

[Nandox7]

I could fix those issues with over-extruding in corners by increasing Jerk.
In my case from 10 to ~20, now I get some nice sharper corners.