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

[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 notifications@github.com 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 notifications@github.com Sent: September 13, 2017 3:37:26 PM To: prusa3d/Prusa-Firmware Prusa-Firmware@noreply.github.com CC: IsmaelPR1977 Iz@IFMarkLLC.com, Mention mention@noreply.github.com 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