[FR] Delta support for LIN_ADVANCE

[ProfDrYoMan]

Hello,

Excerpt: LIN_ADVANCE on delta slows down print, breaks print and gives a lot of "humming" an all steppers while printing.

Long:

I did a switch from repetier firmware to marlin 1.1.1 because of two reasons:

• Delta autocalibration (which works absolutely flawless!).
• LIN_ADVANCE (with a solution inside the ISR).

Repetier firmware uses an "unstable" advance solution which works essentially, but gives way to hard jitter onto the extruder. I guessed it is because advance handling is not inside the ISR.

This kicked me into trying marlin 1.1.1.

Printer is a Anycubic Kossel Plus with a RAMPS1.4 compatible board. USB/UART is running with 250000.
Jobs are driven by OctoPrint 1.3.3rc2. The bowden is ~50 cm long. The extruder got no gear.

Print with advance value K = 0 print as I expect, but the steppers are louder than with repetier firmware. Are there any settings to get marlin quieter?

Speed is 60 mm/s. Acceleration is set to 500 mm/s^2. I am printing a 40x40x5 cube with a 5 mm long notch on one side and a 10 mm long notch on the other side. Only two perimeters. 0.15 mm layer height. Filament is 1.75 nGen.

Even with small K = 30 values the print breaks partly, everything is "humming" and slow.
With a K = 300 value (even higher may be needed for my bowden setup) is starts getting completely broken. Sloooooow, loud, ...

Steps setup and everything is right from my point of view as it is mostly copied from the long working repetier firmware settings.

Any ideas? I will drop my config here this evening.

[ProfDrYoMan]

Maybe linked to this one: #5699

[psavva]

Are you using CURA to slice the model?

[psavva]

@Sebastianv650 maybe you can help?

[ProfDrYoMan]

No. I am using slic3r-dev (build from yesterday from this commit slic3r/Slic3r@6b68b71 off their build server using windows) was used.

Are there any special stuff I need to have correct in marlin for use with a delta? I tried to follow the delta examples. Printing with K = 0 seems ok, but the noisier steppers (as in contrast to repetier).
I only set K (via G-Code) and not the other parameters (all default = 0).

Will upload my configs later.

[ProfDrYoMan]

Maybe linked to this one: #6703

[ProfDrYoMan]

Here are my changes to the default configuration:
https://gist.github.com/ProfDrYoMan/52735c2013038e1c1311187a5508cc0e/revisions

[ProfDrYoMan]

I tested again with the settings above and
M200 D1.75
M900 K200

The extuder does not move into feeding direction anymore. Retracts and redos work.

Setting
M900 K0
and the extruder is not moving as above.

Setting
M200 D0
and the extruder is moving again.

Setting
M900 K200
and the extruder is still moving but there is clearly no advance compensation.

???

[Sebastianv650]

You are the first delta user for LIN_ADVANCE I'm aware of, but if the processing power is enough it should work.

I would do some step by step tests to track down the issues without influences by multiple options:

• Take as much settings from your repetier config without enabling features you hadn't in repetier. See if it works and if the stepper noise is at the same level as with repetier.
• Enable the filament sensor to see if it the extruder keeps alive when using M200. If not, open a seperate issue to keep this clean.
• Even if the filament sensor was working in the step before, I would recommend to test LIN_ADVANCE without it in a first step. If it works, enable it later. Start with K0, comparing the voice of the stepper. If it's only a light difference and it's printing fine, continue.
  Now the next thing is, I wouldn't say "a low value like K=30". Up to now, my tries to get a universal formula all failed - mostly due to the fact I have no validated comparable data from different printers. If K=0 basicaly works and 30 isn't, I would do dry runs (with cold nozzle and cold extrusion warning disabled) and watch to the extruders movement during a test cube "print".
  The correction movements from the extruder should be small but visible, maybe comparable to a filament movement of +- single mm? If it's jumping around like crazy, K is too high regardles of the actual number.
  If the movement is smooth and reasonable, try again with filament and heated nozzle. If the print now fails due to a stalling extruder stepper, your ungeared extruder isn't strong enough for advance.

In any case I wouldn't bet a too high value that LIN_ADVANCE is running on your printer. The processing power of our ATMega chips is already not that comfortable for LIN_ADVANCE and all the things it has to do. That, and added a kinematic printer (a lot to calulate) with a long half-meter feed tube with a semi-soft nGen filament where your ungeared extruder might not be able to do the needed fast movements may be on the edge..
If it fails due to calculation power, you might play with DELTA_SEGMENTS_PER_SECOND. As a owner of a usual XYZ printer I don't know exactly what it will do, but it sounds like a switch to protect it from doing too much calulations.

[oldmcg]

I don't know anything about LIN_ADVANCE, but maybe try M665 S60 (60 segments per second). The regular (non-UBL) delta segments per second with slow feedrates can produce sequences of very very tiny movements. For UBL on delta I added a minimum segment size, default to 0.1mm on delta but #define tunable.

[Maglin]

I was just going to recommend to lower the segments per sec. I'm currently using 160 but when I go to try lin_adv If I saw slowdowns was going to try 100. Also, you might want to try with the LCD disabled to see if that changes anything. It should give you a good amount of extra processor power that you might need.

I believe there is also a minimum buffer slow down option that isn't recommended for Delta's but might solve the strange behavior although it will slow it down when it needs to.

[ProfDrYoMan]

@Sebastianv650 as you see in my config I got nothing extra enabled.
Pretty pain delta config with pid-extruder and bitbang-heatbed and z-probe.
No filament sensor. No automatic bed-leveling or UBL. Just the delta configuration probing.

What puzzels me is that my last test didn't show any change in print (and no advance) with even high K values. I then tried to use M200 and the movement of the extruder stopped, but for retreat and redo.
I will try the same g-code again.

@oldmcg I got 180 segments per seconds configured (as with repetier).
UBL (Universal Bed Leveling?) is off. Not needed for delta with delta configuration probing.

@Maglin I disabled SLOWDOWN as requested in the delta example configurations. I thought the actual LCD code limits the update rate to the LCD im processing power is getting low.

@ALL please review my config above. Maybe I missed something.

[ProfDrYoMan]

Well, I am an "idi**". :) I disabled LIN_ADVANCE in the firmware after it did not work as expected.

Retesting right now with your tips above.

[ProfDrYoMan]

Uploaded a video:
https://filebin.ca/3N1xrklnIEUS
K = 100
DELTA_SEGMENTS_PER_SECOND 60
As you can hear the extruder makes "noises". I do normal retractions with 150 mm/s and 4000 mm/s^2 acceleration and he doesn't skip.

As I have written above, stepper sound on axes with marlin is way louder (even with LIN_ADVANCE off) than repetier. What are the possible solutions for that? Maybe it is linked?

[ProfDrYoMan]

I tried something crazy.
K = 500
=> Extruder starts moving backwards most of the time and only some small steps forward.
Pretty clear that there are some calculation errors I guess.
I am using the last version on branch 1.1.x.

Ok, no LIN_ADVANCE right now.

I will raise acceleration values and lower jerk to get less bleading at the corners. I guess now there will be more ringing, but also more speeeed. :)

Any help on LIN_ADVANCE still appreciated.

[psavva]

K=500 will make the extruder retract in that way. It's the way the algorithm with works if you did actually have such a high pressure in your nozzle.

Turn down K=30 and start from there...

A suggestion that helped me greatly with Lin_Advance was to make my printer use less processing power.

To do so, turn down you stepper driver microstepping. I had my steppers set to 1/32 microsteps, which was way too much for the little ATMega could to handle. Throwing Lin_Advance into the mixture was really pushing it to the extremes.

I lowered my microstepping to 1/16 and all my issues went away with Lin_Advance enabled.

Remember to also turn off any coasting settings in your slicer.

Hope this info helps you.

[ProfDrYoMan]

K = 30 will lead to now effect with 50 cm bowden length.
Yes, with K = 500 it will advance and retract a lot, but it should at least move forward accumulated. Mine went backwards all the way with some stops.

Where do I tune the microsteps? My setting:
#define MICROSTEP_MODES {16,16,16,16,16}

Is this valid for a RAMPSv4 compatible board with A4988 drivers?

Coasting is off. Slicer does not have something like that.

Maybe I will try again with even lower delta_segments and any speedup which is suggested here.

[psavva]

The microsteps are defined by jumpers on the ramps board. The A4988's are typically 16 set to 16 microstepping max...

Check this page to help you set the jumpers on your ramps 1.4
http://www.geeetech.com/wiki/index.php/Ramps1.4#Jumper_Instruction

[ProfDrYoMan]

