More strange pressure advance behaviour
-
Which firmware are you running?
-
Which firmware are you running?
Firmware Name: RepRapFirmware for Duet Ethernet
Firmware Electronics: Duet Ethernet 1.0 + DueX5
Firmware Version: 1.20 (2017-12-23)
Web Interface Version: 1.20 -
There has been a fix to pressure advance since 1.20, so please test 1.20.1 latest RC.
-
Hi Ian,
No need to do that test, I have reproduced the problem.
-
So I am seeing a problem when printing large circles, even when using quite low pressure advance (0.05). I think it's because S3D is messing around with the segment lengths and they end up with extrusion rates varying by up to 8%. The segment lengths vary between 0.015mm and 1.26mm.
Next thing I need to do is to work out whether this alone explains it.
-
Hi David,
It's refreshing to see that you are getting similar behaviour. For info, I have just finished printing the hollow cylinder file using latest edge release and the behaviour is the same - both single and multiple extruders. Max reps for a single extruder was 4 and for 3 extruders it was 7. Other than that, both M122 results from the end of each print show step errors of 0, LA errors 0, and under runs of 0,0.
Doing hollow cylinders makes it a lot easier to analyse the gcode file as, apart from the skirt, every print move is a small segment. I can say that Slic3R does very strange things and messes with the segment sizes. I had a quick look at the other file that we were both playing around with in October and can see the same thing.
Here is a snippet from somewhere in the middle of the hollow cylinders gcode file that I've just been playing with
G1 X116.429 Y174.518 E0.05246
G1 X116.275 Y174.027 E0.02658
G1 X116.024 Y173.042 E0.05246
G1 X115.924 Y172.537 E0.02658
G1 X115.779 Y171.529 E0.05257
G1 X115.706 Y170.510 E0.05269
G1 X115.706 Y169.492 E0.05258
G1 X115.733 Y168.980 E0.02646
G1 X115.779 Y168.469 E0.02646
G1 X115.924 Y167.463 E0.05246
G1 X116.024 Y166.958 E0.02658
G1 X116.276 Y165.971 E0.05258
G1 X116.598 Y165.005 E0.05258
G1 X116.786 Y164.526 E0.02658
G1 X117.209 Y163.599 E0.05257
G1 X117.699 Y162.703 E0.05269
G1 X118.249 Y161.846 E0.05257
G1 X118.549 Y161.430 E0.02646
G1 X118.864 Y161.025 E0.02647
G1 X119.529 Y160.257 E0.05246
G1 X119.887 Y159.887 E0.02658
G1 X120.632 Y159.193 E0.05257
G1 X121.425 Y158.553 E0.05258This is probably the worse part that I can find. There are places where every "E" move is almost identical for very many moves, other places where the occasional odd looking E move occurs and other places where it is as bad as above.
Given that the problem manifests itself much more readily than it did back in October, it would seem that the firmware is more sensitive to the cranky things that the slicer is doing. Is it possible to make any changes to de-sensitise (or preferably immunise) the firmware from the cranky slicer behaviour?
-
I've had to stop work on this until later, but I have a theory about why the firmware is sensitive to these changes in extrusion rate. If my theory is correct, it may be less sensitive if you reduce extruder microstepping.
-
OK. No worries. I'll give that a quick try.
BTW I've had a play around with the resolution setting in Slic3R. There is some indication that the value is in mm but I'm not sure what that relates to. Looking at the layer preview, it isn't minimum segment size. A value of 0.5 shows definite signs that the printed circle would come out faceted. Going down to 0.05 shows smooth curves in the layer preview and the gcode file is much smaller. Looking through it, I can see that the segment sizes are all bigger but I'm still seeing quite a variation in segment size for a given curve.
-
David,
I tried 8 X micro stepping and unity (whole steps). Problem persists but visually much more violent and scary to watch.
Ian
-
S3D is becoming the bane of my existence…
Is there a patreon account we can join to encourage you to code a slicer, David?
-
@bot:
Is there a patreon account we can join to encourage you to code a slicer, David?
Count me in..
-
@bot:
S3D is becoming the bane of my existence…
Is there a patreon account we can join to encourage you to code a slicer, David?
Now, that's an idea.
-
@bot:
S3D is becoming the bane of my existence…
Is there a patreon account we can join to encourage you to code a slicer, David?
I contribute bug fixes and improvements to Cura and so I am interested to know why people are not using that slicer given that it is freely available. I understand that no one slicer is perfect and that for a given job, one may do better than another and, at the end of the day, we all have our preferences. Anyway, to avoid hijacking this thread, I will start another.
-
I used to use cura until the 2.x releases where made and I found that it crashed to much so haven't used it since and especially due to the stubbornness of the devs to allow different extrusion regimes (I know that has bee fixed now) and I to have ditched S3D in favour of Kiss 1.6.2 which once you get your head around the guy which is awful ish then I find it produces excellent prints and is the only Slicer I know that does the equivalent of pressure advice in the slicer itself and which can be set up on per material basis it also does variable layer hight's as well (Not as in it can be told what to do but can work it out for itself).
And it is also free (caveat there are a couple of very advanced features that are locked in the free version but most users would not use them). Don't know if it OS or not tho.
Doug
-
David,
I tried 8 X micro stepping and unity (whole steps). Problem persists but visually much more violent and scary to watch.
Ian
I was wrong, I checked the code and it now takes the microstepping into account.
On my test print at 50mm/sec printing speed, the extrusion rate was nominally 2.01mm/sec but it can change between adjacent moves by as much as 0.11mm/sec. This is enough to trigger the code into reducing speed, due to a second-order effect of pressure advance. I will look at how this can be avoided.
-
Ian, I have just tried slicing my test circles using Cura 3.1 instead of S3D and the extrusion speed consistency is much better, about 1% instead of 8.4%. So until I change the pressure advance code to better handle changes in extrusion rate that shouldn't be there, you might like to try slicing your models with Cura instead of S3D. I think that will fix most of the problem.
-
Ian, I have just tried slicing my test circles using Cura 3.1 instead of S3D and the extrusion speed consistency is much better, about 1% instead of 8.4%. So until I change the pressure advance code to better handle changes in extrusion rate that shouldn't be there, you might like to try slicing your models with Cura instead of S3D. I think that will fix most of the problem.
Hi David,
Thanks for that. A couple of things though. I use Slic3R not S3D because it's the best of a bad bunch for multi (more than 2) colour objects. It's been a long time since I used Cura - I'll see if it's any better at supporting multiple parts\tools.
However, as of tomorrow, I'll be up to 9,000 miles away from my printer, the week after that I'll be 10,500 miles away, and the week after that I'll be up to 11,800 miles away, then reversing the trip. Back on 26th Feb. Enjoy the snow folks - I'm off to the other hemisphere
-
David,
Do we have any update on this? To save you trawling back through this thread here is a summary.
Up until 1st October 2017, I had always had problems when doing arcs using high levels of pressure advance with multiple extruders. After a great deal of testing, we got to the point where you wrote this:
1st October 2017
" So I think I've worked out what is going on. When there is a sequence of short moves such as in an arc, the gcode processor may not be able to fill the movement queue as fast as the motion system empties it, especially if it is having to compute and generate step pulses for 5 extruders. If the queue contains insufficient moves to do full lookahead, then the segments in an arc have to be scheduled to slow down at the end, to ensure that the motors can stop if new moves are not added fast enough. When large amounts of pressure advance are used, this causes the extruders to retract filament at the end of the move. This retraction increases the number of steps that must be generated, which further increases the load on the processor. So if the machine gets into a state in which the gcode processor can't quite keep up with the mechanics of the machine and starts doing jerky movements, pressure advance will increase the load on the processor and make the situation worse."Then...
"Here are some possible solutions/workarounds
Reduce printing speed
Use larger segments in your arcs (lower $fn value in OpenSCAD)
Use fewer extruders
Use lower pressure advance
Use lower microstepping, which will reduce the number of steps being generated. Are you using the default x16? If so then you could try x8 on the extruders, especially if you are using the 0.9deg motors that E3D supply for the Titans.
If you are using 0.9deg motors on your extruders, use 1.8deg motors instead. It may be worth using 0.9deg motors in ungeared extruders, but for geared extruders like the Titan I doubt that they offer any advantage.
Make the firmware more efficient at generating steps and/or processing gcodes. The step generation is probably as fast as I can make it already, but I may be able to improve the efficiency of gcode processing. The 1.20alpha series should be faster than 1.19 already.
Make the firmware reduce printing speed automatically when underrun is imminent
Use a faster processor (but we will have to wait for the Duet N^2G for that!)"I tried the simple things like larger segments and I don't use 0.9 degree motors, so at that point I came to the conclusion that if I wanted to use high pressure advance as is needed by my particular setup with the Diamond hot end, and if I want to use multiple extruders, and if I want to print at anything other than very low speeds, then I'd have to wait for the new generation of Duet.
At that point, I could use pressure advance without any issues but only with a single extruder being driven.
Then on 17th Jan I resurrected this old chestnut of a thread and on 18th I discovered that I now had issues using just a single extruder, so something in the firmware changed between October (firmware 1.19 beta8) and mid Jan (Firmware 1.20 and later).
The final conclusion was that the (new) problem was due to changes in the extrusion rate that Slic3r generates. On 21st Jan you wrote:
..............So until I change the pressure advance code to better handle changes in extrusion rate that shouldn't be there, you might like to try slicing your models with Cura instead of S3D. I think that will fix most of the problem.
I kind of took it from that, that you planned to look at changing the pressure advance code. I haven't seen anything in later release notes so was just wondering what the status is. I'm on 1.20.1RC2 btw.
Cheers.
-
@deckingman, no there isn't any update.
Did we ever establish whether slic3r generates GCode with a uniform extrusion rate for curves?
Duet WiFi hardware designer and firmware engineer
Please do not ask me for Duet support via PM or email, use the forum
http://www.escher3d.com, https://miscsolutions.wordpress.com -
@dc42 said in More strange pressure advance behaviour:
@deckingman, no there isn't any update.
Did we ever establish whether slic3r generates GCode with a uniform extrusion rate for curves?
Not really. Going through the gcode file for those test cylinders, what is for sure is that the extrusion amount can differ but there are no changes to feedrate. I'll have to do some maths on the XY coordinates but I'm pretty sure I did it before and discovered that the reason the extrusion amount varies is that the segment size can vary. I'm pretty sure the change in E amount corresponded with a change in XY of the same magnitude.
Most of the time, the segment size is constant for any given arc but at seemingly random points in the file, odd segment sizes appear (for segment size read E amount). I think at one point you or I decided that change in segment size would lead to a change in direction that was sufficient to trigger pressure advance (but my memory is hazy on that so it could be a Red Herring).
