Enhancing pressure advance
Edgars Batna last edited by Edgars Batna
@bot What if you run every second or third PA value for, let's say, 10 layers. That might dilute the bed level issue enough to ignore it. I think you could do a very rough run with, say, PA 0, 0.8, 1.6 just so we get a feel for the error in play. Regarding the images, I think we only care for the transition points, so, REALLY zoom in on that. Maybe we're not even interested in true dimensions but just the ratio of the transition. Idea pot is boiling.
I wanted to post some pics, but then, running tests, realized it's no use due to my bed level and inductive probe peculiarities unless I do 10 layers or more...
@Edgars-Batna Yeah, the photos are just from my smart phone. I could/should set up a tripod or camera rig to make each photo identical.
The problem with doing more than one layer is that it becomes nearly impossible to capture the results on camera. The one layer, fixed on the bed with a contrasting background may be the best hope we have. I think the bed level was messed up because I changed the bed temperature. Though, it's not really an issue of leveling or tramming, it's an issue of flatness. The bed its not flat. Usually, I'm not printing flat on the bed so this is no issue but for these tests it's cropping up. I might select a region of the bed that is more flat to perform the tests, but I still think these results give us an idea of what is happening.
Edgars Batna last edited by Edgars Batna
Looked through the images multiple times. The best ones from my point of view are somewhere in range of 1.0-1.4. It could be the margin for error... But, one thing that pops into the eye is that 4-40 contains significant imperfections and that with higher PA it gets worse. No value is optimum at those speeds. Almost like PA needs to be more aggressive just around the acceleration sections.
@Edgars-Batna Yes, I would agree with those observations. At these settings, S1.0 is IMO best.
I'm not sure if this over-extrusion at the beginning of slower print moves is an error in PA. I've always been able to get good results by using PA for infill and other sections which just need to be close enough, and slowing down the print enough on the perimeters to give perfect extrusion because it's all one slow speed.
I can also get perfect extrusion by using these extremely low jerk and accel values, but then the top speed becomes a limit of perfect extrusion (due to stepper motor cogging? dunno), and if we have different feedrates in the print, we're bound to get these occurences of slight over-extrusion at the beggining of a slower feedrate section if coming from a higher feedrate section.
I just wish for the plain-jane simple unretract modifier I outlined above. I realize that E0.0000 moves that S3D stupidly generates would mess up the calculation of the target E axis speed, but the calculator could be instructed to ignore E0.0000 lines and look for a G1 line with non-zero E values to calculate the target speed from.
I can tune PA to be good enough for all other occurences.
Actually, it does seem like there is a problem using (high values) of PA with these ridiculously low extrusion rates. Now that I have started a real-world print with the now higher value of S1.0, there are ocassional huge blobs of filament extruded in areas, like support structures, that sometimes produce tiny little segments.
I momentarily had a post with a couple photos of what I assumed may have been problems with low extrusion rates but I thought it may not be the case and it just muddied the discussion so I removed it. FYI to anyone who saw it and thought they were going crazy. Ignore this post. Nothing to see here, move along.
[Edit: to really play gas light with you I now restored that post because I confirmed it definitely is a problem: periodically, a huge blob of filament will be extruded. Consistently in that same support spot, and as well as others I think.]
@Marius-Breuer good thoughts about the input force from the extruder motor. I didn't think of it from that side of the equation.
I was thinking about the pressure due to Bernoulli's principle.
Then I realized something. Given a flow of material at X speed into a restricted orifice, wouldn't not only the pressure increase in the fluid (before the restriction), but the speed of the fluid increase as it passes through the restriction (and the pressure decreases)?
IE, change nozzle size, change extrusion speed?
Marius Breuer last edited by
@bot There are also losses due to friction in the nozzle, especially with "sticky" molten plastics.
The large Volcano nozzles need some extruder torque, even though the nozzle hole is barely smaller than the 1,75mm filament.
Maybe look through data sheets of (bearing) grease. I know that greasing of bearings is done with automated pumps, to select the right pump the grease viscosity has to be known.
Maybe calculating the hotend pressure with the viscosity of thick grease gives results that are in the same ballpark as calculations for molten plastics. Sadly i didn't yet find temperature depended viscosity curves of plastics, making an accurate calculation impossible.
If you do all that in Excel or alike one could quickly change the calculation for different extrusion rates, nozzle sizes (hole and length =>volcano) , nozzle material, ...
@dc42 Can I pay you to implement this "dynamic unretract" feature into FW 2.05.1 in the way I described? It's the last piece of the puzzle for me to achieve acceptable print quality at decent print speed. It would look as follows:
The algorithm looks at the extrusion rate of two print moves that are separated by a retraction. The extrusion rate could be calculated by finding a G1 line in each move sequence that contains a non-zero E value (because some slicers are stupid).
Then, the adjustment to unretraction is made as such:
adjusted_unretract_distance = nominal_unretract_distance + (second_move_extrusion_speed - first_move_extrusion_speed) * new_dynamic_unretract_constant
This could be done for firmware retraction only, if this makes it simpler to implement, but if it's trivial to implement for slicer-based retraction as well, that would be excellent. I would definitely be happy to just use FW retraction, though.
I am totally willing and able to pay to have this feature implemented, and would like for the feature to be available to everyone if desired. I just recognize that payment to implement this feature is warranted since you are likely busy with much more important issues, both professionally and personally.
Please let me know as soon as possible! I'm looking to have this implemented as soon as I can.
I realize that @Edgars-Batna has implemented this in his own way, but I would like for this addition to be purely adjusting the unretract distance based on that formula, without any other changes whatsoever (to reduce required testing and likelihood of errors in calculation, etc.)
@dc42 I have been in discussions with Edgars-Batna, and I will be paying him to implement the feature for me. Do you have any thoughts as to the implementation of it? Edgars-Batna has published his initial coding here: https://github.com/mdealer/RepRapFirmware/commit/841e38d9ad39dc408d785f6b75ab3e6182344f02
I would welcome any thoughts you had, and would be more than willing to pay you, as well, to coordinate with Edgars-Batna on the implementation of dynamic (un)retraction.