[1.1.x] LIN_ADVANCE v1.5

[Sebastianv650]

Cleanup, squash and rebase of development branch, see #9379.

Changes to v1.0:

• K is now a meaningful value with the unit [mm of filament compression needed per 1mm/s extrusion speed] or [mm/mm/s].
• Load inside stepper ISR reduced as no calculations are needed there any more. Instead, the extruder runs at a fixed speed offset during pressure adjustment. Therefore this version runs faster.
• LIN_ADVANCE now respects hardware limitations set in Configuration.h, namely extruder jerk. If the pressure corrections would need faster adjusments than allowed by extruder jerk limit, the acceleration for this print move is limited to a value which allowes to use extruder jerk speed as the upper limit.
• The pressure adjustment moves doesn't lead to a rattling extruder as it was in v1.0 as the extruder is now running at a smooth speed instead of jerking between multiples of extruder print speed.
• This smooth extruder operation and respecting of jerk limits ensures no extruder steps are skipped.

Keep in mind that:

• High K values (soft filament, bowden printers) will lead to print acceleration reduction. This is unavoidable to keep extruder speed in allowed ranges. You can't expect it's possible to draw a great piece of art with a cooked noodle - there is a reason why the handle of a brush is made from wood.

Todo, required in short term:

• Update Marlin documentation

[Sineos]

Is there a reasonable way to determine max jerk for the extruder?

[Sebastianv650]

Usualy I would trust the printer manufacturer and use their default setting. If that's not available, i would start by putting adhesive tape an the stepper shaft or hobbed bolt to create a visual reference. Then do some back and forth G1 E movements at increasing e jerk until the position of rest starts moving. This might be an upper limit, but maybe this is higher than the value which can be used with inserted filament.

In the end I would do test prints I think. Print a test cube with nearly 100% infill and a realy high print acceleration, increasing jerk every layer. This way, LIN_ADVANCE should always use jerk speed for pressure adaption. The point where the extrusion shows gaps or blobs at line ends is the point where jerk speed was too high. This jerk value multiplied by some safety value like 0.8 should be good to go.

[Sebastianv650]

Documentation update: MarlinFirmware/MarlinDocumentation#130

[VanessaE]

You can't expect it's possible to draw a great piece of art with a cooked noodle

@Sebastianv650, you win the internet for today 😜

[thinkyhead]

Fine work. The only effective change needed was to bump the EEPROM version (V52).

I'll put together a companion for 2.0.x and post it shortly.

[thinkyhead]

You can't expect it's possible to draw a great piece of art with a cooked noodle

I think Henry Miller said something just like that once.

[thinkyhead]

@Sebastianv650 I assume 2,000,000 here is going to be larger for 32-bit, and based on the timer master clock…?

[Sebastianv650]

That's true, it's the frequeny of the clock. So it might be variable or at least different for 32bit boards.

[thinkyhead]

The number just above used for acceleration_rate seems to be the one we want: ((F_CPU) * 0.125) or 1/8 of the CPU speed. Equivalent to…

block->advance_speed = F_CPU / (8.0 * extruder_advance_K * block->e_D_ratio * block->acceleration * axis_steps_per_mm[E_AXIS]);

[VanessaE]

@Sebastianv650 ... So, I decided to give LA 1.5 a shot... I cloned your fork, switched to your LIN_ADV_v1.5_final_1.1.x branch, and configured it for my bot (had to do it by hand, my 1.1.6 config files are too old to commit/format-patch/git-am them over). I am at the "LIN_ADVANCE v1.5 / Cleanup and rebase of development branch." commit (you've re-pushed since I cloned, the commit ID in my local copy no longer matches what's on here).

There seems to be a steps/mm issue. Sometimes prints look normal, exactly as they should, and sometimes they look under-extruded. Also, sometimes X does not move the right distance, at least during G29, which has caused two nozzle crashes (if the X carriage doesn't move to the right spot, the sensor won't be where I told the firmware to put it, so there's nothing for it to sense during a probe or Z-home).

When under-extrusion happens, it's very consistent, as if E steps/mm has been set too low. When it's right, it's consistent all the way through the print and the result looks quite good, regardless of how big or small the object is.

I'm pretty sure the bot is mechanically sound, it was performing well under 1.1.6-release, right up until I switched to your fork.

I do not use EEPROM. K is set to 0 in Configuration_adv.h. I have M900 K0 in Slic3r's print start G-code. The actual desired K value is set via an M900 command in the filament G-code.

The only thing I can think of is that re-flashing the firmware triggers something. That's the only thing I've done between prints (I was tweaking an unrelated setting), besides trying different K values in the 0.10-0.12 range. Incidentally, my bot and the filament I'm using at the moment seem happiest with K set somewhere between 0.10 and 0.11, but I can't be sure yet (using my usual direct-feed extruder with 47:9 geared drive).

[Sebastianv650]

@VanessaE do you use 1.75mm filament? Then the 0.1 might be around what I would have expected. If not it's maybe also just right, I'm just curious.

The G29 is only executing travel moves, no extruder moves at all isn't it? In this case LIN_ADVANCE has no effect at all and in no circumstances it should affect X,Y,Z moves, hm..
I'm not using bed leveling. Does this happen at a noticeable frequency, maybe 2 out of 4? If so, it would be intresting if it's due to some bed leveling changes by testing with LIN_ADVANCE completely disabled. Of course with one hand over the power switch so it doesn't crash into the bed.
If the error isn't present then, I have to do a very deep look into the crystal ball as I have no clue how this could be linked to LA.

The under-extrusions: Is this repeatable with some gcode and not happening with another one? I hope so as you wrote if it's good it continues to be good through the whole print? In this case a good and a bad gcode would be intresting.
Also try enabling LA_DEBUG, maybe it gives some useful information.

Random errors are the worst ones..

[Sebastianv650]

As you had to redo the config files, you might also upload old and new ones here so a second pair of eyes have a look on them. Don't ask how often I was sure I changed everything to my old config and then the printer did all sort of wired things after flashing it ;)

[thinkyhead]

Since block->millimeters is now being provided by the millimeters argument to _buffer_steps this extra and expensive calculation may no longer be needed. See above where it does this…

  if (block->steps[A_AXIS] < MIN_STEPS_PER_SEGMENT && block->steps[B_AXIS] < MIN_STEPS_PER_SEGMENT && block->steps[C_AXIS] < MIN_STEPS_PER_SEGMENT) {
    block->millimeters = FABS(delta_mm[E_AXIS]);
  }
  else if (!millimeters) {
    block->millimeters = SQRT(
      #if CORE_IS_XY
        sq(delta_mm[X_HEAD]) + sq(delta_mm[Y_HEAD]) + sq(delta_mm[Z_AXIS])
      #elif CORE_IS_XZ
        sq(delta_mm[X_HEAD]) + sq(delta_mm[Y_AXIS]) + sq(delta_mm[Z_HEAD])
      #elif CORE_IS_YZ
        sq(delta_mm[X_AXIS]) + sq(delta_mm[Y_HEAD]) + sq(delta_mm[Z_HEAD])
      #else
        sq(delta_mm[X_AXIS]) + sq(delta_mm[Y_AXIS]) + sq(delta_mm[Z_AXIS])
      #endif
    );
  }
  else
    block->millimeters = millimeters;

[thinkyhead]

Following from that, you may no longer need target_float or position_float either.

[thinkyhead]

It looks like the XYZ parts of target_float and position_float are almost certainly not needed.

[Sebastianv650]

Be careful, the millimeters argument is only given by the delta code as far as I remeber the PR. usual print moves will not contain it.
I also don't think it makes sense to precalculate it for any possible case as we have to calculate it once anyway. And I think the right context for this is the planner..

[thinkyhead]

Ah, right. So, is this calculated value also not useful?

SQRT(sq(delta_mm[X_AXIS]) + sq(delta_mm[Y_AXIS]) + sq(delta_mm[Z_AXIS]))

[Sebastianv650]

Using the step values instead of float (and this is not much more, as it's steps multiplied by mm/step) made a lot of problems in the past, therefore I dislike it. I know it could save a lot of cycles but it might cost a lot of time tracking down stange behaviours when LIN_ADVANCE is used.
Small example. All we want to know is the ratio between print move length D and extruded filament length E. Let's say we have a printer with 100steps/mm on X and Y and 400 steps/mm on E. Let's start from all axis = 0:

G1 X0.05 Y0.1 E0.00148 // a typical 3mm filament move with 10 steps inside the move, so well above the limit

This equals a ratio E/D of 0.01324.

Now we convert to steps:
X = 5
Y = 10
E = 1 (instead of 0.72)

Now we convert back to mm again:
delta_mm[X_AXIS] = 0.05 // nice!
delta_mm[Y_AXIS] = 0.1 // also nice!
delta_mm[E_AXIS] = 0.0025 // <> 0.00148..

So our used ratio would be 0.02236, which is 169% of the original value! This means the pressure LIN_ADVANCE advances to is also 169% of the needed one. On the next move, we might round to the oposite value and maybe only get 70% of the ideal ratio, so 30% less pressure than expected.

Of course that's what the extruder will do in real live, the first move will have 169% extrusion compared to what the slicer was telling Marlin and the next on has only 70%. In real world, the spring effect of the filament will safe our print as the pressure will be an average so the delta will be 0 in total. But it's not good at all that the stepper tries to follow this spiky up and down pressure movement at all, we want to keep it calm and pressurize the nozzle to the wanted average pressure.

That's also the reason why we need very high resolution e axis when it comes to fine detail prints like with a 0.2mm nozzle. In this case, the single steps of the extruder are spaced too far away from each other with normal resolution extruders, so the springiness of the filament will not longer safe the print. The result is a highly unstable pulsating flow which ruins the print.

[thinkyhead]

I've added a commit that alters buffer_segment to take the most accurate mm available and apply it right from the start. With LIN_ADVANCE we can can use target_float[] - position_float[] at the outset to get delta_mm[]. Then we get the SQRT(sq+sq+sq) distance into block->millimeters as usual. This eliminates the need for another SQRT and we can just use…

block->e_D_ratio = delta_mm[E_AXIS] / block->millimeters;

[VanessaE]

@Sebastianv650,

[long post ahead, go grab a sandwich, some coffee, and some headache pills 😄]

My apologies for going offtopic, but I couldn't think of a better place to discuss this...

@VanessaE do you use 1.75mm filament? Then the 0.1 might be around what I would have expected.

Yep, 1.75 mm nominal (1.72 mm average; Atomic Bright White PLA at 210°C), fed from a free-rolling bearing-based spool holder (very low friction/drag), driven with a common 32-tooth triangle-profile hob gear into a genuine J-head v8, about 72 mm between the nozzle orifice and the gear-filament contact point. At least we can agree on something being right about my bot. 😉

Does this happen at a noticeable frequency, maybe 2 out of 4?

In my opening tests, I had two under-extruded prints out of 7. Both of those otherwise printed perfectly, were it not for the under-extrusion.

Since the occasional under-extrusion started when I updated, it could be caused by some other bug unrelated to LA, that just wasn't present in 1.1.6.

Is this repeatable with some gcode and not happening with another one?

It doesn't appear to depend on the part being printed, and I've had a hell of a time trying to reproduce it predictably, let alone finding a pattern (see below).

Originally, I did four partial prints of a common "XYZ cube" while looking for a good K value, followed by two positioning tests for unrelated reasons, then the "Ctrl-v v3" calibration piece to see how my chosen setting performs in a more real-world instance. Since I was only trying to dial-in K, I didn't take notes, nor did I save any of the cubes. I still have the Ctrl-v piece, though.

For each print, I changed my K value as needed, in Slic3r's filament g-code, and re-exported (force of habit). I'm 100% certain that I re-flashed the firmware (to tweak my Z probe offset by 0.01 or 0.02 mm) just before each of the two bad prints, but that may be a red herring.

In any case, FOR SCIENCE!!, I went ahead and did the following battery of tests:

Set 1: I loaded a cube into Slic3r, sliced it with my usual settings, K = 0.105, and loaded the gcode into Pronterface. I started the print, then paused it after all of the bottom solid layers were down. I then removed the part from the bed, and immediately re-printed from the start by clicking Pronterface's "restart" button. Thus, identical g-code was printed, with identical-everything-else, every time, as you suggested.

After 10 tests, one was slightly under-extruded, none were failures.

Set 2: I clicked over to Arduino IDE, re-compiled and re-flashed without making any changes to my configs, re-connected with Pronterface, and printed the same cube I already had loaded up. I let it go until all of the solid layers were printed, cancelled the print, and removed the part from the bed. I then disconnected, re-compiled/re-flashed the firmware without making any changes, re-connected, and re-printed.

After 10 tests, none were failures.

Set 3: I did that exact same series of steps again, except I alternated bumping the Probe Z offset up or down by 0.02 mm in Configuration.h before each re-compile/re-flash. Just enough to say I changed it, with only a negligible impact on the printed part.

After 10 tests, two were slightly under-extruded, none were failures.

Set 4: I tried to just recreate the set of conditions where I saw the bad prints. I loaded the cube into Slic3r, then repeated the following sequence: first, I changed my K value in the filament config, then sliced/exported to gcode. Then, I went over to the Arduino IDE, adjusted my probe Z offset, and re-compiled/re-flashed without making any other changes. I then loaded the gcode into Pronterface, and printed. For each test, I changed K by 0.005, and probe Z offset by 0.02, alternating between increasing both and decreasing both (at the same time).

After 10 tests, two were slightly under-extruded, one was a fail (bad underextrusion per my opening post).

Summary: Out of 40 tests,

• 34 printed without incident.
• 5 were slightly under-extruded, probably due to variations in filament diameter going below the minimum needed to create solid layers at my E steps/mm.
• 1 was a failure.
• All of the prints in the first 30 tests were from the same g-code file.
• In all cases in these 40 tests and the several that preceded them, as near as I can tell, a failed part was both preceded by, and followed by a totally good print, right down to the first/last line, which I think rules out hardware and filament issues.

I made one more try, printing a cube with K=0.12. Still came out okay, though its corners were not as rounded as the last time I printed this cube with that setting (one of the initial four).

if it's good it continues to be good through the whole print?

That's correct, if it starts out good on the first layer, it'll be so all the way through, or at least until I cancel the print (no point to print a whole cube if I only need the first 10-15 layers), unless of course the extruder slips or the filament diameter gets too small in some spot. However, that failed Ctrl-v takes ~2.9m of filament, and this being Atomic brand, I can neither blame the extruder hardware nor the filament.

As you had to redo the config files, you might also upload old and new ones here

Here you go, old: configs-old.zip; new: configs-new.zip

As for the failed X move during G29, let's ignore that for now, after all of those tests, I have not reproduced it, so it must have been a transient mechanical glitch. I printed in installed new X and Y bushings just a couple days ago, and they're not fully broken-in yet, so maybe they got bound up.

EDIT: Just to make sure what I have matches what you guys have, I've updated my local copy, now at 9317fcf61f7be6af152042b216b70fbb369aa619 (with my settings on top, via git add/commit/pull --rebase).

[thinkyhead]

I've dropped the extra commit, so this should be back to its old self again.

[Sineos]

Update to the pattern generator: MarlinFirmware/MarlinDocumentation#132

[ghost]

@Sebastianv650
Today i play with your linear advance and i love it , i have strong respect for this , i have seen in the outlines i don't have this old waves just before a direction change ....
I have something to ask you .... FREQUENCY XY limiter ..... Have serious bad maths algorithm , makes spikes , and many extra ordinary behavior .....
May be , if you have time ... You can explore this , and find a better calculation ....
To reduce the feedrate on many direction change is very usefull for large printer , and ... for the printer that have a moving bed ...
You have the exact brain to make it better ... 😄 ... I'm serious

Thks in advance ' in linear advance ' 😄

[Sebastianv650]

@studiodyne thank you, but I will focus mainly on LA especially as long as the "transistion phase" from v1.0 to v1.5 will create more issues.
I also never played with frequency limiting before as non of my printers has a problem with skipping steps due to reconances. So I could also do some theoretical work here, but I might keep it in mind for the future.

[ghost]

Thks 👍
My own issue with all Linear advance , is your values , i never have the same ... For my printer now , in direct drive PET/250deg , 60mm/s , layer height 0.4 / nozzle 0.4 ,
I need 0.06 to finish a circle ...
I have no idea , if it's normal or not , it's my first time with this new LA

[Sebastianv650]

You are the first one who calibrates K using a circle ;) I recommend the pattern generator in the documentation page, but nevertheless 0.06 is in a valid range.

[ghost]

I don't calibrate , it's too long , i don't make G29 ubl pattern too
I set with my eyes when starting a print and it's enough for me
The circles can be explained by , i have made my print with my new firm , and i make 2 skirts outlines to have time to babystep. And i see ... on my 100mm circles ' because my object is circular ' , i see that 5 mm is missing to finish the loop ... i understand and i set to 0.10 , the seconde loop is not totally made , and my inside outline of the object was perfect , with 0.06
And i have LCD->store eeprom
And it's all

Calibration and other things that need to detroy one day , just for something i can make in one second lolll not for me !

Thks

[emphasize]

Hey folks,

I have some hard time calibrating LIN_ADVANCE 1.5. Namely, the rattling - or better: grinding - problem. Lower radius arcs are an absolute drum festival, straight lines are quite normal. The Calibration pattern print says K optimal at 1, but the extruder says otherwise (Apocalypse Now-style). With low K the noises are (obviously) lowered, but also the effect. Upping K means slowing down the system+blobbing. (Accel at 2000, X/Y Jerk 15, E Jerk 10; default) Lower E_Jerk -> slowing system. Upping E_jerk (tried up to 15) -> drums. Max_feedrate { 300, ... , 50} Minimum_Stepper_Pulse 0. The sweet spot is nowhere to be found.

I'm running DUAL_X_CARRIAGE mode (free), but i dont think this is an issue (but on the other hand i've got some problems getting duplication mode running with LA on a week ago - if you recall). Stepper driver current is optimal. (just to rule that out). No retraction set. Bondtech-Bowden setup (416 steps/mm). 1.1.8 hotfix branch firmware btw. Very confusing, because it's stated

The pressure adjustment moves don’t lead to a rattling extruder as it was in v1.0: as the extruder is now running at a smooth speed instead of jerking between multiples of extruder print speed.

You wish. (default_max-)Extruder acceleration is nativly set to 10000. Does that need some adjustments? I'm at a loss here and there are a couple of (possible) turnwheels to adjust. Some guidance would be greatly appreciated.

EDIT: What is the distinction between DEFAULT_MAX_ACCELERATION (M201) and DEFAULT_ACCELERATION (M204). In what scenarios max is needed?

[emphasize]

Another thing to mention: the driving wheel(s) of the extruder moving back and forth. In the back of my mind i remember a statement saying that this should not be the case (some youtube vids visually substantiate this)

[Sebastianv650]

The reduced rattling statement is meant in relation to v1.0. In the old version, the executed extruder speed was quite infinite in some situations, which was realy rattling. This e speed spikes are not longer existing.

A K of 1 means 1mm filament compression for each mm/s your extruder is doing. Of course that will produce some noise, what do you expect it to do :)

The sweet spot is nowhere to be found.

According to your K, you are using a bowden printer. With the reports I have at the moment, I can say that advance isn't working for at least some bowden users due to effects inside the bowden tube itself. The pressure which is generated by the stepper isn't transfered into the nozzle at all, the force is reacted inside the bowden tube. I don't think there is a solution for this problem.
All you can do beside switching to a direct extruder setup might be to look for a K value which gives you prints which are better than K=0. Maybe some much lower K values will lead to a slightly improved print - or maybe not.

The extruder acceleration isn't related to LIN_ADVANCE, only the extruder jerk is important.

What is the distinction between DEFAULT_MAX_ACCELERATION (M201) and DEFAULT_ACCELERATION (M204). In what scenarios max is needed?

Default acceleration sets the default acceleration for print and / or travel moves. The max. acceleration per axis is used to check if an axis acceleration is violated, and if so the acceleration is reduced. For example if you use a print acceleration of 1000mm/s², a max. X accel. of 10.000mm/s² and a max Y accel. of 500mm/s² (maybe a heavy bed) most print moves containing a Y component might be limited.

Another thing to mention: the driving wheel(s) of the extruder moving back and forth. In the back of my mind i remember a statement saying that this should not be the case (some youtube vids visually substantiate this)

With LA, pressure is build up during acceleration, so the wheels move forward (faster than without LA). During deceleration they will move slower than without LA, in nearly every case this means reverse movement. It depends on the amount of pressure which has to be released, which is given by K.

[VanessaE]

LA works a lot better for me as with most, but I think @emphasize is saying that when the nozzle swings around a small hole, LA tends to become overzealous - why waggle the extruder back and forth for each segment? LA should probably look one or two moves ahead and average-out the extruder activity if the move in question isn't obviously a sharp corner or large change in flow rate.

I've seen the same issue. It's only really noticeable when you exceed K=0.2 or so.

[emphasize]

Thanks for weighing in on this @VanessaE. I've read quite a bit of your conversation back in 2016 discussing a somewhat similar - rattle related - topic. But since then the context has changed quite a bit.

LA works a lot better for me as with most, but I think @emphasize is saying that when the nozzle swings around a small hole, LA tends to become overzealous

Exactly. I've seen you talking about MINIMUM_STEPPER_PULSE. Might a higher pulse width (now set to 0) eleminate some problems? Or is that a wrong path?

LA should probably look one or two moves ahead and average-out the extruder activity if the move in question isn't obviously a sharp corner or large change in flow rate.

Very nice proposal. Make arcs great again!

[VanessaE]

a somewhat similar - rattle related - topic

It was the same topic, actually. We just weren't sure of the underlying cause, I guess, but that problem was solved with the LA 1.5 update.

Exactly. I've seen you talking about MINIMUM_STEPPER_PULSE. Might a higher pulse width (now set to 0) eleminate some problems? Or is that a wrong path?

Yeah, ignore that, it no longer applies here.

[emphasize]

when the nozzle swings around a small hole

But its not only that. Thin geometries with just a few (extrusion_width) of "infill" are also problematic. (Is infill-K really that needed?)

[thinkyhead]

Is there an option in your slicer to insert G-code before infill and before perimeters? If so, then it would be interesting to see what happens when you turn off linear advance for infill, but enable it for perimeters.

[VanessaE]

Slic3r has no such option.

[emphasize]

Ideamaker (indirectly) and presumably s3d does. Will check it tomorrow.

(inject gcode after ;TYPE:WALL-INNER / ;TYPE:FILL)

edit: but i dont think unexpected will happen - i reduce the noisy stuff to the perimeter sections. A partial workaround i guess

[emphasize]

It appears that i found the sweet spot. And its really a ... spot. i expected a margin(/or plateau) of some sort. Nevertheless, upwards E_jerk 12 i got increasing noise level. downwards pendulum printing moves.

[Sebastianv650]

Regarding the LA look-ahead, don't adjust if pressure change is below x:
This feature has two sides. On one side, yes, it was on my list for the v2.0 I wanted to do but which was reduced to something I named v1.5 now as I hit performance limitations with most of the features I wanted to implement. While this look-ahead is quite possible, we have to think about what should happen if we have not adjusted the pressure before (because the change was below "x") but in the next step we need an even bigger pressure change. In this case we could run the extruder at the given speed offset for a slightly longer time period or we have to run the extruder faster than K usualy would result in. In both cases, the pressure advance E steps wouln't be perfectly aligned with the time point we need them, but that's maybe OK. In the end, it consumes cycles we maybe don't have on an ATMega.
On the other side, my personal opinion is that XY jerk should be always at a level so that each circle can be executed with the choosen speed without acceleration and deceleration in each small segment. Even without LA, a circle with non-constant speed isn't looking great.

In the end my plan is to wait until 32bit boards are somewhat common. I hope Marlin will split into a 32bit-only version around then, at this point we are free to use all the available power. I'm thinking about s-shaped accelerations, maybe a smarter kind of jerk handling and something like LA 2.0.

[psarkozy]

Dear @Sebastianv650, I am a great fan of your work on LA, as I use a full steel frame cartesian printer. I have switched to MK4DUO (marlin based, updated daily from marlin) firmware on an arduino DUE, which works absolutely fine and has plenty of cpu power to spare :)

Your new LA 1.5 performs best for my direct extruder with very low K values of 0.03mm.

[Sebastianv650]

Nice to hear! Which extruder are you using, I'm always intrested which ones need lowest K values?

[psarkozy]

Direct generic extruder with 95steps/mm. 50mm nozzle tip to gear grip. I just meant to say that there is a working 32bit version of your LA1.5 in MK4DUO.

[cfelicio]

Has anyone tested Linear Advance 1.5 on a CoreXY with S Curve and junction deviation also enabled? Produces a bit of strange behavior for me on the extruder, it goes rattling back and forth like crazy, even with very low K values. Or is this normal behavior? I never used this before :)

[thinkyhead]

@cfelicio — Have you tested 1.1.9?

[cfelicio]

yup, I'm on 1.1.9

After reading a bit more about how it's supposed to work, I guess it's normal for it to rattle back and forth. The fact I'm using bowden doesn't really help, so I will just leave disabled for now, I'll look into getting a direct drive :-)