[Don't merge!] LIN_ADVANCE v1.5 for testers

[Sebastianv650]

This is a most likely working, but unifinished version of a LIN_ADVANCE "v1.5".

After all my tries failed where I tried to improve LIN_ADVANCE with the existing method used, I decided to go with another approach. The final result is the same, but instead of calculating advance steps inside the stepper ISR and execute them in a horrible inconsistent time interval with all sorts of spikes, this one offsets the extruder speed during acceleration and deceleration.
This is done using a reference speed offset which is defined as speed offset needed at an extruder acceleration of 10mm/s². Inside the planner, the extruder acceleration is calculated and based on this and the speed offset for the block.
The extruder ISR is now running at the fixed speed offset calculated for the block during acceleration and deceleration. Each ISR run will execute an advance step together with all other extruder steps (where the extruder steps can only be 0 or step_loop value).
This way, there is absolutely no calculation needed within the stepper ISR, which saves memory and processing time. Also the extruder speed has no spikes any more, which results in smooth running. Another benefit is that we can now check for extruder jerk violations inside the planner easily and limit the speed if necessary.

All this means LIN_ADVANCE is no longer using a spring constant K for tuning but a V value as speed (or Velocity) offset.

This method has a possible disadvantage as well (of course):
It's only precise as long as Marlin is using a true linear acceleration and final speed is always start speed of the next block. As we know, this is only true in an approximation. Might be good enough in reality, has to be tested.
Up to now it's also using the same extrusion length to line length ratio for its calculation as v1.0 did. This means it's also using the float raw values from gcode, but if further tests are fine I would test using the step-based values already available in the planner. Maybe the precission is good enough for this version.
This also means it's most likely also not delta-compatible. For this, I have to understand where the delta transformations are calculated first, and how to calculate the extruder acceleration for deltas. Maybe someone has a good approach?

As you might see, the implementation is not very polished up to now. It's ment to be functional for testing, as long as it's running on a cartesian printer with only a single extruder stepper (no mixing extruder or other fancy stuff).
My first test prints (fast cylinders and parts where I know the v1.0 makes problems) are looking very promising, that's why I decided to creates this PR so others can have a look at it.

Feel free to comment, test it, give advises how to code it better!

Known issues / things todo or check:

• Enable the eISR to also handle others than only extruder 0
• Zero current_adv_steps when the extruder has changed
• current_block is set to Null as soon as the last step_loops is done, but the time until the next block is called is still belonging to the old block. This prevents LIN_ADVANCE from executing the last advance steps.
• Detect retracts which got joined with a short segment by a unusual e/D ratio instead of checking for the leading axis.
• Check if set extruder speed is suitable to execute normal + advance esteps. Might be necessary on low K factors for example.
• Check handling of variable width moves, where no acceleration is present at all
• On variable width path it's possible that we need to deplete pressure during acceleration, therefore LIN_ADVANCE would need to check for the actual direction needed. In this case, the calculated extruder speed will not be the optimum for correction but still good enough.

[Sebastianv650]

Now it should be Delta compatible! Notifying: @mylife4aiurr, @iosonopersia

Linking: #9048

[ghost]

I am in favor of this new maths

For one reason ... The k factor is not linear when nozzle size is changing
I'm asking you about something , you can test for me , may be this new algorithm is linear and don't need to be changed if nozzle change
I'm not sure but this algorithm seems to be portable whatever the size of nozzle , but may be i'm wrong
A print with 0.4 nozzle , and an adjusted k factor
A print with 0.6 nozzle and now , to verify if the k can stay the same

If the k can stay approximatively equal , @thinkyhead will love this new maths
When i use 0.6 nozzle k=5 to have perfect corner of a square , but when i use 0.4 my k=15
If you can create a ' all nozzle k factor ' , you will have my feliciations

[Sebastianv650]

@studiodyne V and K behave in the same way and are even linked by some equation. Therefore the nozzle diameter will change V as it did with K. Nozzle diameter is a basic element that will change pressure behaviour, as it's also true for different filament types, extrusion temperature, filament diameter and so on.

With lots of empirical data it should be possible to find the formula that links all this into V or K, but I don't have a lot of printers to create all that data.

[ghost]

Yes , these maths can work if nozzle size change , but only if filament size have the same size ratio , to avoid the corruption of the ' physical pressure '
ok ok ok
...

[Itox001]

@Sebastianv650 does this mean that it sholud perform better for bowdens? If so, I'll gladly give it a try.

[mylife4aiurr]

i would be happy to try it. :)

Im new too all things github. Is new version lin_advance in bug fix or different branch. Link?

[Sebastianv650]

@Itox001 yes, it should play nice with bowdens. It respects extruder jerk and notifies you if you want to push it over the limits.

@mylife4aiurr At the moment it's only in my personal github fork.

Please note that I think there is a bug in the latest change for kinematic. Use only (kinematic incompatible) version here: https://github.com/Sebastianv650/Marlin/tree/ecfcb73fb5b890a479376a66ed99ca23fd60c775

I will fix it in the next minutes, I hope so..

[Sebastianv650]

Fixed, now it's functional again.

[mylife4aiurr]

I'm familiar with old ways of calibrating K value for cartesian printers (range of lines different k values). But for delta I couldnt use the website to generate the lines with different k values. So for delta I tested linear advance with a calibration object like:
https://www.thingiverse.com/thing:2497674
or
https://www.thingiverse.com/thing:2693748
starting with values above K90. Is this the same procedure, it just says see marlin documentation in your branch...

//#define LIN_ADVANCE

#if ENABLED(LIN_ADVANCE)
#define LIN_ADVANCE_V 1.47 // Unit: Speed offset [mm/s] at an extruder acceleration of 10mm/s²
#endif

where input K value or V value?

sorry noobs question, i really wanna help

[mylife4aiurr]

Ok i reread. K value not used. planner will define based on V value as speed (or Velocity) offset.
So i dont have calibrate anything?

[Sebastianv650]

So i dont have calibrate anything?

@mylife4aiurr you have to calibrate it. In the end the pattern generator has to be modified, but for now such test prints (I would prefer a flat cube) has to do the trick. As this is brand new, I can't give ranges for usual V values up to now. The one inside the config files is about right for my direct drive one. Maybe a calibrated old K value / 100 will give you a rough start point.

@ALL: Known issue with current code base: While the e_accel calculation in commit "sqrt removed / perfomance improvement" gives good results, the latest kinematic compatible version fluctuates around the real value. I have to find a better kinematic formula..

[CCS86]

Okay, I am not so sharp with Github yet. I have my own fork of Marlin 1.1. I created a new branch to Merge and test the LA1.5 code. Am I taking the right approach here, or off track?

[Sebastianv650]

If you don't want to merge other changes as well, you don't need to merge anything. Just download the whole thing from my branch and edit the config files to your need.

[CCS86]

Your PR # 9379 has only the required changes right? Is there a way to merge those into my new branch?

[Sebastianv650]

Yes, it's just rcbugfix plus this changes.
If you have a clean rcbugfix branch I would do it this way:

• Rebase your rcbugfix brach based on marlin/rcbugfix.
• create a new branch from this one with a name like LA1.5
• Create the pr from my branch against your LA1.5 branch.

Then you will end up with a branch that's nearly a copy of my one.

[CCS86]

Yeah, I guess the problem is that my fork is based on the stable 1.1 code, so I would be "testing" more than just LA1.5, if I do it that way. Sorry to muck up your PR discussion.

[mylife4aiurr]

Ok so if old K factor was 190 > 190 / 100 > try #define LIN_ADVANCE_V 1.9 ??? as starting point??

I also want to confirm syntax:
M900 K190 = M900 V1.9 ?????

I'm defining V or K factor in my slicer so I can change it without having to reflash firmware between changes. Or only use for perimeters, etc... Or turn it off.
Does M900 V0 ; disable???

[aaulick]

@Sebastianv650 can you talk a little more about what the V value means exactly?
If we are accelerating the nozzle from 0 to 40mm/s at 10mm/s², and the gcode calls for final e velocity of 1mm/s, what does the extruder velocity or acceleration do?

Is deceleration the same, just reversed, or different?

Is there any change during coast?

Assuming that this is still linear advance, it should be possible to compute V from K so that people don't need to change config files. I want to derive that formula.

[Sebastianv650]

@mylife4aiurr: 3x yes.

@aaulick Acceleration and deceleration is the same, just reversed.

Is there any change during coast?

Coasting is usualy used to speak about a printing move without extrusion (coast at end). That's not happening in LIN_ADVANCE. If you talk about constant speed cruising state, this one is unchanged.

can you talk a little more about what the V value means exactly?
If we are accelerating the nozzle from 0 to 40mm/s at 10mm/s², and the gcode calls for final e velocity of 1mm/s, what does the extruder velocity or acceleration do?

Final or start speed is not relevant for this kind of approach. It could play a role to make it more precise, but not with the power our chips have.
With LIN_ADVANCE enabled, the planner calculates the acceleration of the extruder stepper. For example if you have a print acceleration of 1000mm/s² along 10mm in X and a extrusion distance of 0.1mm, the extruder acceleration is 0.10/10 * 1000 = 10mm/s². At 10mm/s², with a V=1.47mm/s that means we have to run the extruder at 1.47mm/s + extrusion steps during acceleration and at -1.47mm/s - extrusion steps during deceleration.
But the relation is not linear, each other speed offset is calculated by v = V * 0.01 * e_accel².

Assuming that this is still linear advance, it should be possible to compute V from K so that people don't need to change config files. I want to derive that formula.

There should be a easy to find linear relationship. You can try it if you want, if not I will derive the relationship for the final PR.

[CCS86]

@aaulick, LA should preclude the need for coast.

@Sebastianv650, should we not use the original K calibration code generator, incrementing V instead?

[Sebastianv650]

@CCS86 the generator would be the best option, it should work if you replace all "K" to "V" inside the generated gcode. But it needs modification as the script can only generate integer numbers at the moment. So it's not possible to say generate a pattern with K = 1 to 2 in 0.1 increments.

[billyd60]

Edit Nevermind this is an actual bug I stumbled on. Found the fix

Getting an error when I try to upload:

Arduino: 1.6.9 (Windows 7), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

sketch\Marlin_main.cpp: In function 'void controllerFan()':

Marlin_main.cpp:13114: error: 'controllerFanSpeed' was not declared in this scope

       controllerFanSpeed = speed;

       ^

exit status 1
'controllerFanSpeed' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

[billyd60]

I had a successful print on my Taz 5 with 1.5 LA, k .22 with ABS. It did fix the squiggly line issue we talked about in the 1.1.6 cura thread. However it seems to need more overlap when doing layer fill as it was leaving a few gaps that weren't there for 1.1.8

But I am having a minor hardware issue that I just discovered so the under extrusion may be unrelated to your code. I have to repair that and try again tomorrow.

Overall happy but not sure if I needed to change anything in config.h and adv.h relative to previous installs. e.g eisr did I have to do anything with that in the config files prior to uploading? Sorry I have limited knowledge of Marlin just a user.

[thinkyhead]

@Sebastianv650 — Has this advanced beyond the experimental stage at this point?

[Sebastianv650]

@billyd60 Underextrusion shouldn't be related to LIN_ADVANCE, as it isn't changing the absolute amount of esteps. When your problem persists after your repair, do you have problems with infill to perimeter overlap or gaps between the lines itself?

Overall happy but not sure if I needed to change anything in config.h and adv.h relative to previous installs. e.g eisr did I have to do anything with that in the config files prior to uploading?

I'm not sure what you mean with eisr in relation to the config files? Basicaly you only have to change all the values to your needs like steps/mm and so on, and enable LIN_ADVANCE in the configuration_adv.h file.

@thinkyhead yes I think as it is today it's already better than v1 an all points. It respects printer jerk limitations, limits print acceleration if needed, extruder runs smooth and can not skip steps any more. The load on Marlin due to the stepper ISRs is reduced noticeable, in arcs where I would have got stutter with v1 there is no problem with v1.5. Also no problems using high baud rates, I did all my prints with 250kbaud without a single checksum error.
If @mylife4aiurr reboots disapear with his memory saving changes I will call it stable.
The only things which can be improved is variable width paths as I listed them in my checklist (topmost entry of this PR). I will do that, but this can be seen as a second step as v1 also didn't handled this in a usable manner and as it is today is already better than without LIN_ADVANCE at all.
If you think it would be a good idea, I could create a clean PR to be merged, so we get maybe more response from users. The only important thing is an updated documentation, but maybe some notes in the configuration_adv would be a good start, then see what questions will come I have not on my list at the moment and update the documentation after that?

[mylife4aiurr]

My 2 cents.
I think v2 will be great for those that dont have to make the trade off's I had to make, to use it. Delta's tax the computational capabilities of 8 mhz processor already. If I just remove and reinsert sd card, printer pauses momentarily. The character based lcd lags if I try accessing it while printing, so I can just forget about an graphical lcd altogether.

I could have been doing something wrong, but v2 slowed down the printer noticeably. Its was like I had set a slower print speed. K factor 0 no speed impact. Through the calibration pattern gcode I found a K factor of 1.05(newest version) to 1.4(older versions) looked nicest. But using that found K factor slowed the printer down alot. I'm not talking small parts so it cant reach max acceleration. I mean big models that took up 80/90% of print bed, printed slower. If I request 60-80 mm/s it seemed the printer was using 25-35 mm/s max. (ooze control of features s3d had similiar benefits without speed penalty)

With my particular setup:
Delta Auto Config
Unified Bed Leveling
Mesh Validation
SD card support. etc
My Delta's bed is aluminum, it wraps when heated. To mitigate this I do all calibrations and bed leveling with bed and nozzle at print temps as is good practice ofc. The 1st layers delta auto calibration, UBL, and mesh validation produced are simply amazing. Before I learned how to use these features I had problems with bed adhesion, and 1st layer appearance. I would love to use your linear advance in combination with everything else but it seems I'm running into cpu and memory limitations, and the bed leveling I can achieve at this point is a feature I cant pass on for linear advance's sake. Having said all that, I will surely use it on my other printers that arent delta's. I hope to update this Delta with a Re-Arm or Mks Sbase v1.x 32-bit board at some point, then I'm sure these issues wont be a problem.

If @mylife4aiurr reboots disapear with his memory saving changes I will call it stable.

The reboots really bothered me. Im not 100% on the reasons they occurred. They never happened before. They only happened after I complied firmware and got low memory warns. At first I suspected something funky was happening with UBL because the reboots happened on larger models at the edge of print bed. But then the reboots happened on larger models more towards center of print bed. So I suspect the reboots are insuffucient memory issues more than linear advance v2. As I mentioned above Im reluctant to give up awesome 1st layers. Yes I can compile with mesh validation and UBL off, but its hard to do linear advance gcode calibration on a printer with an uneven bed :)

[Sebastianv650]

@mylife4aiurr I don't think the slowdowns are due to calculation speed limitations as this version should be faster. I guess it's the high K due to the bowden which limits acceleration. You can test this by commenting out "NOMORE(accel, max_accel_steps_per_s2);" in planner.cpp. Don't print functional parts with this as it might skip e steps, but it should result in the same print speed and time as with K=0. A simmilar effect (equal CPU load, no time increase) should be able to be simulated by setting K to 0.1 for example without commenting out the line above.
If this tests work, it's not CPU load. If they don't solve print time issue, I'm wrong.

[Sineos]

Updated: https://github.com/Sineos/MarlinDocumentation/tree/k-pattern_update

• Add select for Lin Advance version 1.0 and 1.5
• Add printed K values beside every second test line

When this PR gets merged I will issue a PR against the Marlin docu.

[billyd60]

Most of the problems I had in the cura thread and here were due to a hardware problem. My printer carriage linear bearing on the lower x rod was not being held rigidly. As a result the nozzle height at z=.2 was not right and leveling was off as a result too. (since you use nozzle height to level) I don't use auto leveling.

I have it all sorted out and am printing with 1.1.x and l,5 LA. It works well except I am still not getting smooth layer fill around a hole when the printer leaves a gap and returns later in the layer to fill that gap. When it returns the extrusions are not clean, they are rough with occasional blobs. Nothing to wreck the print but still super irritating since the rest of the layer is perfectly smooth. I can't figure this out. Why would everything get messed up in only those areas? Perhaps this is related to firmware retraction? But if that was the case why wouldn't more areas of the print get messed up (e.g. after every retract).

So my sole printing issue is when filling a layer and a gap is left to be filled later on in that layer, when the gap is filled it is not with nearly the same quality fill as the rest of the layer. Bizarre problem.

[Sebastianv650]

@billyd60 This flat test part should reproduce your problem isn't it? Can you print it with K=0 and K=0.22 or which value you used where the problem get's visible. I will do the same on my TAZ 5 and then we compare the pictures.
My guess would be it's due to over extrusion (not related to advance), but we will see. I printed a lot of puzzle parts this week where infill was splitted as in this hole parts with no issue, therefore I'm somewhat relaxed ;)

