More strange pressure advance behaviour
-
@CaLviNx:
Here Let me pick your dummy off the floor, there there its not so bad…..............
Are personal snipes really necessary?
-
@CaLviNx:
Here Let me pick your dummy off the floor, there there its not so bad…..............
Lighten up a little my friend its not as if it's life or death
I'd like to point out that Ian already apologised here https://www.duet3d.com/forum/thread.php?pid=18656#p18656.
-
Thanks David,
I'm just trying to keep this thread on track so that we can seriously address these pressure advance issues, but it keeps veering off topic, which makes me angry and frustrated. Now I have personal snipes to contend with as well.
-
Any progress on this? Just got back from holiday and have looked through the release notes of all the firmwares but couldn't see anything that indicates if it has been addressed or not. To summarise, the problem existed when using multiple extruders (mixing) but was no present when I changed to a simple single drive tool. Having seen the potential of using pressure advance, I'd really like to be able to use it. Thanks
Ian -
I appreciate that nothing much is likely to happen on this due to the impending TCT show but I've been doing a bit of testing and have some info which might help diagnose and fix this issue.
To cut a long story short, when using pressure advance with a single extruder there are no issues, but with multiple extruders there are problems which are severe enough to ruin a print. This applies to tools set up as mixing tools as well as being defined to use a single extruder. What I mean by that is if a tools is defined to use all 3 extruders but the mixing ratio is set to 1.00:0.00:0.00, there will be no issues. The problems occur only when using multiple extruders, so with a mixing ratio of (say) 0.33:0.33:0.34.
The problem manifests itself when doing arcs i.e circular perimeters. It can occur when printing objects such as rectangles with rounded corners, where it will show up during the arc moves. I have a feeling that it is more likely to occur when the arc comes immediately after a long straight move but this is just a feeling. I've seen it on arcs ranging in radius from 5mm to 21mm. I haven't tested smaller or larger radii.
I can reproduce the problem but not consistently. That is to say, if I print a test piece which is a number of cylinders of different sizes, I can pretty much guarantee that it will manifest itself doing the perimeter of at least one of the cylinders at every layer change. However, it won't necessarily manifest itself on the same cylinder at the next layer change but may instead show up on a different cylinder. Hence my feeling that it might be related to the move that precedes the arc as the cylinder perimeters are not done in the same order for every layer.
When it's behaving itself, observing the extruder while the arc is being laid down, I can see that pressure advance is not being applied to individual segments as would be expected (or at least it is so small as to not be visible), although it does seem to be applied at the very end - i.e the final move of the arc seems to be treated as if it were the end of a long move. However, when it misbehaves, I can see the extruders slow down/run backwards. It's as if at some point, the firmware decides that this is not a series of short arcs but a few long moves that need pressure advance applying to each. The result is that the object gets printed as if it were a multi faceted shape (Hexagon, Octagon, Dodecagon, or some such). Or an alternative is that it applies pressure advance to a very small segment, then because that has slowed things down, it throws away the next few segments in order to catch up to where it should be. Once it starts misbehaving, it will continue to misbehave until it finishes that arc. Then the print will move on and it may or may not misbehave on the next arc.
While printing the multiple cylinders, I can toggle between a tool with a mixing ratio of 1.0 where everything prints just as expected, and a tool that uses more than 1 extruder and it will misbehave. It seems to manifest itself regardless of what the actual pressure advance setting is but is more noticeable with larger values. For whatever reason, I need to use large values in the region of 0.4 to 0.6 with the Diamond hot end but I've seen the effect using 0.1 and even 0.05 but obviously it's not as severe.
Hope this information helps in diagnosing and ultimately fixing this issue. I'd very much like to be able to use pressure advance with multiple extruders. I'd have thought that it could have been simulated without physically have a mixing hot end. Just define a mixing tool and run an "air" print? Happy to supply any info and/or run tests.
Ian -
Thanks for the info. I've added this to the fix list for firmware 1.20.
Does the problem also occur using a mixing ratio of 0.98:0.01:0.01 ?
Does the problem occur more readily when you use a smaller layer height?
-
I'll run those tests when I get chance and report back
-
OK David. I have some more information for you. BTW I'm now using 5 extruders whereas before it was only 3. I can go back to 3 if you really want me to but it means a lot of editing to config,g - let me know.
So using a mixing ratio of 1.00:0.00:0.00:0.00:0.00 does NOT provoke the problem (as previously stated but just to recap)
A mixing ratio of 0.96:0.01:0.01:0.01:0.1 also does NOT provoke the problem.
However, a mixing ratio of 0.92:0.02:0.02:0.02:0.02 DOES provoke the problem as does any other mixing ratio. By visual observation, with this ratio the problem was as bad as 0.20:0.20:0.20:0.20:0.20 (equal amounts of all 5).With this mixing ratio 0.60:0.10:0.10:0.10:0.10 the problem was much worse and this one 0.80:0.05:0.05:0.05:0.05 is deadly. Unless it was just a factor of time into the print (can't think why), I can guarantee that when set to that, the problem will manifest itself, especially on any circle with radius of 10mm or less. If you set a highish pressure advance value, you can see that it is being applied at a number of points around the circle, just as if it was at the beginning/end of a longish move and each time it does that, the entire print slows down and becomes jerky.
Since I originally came across the issue, I have halved my print accelerations from 1000 to 500 for X and Y so I don't think acceleration setting is a factor.
While it was in "problem mode" - i.e. with the mixing ratio set to 0.80:0.05:0.05:0.05:0.05, I played around with few things to see if I could make it better or worse. I halved the print speed which made no difference other than the fact that visually, the jerky behaviour didn't look as dramatic it but was still there. I also tried setting the extrusion multiplier to 50% for all extruders. Obviously this showed up on the print but the behaviour of the XY axis and the extruders themselves was unaffected. i.e the problem still persists at 50% lower extrusion rate (and 50% lower speed).
I also did M122 and I have a hard copy of the result. I don't know what might be useful. Here are a few things
These are the 5 extruder drivers
Driver 5: stalled open-load-A
Driver 6: stalled
Driver 7: stalled open-load-B
Driver 8: stalled open-load-A
Driver 9: stalledDon't know if the main loop time is relevant but here it is along with the step errors (0).
Slowest main loop (seconds): 0.607156; fastest: 0.000000
=== Move ===
MaxReps: 12, StepErrors: 0, FreeDm: 86, MinFreeDm 30, MaxWait: 5768300ms, Underruns: 630, 0
Scheduled moves: 111998, completed moves: 111968Let me know what else I can do to help.
Cheers
-
Thanks. Are you quite certain that the jerky movements are a consequence of using pressure advance, and that you don't get them if you set pressure advance to zero?
-
Thanks. Are you quite certain that the jerky movements are a consequence of using pressure advance, and that you don't get them if you set pressure advance to zero?
Absolutely 100% certain. My default is not to use pressure advance at all (i.e, to have pressure advance set to zero) in config.g for that very reason. If I want to use it, I put it in the start gcode file for a particular print, first making sure that I'll only be using single extruders, then turn it off in the end gcode. It's caught me out too many times to do otherwise.
-
Just wanted to add that during a print I can "toggle" the problem on and off in one of two ways. Either by switching between a tool that only uses a single extruder (toggles it off) and one which uses multiple extruders (toggles it on), or by setting pressure advance to zero for all extruders (toggles it off) and setting pressure advance to a non zero value (toggles it on).
-
Further update. Jerk setting have no effect on this issue. I usually run around 2400 and have just tried values down to 600 and up to 4800 for X,Y and all 5 "E"s
-
Hi Ian,
Investigating this is now close to the top of my list.
1. Please run commands M201, M203 and M566 without parameters and confirm that they report the same values for all 3 extruders.
2. Please confirm that mix ratios of 0:1:0 and 0:0:1 work just as well as 1:0:0 i.e. the problem doesn't occur.
3. Please share the STL for your test piece with the cylinders.
Thanks - David
-
PS - please also confirm that you configured the same pressure advance for all the extruders.
-
Hi David,
1. as follows (copied and pasted from console). BTW, it's 5 extruders now. All values are the same for all 5 extruders
11:58:11
M566
Maximum jerk rates: X: 2400.0, Y: 2400.0, Z: 20.0, E: 2400.0:2400.0:2400.0:2400.0:2400.0
11:57:43
M203
Maximum feedrates: X: 50000.0, Y: 35000.0, Z: 300.0, E: 7200.0:7200.0:7200.0:7200.0:7200.0
11:57:09
M201
Accelerations: X: 1000.0, Y: 1000.0, Z: 20.0, E: 7200.0:7200.0:7200.0:7200.0:7200.02. I'll run tests and report back (as above, I'll do all 5, not 3)
3. I've created a folder on my Google Drive. It contains the STL, the OpenScad file and the Gcode file. I sliced it with one bottom layer and a single perimeter. Here is a link to that folder https://drive.google.com/drive/folders/0B_MwtHtQR_Zvd1BSd1RKSFYwbTQ?usp=sharing
Ref the "Ps" Yes, I can confirm that the same pressure advance was configured for all 5 extruders (drives 0 to 4 inclusive).
Console display looks like this :
12:14:10
M572 D4 S0.4
12:14:04
M572 D3 S0.4
12:13:59
M572 D2 S0.4
12:13:53
M572 D1 S0.4
12:13:47
M572 D0 S0.4BTW, I've always entered it this way and that's how my config.g looks (when they are not commented it out that is). Could I use the format "M572 S0.4 D0:1:2:3:4" instead of 5 separate lines?
Cheers
Ian
-
Hi David,
Ref your number "2" I can confirm that all mixing ratio using a single extruder behave themselves. So all these do NOT exhibit the problem:
1.00:0.00:0.00:0.00:0.00
0.00:1.00:0.00:0.00:0.00
0.00:0.00:1.00:0.00:0.00
0.00:0.00:0.00:1.00:0.00
0.00:0.00:0.00:0.00:1.00Actually, I could have told you that before because the "Banded Vase" that I might print at the show is sliced at 90mm/sec so I used pressure advance on it with all 5 extruders (tools 0 to 4) set to 100% mixing ratio. Actually, it has 3 solid bottom layers using tool 5 (the sixth one) which is set to 0.20:0.20:0.20:0.20:0.20 and IIRC it did misbehave on the rounded corners.
Ref my last post, I lied - twice. The pressure advance is set to zero in config.g, not commented out and I sliced the cylinders with two perimeters, not one.
I've put a copy of my config.g into the same folder as the STL etc, in case you want to check any settings.
Cheers
-
Hi David,
BTW, I've always entered it this way and that's how my config.g looks (when they are not commented it out that is). Could I use the format "M572 S0.4 D0:1:2:3:4" instead of 5 separate lines?Not yet, but I was thinking of adding that facility.
-
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