Thank you for that information.
My RAMPS4 compatible board "Anycubic Trigorilla" has no jumpers below the drivers. From the config above I guess they are fixed on 16 microsteps.

[Maglin]

@ProfDrYoMan I have the same board. It's the one I've been using. I have the Kossel linear. You might want to start out with K=5 and go up from there. I don't know the math behind the lin_advance but I'm willing to bet with such a high K it's like saying there is always a ton of pressure on the nozzle and it's always trying to retract. I'll play with lin_adv this weekend and report back.

[Sebastianv650]

@ProfDrYoMan I thought you have a filament sensor because you mentioned M200 to set a diameter. So you are using volumetric extrusion? What does M200 D0 do then? I'm not familiar with that command.

As a general thing, as @Maglin wrote, don't think as K=x is a low number and K=y is a high one. Maybe for some printers 5 is a high number, where other extruders want 300. Up to now, I can't say that for sure.

I watched your video in a loop over and over again. Things would be much more easy if we could have some debugging information out of Marlin like graphs of X,Y,Z,E speed over time. I'm missing something like SPS analyzer ;-)
In the end, comparing the movement of the print head with the extruder advance seems to work basicaly. What I mean with this is that the extruder moves in the correct directions at a speed related to the print head speed. When you write it's basicaly only going backward with higher K values, if this happens during real prints and not dry run I would think about missing steps. Forward steps will becomme skipped due to the force needed to extrude, backward moves doesn't need that force.
What can also be seen (and heared) in the video is that while it is printing the fast straight line in the later half of the video is that the extruder does some rattling because a delta printer has to do a lot of small arcs to get a straight line. On a non-kinematic printer, you will see such a behaviour in arcs with a lot of points.
While I understand why this can happen, this is still something where some research may be helpful to improve Marlins motion planner or advance calculation. As long as the jerk in the arc points is lower than the allowed XY jerk, Marlin should go smoothly through the arc without acceleration or deceleration. If that's the case, the extruder shouldn't rattle. Again, if someone has in idea how to get speed graphs, that would be awsome!

To get some "slow motion" to see whats going on with the extruder, you can slow down your acceleration to extremely low values like 100mm/s².

One last thing why Marlin 1.1 makes you stepper louder: Marlin has changed the way jerk is calulated from 1.0 to 1.1. If your repetier is using something like the old way of jerk calculation, you should get the same level of noise when you cut the jerk values in half.

[ProfDrYoMan]

Refering to http://marlinfw.org/docs/features/lin_advance.html K is not depending on the printer.

The amount of prefeed or pullback will be the same for all printers, which is pretty clear.
It is clear, that every printer (bowden or not, fillament type) needs a different K value (and borden a pretty high one).
A K value of 10 or 20 gives me close to no visible or hearable extra prefeed or pullback.

I tested many different jerk values. It is not the different jerk which is making the noise.
Marlin is much noisier when doing a straight line (yes, it's not straight with an delta) that repetier in the same case. In the video you can hear the noise (not only from the extruder) the printer is close to that loud if K = 0 or LIN_ADVANCE is not enable.

I really guess it is a bug if the extruder starts to unwind quicky with high K values and doesn't even try to move any step forward.

This may be reproducible with a non-delta printer. I don't know.

Seems I need to quit marlin and get a powerfull 32-bit board with firmware matching it.

[aaulick]

I am seeing exactly the same issue with retract-only on my delta -- K=0 works fine, even K=1 leads to a lot of extruder noise, jitter, and filament making many quick back-and-forth movements but on average more retraction than feed.

Looks like this is issue #7521 , LIN_ADVANCE just has the wrong math for delta printers.

[Sebastianv650]

@aaulick it took some time but I'm now aware of that and working on a version 2. It will take some time, but hopefuly I can create better LIN_ADVANCE code..

[thinkyhead]

@Sebastianv650 — There was a patch recently to help with kinematic feedrates which passes the distance of the current segment directly to the planner buffer functions instead of letting buffer_segment keep getting it wrong. So you might have just the data you need now at the planner level to fix up LIN_ADVANCE for kinematic machines. I haven't looked at the question too closely, so maybe it's not enough yet… or maybe it 'accidentally' fixed LIN_ADVANCE too.

[Sebastianv650]

@thinkyhead yes, that's already incorporated in my work-in-progress v1.5 PR.

[thinkyhead]

Let's move discussion and testing to #9700.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.