[1.1.6] LIN ADVANCE w/ Cura 3.x #8827
Comments
|
Slic3r produces Gcode compatible with the automatic mode if Linear Advanced. Cura does not produce Gcode incompatible with the automatic mode due to the dynamic widths of the Filament layed down. Where x.xxxx is the calculated ratio according to the formula : Example: 0.4 * 0.2 / ((1.75 / 2) ^ 2 * PI) = 0.033260135 An alternative is to set |
|
This is set in the configuration adv by the way... |
|
Is Cura doing dynamic widths when "flow equalization" is disabled? I'll try defining that parameter and see if it helps, thanks. |
|
I don't think it will help. https://ultimaker.com/en/resources/20419-speed |
No, LIN_ADVANCE is using the volumetric flow speed of the extruder. Everything else won't work. When I wrote the code, there was a problem with Cura generating single segments in a kind of random pattern which contained a crazy extrusion ratio magnitudes away from real world values (not related to variable extrusion as used in gap fill). Therefore the option for fixing the ratio was introduced. If you send me a sample gcode of a not working file I can have a look at it how it behaves todays. Back then, Cura wasn't using variable gap fill as far as I remember so this work around worked quite well. |
|
"it will hurt if used together with a fixed ratio as described above!' |
|
Wrong extrusion values, not dynamic widths. Or to say it different, spikes nobody could explain to me up to now. Say we have the outer perimeter of a layer, in the problematic cases back then we had a small about of single segments with values around 0 extrusion and others had 10x the expected extrusion. I think it was (or is, have not checked latest Cura) bug. Nothing you will see in the final prints as it's not important if a single segment with a lentgth of maybe 0.05mm has no extrusion. But the algorithm will go nuts trying to compensate for the nozzle pressure that jumps around like crazy. On the other hand, when you fix the extrusion width, that means LIN_ADVANCE is no longer watching the E values in the G1 code. It's then simply calculating an extrusion amount based on the segment length which works as long as there is no variable extrusion with in the gcode. It's like measuring the fuel usage on your car vs. calculating the usage based on the known average consumption and the distance traveled. |
|
Thanks for the info @Sebastianv650 It sounds like the fixed ratio is more of a bandaid for very simple gcode. I have also seen these crazy values in the Cura code, but haven't looked for them recently. The new versions of Cura print very nicely without advance. I really prefer it over Slic3r and others. I definitely hope to get it to play well with LIN ADVANCE. Ideally, we could help the Cura devs find and squash the bug causing non-realistic extrusion rate moves. Maybe another bandaid could be applied to the ADVANCE engine. If all this "weird" Cua moves were extremely short segments, perhaps ADVANCE could just use a segment length if/then to return a 'zero' advance condition, on those tiny moves. In reality, there is a lag in the realization of the advance move, and if the extrusion rate change being compensated for is over before the advance gets there; there isn't much point in compensating anyway. Filtering this up front could reduce the number of unnecessary advance corrections. |
I'm not too motivated doing that due to multiple reasons. They know about this issue but I don't have the feeling they are interested in understanding or even solving it.
I tried some, for example calculating the average extrusion ratio from the last x segments. In the end nothing worked well enough, as the errors to the real value are too big. As a pressure advance algorithm has to work with the change in speed (missing the propper english term), it's very sensitive for wrong values which results in extruder rattling, blobs and voids in the print. As a real world part contains nearly 100% short segments, searching for short ones will also not help.
I'm not sure if I got this one right. LIN_ADVANCE and every other implementation I know of is adopting the preasure in real time for each segment. So there is no lag in adoption, maybe you mean other effects that results in a lagging extrusion? For example I know that in at least some bowden systems, even with an advance thing active the print quality doesn't get to the point like a direct drive one. There are some effects I can think about which can cause that, where I would call buckling inside the filament tube to be the big one. Up to now, there is no software solution to this. |
|
I did a little more testing and am seeing ADVANCE "jitter" in very simple areas of code, at K values approaching 100. I have a lot of the "fancy" Cura settings disabled. But I am still using acceleration control. Do you think this could be creating an issue? You can see here, that we are just making straight infill passes. But they have a small non-extruding 'overshoot move' for infill/wall connection, an acceleration change, then a rapid reposition for the next infill pass:
|
|
Acceleration control means overwrite the Marlin acceleration settings? That's fine, also non print movements are just fine. At a first glance this gcode section looks OK. If you rename the gcode to .txt you should be able to upload it here and I will have a look at it. Please also post your jerk settings. Acceleration and speed is already visible in gcode. |
|
One last thing just to be sure: You are using the 1.1.6 release and not the latest 1.1.7? One of the last commits for 1.1.7 broke LIN_ADVANCE. |
|
@Sebastianv650 , I'm not quite sure how to check the version. I did a "find in files" search for 1.1.6 and found 3 hits, but no hits for 1.1.7. Correct, I have Cura using M204 on the fly to vary XY acceleration between wall and infill moves. I found that it can help achieve good surface finish, while avoiding over-extrusion at the reversal areas of solid line infill. I have played with the accel and jerk settings for the extruder while printing (way down to 100 and 1), and saw only a very small change. Varying the K value has a much larger affect. This makes me believe that it has more to do with the advance calculation, than the extruder lacking performance. The other thing that points me this way, is that using the K factor test, I can run a K value of 1000 without any extruder noise or skipped steps. But when printing I can barely get over 100 before noise gets bad and eventually steps are skipped. Having not read the advance algorithm yet, this is my theory: Something about either the overshoot G1 move (with no extrusion), the G0 repositioning move, or the M204 lines, are tricking the advance algorithm into thinking that the extrusion rate goes to zero between infill passes. When in reality, this code gives essentially a constant extrusion rate. The two travel moves between each printing segment are so short in duration, there is no reason to bleed off pressure and then build it again for the next pass, which is the behavior I am observing. |
|
Here is that gcode file: |
Nice and easy, but that's not the case ;) Non-extrusion moves are not handled by LIN_ADVANCE at all, therefore also no calculation is done then. Which kind of printer are you using, cartesian? I will look into the gcode next. |
|
Yes, it's a modified Ultimaker Original. So, any line without a commanded E value is ignored by advance, and it effectively treats all lines with commanded E as sequential? |
|
I can't find strange things that could screw up the code in your gcode. There are not even retracts in this print? I still don't like Curas way of doing things, for example the infill around the hole, but it should work anyway. So if we focus on the infill lines, we have simple basic gcode and we have a simple cartesian printer.. I have to re-ask the question again: Which problems do you get exactly using this code (let's stay to the infill lines): Is the extruder skipping steps and / or the printed lines when it does some noise have defects? One last thing is in my mind: Do you use any kind of Marlin-side bed leveling function? If so, can you try again with it disabled, maybe compensating with a big first layer for the test print?
Yes and no. Non extrusion moves, extruder only moves, wipe commands etc. are ignored for all kind of pressure calculation and extra step execution. They will always behave as if K=0. But it always keeps track of the XYZ position, so it knows the propper values for ratio calculations and so on. |
|
You might also recheck if the problem persists in Marlin 1.1.0. As I described here, at least I get some strange results with new versions. |
|
Cura does a pretty good job of using "combing" to avoid retracts, by traveling over the printed part instead. So, there are probably very few, if any, retracts in this print. I agree, the gap filling algorithm still has it's weak spots. Concentric circles where you can't quite fit another bead inside, give it fits. Sometimes it lays down a nice circular (roughly) thin gap filling bead. Other times it does a bunch of rectilinear scribbling. On the very simple infill: my problem is that I can't even approach the K value determined in the K factor testing without a ton of extruder noise and skipped steps. At K values under say 100, the print is still functionally good, but noisy. As I get over 100 though, I end up with under-extrusion from skipped steps. At these increasing K values, it becomes apparent that advance is bleeding off pressure at the end of every infill bead, then re-advancing at the start of the next. This is obviously unnecessary, but even this "hyper-active" advance still seems like it should work. In the K factor testing, I can run from 20 mm/s to 70mm/s with a K factor of 800, and get a smooth bead, with no extruder noise. So even if advance is thinking that the print speed is moving between 0 mm/s and 50 mm/s (same velocity delta) on these infill passes, why is it skipping steps and making noise at K150? I am not using any software bed leveling. My testing is super limited at the moment. Hopefully I will find some time to test more things and let prints complete. I will be following your pull request as well. |
|
On a side note, does the nozzle prime pass in the K-factor testing code way over-extrude for you? I haven't calculated the extrusion rate, but had to modify the code so that the first few test passes weren't still bleeding off extra pressure. |
|
I did some more testing with combinations of acceleration control and infill wipe on/off. Even with both disabled, advance is really twitchy. It actually tweaks out pretty hard when moving between one perimeter and the next. To me this means that it is not properly ignoring rapid moves. It either sees them as a 0 mm/s, correctable move, or as a very fast print move. Something is going on there. |
Yes that's intentionaly. The generator is written to do an extruder prime as done on the Prusa printers, in this case it's extruding 10mm of filament during the 100mm move. Not the best way, but the generator has to work on all printers so it's OK to be on the save side. I checked a lot of Marlin versions between 1.1.0 and 1.1.7 today, except version 1.1.7 advance is basicaly working as intendet at least on my printer so we can exclude a general broken code from the list. Please upload your configuration.h and configuration_adv.h files with the values you used for the test. My hope is that the values are comparable to my printer so I could run the code with more or less exactly your settings in my printer. Or I might find other things that might be a reason for the failure. |
|
Hmm, it seems like after intentionally over-extruding, there should be a bleed-off move as well. Before I modified it, the first 3 or 4 test passes were fat. Here's a quick video from this morning. K was set to 150 and extruder jerk turned down to 1. https://www.youtube.com/watch?v=1wtAOqucY8w Configuration.h.txt Here is a photo from K factor calibration. My results are interesting. When going from 20 - 70 mm/s at 0.15mm layer height, my printer never "recovers" over the high speed segment with low K values. I forget the exact K stepping here, but can check at home. I think it goes something like 0, 100, 250, 400, 550, 700, 800, 850, 900
|
|
So the lowest line is K0 and top is K900? Wow, an enormus range! I know it's not related to the topic, but looking at this K0 line it's once more an absolute mystery to me why to use bowden setups. Yes the head is light, but the price is high for this weight saving.. Back to topic. What puzzles me is that during the whole fast section at K0 (meaning LIN_ADVANCE is inactive) there is no sign of the pressure coming back again. The line stays super-thin until the slow phase starts again. If I'm right, we have a 3mm bowden system here using a somewhat low geared stepper, I guess using PLA. 3000mm/s² acceleration and 20mm/s XY jerk. Reading the last one, I think I found a possible reason for the problem.
I suggest testing again, using a total relaxed set of values: If this works, reset acceleration to default values and test again.
That's due to the "bowden-effect", have in mind that there is no K factor set at this moment. Depending on how much friction and compressible filament is in there, the pressure stays high a long time. Due to the same fact, the extrusion width does not recover during the high speed section. |
|
I hear you on the bowden! And this is with fairly rigid PLA. My bowden tube is shorter than stock, but might be more elastic. I went on a quest for the perfect material, with both very low coefficient of friction and high elastic modulus. Never landed on the ideal. I was thinking that a PTFE lined, braided cable could be the hot ticket. I have played around with suspending the extruder driver above the printer, to allow a much shorter tube, and a straight shot for less friction. The trick is finding a setup that allows the range of motion needed, but that doesn't change the amount of force that the bowden tube exerts on the print head. The little 6mm rods suspending the head are prone to flex, especially near bed center. This would give you inconsistent layer thickness and banding in the print. Still haven't nailed that one yet either. On the failure to recover on my test: I might try again with less of a jump in speeds, since 20 - 70 isn't representative of prints I usually make. The 20mm section of fast print only takes about a 1/4 of a second to complete, so I'm not too surprised that it didn't recover in that time. In order to get the flow rate desired, we need the correct force on the cumulative spring (tube and filament). It takes a while to build that force, when you are continuing to bleed it off with a printing move (it's a differential equation). This is why advance makes so much more sense. I spoke about extruder jerk just because I thought the advance algorithm was asking for moves too demanding for my extruder (you are correct, it is a geared stepper). By lowering that jerk, I was trying to force aggressive extruder moves to be limited by the max acceleration setting, and not bypass it. I'll try the XY jerk test and report back. In an ideal world, we wouldn't have to use jerk to bypass acceleration. But in reality, I have found smallish circles get extremely tripped up when you don't allow enough XY jerk. This will at least be good for troubleshooting. Thanks! |
|
Okay, tried XY Jerk @ 5 and all XY accels at 500. Ran the K value at 150, which should be very conservative for my springy setup. I am definitely still seeing twitchy advance: |
|
I pushed some updates to the test pattern generator. For this topic, the option to control the prime and a new test pattern may be handy
This pattern uses an area of 0 to fast speed and back to 0. If @thinkyhead accepts the PR, it will be available in the docu. |
|
@Sineos: cool, is there a link I can access the pattern generator in the meanwhile? |
|
I did a little more testing today to see how much the bowden length affects the required K value. I shortened it to almost nothing and held the extruder drive to see what an unrealistic 'best case' looks like:
I finally found K values that were excessive, but I'm pretty surprised how high K still needs to be, with such a short bowden tube. I would say K500 is best:
From there, I went to a 12" bowden. Still far too short to actually be hard mounted to the frame. I suspended it above the printer with bungee cord:
...annnnnnd I am right back to needing a K value around 900. I don't get it. This is using 2.85mm Polymax PLA, with a 0.4mm nozzle, and 0.15mm layer height:
|
|
@CCS86 |
|
Sorry for the delay, I'm now available again. I will start some tests today, see #8935 (comment) for details. I know you are already using 1.1.6, but maybe I find a better way to do some things and it might work for you then.. |
|
Cool, thanks Sebastian. I'm happy to help test some more. |
|
Hi I am using 1.1.6 and S3D slicer. I am getting weird squiggly lines during layer fill when it encounters a hole in the layer, and when instead of completing the layer fill completely around the hole, it returns later to finish it in that spot at the end of the layer. (Or if it does part of a hole first and leaves to fill the rest of the area). Otherwise my printing with lin advance is perfect. I can't figure out what is causing this. The other part of it is it's sometimes much worse than other times. So it's a random behavior to boot. In other words sometimes when it comes back to complete a gap in layer fill near a hole, it's not bad at all. A little off but not seriously bad. Other times it's so bad it literally ruins the print causing a huge bulge in the area which burns and ruins the look. First Attached is in area that's "good" but you can still see the problem. That's a stripe that done first and then goes on to do the rest of the layer. These don't turn out as bad as when the stripe near a hole is done last. That is shown in the second picture. Huge bulges and burned plastic occur in these areas. I can post code but there's nothing there to cause this that I can see... |
|
You might want to have a look at #9379. I will do some more improvements, but I would call it good for everyday printing as it is at the moment. Would be intresting if this problem goes away with the update. |
|
I did upgrade to 1.1.8 last night. It's improved but still a problem. |
|
The easiest way to get the PR is to just download the complete Marlin version from my branch: |
|
Thanks will do it tonight. As always your efforts are so much appreciated. If it wasn't for you (and all the contributors to Marlin) my Taz 5 would have been in the trash heap a long time ago. |
|
Linear Advance 1.5 is now merged into the bugfix branches. |
|
@CCS86 have latest bugfix 2.0 solved your issue? if your "issue" is in fact a question then Please post your question either on discord: https://discord.gg/n5NJ59y or on facebook: https://www.facebook.com/groups/2080308602206119/ |
|
I know it was phrased as a question, but I think it was a bug I was describing. I haven't tried the latest bugfix, so it is possibly resolved. I'll mark it closed and try the new version when I get time. |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Hi guys,
I have been trying to get Linear Advance up and running. Using the G-code K factor testing I found an acceptable range of K values (pretty large on my bowden setup). The extruder runs smoothly (and quietly) during this test with values up to K1000. (slow/fast speeds = 20/70, 0.15mm layer height)
However, when attempting to print using the newer versions of Cura, there is a clear incompatibility. Even with K values smaller than 100, the extruder is making a lot of noise and skipping steps. My hope is that there are one or more specific settings in Cura leading to confusion in the LIN ADVANCE algorithm.
After some testing, I found the "flow equalization" feature was causing a lot of this. I think it's primary function is that when gap filling areas with very thin widths, it chooses to move the print head faster, rather than slow the extruder. In doing so, it is keeping the volumetric extrusion rate more constant. It seems to me that this should actually compliment LIN ADVANCE, but instead it confuses it.
Does this mean that LIN ADVANCE only looking at print head speed, on printing moves, rather than effective extrusion rate?
Even with this feature disabled LIN ADVANCE behaves quite differently in testing vs printing. Using a 0.15mm layer height and slow/fast speeds of 20/70, I find K800 gives me the smoothest line width, in testing.
In a print with my wall speed at 20 and infill speed at 45, K value set to 100, I'm getting a fair amount of extruder noise / clicking from advance. It doesn't seem to be skipping (many) steps, as the print extrusion looks pretty good. But I'm still wondering why, with such a small K value (compared to the test), the extruder is so wild.
Has anyone tested this and had good success?
The text was updated successfully, but these errors were encountered: