LIN_ADVANCE = better extrusion control

Discussions about ideaMaker and other printing software.
ABH
Posts: 177
Joined: Sun Aug 14, 2016 7:31 pm

LIN_ADVANCE = better extrusion control

Postby ABH » Sun Jan 28, 2018 8:21 pm

LIN_ADVANCE is a newer feature in the Marlin motion controller firmware.
The filament between the nozzle orifice and the extruder gear isn't a stiff rod (or an enclosed volume of liquid), it acts like a spring, so the traditional Marlin firmware's assumption about a linear relationship between extruder steps and printer-head motion steps is a coarse approximation. The linear relationship is only valid for constant speed. When speed changes up and down, you need to take the dynamic properties of the extrusion system into account. This is what LIN_ADVANCE is about. It regards the filament between the extruder gear and the nozzle orifice as a spring and adjusts the extruder steps dynamically according to this model. The spring constant K, must be found from a calibration. There are instructions here http://marlinfw.org/tools/lin_advance/k-factor.html for generating a calibration g-code file that can be used for finding the optimal K value.
Optimal K value depends on the type of extruder, the filament type and nozzle temperature. I found that for Raise3D premium PLA printed at 215 °C on a Bondtech extruder, I would need K = 50.

The benefits from using LINEAR_ADVANCE should be:
- no need for slicer features like "coast at end" etc. (must in fact be disabled to prevent interference with LIN_ADVANCE)
- reduced need for retraction
- better dimensional accuracy
- no bulging corners
- solid infill much more even (you don't see the rough bulges at direction changes)
- less oozing

I personally found that using LIN_ADVANCE doesn't give you major improvements compared to a well tuned printer using "coast at end" etc, but I also never prints faster than 50 mm/s. Maybe the advantages are bigger when printing faster.
For the models I have printed, you really need to look close to see any difference.
The most noticeable improvement is the smoothness of the top layer infill. It feels completely smooth when LIN_ADVANCED is enabled.
Here are photos of the top of a 20 mm square box.
LIN_ADVANCE.jpg

The print to the left is without LIN_ADVANCE. The print to the right is with LIN_ADVANCE.

You can hear from the extruder sound that it is working differently, when LIN_ADVANCED is enabled.
So far I only used LIN_ADVANCE for PLA, so I don't know the importance of tuning the K factor for other materials.

The motion controller firmware I used, can be found here:
https://github.com/ABH10/Marlin-for-Raise3D-N-series/tree/1.1.x_Raise3D

The default value for K is 0, which means that LIN_ADVANCE is disabled.
You need to use a g-code like "M900 K50" to set the K value to 50. Once you set K to something else than 0, LIN_ADVANCE will be enabled. If you don't add any M900 code, then LIN_ADVANCE is disabled.
The M900 code could be added to the Starting Script.

firesped
Posts: 849
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: LIN_ADVANCE = better extrusion control

Postby firesped » Sun Jan 28, 2018 9:30 pm

what did you set for your slow and fast speed tests? did you leave them at 20 and 70? I'm guessing you want to calibrate that script to the printer.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

stewart
Posts: 45
Joined: Fri Dec 08, 2017 2:17 am

Re: LIN_ADVANCE = better extrusion control

Postby stewart » Sun Jan 28, 2018 11:12 pm

LIN_ADVANCE will be huge improvement for faster prints. I believe it will be absolutely essential for dual extrusion prints especially when the filaments differ. Thanks for providing this fork!

ABH
Posts: 177
Joined: Sun Aug 14, 2016 7:31 pm

Re: LIN_ADVANCE = better extrusion control

Postby ABH » Mon Jan 29, 2018 7:07 am

I just used 20 mm/s and 70 mm/s for the calibration, although I never print with 70 mm/s. There just need to be a clear difference between the two speeds to show accelerate and brake regions. It is better to cover a larger speed range in the calibration than a too small range in order to increase the "sensitivity". The K-factor found from the calibration should be independent of the speeds used in the calibration.
I found that there was a range of K values around K = 40 that looked almost equally good. From testing on a real model I ended up using a slightly higher K value (K = 50).

firesped
Posts: 849
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: LIN_ADVANCE = better extrusion control

Postby firesped » Mon Jan 29, 2018 11:56 pm

working on the raisetouch Pull Request finally. I got the M105 working the same way now using the code in marlin.

need to look into all the other stuff that needs updating for it now. primary version of the firmware requires M190 and some code for the PID tuning.

additional function is figuring out how to make the filament sensor work. not necessarily the same way raise did it.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

firesped
Posts: 849
Joined: Mon Mar 21, 2016 9:23 pm
Location: Tucson, AZ

Re: LIN_ADVANCE = better extrusion control

Postby firesped » Tue Jan 30, 2018 7:47 pm

Now I can post this. finally worked on the raisetouch Pull Request.

user-friend firmware for the N-Series is here. https://github.com/Firesped/Marlin/tree ... ch-Raise3D

Designed to be configured like the Raise3D firmware is. Easy settings in the beginning of the configuration file with documentation.

version numbers are not based on raise3d firmware numbers. so it shows 1.1.8

F commands are no longer there. Instead it now uses a modified M120 and M121 to control the Filament Runout Sensors.

M119 will show the status of the lack material pins. including sensor states and normal states.
Sensor state is used to control the sensor from reporting.
Normal state is used to control the PIN read logic.

M120 S# will turn E# sensor on
M121 S# will turn E# sensor off.
M120 N# will change E# PIN read logic to NORMALLY OPEN.
M121 N# will change E# PIN logic to NORMALLY CLOSED.

LIN_ADVANCED is enabled but k factor set to 0. So will not function without changing the k factor.

As long as raise3d hasn't added anything else to the firmware. should be good.

Note: fast stop on the raisetouch does not work, not sure why. However, the new feature in marlin 1.1.x Emergency Parser is enabled which is better.
RL name: Michael Nolen
printers:
raise3D N2 kickstarter Early Bird
Trinus Deluxe (running smoothieware on Azteeg X5 GT board)
Monoprice Maker Select v2

stewart
Posts: 45
Joined: Fri Dec 08, 2017 2:17 am

Re: LIN_ADVANCE = better extrusion control

Postby stewart » Tue Jan 30, 2018 9:56 pm

Great news! Testing now.

stewart
Posts: 45
Joined: Fri Dec 08, 2017 2:17 am

Re: LIN_ADVANCE = better extrusion control

Postby stewart » Wed Jan 31, 2018 12:28 am

Getting beautiful prints, better infill, corners, etc with k-factor tuned. Thanks for the fork!

Fastmover
Posts: 1
Joined: Wed Jan 31, 2018 5:40 pm

Re: LIN_ADVANCE = better extrusion control

Postby Fastmover » Wed Jan 31, 2018 5:49 pm

Hi

I use Linear Advance on my original Prusa MK2 and the results are just fantastic.
So I look forward on using this feature on my Raise 3D N2 Dual to.
However J have no Idea how to compile new Firmware. I just tried to get all that Arduino stuff running and compiling.
But I allways get an error message regarding missing files even though they are there.

Could someone help me with a step by step tutorial or just even send me the ready to use firmware ?

That would be rally great :-)

I hope my English is OK since I live in the Black Forrest in Germany and dont wirte English often at all

Best Regards

Robert

ABH
Posts: 177
Joined: Sun Aug 14, 2016 7:31 pm

Re: LIN_ADVANCE = better extrusion control

Postby ABH » Thu Feb 01, 2018 8:55 am

You have pre-compiled firmware versions for the std. configurations in the link I provided.
For the N2dual it is here:
https://github.com/ABH10/Marlin-for-Raise3D-N-series/blob/1.1.x_Raise3D/N2-dual-1.1.8.firm
So, unless you need special features, like the run-out sensor, then you should be able to use these versions directly.
Last edited by ABH on Thu Feb 01, 2018 11:49 am, edited 1 time in total.

3Dimensionen
Posts: 8
Joined: Fri Jul 28, 2017 11:36 am

Re: LIN_ADVANCE = better extrusion control

Postby 3Dimensionen » Thu Feb 01, 2018 9:44 am

Hi ABH,

i really appreciate your work and your firmware releases.
Do you already have something in the pipeline for N2plus dual-V2 Hot End and BondTech extruders?
I am no expert in regards of firmware programming :-).

Thank you in advance
Best regards
Peter

ABH
Posts: 177
Joined: Sun Aug 14, 2016 7:31 pm

