More strange pressure advance behaviour
-
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
-
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?
