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

totalitarian commented 7 years ago

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. 20170626_204645 20170626_204736

Sebastianv650 commented 7 years ago

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

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

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.

k-linien

Swiftnesses commented 7 years ago

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

totalitarian commented 7 years ago

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.

20170627_184240

Sebastianv650 commented 7 years ago

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

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

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

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

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

totalitarian commented 7 years ago

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

Sebastianv650 commented 7 years ago

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

bubnikv commented 7 years ago

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

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

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

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

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

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

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

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

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

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

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

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

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

GurliGebis commented 7 years ago

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

3d-gussner commented 7 years ago

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

fiveangle commented 7 years ago

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

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

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

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

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

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

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

IsmaelPR1977 commented 7 years ago

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

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

IsmaelPR1977 commented 7 years ago

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

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

Sebastianv650 commented 7 years ago

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

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

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

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

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

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

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

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

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

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

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

wp_20170724_09_18_50_rich 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:

wp_20170724_09_20_19_rich wp_20170724_09_20_37_rich

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

prusa3d / Prusa-Firmware

Linear Advance Integration #75

ifdef SNMM

else

endif