Prusa-firmware: Linear Advance Integration

[Matts-Hub]

I've noticed that the firmware still refers to the old version of the advance algorithm in Marlin, and is not able to be configured through M905 like it is now in stock Marlin fw. Refer to http://marlinfw.org/docs/features/lin_advance.html. A new LIN_ADVANCE feature has been introduced which has been shown to drastically improve print quality in some areas.
It would be great if this could be integrated in the next update

[PavelSindler]

Thank you for this information.

[bubnikv]

@quintox303 By the way, do you know whether it works and how well does it
work?
I know there is an implementation of the pressure advance in Repetier and
Sailfish and AFAIK it only works for Sailfish. I did not follow the
development of Marlin since the last summer though.

On Fri, Apr 21, 2017 at 2:47 PM, PavelSindler [e-mail]
wrote:

Thank you for this information.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-296181333,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I_MY5akzFeuJ8ZvUsWjxPoJUVmqvks5ryKVlgaJpZM4M-XYc
.

[Matts-Hub]

@bubnikv Yeah I've seen evidence to show that it definitely does work - and really well too! There was a discussion of it at this post on the facebook group https://www.facebook.com/groups/Prusai3users/permalink/732860686898415/. The user posted pictures taken from another group of prints done on a tevo tarantula (bowden extrusion). If you have a look, you can see the prints are perfect.

There have been suggestions that pressure control isn't relevant for direct drive systems or that it wouldn't make a difference. But the pressure control doesn't only account for spring action in the feeding system before it reaches the nozzle, but also for the actual pressure build-up in the nozzle before extrusion begins. Hence it would be applicable for all extrusion systems. Also the testing that was done for the original documentation I posted in the link of my original post, was all on a direct drive printer.

I also posted some pictures in the comments of that post showing the bulging corners that I was experiencing - something that can and would be fixed through the use of pressure control

[theFPVgeek]

Would love to see this enabled as well. I must reiterate @Quintox303 's statement that it is beneficial to direct setups as well not just bowden. Additionally while "slicers have options to control the nozzle pressure in some ways. Common names are: Pressure advance, Coast at end, extra restart length after retract. Disable them all! The firmware will do a much better job than the best slicer can do, and they would influence themselves in a bad way. It is also strongly recommended to disable further features like wipe while retract.

[fiveangle]

I have 1st hand experience that it makes a huge difference in allowing print speeds that are otherwise unattainable without it. I am considering switching to Marlin 1.1 when it releases to gain this functionality on my MK2, even though it would mean losing all of the wonderful benefits of the PR stream.

On a bone stock _Printrbot Simple Metal with Heated Bed 1403_ with Linear Adv enabled and tuned for PLA I was able to attain identical quality at true 70mm/s that I had to drop to 30mm/s to attain without it. Any model with lots of sharp corners benefits greatly by not requiring glacial-like speeds to keep excellent print quality. The big benefit I see for the PR i3 is the ability to print the more complex but strong Cubic infill at probably double the speed as what we can now, with zero degradation in print quality and strength.

If you print at 20mm/s it doesn't gain you anything, but printing models in an hour at 80mm/s for "Fast" rates with better quality than a 2.5hr print without it really improved the satisfaction level of my Printrbot for prototyping phase of model design. Nobody cares about speed for final rendition, but that's perhaps only around 15% of the prints we do, right ?

It would be oh so grand if PR ported this feature to the i3 stream with Release Notes claiming it "Experimental" and have the "K" factor set to zero by default, which would not change behavior from current, but those of us who understand how to use the feature would gain a 2 to 4-fold factor improvement in "Fast" print speed. Once in the stream, your team could begin kicking the tires of how to best incorporate it. I could envision the already fast "Fast" Slic3rPR profile print time being cut in half (no, I'm not kidding... although you may have to drop the LH down to 3, since 3.5 is pushing the physical limits of the 0.4mm nozzle).

With the L.A. feature, it would really help bridge the gap for the PR i3 between a great consumer printer, and a great prosumer printer.

[fiveangle]

I forgot to mention: top-layer is dramatically improved even at normal speeds.

Regardless, below are two models printed with and without at 120mm/s (no slow-down enabled in slicer) with 800mm/s^2 acceleration values on PBSM1403. Notice the uncontrolled bulging of the fingers around the ring without L.A. enabled:

Standard:

With Linear Advance:

(Original model by wstein: http://www.thingiverse.com/thing:598964)

Here's demo of a print at 100mm/s and the 2EW-thickness thin blades came out absolutely perfect:
https://www.youtube.com/watch?v=dkVFFfI7aMY

(Original model by Dalpek: http://www.thingiverse.com/thing:705095)

With PR controlling the slicer as well with Slic3rPR, you could incorporate Linear Advance feature to change the K value based on the filament profile and print profile to automatically generate the best result. This would be an aboslute game changer for the PRi3. Move over Ultimaker ! :)

[GurliGebis]

Looks like there is a PR for this awaiting :)
https://github.com/prusa3d/Prusa-Firmware/pull/93

[psavva]

@Sebastianv650 is the developer for LIN_ADVANCE
Awesome prints with it enabled.

[bubnikv]

I was looking into the pressure advance theory and implementations since I joined Prusa Research the last spring. I certainly see a value in it and I was toying with the idea of porting the Sailfish pressure advance to Marlin, but due to a lack of time it never materialized. I checked the implementation by @Sebastianv650 this Monday and I find it very clever and cleanly integrated. I especially like the idea how the E events are interleaved with the XY events sharing the same interrupt.

[Sebastianv650]

Thinks @psavva for informing me about the discussion here :)
I had a quick look at the postings happened before. Regarding the topic direct drive vs bowden, I would even say LIN_ADVANCE is better suited for direct drive systems than for bowden. This is due to the fact how Marlin (and I guess most of it's forks) handle the extruder speed / jerk. While it's possible to get smooth (=no speed jumps) movements out of 3 axis, this is not true for a 4th axis (the extruder) except you allow a full stop at each corner. Think about extrusions at different width inside one outer perimeter. Each speed jump will be amplified by LIN_ADVANCE. On a direct drive system, the needed K values are "low" so the extruder will likely be able to follow the movements. On a bowden system with a "high" K value the extruder might skip steps. Therefore, LIN_ADVANCE might not be useable on every printer and every filament out there.
Beside that, on a bowden system there are friction effects due to buckling inside the tube, and I have no idea how it might be able to compensate them.
Note that I don't own a bowden printer, so I have only reports of other users and physical knowledge as a base for the text above. I use a geared direct drive printer with PLA only (except some special prints).

[Swiftnesses]

+1, can't wait for this!

[Sebastianv650]

I'm currently working on the porting to the Prusa i3 MK2 Firmware. Up to now I don't have an i3, so all my coding is untested and I can only check if it "looks good" and compiles. But that should change in the near future :)

I will keep you updated if there are news and of course provide a link to my Github Fork as soon as I think it is ready for beta-tests.
Nevertheless please be patient, it's not only porting. First I have to get, build, calibrate and get familiar with the new i3, after that the first LIN_ADVANCE code tests will start. If I start directly with my modified FW, I will never know if something happens due to a bug introduced by my changes to the FW or if it's a fault of calibration or a build error.

[Matts-Hub]

Sounds great! I'll be happy to test it as soon as a beta is ready

[bubnikv]

We at Prusa Reserach are excited as well :-)

