Linear Advance Integration

Matts-Hub commented 7 years ago

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 commented 7 years ago

Thank you for this information.

bubnikv commented 7 years ago

@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 notifications@github.com 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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

psavva commented 7 years ago

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

bubnikv commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

+1, can't wait for this!

Sebastianv650 commented 7 years ago

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 commented 7 years ago

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

bubnikv commented 7 years ago

We at Prusa Reserach are excited as well :-)

GurliGebis commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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 notifications@github.com 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 commented 7 years ago

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

Swiftnesses commented 7 years ago

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

fiveangle commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 notifications@github.com 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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Very nice. What firmware version is this based on?

On Mon, 26 Jun 2017, 16:13 Sebastianv650, notifications@github.com 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 commented 7 years ago

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

Swiftnesses commented 7 years ago

Would someone be so kind to compile a hex?

Sebastianv650 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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, notifications@github.com 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 commented 7 years ago

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

On Mon, 26 Jun 2017, 17:38 Sebastianv650, notifications@github.com 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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

That makes sense :-)

bubnikv commented 7 years ago

@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 notifications@github.com 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 commented 7 years ago

@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)

prusa3d / Prusa-Firmware

Linear Advance Integration #75