Re: LIN_ADVANCE = better extrusion control

Postby ABH » Thu Feb 01, 2018 11:54 am

N2plus dual and BondTech is not among the pre-compiled versions I have included, but you could use the std. N2plus dual:
https://github.com/ABH10/Marlin-for-Raise3D-N-series/blob/1.1.x_Raise3D/N2PLUS-dual-1.1.8.firm
I have compiled, and then just set the E-steps for your Bondtechs in ideaMaker, like you propably do today?

ABH
Posts: 177
Joined: Sun Aug 14, 2016 7:31 pm

Re: LIN_ADVANCE = better extrusion control

Postby ABH » Thu Feb 01, 2018 3:08 pm

Hi Peter,
I realize that my Marlin firmware isn't compiled with "DISTINCT_E_FACTORS" enabled, so my proposal above doesn't work. You cannot use different E-steps for two extruders in my firmware. I never had a need for that, so I didn't compile with this option.
I guess firespeds firmware can do what you need. If not, then I would be happy to compile a firmware for you (untested).

socke
Posts: 236
Joined: Mon Mar 21, 2016 2:55 pm

Re: LIN_ADVANCE = better extrusion control

Postby socke » Sat Feb 03, 2018 11:51 am

This is a very nice feature. Unfortunately I don't get firespeds firmware running on my printer. While heating up the hotend I'm always getting this:

IMG_20180202_191020.jpg


Does anybody experience the same?
I already spent hours digging a little bit deeper into this and tried changing parameters of the thermal runaway protection. I found that the error happens exactly at the time (after starting to heat the hotend) defined in this line:

Code: Select all

  #define THERMAL_PROTECTION_PERIOD 40        // Seconds

I tried to increase the time up to 240s, but it didn't help: It heats up and after 240s it brings the error although the hotend reaches the target temperature much earlier - also it doesn't start printing.
Further I tried to change this:

Code: Select all

  #define THERMAL_PROTECTION_HYSTERESIS 8     // Degrees Celsius

But also no success.

Any ideas?
Could it have to do with the modifications for the touchscreen? Should I try the official Marlin code (without touch)? I already tested a merged version of the temperature.cpp from Marlin's bugfix branch, but also no success...

Btw., I can't use precompiled firmwares as I'm using a modified bed and different thermistor. Therefore I'm testing with a slightly modified configuration...

Jetguy
Posts: 2643
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: LIN_ADVANCE = better extrusion control

Postby Jetguy » Sat Feb 03, 2018 12:13 pm

Actually, if you are compiling from source code and you also used the selection of a different sensor type (you stated this for the bed), I don't know 100% that code was carried over from Raise 3D into this branch but I too found some serious issues with the safety code and NO, actually there is chance it's not even the settings part of the code you are staring at. viewtopic.php?f=3&t=4842&hilit=sensor+type

To sum up what we found was that elsewhere in the code, there is other newly added code that when sensor type is changed, the checks are not very logical and use raw ADC values and some assumptions as hard coded values for the limits. In my specific case, I found that you could not set a temp. In other words, you sent a gcode temp to turn on the heater by setting a set point. The problem was, that set point might get set for a second, and then reset to 0. It was extremely frustrating. It's a miracle the code works at all on the stock printer.
Again, what is happening and outlined in that thread, there are various checks and balances in the heater code. In and of itself, that's good, with a giant but in the middle of that, the limiting values, how they chose to implement - changing the sensor type instantly broke the code- something that should not happen. But further investigation made question to the miracle that it works at all as configured.

Again, I posted this as a question and everyone blew it off. Raise 3D said they are checking it out but absolutely no feedback, just crickets.

Jetguy
Posts: 2643
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: LIN_ADVANCE = better extrusion control

Postby Jetguy » Sat Feb 03, 2018 12:31 pm

Again, I think the problem here is not many people get this deep in and change sensor types. I did it because I was investigating making a Raise3D Delta style printer. I used an existing printer (Boots Industries BI 2.5 Delta) I had around, a raise 3D N1 LCD touch box, a standard raise 3D mainboard. But like you had to change a temp sensor type to match the specifics of the hardware. That should not break the marlin source and in the past on previous Raise 3D source code (because I had the forum posts to prove it way back when people damaged early Kickstarter beds) you could change the temp sensors. Like you, the first place I looked was the normal settings in the configuration.h section. Disabling that completely or changing setting had no effect on the faults I saw. That lead to a lot of debugging and eventually, we kicked over that stone and got it functioning but that's that post I shared with you. I have not cross compared sources here to see if that bug exists in the branch you are using and again, I urge the entire community to take a second look here, test with different sensor types on the bench, I know Raise source code 1.1.6 has potential for this problem and I don't know if everyone saw my post about it.

socke
Posts: 236
Joined: Mon Mar 21, 2016 2:55 pm

Re: LIN_ADVANCE = better extrusion control

Postby socke » Sat Feb 03, 2018 12:51 pm

Thanks Jetguy for pointing to this. I didn't see this thread earlier. But I did also see the behavior in some previous version, that a entered temperature was reset. I couldn't test further because lack of time for this and so I reverted to my previous version at this point in time.

However, this doesn't solve the issue. I really wish, Raise 3D would put some more effort into fimware development instead of making ideaMaker more nicely. In fact I bought a printer which needs a good firmware, whilst there are enough slicers on the market. Just my 2 cents ...

@Raise 3D: What can we expect in the future?

@Jetguy: I'm curious, how do you normally debug Marlin? With something like Atmel's JTAG ICE debugger or with some code instrumentation? I'm just curious, not sure if I'm willing to spend the time for that. Maybe I have to think a while about it...

Jetguy
Posts: 2643
Joined: Tue Mar 22, 2016 1:40 am
Location: In a van, down by the river

Re: LIN_ADVANCE = better extrusion control

Postby Jetguy » Sat Feb 03, 2018 1:04 pm

Well, I have to give credit to my friend James Armstrong who really is 10 times the firmware expert compared to my hacky methods. We just kept adding serial debug statements in the code stepping it through and a lot of reflashing. Also, I had enough hardware (multiple boards, sensors, and types of everything) such that we could ensure and cross check it wasn't a one off. I guess I should learn JTAG and use one, maybe could have found it that way too and maybe quicker with a proper setup.

And yes, you and I are exactly in the same thoughts- some new folks hate me for it or just don't get it but yep- you took the words out of my mouth. "I really wish, Raise 3D would put some more effort into fimware development instead of making ideaMaker more nicely. In fact I bought a printer which needs a good firmware, whilst there are enough slicers on the market. Just my 2 cents ..."

socke
Posts: 236
Joined: Mon Mar 21, 2016 2:55 pm

Re: LIN_ADVANCE = better extrusion control

Postby socke » Sat Feb 03, 2018 1:09 pm

Thanks! :mrgreen:

socke
Posts: 236
Joined: Mon Mar 21, 2016 2:55 pm

Re: LIN_ADVANCE = better extrusion control

Postby socke » Sat Feb 03, 2018 2:14 pm

The thermal runaway protection seems to be not the only one problem: In a last act of despair, I completely disabled the thermal runaway protection (which was not that easy, thanks Marlin). But again, nothing happens after heating up everything - the print just doesn't start. Maybe touch screen communication?
For today I'm done. :(


Return to “Software”

Who is online

Users browsing this forum: No registered users and 3 guests