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