Linear Advance Integration #75
Comments
|
Thank you for this information. |
|
@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 ***@***.***> 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
<#75 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I_MY5akzFeuJ8ZvUsWjxPoJUVmqvks5ryKVlgaJpZM4M-XYc>
.
|
|
@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 |
|
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. |
|
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. |
|
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: (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 ! :) |
|
Looks like there is a PR for this awaiting :) |
|
@Sebastianv650 is the developer for LIN_ADVANCE |
|
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. |
|
Thinks @psavva for informing me about the discussion here :) |
|
+1, can't wait for this! |
|
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. |
|
Sounds great! I'll be happy to test it as soon as a beta is ready |
|
We at Prusa Reserach are excited as well :-) |
|
@Sebastianv650 Could you take a look at the work done here, if that would be of any use to you? #99 |
|
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:
#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_ADVANCEMaybe 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. 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.
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. |
|
@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) |
|
@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. |
|
@GurliGebis OK then let's keep the existing PR as a reference. @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. |
|
@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 :) |
|
A small update for the interested ones: |
|
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. |
|
I took two test peaces and made a short presentation. In reality it's even more impressive, but the pictures should do it: |
|
@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 |
|
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. |
|
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 ***@***.***> 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
<#75 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5I80DUJD9Ry45cvniQVY2HKLYZpdUks5sHmN1gaJpZM4M-XYc>
.
|
|
Really nice results - very noticeable improvement. I'm looking forward to giving this a try :). |
|
Great improvement, although minor to my eye... That said, it's an advancement towards perfection! :) |
@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 :) |
|
@Sebastianv650 not EEPROM problem, but memory (RAM) problem I think. |
|
PR #133 just got merged 🥇 |
|
@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? |
|
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? |
|
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. 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 😃 |
|
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. |
|
@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. |
|
@triplepoint, @Sebastianv650 I think it might be a RAM issue, which I'll be able to confirm later on :) |
|
@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. |
|
Is your electronics inside the enclosure? Maybe it's overheating? |
|
Yep, the cables for the motors are too short for me to move it outside the enclosure. |
|
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? |
|
Slic3r generates a gap fill with varying extrusion width for years. |
|
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? |
|
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 ***@***.***> 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
<#75 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFj5IwfbiiWqjF3oCHyKMyd6mRdRqXmdks5shPDdgaJpZM4M-XYc>
.
|
|
@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. |
|
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. |
|
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:
#75 (comment)
|
|
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 :) |
Print fan speed: measuring pulse width
|
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. |
|
Absolutely |
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
The text was updated successfully, but these errors were encountered: