More strange pressure advance behaviour
-
Hi Ian,
I ran your cylinders model on my Ormerod (which uses a Duet 0.8.5) configured with a pretend 5-input mixing extruder. I sliced it at 60mm infill speed and 30mm perimeter speed, which are the usual speeds I use on that printer.
Initially I couldn't get the problem to occur, even with a mix of 0.80:0.05:0.05:0.05:0.05. So I tried changing various parameters. I saw that your extruder jerk was set much higher than mine (2400, whereas mine was set to 20 - I'm not sure why I had it set so low). I tried increasing it, but the extruder rattles a lot if I go above about 300. So I settled on 600. I suspect that steps will be missed if I go higher than that.
By increasing the speed, I was able to reproduce the problem you report on the smallest cylinder. By increasing speed further to 200% and the mix ratio to 1:0.2:0.2:0.2:0.2 I made it occur on most of the cylinders.
Running M122 revealed a very high underrun count. 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.
The partial M122 report you posted shows an underrun count of 630, so I think this accounts for the same symptom on your printer.
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!)
Some of these should be testable on your system even if they are not practical for general use.
HTH David
-
Hi David,
Thanks for that. At least we have a reason, if not a complete solution. What you describe might be happening fits exactly with my empirical observations.
It's interesting what you said about extruder jerk. I'm not sure why I have mine set to 2400. It's something that I've played around with in the past but never seen any real difference in how the machine behaves or how the prints turn out. I'll certainly try with it much lower.
I'm using 1.8 degree steppers and 16X microstepping (with interpolation). I generally print at much higher speeds than you - usually 60 to 90 mm/sec unless it's a really detailed part. Maybe I'll dig out the 0.9mm nozzle so that I can print big things but slower. Apart from that, out of all the suggestions you listed, I'll just continue to run with zero pressure advance when using multiple extruders as those are the only conditions that give me a problem.
Put me down for the first Duet N^2G - at least now we know that there is a real need for a faster processor
Ian
-
Sorry to resurrect this old chestnut but I have done some more testing and have what I think is some new information. I created a new test part which is basically just a number of hollow cylinders varying in radius from 5 to 20 mm. In OpenScad I used the parameters $fa and $fs rather than $fn and set each to 0.5 which, if my understanding is correct should create a lot of "facets" but limit the minimum size to 0.5mm. So each cylinder will have the same size segments but the number will vary depending on radius. Although no doubt Slic3r will do it's own thing with them…..
I sliced it at 75mm\sec but first layer speed at 50%. The cylinders are 1mm thick with layer width of 0.5 so effectively just 2 perimeters. I had pressure advance set to 0.6 and used 3 extruders because this is what I'd like to priny with following on from my other tests. Then I played around with extruder Jerk and acceleration as well as print speed to see if I could find a setting that would work with that pressure advance.
@DC42 - David
Please, please watch this video which I've uploaded to my google drive rather than YouTube https://drive.google.com/file/d/1frP3skZiIG07_aHDAfy44I3UrS0upzID/view?usp=sharingSetting jerk really low slows things down a lot as expected, but it means that you can see what's happening. I also tried at 25mm\sec print speed but still have problems. It looks all the world to me as if when it behaves itself, one complete circle is treated as one complete arc and pressure advance is only applied at the end of that circle. Yet when it misbehaves, (which is more often than not with this test), it seems that one complete circle is treated as multiple arcs and pressure advance is applied multiple times around the circle, instead of just once at the end. It's not simply stopping, you can see the extruders run backwards slightly. But it makes no sense in that there is a condition where the largest and smallest radii cylinders print OK but the medium sized ones don't.
Anyway, please watch the video and tell me what you think. There is an M122 in there which I tried to do while it was misbehaving which might you tell you something.
Thanks
Ian
-
As it happens I already had a note to look at the pressure advance issues that you and one other user reported.
Let me explain what should be going on.
I will assume that the slicer faithfully reproduces the segments in the STL model, specifies the same linear speed for all of them, and the same extrusion amount for all of them (if it has faithfully reproduced them from the STL model then as they should all be of the same length, they should all specify the same extrusion amount). This is easy enough for you to check by looking at the GCode.
When printing a circle, the firmware would like to print all the segments at the speed you requested in the G1 commands, and not have any acceleration or deceleration at the start and end of each segment. It can only do this if it doesn't violate the X and Y jerk limits. So it calculates the X and Y velocity components of the requested speed for each pair of adjacent moves, then compares the difference in the X components with the X jerk limit. Similarly for the Y component. If both are within limits, then it will print the segments at constant speed, and there will be no pressure advance except at the start and end of the circle.
Things that can stop it from printing at constant speed:
1. Violating the X or Y jerk limit, which will happen when the combination of requested speed and change in angle between segments is too great. With constant segment length, the angle change will be greatest for small circles. So if this happens, the remedies are to increase the X and Y jerk limit, or reduce printing speed, or use shorter segments (assuming the slicer doesn't undo that by combining segments).
2. Move queue underrun. If the GCode decode system can't feed moves to the planner fast enough, then the machine may not be able to maintain the requested speed consistently. If this happens, the Move Underruns in the M122 report will start growing.
3. Slicer doing stupid things. For example, S3D inserts tiny non-extruding moves between the segments of curves when it is printing as skirt. Perhaps it does the same thing in other situations too.
One the firmware has decided that it can't print at constant speed, it will put acceleration segments at the start and end of each GCode segment, and pressure advance will be applied during those segments. The extruder jerk limit will have a secondary effect of limiting extruder acceleration, the more so when using high values of pressure advance.
In your video you have changed extruder acceleration and extruder jerk a lot. But those should only affect the behaviour once the move system has decided that it can't maintain linear speed at the segment boundaries. I've watched more than half your video so far and although I've just seen you reduce print speed, I haven't seen you increase the most critical factors, which are X and Y jerk, or say what you have them set to.
It would be helpful if you could analyse the GCode for one or more of the circles that is printing jerkily, check that the 0.5mm segments have been faithfully reproduced and nothing else inserted, check that the extrusion rate is constant from one segment to the next, and calculate the X and Y jerk values that are needed if the requested speed is to be preserved across the segment boundaries.
-
Hi David,
I'll do as you ask as soon as I get chance.
In the meantime, I can answer a couple of the points you raised. In those tests I didn't change X Y jerk or accelerations. Only the extruder settings - mostly because I was trying to see if there was something I could change which wouldn't affect overall print speed too much. So accelerations for both X and Y are set to 1,000 but I use M204 P500 T1000 so in theory, for print moves the accelerations are 500mm/s^2. Jerk for both X and Y were set to 600 mm/min. These settings are quite modest compared to what I have used in the past.
The slicer (Slic3R in my case) does do things with the stl. I did a quick test some time ago rendering an OpenScad file of a cylinder using vastly different $fn values (I can;t remember exactly but something like 100 in one case and 1,000 in the other). The rendering times were vastly different and the resultant stl files were different sizes. Running both files through Slic3R I got exactly the same size of gcode file. I didn't look through the file to compare line by line but the fact that the overall file size was identical indicates to me that the slicer must "do it's own thing" regarding segment size.
Note also that this behaviour only happens when using multiple extruders. I don't get it happening when using a single extruder. This must be significant no?
Ian
-
If you only get this behaviour when using multiple extruders, that's highly significant. Please check the "Move Underruns" count in M122 after doing one of these prints. Also check MaxReps.
-
Ian, Slic3r has a 'resolution' param; is it set to 0 in your case? If not, it will limit the resolution of the input, so $fn=100 or $fn=1000 may lead to the same output…
-
@fma:
Ian, Slic3r has a 'resolution' param; is it set to 0 in your case? If not, it will limit the resolution of the input, so $fn=100 or $fn=1000 may lead to the same output…
Thanks. I didn't know that. However, I just checked and found it in the advance section of Print Settings and it is set to 0. It's been a while since I sliced those two objects so I'll redo those tests and see if the behaviour is the same as my memory tells me.
-
If you only get this behaviour when using multiple extruders, that's highly significant. Please check the "Move Underruns" count in M122 after doing one of these prints. Also check MaxReps.
Hi David,
Historically, it has always been the case that I only had the problem with multiple extruders. That has been the theme running throughout this thread. If you go back just a few posts, you'll see that you were able to reproduce it yourself. I could even "toggle" the problem on and off by switching between a tool that used 3 extruders and one that only used a single extruder.
However, I've just run a repeat test of those in the video using a single extruder and today, I have the same issues with single extruder as I have with multiple extruders. So something has changed since the last time I tried to print with pressure advance last October.
There are 3 things I can think of that have changed. Firstly the machine uses CoreXYUV configuration for homing but uses the same motor mapping for all moves other than homing, so I wouldn't have thought it was that. Secondly, I have been using a different file. So as I type this, I'm printing the original file that we both used back in October. This is now exhibiting problems with just a single extruder which it did not do back in October. Thirdly, there have been other changes to the firmware so might that be the reason for the changed behaviour? I can't think of any other given that I have changed behaviour now compared to the behaviour that I was witnessing back in October printing the same file.
I ran M122 after doing the quick test this morning using the latest hollow cylinders file that I used in the recent video but with a single extruder and which exhibited the same erratic behaviour as multiple extruders. The result from that showed :
MaxReps5, StepErrors 0, FreeDm 240, MinFreeDm 90, MaxWait 320177ms, Underruns 0,0
The print that's running now is the same one that we used in October. I'll let this print finish the run M122 to see if the results from that are different to the results of M122 that we had in October.
-
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..