lochtest.stl.txt

[Sebastianv650]

I know my first layer z offset wasn't perfect this time, but most important aspect is that the lines are equaly. Here are two 1200dpi scans of the test part:

30mm/s first layer:

50mm/s first layer:

As you can see, I can't reproduce your issue. Looking forward to you ones, please also attach the gcode when done.

[thinkyhead]

Why would everything get messed up in only those areas? Perhaps this is related to firmware retraction?

@Sebastianv650 — Would it make sense for Marlin to ignore all G10/G11 when using linear advance? I guess it would be harder to filter out G1-based retract and recover.

It looks like things are coming along well! If we were to release 1.1.9 really soon —like in the next few days— would we be able to include a working version of linear advance that we have reasonable confidence in?

[Sebastianv650]

@thinkyhead retracts and prime movements are filtered nicely since Commit "Improvement Loop 1" 7c5b6a8.
Up to this point, I was checking if master axis = e axis which is not always a good one. Now the check is:

• Do we have esteps? If not, not advance is needed
• Do we have X, Y, Z steps? If not, it's an extruder only move which is never advanced.
• Do we have a K > 0? Self explaining..
• Is the extruder running forward? Easy check to filter all kind of retracts, wipes and so on.
• New is this one:

// Check for unusual high e_D ratio to detect if a retract move was combined with the last print move due to min. steps per segment. Never execute this with advance!
// This assumes no one will use a retract length of 0mm < retr_length < ~0.2mm and no one will print 100mm wide lines using 3mm filament or 35mm wide lines using 1.75mm filament.
if (block->e_D_ratio > 3.0) {
 block->use_advance_lead = false;
}

I feel very safe with this limit ratio of 3.0 as I think no one will exceed this limits.

For a release in the next days I would take the code as it is today, I will create a clean PR today so you can have a look at it without all the commits between.
We have to keep in mind we will get a lot of questions back as most users will not understand what's going on for example when they get low accelerations with bowden printers using high K values, but this can be answered. And v1 also didn't played nice with high K, but instead slowing down print acceleration it most likely missed steps which is even worse.

[billyd60]

Bad nozzle was the cause.

[thinkyhead]

Replaced by #9700

[prahjister]

Do you have any advice on the other settings that affect the speed and outcome. I made a test from 0 to 3 in .1 increments. Actually I did 1 to 30 then manually went in and changed from .1 to 3. I always get a blob when changing from slow to fast. By the time it gets to 3 it is at a crawl. I did adjust my jerk up to 10 and improved speed. Just not getting the corners like I hoped. Also with the tool to make the gcode pattern should i change things like flow to what I print with. For example I print at .9 but I left it at 1 in tool. I apologise I never really knew of a way to test/calibrate jerk and acceleration. I just been cautious and set low.

[Sebastianv650]

Let's tell us something about your printer. Which material type are you using, which diameter, how long is the distance between hobbed bolt and heat breake?
A good picture of the calibration pattern might also help telling what's going on.

[prahjister]

JGAURORA A5 930mm Bowden pla 1.75mm

Will take a pic tomorrow.

[prahjister]

And should i be using this version? https://github.com/Sebastianv650/Marlin/tree/LIN_ADVANCE_v1.5

[Sebastianv650]

Yes that's the version this PR is based on.

[prahjister]

Starts at .1 from the bottom. Next is .2....I did adjust the extrusion multiplier before this test.
I when i did with .1 i thought it was the 1 that was best now .8 seems better

[Sebastianv650]

Yes 0.8 seems to be quite good.

[bruce356]

Hi, upgraded to the latest version of Marlin Bugfix 1.1.x with Lin-advance 1.5.
Previously used Marlin v1.1.6 with Lin-advance 1.0.
My setting #define LIN_ADVANCE_K 0.06.
Cartesian printer Mendelmax type, E3D V6 hot end 0.4mm nozzle, PLA 1.75mm direct drive extruder with 5 to 1 geared stepper. RUMBA Board with TMC2130 drivers.
With Lin-advance enabled there is a delay in starting to feed filament causing a gap.
With Lin-advance disabled there is no such problem.

Pictures below - thanks

[thinkyhead]

@bruce356 — Copied to a new issue #10156

[Sebastianv650]

Thanks, let's do not extend this one into infinity.