[GurliGebis]

@Sebastianv650 Could you take a look at the work done here, if that would be of any use to you? https://github.com/prusa3d/Prusa-Firmware/pull/99
Currently, it seems like it won't boot with the changes in there (I have only separated it out from the other pull request, that included other changes).

[Sebastianv650]

Oh, I wasn't aware there is already a PR! But if it's not working, it's maybe a good idea anyway to start with my own thing.

On a first look, I would state the following:

• Stepper.h defines Ex_DIR_WRITE and related methods only up to 3 extruders. In stepper.cpp, you allow also the call of E3, which will not exist.
• If this PR leads to a failed startup (no display), it's most likely due to a problem with ISRs. This PR does two steps at once (if not more): My concept of allowing specific ISRs inside some others and LIN_ADVANCE itself. Both manipulate the ISR behaviour, that's why my first implementation does not contain the first one (allowing interrupted ISRs).
• Inside stepper.cpp, you are changing setting of Timer0. I Don't know whats the meaning of this. LIN_ADVANCE is using only Timer1 as the default stepper ISR is using it also:

#ifdef LIN_ADVANCE
  #if defined(TCCR0A) && defined(WGM01)
    TCCR0A &= ~(1<<WGM01);
    TCCR0A &= ~(1<<WGM00);
  #endif
  e_steps[0] = 0;
  e_steps[1] = 0;
  e_steps[2] = 0;
  TIMSK0 |= (1<<OCIE0A);
#endif //LIN_ADVANCE

Maybe this helps if you want to try to fix it.

My version of LIN_ADVANCE for Prusa is a slightly stripped down version. Bubnikv asked for a simple code to ensure usability, and I think that's possible as this FW doesn't has to support every possible printer configuration. Therefore I removed all the extruder related arrays from my variables. On an i3 (even with multi color) there will be never the case where 2 or more extruders operate in paralel for printing. Therefore we will always have a single active one.
As far as I got the multicolor thing up to now - might be wrong - it will always use "the same" stepper, only switching the real stepper over the expander board. Another reason for eleminating arrays. On the other side, when it comes to multi color version of the FW I think we have to add some lines of code to tell LIN_ADVANCE to reset all values on a color (=stepper) change. We will always start with "0 pressure", but that's something for a later time.

A more important decission has to be made how K will be provided to the printer for Prusa FW. My original implementation wasn't storing K into EEPROM, just because it's not a fixed printer value but related to the filament type, which can change.
If the user mainly, but not solely, uses one material kind and switches to another after a longer time there is a high chance he will forget to change or calibrate K. K should be something like the nozzle temperature, you have to select it on every print start and especialy also when you change material during a print (again thinking about multi color/material).
Therefore one option would be to add a specific K to the material preheat settings. Two points are against this:

• The user can't change this settings except by flashing a new FW.
• This settings are not called when the slicer issues a filament / material change.

As a solution, I would recommend to implement an option to store K values filament based inside the slicer. This could be done by a filament change gcode script or (even better) automaticaly by Prusa Slic3r edition. This way, K would be set over M900 on every print start and filament change, in the same way as the slicer has to set the nozzle temperature at the same time point.

[GurliGebis]

@Sebastianv650 The PR I have is a cleanup of another PR, that contained some other stuff as well, that did not make sense to merge in at the same time.

Looking at your feedback, it is clear that there are several other issues with it, so I'm all for going with your work, especially since you know alot more about both the firmware and LIN_ADVANCE :)

I'll keep an eye open for your code, and give it a try when it is ready (and I find out how to recover from a bad firmware flash - not going to experiment with that without having a backup plan)

[fiveangle]

@Sebastionv650 I never understood why baseline Marlin includes a non-zero K value. Was there a reason it was chosen ? I of course set it to zero at compile then use gcode based on filament (or default "0") for the bulk of filaments that I haven't tested. I don't know how anyone would use it otherwise.

[Sebastianv650]

@GurliGebis OK then let's keep the existing PR as a reference.
What do you mean with a bad firmware flash? As far as I know it's nearly impossible to damage the Bootloader because the firmware will not write into this memory area. Therefore even if you flash a completely broken FW version, just load the original one in Arduino and flash again. I also managed it one time to flash a stock Marlin (without my configuration) to my printer with the result that the printer was completely unusable ;)

@fiveangle you are right, especialy if we assume the Slicer should set the K value with the start-gcode script a default 0 would be much better. I will propose this as a default for the Prusa version.
The reason behind the non-zero default value was to give users a feeling for a possible valid range of a K value. Without any hint, it would be hard to find out if you should start the search during calibration around values 0-10 or 100 or even 10000. But this realy should go into the description inside the comments!

[GurliGebis]

@Sebastianv650 If you flash the wrong hex file, the bootloader will be gone, and AFAIK the you have to use the ICSP header to reflash the bootloader back into the atmega chip :)

[Sebastianv650]

A small update for the interested ones:
I got my i3MK2 kit this week and built it yesterday. After little calibration, I got my first test cubes this morning :)
After tracking down an ungly copy & paste error in my LIN_ADVANCE i3 test FW, it's now basicaly "working". Working means all axis are moving and it just printed a quick K testcube. More testing to be done now!

[nrepian]

Nice work @Sebastianv650 :). Have you got any photos you could share with it enabled vs default? I'd be interested to see how it looks on the MK2S.

[Sebastianv650]

I took two test peaces and made a short presentation. In reality it's even more impressive, but the pictures should do it:

First LIN_ADVANCE test result.pdf

[thess]

@Sebastianv650 - This is super! It would be nice if others could try it. At the moment, the firmware in your repo compiles OK, but the extruder is in-operable. Could you push your current version so I can give it a go? TIA

[Sebastianv650]

I know my Git is broken at the moment. But please give me one or two more days for testing and code cleanup and completion. I want to have a quite solid thing I can give to all of you that want to test it before the PR, not a alpha-draft which only generates dissatisfaction and error reports.
I also want to find the perfect K for testers, but 50 seems to be quite good as a first shot.

[bubnikv]

This looks great, thanks! We are looking forward to test it on our print
farm :-)

On Sun, Jun 25, 2017 at 3:41 PM, Sebastianv650 [e-mail]
wrote:

I know my Git is broken at the moment. But please give me one or two more
days for testing and code cleanup and completion. I want to have a quite
solid thing I can give to all of you that want to test it before the PR,
not a alpha-draft which only generates dissatisfaction and error reports.
I also want to find the perfect K for testers, but 50 seems to be quite
good as a first shot.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-310903270,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I80DUJD9Ry45cvniQVY2HKLYZpdUks5sHmN1gaJpZM4M-XYc
.

[nrepian]

Really nice results - very noticeable improvement. I'm looking forward to giving this a try :).

[Swiftnesses]

Great improvement, although minor to my eye... That said, it's an advancement towards perfection! :)

[fiveangle]

This looks great, thanks! We are looking forward to test it on our print
farm :-)

@bubnikv - you may find the parts don't meet your specs due to all the fine tuning you've put into tweaking your farm for production. You've surely tweaked inputs to perfection in order to compensate for the limitations without LIN_ADVANCE in order to get the desired output. I found the increased dimentionsal accuracy with fast prints using LIN_ADVANCE caused me to have to go back and tighten up dimensions that mate to square-cornered parts, decrease hole size for self-tapped thread inserts, etc.

So be sure to test actual assembly of the parts before shipping to MK2S users ;)

But after recalibrating your process, I suspect this feature will increase your farm output at least 50% at better quality.

ps- so excited at the possibility to soon have this in the standard Prusa FW so I don't have to give up all the other Prusa-specific features :)

[probonopd]

I suspect this feature will increase your farm output at least 50% at better quality

Interesting. Which settings do you suggest to change (e.g., which speed settings to increase, and typically by how much)?

[fiveangle]

Typically, all of the tweaking to reduce speed from max for different activities (perimeter, outside perimeter, infill, top layers, support, etc) become relatively moot since LIN_ADVANCE allows more accurate deposit of the amount of material under wider range of conditions. That said, I suspect the same speed changes may help at the new upper top-end but would have to be determined by trial-and-error.

For me, using Simplify3D on an otherwise stock Printrbot Simple Metal 1403 with Heated Bed, Where it required 50mm/s max with 1500mm/s^2 acceleration plus various slow-down tweaks to attain perfect quality, I found I was able to remove all slow-downs, increase max speed to 100mm/s, decrease acceleration to 800-1000mm/s^2 and print usually 50-70% faster (shorter time) with higher quality end result.

In short it broadens and extends the range of print speeds that allow quality results so we don't have to hand-tweak every little thing. I'm extremely curious to try LIN_ADVANCE on the MK2 using SlicerPE because they have tweaked these speed settings so maticulously — I'm interested to see if simply bumping overall speeds by 100% (while reducing printing accelleration in FW) will result in same or better quality. Could all the tweaks help extend the speed of printing even further than we've previously seen on other printers with LIN_ADVANCE ?

There's not been any printer running LIN_ADVANCE that had so much slicer optimization done to it that i am aware of, so it would be yet another huge win if it turns out all the tweaks Prusa has done ultimately allow LIN_ADVANCe to scale print speeds even further up.

Can someone say 150mm/s "Prototype" mode ? :)

[Sebastianv650]

@markaswift On one side it looks slightly more impressive in reality, each picture is always 2D so something is lost. On the other side, it's how you define minor and major.
The final thing that made me thinking about starting LIN_ADVANCE development was the print of an extruder body with PETG. I wanted to print it quite fast, there was no need to have a nice looking part. But I always get gaps between the perimeter lines, as we can also see them on the pictures in the pdf. This means the part is defect for me - it will fail during load much earlier than a print without gaps.
Therefore, one (and for me the biggest) advantage from LIN_ADVANCE is that we can now print much faster without voids somewhere inside the print, resulting in mechanicaly full functional parts.

When it comes to visual quality, LIN_ADVANCE also helps with that especialy on mechanical parts with corners. As the red lines in my pictures show, a cube has not a cube shape but something like I would call a pillow. This is a visual problem at first, but can also be a problem when it comes to mechanical fit of parts as @fiveangle stated above. Another thing is top surface quality, mostly noticeable on parts with flat top layers where you get a quite rough infill to perimeter intersection area without LIN_ADVANCE.

Of course, slowing down print speed is a solution. But why print external perimeters at 20mm/s when our hotend is capable of extruding up to 10mm³/s and our axis can do above 100mm/s? With LIN_ADVANCE, you can get the same quality at much higher speeds.

@probonopd it's not possible to say you can increase speed up to x times compared to without LIN_ADVANCE, it depends on the parts and your needs. But on my TAZ, I sometimes just set all the speeds to 60mm/s without slow downs with great results. An upper limit (at least with Marlin on my TAZ) is given by the calculation speed of the Rambo board - when it starts stuttering in arcs, it's too fast and this harms visual quality much. I'm looking forward the see if something like this happens also on the i3, but my first curvy print today was no problem at 60mm/s so it seems to work better :)

[bubnikv]

@Sebastianv650 I did some optimizations of the planner code in November
2016,
when I converted some of the planner code from floating point to a fixed
point arithmetic.
Also it helps, that our printers are equipped with plain character displays
as serving a large
graphics display is quite CPU consuming. So it may be, that our firmware
will start
stuttering at quite higher print speeds than the TAZ.

On Sun, Jun 25, 2017 at 10:42 PM, Sebastianv650 [e-mail]
wrote:

@markaswift https://github.com/markaswift On one side it looks slightly
more impressive in reality, each picture is always 2D so something is lost.
On the other side, it' how you define minor and major.
The final thing that made me thinking about starting LIN_ADVANCE
development was the print of an extruder body with PETG. I wanted to print
it quite fast, there was no need to have a nice looking part. But I always
get gaps between the perimeter lines, as we can also see them on the
pictures in the pdf. This means the part is defect for me - it will fail
during load much earlier than a print without gaps.
Therefore, on (and for me the biggest) advantage from LIN_ADVANCE is that
we can now print much faster without voids somewhere inside the print,
resulting in mechanicaly full functional parts.

When it comes to visual quality, LIN_ADVANCE also helps with that
especialy on mechanical parts with corners. As the red lines in my pictures
show, a cube has not a cube shape but something like I would call a pillow.
This is a visual problem at first, but can also be a problem when it comes
to mechanical fit of parts as @fiveangle https://github.com/fiveangle
stated above. Another thing is top surface quality, mostly noticeable on
parts with flat top layers where you get a quite rough infill to perimeter
intersection area without LIN_ADVANCE.

Of course, slowing down print speed is a solution. But why print external
perimeters at 20mm/s when our hotend is capable of extruding up to 10mm³/s
and our axis can to above 100mm/s? With LIN_ADVANCE, you can get the same
quality at much higher speeds.

@probonopd https://github.com/probonopd it's not possible to say you
can increase speed up to x times compared to without LIN_ADVANCE, it
depends on the parts and your needs. But on my TAZ, I sometimes just set
all the speeds to 60mm/s without slow downs with great results. An upper
limit (at least with Marlin on my TAZ) is given by the calculation speed of
the Rambo board - when it starts stuttering in arcs, it's too fast and this
harms visual quality much. I looking forward the see of something happens
also on the i3, but my first curvy print today was no problem at 60mm/s so
it looks to work better :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-310926933,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5Iz3C0BoWV19pyCcy-XzQmQSEQSg-ks5sHsYjgaJpZM4M-XYc
.

[Sebastianv650]

I think it's ready to be released to everyone who wants to give it a try. I rebased my branch and added last bugfixes and cleanups:
https://github.com/Sebastianv650/Prusa-Firmware/tree/MK2-LIN_ADV-DEV

Feedback is welcome!

[Sebastianv650]

Here is a flat cube for K calibration tests, also see http://marlinfw.org/docs/features/lin_advance.html for more details. M900 Kxx is used to set a K value.

Prusa_K.txt (rename to .gcode)

[totalitarian]

Very nice. What firmware version is this based on?

On Mon, 26 Jun 2017, 16:13 Sebastianv650, [e-mail] wrote:

Here is a flat cube for K calibration tests, also see
http://marlinfw.org/docs/features/lin_advance.html for more details. M900
Kxx is used to set a K value.

Prusa_K.txt
https://github.com/prusa3d/Prusa-Firmware/files/1102587/Prusa_K.txt

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311089517,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACRnIP-sq1BC9tK53Mc-Mi474FliSe4Yks5sH8q2gaJpZM4M-XYc
.

[Sebastianv650]

It's based on the Prusa MK2 branch as it is today - that means 3.0.12 RC2.

[Swiftnesses]

Would someone be so kind to compile a hex?

[Sebastianv650]

Here you go, created using Arduino. It's for an i3 MK2 with 1.75mm filament and Rambo 1.3 - no multi material. Use at your own risk!

Prusa i3 MK2_LIN_ADV.txt (rename to .hex)

[GurliGebis]

Nice, with a bit (a lot unfortunately) of luck, someone with commit access will see it and merge it. Would be nice to have in the firmware though :-)

[Sebastianv650]

I will create a PR when there are some positive feedbacks. Nothing is worse than a quick untested PR that might also get merged as a worst case ;)

[totalitarian]

I was hoping it would be the latest RC branch as as was having issues
unloading with the non RC version.

Am I right in thinking we need to turn off coasting etc?

On Mon, 26 Jun 2017, 16:53 Sebastianv650, [e-mail] wrote:

It's based on the Prusa MK2 branch as it is today.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311101371,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACRnIF9f-7LyebWNc0d-9yXEl0q06Vm4ks5sH9QPgaJpZM4M-XYc
.

[totalitarian]

I'll run a test in a couple of hours. 20mm cube ok?

On Mon, 26 Jun 2017, 17:38 Sebastianv650, [e-mail] wrote:

I will create a PR when there are some positive feedbacks. Nothing is
worse than a quick untested PR that might also get merged as a worst case ;)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311113809,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACRnIFaa-TGQo2DNL_f-G-p-fbFiokaIks5sH958gaJpZM4M-XYc
.

[GurliGebis]

@Sebastianv650 two questions - where does it persist the K value? (cannot find any EEPROM changes to persist it - might just be me missing it though). And didn't you forget to update the variants folder configs, to enable LIN_ADVANCE?

[Sebastianv650]

@totalitarian it's based on 3.0.12 RC2, state of today. That's the MK2 branch.
Coasting should be off, that's true. Print whatever you want, if you use PLA give it a try with K50 (M900 K50). If you use other materials, you will have to do the calibration first.

@GurliGebis

where does it persist the K value?

Nowhere :) See the last half of my post above: https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-309014166
I don't think it's useful to have a single stored value.
Regarding the variants foder: Up to now in my branch, LIN_ADVANCE is enabled by default (see Configuration_adv.h). In my PR, it will be disabled by default. I think it's better this way until we got enough feedback to say it's OK to enable it also for i3 MK3 beginners. In the end, this decision is up to the Prusa DEV team.

[GurliGebis]

@Sebastianv650 I see, didn't think about that, but you are right :) since it is on a per-filament basis, having it as part of the filament specific gcode in slic3r makes alot more sense.

Is there a reason for having it as an option that can be disabled in the firmware? (AFAIK, a K value of 0, which is the default, is equal to just the normal advance code).
Wouldn't it make more sense to just remove the old non linear advance code it replaces?

[Sebastianv650]

Is there a reason for having it as an option that can be disabled in the firmware?

I made it this way because it's the usual coding style in Marlin, how new options are handled. I also think it would be a too hard cut to make a PR that completely eleminates the known behaviour.
Basicaly, K=0 will lead to a simmilar result as a disabled LIN_ADVANCE, except some small overhead. When the Prusa team decides it's stable and can be always enabled, they can remove the ifdef statements or call me to do it.
The old ADVANCE isn't existing in Prusa FW (except some smal fragments I removed during my changes).

[GurliGebis]

That makes sense :-)

[bubnikv]

@Sebastianv650 I have flashed the firmware to three of our printers, we
will be testing it tomorrow. I am really curious how it will come out.
Thanks.

On Mon, Jun 26, 2017 at 8:52 PM, GurliGebis [e-mail]
wrote:

That makes sense :-)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311149106,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I-B0ScwWfPRvWUJDCuzL02oyksmaks5sH_3cgaJpZM4M-XYc
.

[GurliGebis]

@bubnikv a quick off-topic question, would Prusa Research be interrested in a unified firmware, that works with both the single material and multi material version of the MK2? (Just to know if it is worth working on, or if I should just close my pull request)

[totalitarian]

Flashed and a 20mm x 10mm cube. left cube was using the default prusa profile, right cube was using K50 with the settings as per here

Sorry the filament is probably not the best to notice the differences.

One thing I did notice is the K50 cube (right) has tighter corners, but they are also stepped a little as show in photo 2 and the edge is not square. Obviously I need to do some more tests and calibration.

[Sebastianv650]

Hard to see any difference. But at default speed that's not a surprise: The visual faces are printed at 25mm/s (external perimeters) and 30mm/s (top surface). At these speeds, LIN_ADVANCE will not do much as there is not much pressure to correct.

[totalitarian]

Yeah I should have used a better colour. BTW the K50 was done at 70mm on
all visible surfaces

On Mon, Jun 26, 2017 at 9:06 PM Sebastianv650 [e-mail]
wrote:

Hard to see any difference. But at default speed that's not a surprise:
The visual faces are printed at 25mm/s (external perimeters) and 30mm/s
(top surface). At these speeds, LIN_ADVANCE will not do much as there is
not much pressure to correct.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311167017,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACRnIMeg3igFNdkf9Qags-q2G3FhJ7Duks5sIA8zgaJpZM4M-XYc
.

[Sebastianv650]

I created a simple gcode which can be used to determine a good K value very quickly. No more need to print a lot of flat cubes:

• It prints a single zigzag line where each line is printed with another K value.
• First line is K=0, each following line is 10 units higher.
• Each line consists of 3 line segments in gcode: A 20mm slow segment printed at 20mm/s, a 30mm fast segment (70mm/s) and finaly a 20mm slow one again (20mm/s).
• The current gcode uses PLA temperatures and K ranging from 0 to 90. For other materials, just the tempertaures and K values has to be changed.

gcode: K-Line Test.txt - rename to .gcode to use it.

Having a look at the final line widths, it's very easy to see what K value we need:

• If you get a thinner line width during the acceleration from 20 to 70mm/s and a slight blob during deceleration down to 20mm/s again, this K value is too low.
• If you get a thicker line width (blob) during the acceleration from 20 to 70mm/s and a thinner line width during deceleration down to 20mm/s again, this K value is too high.

Here is a labeled picture from my PLA test print. Don't get confused by all line widths on the left are thinner than on the right side - clearly a bad bed leveling. This is not related to LIN_ADVANCE ;)

• You can clearly see the signs of a too low pressure correction (too low K value) from K=0 to 20. At K=30, it's still noticeable.
• The lines with K=40 and 50 both looks good.
• The lines starting with K=60 and up have the signs of a over-correction of the nozzle pressure (K too high).
• So we can say the perfect K will be somewhere between 40 and 50. 45 will be a good value to print with.

[Swiftnesses]

Excellent. Have you considered using the bed measurements as an indicator of 'k' value :p

[totalitarian]

Excellent test. Here are my results, sorry they are not as obvious as your photos as I was struggling with lighting. One tip i've found is that if you rub your finger along each line you feel which ones are smoothest. I think my ideal is also between K40 & K50, would you agree? Also could I get a copy of your profile for PLA as i'm still a little unsure what needs tweaking to print with linear advance.

[Sebastianv650]

@totalitarian based on your picture I would take 40. If you have a flat bed scanner (if that's the right wording), it might help with inspection in such situations when you peel of the line path from the cold bed carefuly and make a scan with highest dpi from it. Works like a magnifier!
I have no finished PLA profile, I even don't have a real "take this one" profile for my much older TAZ 5. I'm used to work with basic profiles and adjust the settings according to the object I want to print. It's more easy for me this way than to create a lot of profiles for all the possible combinations (tech. parts, figures, with and without support, ..).
That said, there is no special setting you have to change due to LIN_ADVANCE. I would recommend to reduce the infill/perimeter overlap from 25% to 15% to increase (top) surface quality even more. Beside that, you can increase the speed using LIN_ADVANCE - but how much depends on the model kind.
Two examples:

• For technical parts (more or less straight lines with only a few arcs), you can basicaly print at the maximum flow rate your hot end can handle. I have not measured the limit of the 1.75mm e3d v6, but I guess at 0.2mm it should be save to go up to 80mm/s likely even more.
• For figures and other objects with "free style" surfaces, it highly depends on the mesh detail and the shape itself. To get a perfect outer finish, it's important that the nozzle mooves around the perimeter lines very smoothly. Every acceleration / deceleration (even with pressure correction) will add imperfections. Therefore, it's still safe to increase speeds like infill, solid infill, support and so on up to 80mm/s. Even the perimeter lines can be printed quite fast, but the problem here is that imperfections to the inner perimeter lines will not be eleminated completely by the external perimeter, regardless how slow you print the external one. So keep the perimeter speed at a reasonable speed, maybe 50 or 60mm/s. External perimeters are the most important ones, 30-40 should be a good start point.

[Sebastianv650]

Beside changing the speed, you can play with retraction settings and other things in the printer tab. For example, a wipe while retract might no longer be necessary. If your esteps/mm setting is properly calibrated, even a lift z during retract shouldn't be necessary - this was the first thing I changed in the profiles as it leads to a lot of vertical "zits" on the prints if they are not covered by the next layer. This will also reduce the print time.
I also disabled retract on layer change as I see no need for it, but your milage may vary.

[totalitarian]

@Sebastianv650 Thanks. I took it from http://marlinfw.org/docs/features/lin_advance.html that there were specifics that needed to be changes. Such as setting all speeds to the same value. I guess that was just for calibration purposes?

[Sebastianv650]

If you are refering to

Set all print speeds for the cube to the same high value, 70mm/s for 0.2mm layer height for example - but be sure to not exceed the flow rate your hotend can handle!

Yes, this is only relevant for calibration. The only things you have to set or deselect permanently are described in "Before Using Linear Advance".

[totalitarian]

Great, going to try a full print now 👍 thanks for adding this.

[totalitarian]

@Sebastianv650 what do you have your acceleration set at? I put all mine to 500mm/s

[Sebastianv650]

I used the 500 only for the k calibration tests, for normal prints I'm using the default settings.

[bubnikv]

@Sebastianv650 Thanks for a great job. We tested your code on our farm
prints and the improvements of the print quality at high print speed are
convincing. For our ABS-T we used K=25. K=50 was too high for ABS-T as ABS
has a much lower viscosity then PLA, therefore less nozzle pressure is
required.

Do you think your code is ready for a pull request? I quickly browsed
through your changes and they are quite minimal and localized, so I would
not be afraid to merge the code, maybe with the LIN_ADVANCE symbol disabled
by default.

We are now going to test your implementation on our multi-material bowden
setup. I am really curious whether it will work and whether it will help to
fight some of the stringing issues we are having with PET-G.

On Wed, Jun 28, 2017 at 7:52 AM, Sebastianv650 [e-mail]
wrote:

I used the 500 only for the k calibration tests, for normal prints I'm
using the default settings.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311563258,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I8u0dlLlvsweVTjIpslHD7Tlyq6zks5sIeoQgaJpZM4M-XYc
.

[nrepian]

@bubnikv, if this gets integrated in to the next firmware update, would we be able to save the K value in Slic3r PE under "filament settings"? It would be a handy place to have it.

[bubnikv]

if this gets integrated in to the next firmware update, would we be able
to save the K value in Slic3r PE under "filament settings"? It would be a
handy place to have it.

There is a new filament specific start G-code available since Slic3r PE
1.35.2.

[GurliGebis]

Since there already is some placeholders in the gcode, I would imaging it would be possible to have a specific field for it, and have it inserted into the filament gcode automatically.

[bubnikv]

@Sebastianv650 The multi-material setup has the direction of every 2nd extruder reversed. I had to adapt the advance_isr() function:

'''
void advance_isr() {

nextAdvanceISR = eISR_Rate;

if (e_steps) {
  bool dir =

ifdef SNMM

    ((e_steps < 0) == (snmm_extruder & 1))

else

    (e_steps < 0)

endif

    ? INVERT_E0_DIR : !INVERT_E0_DIR;
  WRITE(E0_DIR_PIN, dir);
  for (uint8_t i = step_loops; e_steps && i--;) {
    WRITE(E0_STEP_PIN, !INVERT_E_STEP_PIN);
    e_steps < 0 ? ++e_steps : --e_steps;
    WRITE(E0_STEP_PIN, INVERT_E_STEP_PIN);
  }
}

}
'''

One thing makes me a bit nervous. Without LIN_ADVANCE, the steppers are interleaved, so that the settle time for the digital signals to the stepper drivers are observed. With LIN_ADVANCE, the E axis is controlled separately and the stepper signals are toggled as quickly as possible. It may happen, that the steppers will not keep up.

[Sebastianv650]

@bubnikv

For our ABS-T we used K=25. K=50 was too high for ABS-T as ABS has a much lower viscosity then PLA, therefore less nozzle pressure is required.

That's a great finding! In fact I never used ABS before (only PETG) and when I did an estimation for ABS some month ago I only compared Young's modulus which would mean ABS K around 85. I wasn't thinking about differences in viscosity.. I will add that as a reference to the Configuration_adv.h section.

I like @GurliGebis idea about the placeholders, it would make the filament change / start gcode generic as it is today with bed and nozzle temperature.

One thing makes me a bit nervous. Without LIN_ADVANCE, the steppers are interleaved, so that the settle time for the digital signals to the stepper drivers are observed. With LIN_ADVANCE, the E axis is controlled separately and the stepper signals are toggled as quickly as possible. It may happen, that the steppers will not keep up.

In Marlin they are interleaved: Starting the signal for each axis, after that stopping the signal in the same order. In Prusa FW, they are not interleaved (or I don't understand what you mean with interleaved):

if (counter_x > 0) {
  WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN);
  counter_x -= current_block->step_event_count;
  count_position[X_AXIS]+=count_direction[X_AXIS];   
  WRITE(X_STEP_PIN, INVERT_X_STEP_PIN);
}

Only one subtraction and one addition is between the signal switching, which is almost nothing. (about 3.5µs)
But this was also my fear when I did the porting. But in fact it works on both of my Rambo boards, the i3 itself and my TAZ 5 where I also use no delay in Marlin. As it is also working on your test system, I would call it save as long as we don't change to a faster board. Then, also the xyz routings will need delays, or even better an ISR for switching on and another for switching off to get a true 50% high/low signal.

The multi-material setup has the direction of every 2nd extruder reversed. I had to adapt the advance_isr() function:

I was not looking into snmm definitions up to now. I see, you are using always E0 (as expected) and there is a own snmm_extruder variable to track the active one for switching e direction and other stuff.
I will add snmm handling based on your code changes. Additionaly, I want to add a function that resets the actual filament pretension variable to 0 so the FW knows that on every tool change we start with 0 pretension again.

Then I would answer

Do you think your code is ready for a pull request?

with yes and I will create the PR.

[GurliGebis]

@Sebastianv650 once it has been merged, I'll see what I can do wrt. fixing PR Slic3r to have a placeholder for the M900 command :) (Though I cannot guarantee anything, since my pull requests seems to be ignored completely by upstream)

[Sebastianv650]

PR #133 is in place.

@GurliGebis bubnikv motivated me to do the LIN_ADVANCE porting, therefore I think he will do with Slic3r PE whatever is best to support LIN_ADVANCE for the i3 :-) So if you have a good PR for Slic3r and it's helpfull, I think he will merge it (if he isn't faster on his own).

[GurliGebis]

I'll give it a try, if not for anything else than an exercise ;)

EDIT: Scratch that, it's been too long since I have touched perl for me to do this.

[totalitarian]

@Sebastianv650 i'm getting a rough (blobs) on the top surface where the top infill meets the perimeter. Any ideas what could cause this? Overlap is set to 15%

[Sebastianv650]

@totalitarian rougher than with 25% or without LIN_ADVANCE? Wich material and k value are you using, can you provide pictures and the print profile you used?

[thess]

@Sebastianv650 - Thanks for the addition. With LIN_ADVANCE enabled, my results have been dramatically improved. This is especially true for corners and sloping edges like 3DBenchy gunwales.

@totalitarian - After adjusting retract settings for LA slicing, I do not see the type of problem you have been observing. I found that using existing g-codes does produce distortions and zits but after re-slicing them with various retract settings adjusted or disabled, things are pretty good.

[totalitarian]

@thess could you share your profile. I did manage to fix mine by lowering the extrusion multiplier in the end.

[GurliGebis]

@Sebastianv650 heard anything from PR on this, or are we at the "wait and hope it gets picked up" stage? :)

[3d-gussner]

Hoped it will be in 3.0.12... :-(
@bubnikv @PavelSindler how did the tests in your farm went?

[fiveangle]

are we at the "wait and hope it gets picked up" stage? :)

Lovin'it over here (although haven't had too much time to optimize profiles). I don't expect to be upgrading anytime soon until it's merged official :)

[fiveangle]

@bubnikv @PavelSindler how did the tests in your farm went?

My curiousness would be on the systems that you implemented it on in your farm, did you set K=0, and can you confirm the results are identical the previous GA release without L-A ?

If this can be confirmed, then the fear of merging would be subsided. I've not seen a single additional hesitation or studder on my system, but being simple cartesian, text LCD, integer math planner optimizations, and relately low steps/mm in all axis, the MK2 really is the most ideal 8-bit platform for this realtime math-heavy feature.

[bubnikv]

how did the tests in your farm went?

The linear advance did not find its way to our print farm yet due to other
issues to be solved there after we moved to a new bigger site recently.

So thanks @Sebastianv650 for your efforts, we will certainly merge your
Linear Advance, but it will take some time to test it thoroughly at our
side before we will push it out officially.

On Wed, Jul 12, 2017 at 7:17 AM, Dave Johnson [e-mail]
wrote:

@bubnikv https://github.com/bubnikv @PavelSindler
https://github.com/pavelsindler how did the tests in your farm went?

My curiousness would be on the systems that you implemented it on in your
farm, did you set K=0, and can you confirm the results are identical the
previous GA release without L-A ?

If this can be confirmed, then the fear of merging would be subsided. I've
not seen a single additional hesitation or studder on my system, but being
simple cartesian, text LCD, integer math planner optimizations, and
relately low steps/mm in all axis, the MK2 really is the most ideal 8-bit
platform for it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-314650220,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5I25xpnmRZ7iWNxJuDbOKJKS5ofJ_ks5sNFbmgaJpZM4M-XYc
.

[Matts-Hub]

I'm just about to flash this onto my printer tonight so I'll post some feedback soon. @Sebastianv650, you did an awesome job! Has anyone else considered how this also may have a positive effect on seams left at the beginning/end of perimeters? You would think that by reducing the pressure to zero at the end of an extrusion, you'd be able to reduce the size of the bulge that's made..

[Sebastianv650]

It will definitly help with the line start/stop quality, especialy the line end will be smoother as it's acting like "coast at end". But I have no comparison parts at the moment to show pictures.
But have in mind that this effect might not be too impressive, because there will be always a visible seam and there are other things influencing a "blob" at line start and end also. For example:

• How long does the nozzle will stand still at line start / end? This is defined by retraction speed and length.
• It looks different with Z-hop enabled / disabled.
• Will the next move go inward the part or away from it.

[IsmaelPR1977]

Hi @Sebastianv650 I love all the work that is being done here! I have a free printer that I love to try this on! A pre-compiled version of Prusa 3.0.11 firmware would be ideal is that is possible.

[fiveangle]

@IsmaelPR1977 : https://github.com/Sebastianv650/Prusa-Firmware

[IsmaelPR1977]

@fiveangle Please excuse my ignorance but what do I do once I am at that link that you shared with me? Thanks in advance.

[Sebastianv650]

You can find a pre-compiled .hex file with all the changes in it there. See the description here.

[IsmaelPR1977]

@Sebastianv650 thanks! I am also able to compile firmware, so I might give it a go from the version that you linked me to. Though I wanted to try and stick with 3.0.11 since I don't have the MMU nor plan to get one for either of my two MK2 printers. I have my two printers customized with 3030 aluminum extrusions so I definitely want to give this community mod version a try, but it is based on 3.0.12 correct?

[GurliGebis]

@IsmaelPR1977 Yes, it is based on 3.0.12 , with a few other fixes and then LIN_ADVANCE :)

[Sebastianv650]

There is no disadvantage of 3.0.11. If you are not configuring it for MMU, you will end up with what you have at the moment (+ some bugfixes etc).

[IsmaelPR1977]

Hi @Sebastianv650 the M900 Kxx value can be placed in my slicer like S3D? Thanks! I am about to give your FW a try, just finished compiling.

[Sebastianv650]

I don't know which option s3d has in regard to m900,therefore i can't answer the question. But you can place the command in the start gcode section for example.

[IsmaelPR1977]

I have printed several cubes with different K values in ABS but I am still getting the bleeding corners. Does the M900 code need to be in a specific location in the gcode script? Thanks in advance for the help!

[robrps]

@IsmaelPR1977 Did you make the same mistake I did and not uncomment the line 275 in Configuration_adv.h?
//#define LIN_ADVANCE
to
#define LIN_ADVANCE
Otherwise, have you run the K-Line Test.gcode from https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-311386115 you should see a clear difference, especially towards the back of the test print. If it all looks the same, and you have uncommented that line, then try adding the full M900 command - S3D might not be compatible with the auto detect mode (I've not tried it with S3D)
M900 K45 W0.4 H0.2 D1.75
where W = extrusion width
H = layer height
D = fillament diameter

It's making a noticeable difference with my PLA prints (Haribo + Titan)

[GurliGebis]

@Sebastianv650 what would a recommended K value be for PETG?
I have tried printing 25x25x2mm cubes with 70mm/s and 500mm/s2 and a K value of both 50, 100 and 150, and they all have bulging corners.
I have read somewhere that 150 is a good starting point for PETG, but it seems quiet high, compared to the test G code file you have attached.

EDIT: Ignore this for now, I'll try again, this time with LIN_ADVANCE enabled in the configuration file.
Thanks @robrps for pointing this out :)

[Sebastianv650]

@robrps wrote everything important :-)
Especially now that i recommend the zigzag pattern to test different k values instead of cubes. This works much faster and you can test a complete range of k values. Just edit the gcode to the k values you want.

[GurliGebis]

@Sebastianv650 I'm seeing some weird things when running at default acceleration with 70mm/s speeds.
I have tried printing the first 6mm of a benchy, and there seems to be some "spill" at the front.

Should I slow down the acceleration, or some of the speeds? (I'm not sure what I should change to fix it)

[fiveangle]

@GurliGebis - Other than the possible opportunity to reduce/eliminate slicer tweaks designed to deal with pressure-induced problems (some levels of coasting, wiping, large retract, massive slow-downs in certain types of paths, etc) here's no "magic" to tuning with Linear Advance vs. not.

The stock Slic3rPE, PE print profiles, and PE FW give you a good baseline. If you can stand the slow speed that it accomplishes it at, the results are great.

Venturing into the land of Linear Advance and trying to boost print speeds puts you back in the realm of standard printer tweaking: adjust, wash, rinse, repeat :)

[Sebastianv650]

@GurliGebis do you use an mk2 with petg for the tests? Which k value, and do you have a picture of the zigzag test pattern?

[GurliGebis]

@Sebastianv650 yes, MK2S with 3.0.12-2 firmware, with your MK2_LIN-ADV-PR branch merged.
I'm running it at K=60 - here is the zigzag pattern (it is bent a little, since PETG likes to do that, if you remove it before it has cooled down)

I have tried rotating the picture, but github insists on it being rotated like this.

Here is the first 6mm of benchy printed with 70 mm/s speeds, with normal acceleration:

I have tried printing it with 500mm/s2 acceleration, and it seems to improve it a bit, but I'm not sure what to make of that :)

[Sebastianv650]

I think you have a problem with overheating here. The upward curling front is a sign for this, the second usual reason for upward curling is internal stresses when you lay down the filament around a tiny radius on an overhang. In this case, nozzle pressure adaption can't help also, increasing fan helps a bit but only thing that helps 100% is then to reduce the print speed a lot (20mm/s or less) to give the printed line to relax the internal stresses before the nozzle moves on. I opened an issue in prusa slicer to handle such cases.

So, try again with k0 and play with fan settings until you get a curling free print also at the wanted speeds.

[GurliGebis]

I'm running the fan at 30%, so might be worth increasing it a bit, to see if that helps.
I can also try turning down the temperature a bit (printing at 240, which is in the high end of what the filament specifies.

If I set K to 0, wouldn't that disable linear advance completely, resulting to problems with the higher speed?

[GurliGebis]

@Sebastianv650 Going from 30%/30% fan speed to 60%/100% fan speed seems to have fixed the problem.
So that is worth thinking about if using PETG at higher speeds :)

[IsmaelPR1977]

@robrps you were right, I still had it commented out. I enabled it and for sure there is a vast improvement in my ABS printing. Did several tests and a value of K21 is the sweet spot for my MK2 printers. I have modified them both with 3030 extrusions so needless to say the print quality improvement is pretty obvious and not to mention at much faster speeds now. Thanks @Sebastianv650 and everyone who has worked on this. Many thanks.

[robrps]

K60 is the sweet spot for the rigid.ink PETG that I'm using as well. I've been printing at 50mm/s as I believe it prefers its slower than PLA. My fan is at 30%/50%, but it's a big GB1205PKV1-8AY blower type.

[robrps]

@Sebastianv650 In your Configuration_adv.h comments it mentions

Slic3r (including Prusa Slic3r) produces Gcode compatible with the automatic mode.
Cura (as of this writing) may produce Gcode incompatible with the automatic mode.

Is there a way of checking if that is the case with other slicers? At the moment I'm assuming that Simplify3D doesn't and I'm adding the full M900 K45 W0.44 H0.2 D1.75.

I can add that to either the Material Config or the Print Quality Config, but as the M900 command contains both K and H settings it means altering one of the values manually if I change, for example, from PLA to a flexible material.

My ignorance of gcode means I'm not sure if I can add the M900 K45 to the Material Config, and add a post process line to the Print Quality Config to add a second M900 W0.44 H0.2 D1.75 command before it print a skirt/brim(or somewhere). Would the 2nd M900 override the first and fall back to the firmware default of K0, or would it remember the first K value and combine them? of course this is non-point if I can confirm if Simplify3D is compatible with the automatic mode.

[fiveangle]

I've observed Start GCODE in Slic3rPE runs before the material GCODE is ran (so material GCODE will be last active prior to print start).

[IsmaelPR1977]

@Sebastianv650 I am placing my M900 K value as the last line of my S3D start script and I am getting great results at this point. I do not use the full M900 script.

[cbarreto61]

@robrps I was wondering how far you can push the speed with PETG, it is my material of choice since I print mostly mechanical parts. I havent been able to test this feature yet since I am traveling for work :(

[IsmaelPR1977]

Josef mentioned having linear advance in the next firmware release in a post I responded to on our FB group.

[robrps]

@cbarreto61 I'm currently printing the SpannerHands 1Kg spool holder in PETG at 50mm/s. Before the linear advanced I wouldn't print it faster than 35mm. This probably isn't a good example though as most of it is perimeters...

[GurliGebis]

@Sebastianv650 I just had an interresting problem with the LIN_ADVANCE code.
If I print a small circle with 100% infill, the circle does not get extruded, but the infill does. (It seems like small extrusions of filament gets ignored).
The only fix I could do was reflash it with the original 3.0.12-2 firmware.

I don't know how this could be causing this, since I has been printing fine with LIN_ADVANCE for the past few days.

Any ideas?

[Sebastianv650]

Back from holiday, sorry for the delay :)

@robrps as @IsmaelPR1977 is using the short form of M900, it should be fine. In fact the short "M900 Kxx" should always be the prefered one, especialy when you use a slicer capable of doing thin walls / variable width infill. Otherwise, variable width paths will not be handled correctly because the real flow rate (real width) is not taken into account. Slic3r is using variable widths since a long time, S3D is using it since version 4.0 so you should use the short one except you are seeing strange print defects (missing steps) that can't be solved in another way.
The only reason I added the long version of M900 is Cura, as it was producing realy strange code at this time. When you plotted the extrusion widths along all printed line segments, you got every number from infinite small to a multiple of the choosen line width randomly. Not sure how Cura behaves at the moment.

@GurliGebis can you provide me the gcode and model causing the problem? I have no instant idea what could be the problem, but I will try finding the reason. It was a PETG print?

[GurliGebis]

@Sebastianv650 It is this stl file (I haven't got the gcode, but it has been printing fine several times before the problem happened) : https://www.thingiverse.com/download:3542754
It is PETG i'm using - I haven't kept the gcode around (octopi reinstall, but that's another story)

[GurliGebis]

@Sebastianv650 My only idea is, that it is some kind of memory corruption, that it was fixed by restarting the printer when I flashed the original firmware (I'm running out of PETG and need to have these printed fine, so going without LIN_ADVANCE untill I have printed the parts I need, then I'll go back to LIN_ADVANCE).

If you want to see if you can trigger it, take the model I linked, cut it in two at the 110mm mark, and keep only the top (so you have the two top "dots"), then try and print them at 0.2mm with a 5mm brim

[Sebastianv650]

So you printed this thing with LIN_ADVANCE with success and after some copies it failed. A memory (EEPROM) problem would be strange as the printer isn't storing something as long as no M500 is executed. So if something happens, a power cycle should reset everything.

You wrote the problem happened only on small circles, and in this stl the circle leads to the small perimeter speed to be applied. What was your speed here, compared to the (solid?) infill? Are all perimeter loops completely missing or are there some stringy / underextruded perimeters.

At the moment I can't test this under real conditions as I only have the original PLA filament shipped with the i3. My older printer (TAZ 5) is using 3mm filament and I got a lot of eSUN filament end of last year when they sold it for an incredible low price. So I have to empty my storage before I want to switch.

When you have some remaining time and PETG, maybe you can do some prints and pictures of the failure (if it is reproducable again), also with K0 and half of your normal PETG K value to see how it correlates with K value.

[GurliGebis]

@Sebastianv650 not EEPROM problem, but memory (RAM) problem I think.
All the perimeter loops are missing, but only if the perimeter is small (like the small "dots" on top of the model)
As soon as I get these printed, I'll go back to the LIN_ADVANCE firmware and see if I can reproduce the problem, with pictures, gcode and everything :)

[GurliGebis]

PR #133 just got merged 🥇

[cbarreto61]

@robrps I am glad to hear that it helps you print faster. I am intrigued because on my machine I print always at 50mm/s, but still I suppose is not as fast as yours since I have the speed reduction for infil, perimeters and so on. I wonder if you have tried faster speeds?

[3d-gussner]

1st Thanks for the great job @Sebastianv650 and the rest of you testing it!!!

Do you think anyone could share the Slic3r PE config.ini or Slic3r_config_bundle.ini?
If you are using Octoprint don't forget to delete the API key from the shared files.

[Sebastianv650]

Nice to see it got merged :)

My Slic3r profiles are quite away from the default ones as I don't like some of their default values, therefore I think it's not a good start point for people that are used to the default ones. It's also always a question of quality one want's to have in the prints.
Let's see what happens to the default profiles, maybe they create a fast profile for use with LIN_ADVANCE?

Now I have an i3 and a TAZ 5 with LIN_ADVANCE. Both print fine, but I like to have one tool per job.. I think the i3 has to become multi material as soon as the lead time for orders goes down or my 3mm filament is low enough to be replaced by 1.75mm one :smiley:
A multi-material direct drive would be my choice, but that would be a medium-big project beside upgrading to the multi material update..

[triplepoint]

Congrats on getting this landed. Was there ever any follow up on the missing perimeter loops issue @GurliGebis reported? I'm concerned this was merged to master with a potential bug unresolved.

[Sebastianv650]

@triplepoint I will have a look into the perimeter issue when GurliGebis can do some tests. But I don't expect an error in the main meaning as LIN_ADVANCE is running in Marlin the same way for a longer time. Maybe he hit some mechanical limits with PETG that can be improved or avoided with some other settings.
Up to now I'm quite relaxed as LIN_ADVANCE isn't handling small circles different from a line, infill or other printed segments. So if it's dedicated to perimeters and small circles and it has worked before, I think about other things maybe first than a software bug that should be reproducable (LIN_ADVANCE isn't using pointers or fancy arrays that might cause RAM corruptions).

[GurliGebis]

@triplepoint, @Sebastianv650 I think it might be a RAM issue, which I'll be able to confirm later on :)
I'm pretty sure I won't be able to reproduce the problem.

[GurliGebis]

@Sebastianv650 I just had the problem with stock firmware, so it is not linear advance related. I'll try a power cycle once it is done cooling down, to see if that helps (my guess is that it will)

EDIT: Turning off the power, waiting a few minutes and turning it back on fixes the problem.
So it seems like it is some kind of memory corruption issue, when it has been running for too long, inside an enclosure.

[fiveangle]

https://www.youtube.com/watch?v=PtXtIivRRKQ :)

[Sebastianv650]

Is your electronics inside the enclosure? Maybe it's overheating?

[GurliGebis]

Yep, the cables for the motors are too short for me to move it outside the enclosure.
That is also what I'm thinking :)

[ceryen]

Does K=0 exactly equal the old behavior or does K=0 only approximate the old behavior?

I ask because Cura and Simplify3D (with dynamic single extrusion) may potentially produce gcode that is incompatible with linear advance. So if we wanted to use those slicers, would setting K=0 avoid the incompatibility or is that not sufficient to avoid the incompatibility?

If setting K=0 does not avoid the incompatibility, can we consider making linear advance a toggleable option?

[bubnikv]

Slic3r generates a gap fill with varying extrusion width for years.

[ceryen]

Sorry, I had seen a comment on the Marlin issue tracker indicating that Simplify3D's dynamic extrusion width could be a problem, but I'll defer to your knowledge.

What about the code comment that Cura may produce incompatible Gcode, is that not an issue either?

[bubnikv]

Sorry, I had seen a comment on the Marlin issue tracker indicating that
Simplify3D's dynamic extrusion width could be a problem, but I'll defer to
your knowledge.

From my point of view, you never know until you try. There are are just too
many effect playing with / against each other, like the material viscosity
& extruder delay, velocity & acceleration control etc.

On Mon, Sep 11, 2017 at 10:35 AM, ceryen [e-mail] wrote:

Sorry, I had seen a comment on the Marlin issue tracker indicating that
Simplify3D's dynamic extrusion width could be a problem, but I'll defer to
your knowledge.

What about the code comment that Cura may produce incompatible Gcode, is
that not an issue either?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-328458956,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFj5IwfbiiWqjF3oCHyKMyd6mRdRqXmdks5shPDdgaJpZM4M-XYc
.

[Sebastianv650]

@ceryen K0 will work with any slicers gcode, that's for sure. If the current Simplify3D creates issues, I can't tell as I don't use it. Cura was producing wired gcode that was incompatible with LIN_ADVANCE, but as fare as I know it was the only one.

[fiveangle]

No one has come forward with any evidence that gcode generated by S3D is incompatible with L.A. Until that happens, it's all just F.U.D.

[IsmaelPR1977]

I use it with S3D just fine, no issues. K values work as they should.

---

Ismael Feliciano

--- Original message ---
From: Dave Johnson [e-mail]
Sent: September 13, 2017 3:37:26 PM
To: prusa3d/Prusa-Firmware [e-mail]
CC: IsmaelPR1977 [e-mail], Mention [e-mail]
Subject: Re: [prusa3d/Prusa-Firmware] Linear Advance Integration (#75)

No one has come forward with any evidence that gcode generated by S3D is
incompatible with L.A. Until that happens, it's all just F.U.D.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/prusa3d/Prusa-Firmware/issues/75#issuecomment-329289441

[Sebastianv650]

For information, some people over at MarlinFirmware/Marlin#8079 wrote a script to use the Test zigzag-pattern with variable K values, temperatures and so on. Could be very useful :)

[3d-gussner]

Checkout https://shop.prusa3d.com/forum/original-prusa-i3-mk2-f23/firmware-3-1-0-rc2-mk2-multi-material-mk2-s-mk1-t6454.html#p45064

[GurliGebis]

Wouldn't it be safe to close this issue now? It has been added to the firmware a while ago, and have had some time to get tested.

[Matts-Hub]

Absolutely