Extruder motors skip steps with pressure advance enabled
-
@deckingman I've been there, done all of that multiple times. I'm losing my mind... it happens even if I press the release button on one of the extruders and regardless of motor count or connection. I've tried single motor, tried two in series, tried mixing, tried changing the amps, microstepping, the motors, speeds... I only installed the second motor because it was losing steps like this all along, but I didn't know why and then I installed one big fat Nema 23 out of desperation, then changed from V6 to Volcano.
-
@edgars-batna One other thing. The gcode file is sliced using relative extruder moves (which is good). But just check that you config.g and any config-overide, g has an M83 command somewhere to tell the board to expect relative extruder coordinates. Make sure there are no M82 (use absolute extrusion) commands anywhere in your configuration files.
-
@edgars-batna I can see why you would be thinking that you are losing your mind - I would too watching that video. Humour me - try running ta print but with no filament loaded and observe the motors. (check the M83 thing first).
-
@deckingman Don't see M82 anywhere. This video sums up last 3 months of my life: https://www.youtube.com/watch?time_continue=6&v=KjCO0thvlNY
I'll try without filament, but I think I already tried it. I need to make a list...
-
@edgars-batna said in Extruder motors skip steps with pressure advance enabled:
@deckingman Don't see M82 anywhere. ......................
OK - but tell me that you do see an M83. I have this nasty feeling that without either M82 or M83, the board will default to M82 (absolute) extrusion.
-
@deckingman I've posted my config.g from the start with the original post and it's the second line. If there would be a problem such as this, then the whole thing wouldn't work, but it's printing fine with PA disabled.
Just tried without filament - behavior is, I think, marginally worse than with filament. The bigger motor behaves way worse. This would fit the "impossible steps" theory as the rotor inertia is higher and there's no "filament brake" against oscillations now. Gonna post a vid as soon as I get to it, but it's basically the same and it seems that it's the worst during first layer, so it must be speed dependant. The slower the head the more skips they seem to get.
-
@deckingman Video without filament: https://www.youtube.com/watch?v=oXsFLG7AMug&feature=youtu.be
-
The video makes me think broken wire.
-
@edgars-batna said in Extruder motors skip steps with pressure advance enabled:
@deckingman Video without filament: https://www.youtube.com/watch?v=oXsFLG7AMug&feature=youtu.be
Well that rules out anything to do with the hot end. We can forget all about jams and blockages. Time to test each individual extruder motor to see if we can narrow it down to one or the other (or both).
Also can you post your complete config.g file. Maybe one of use can spot something that you have missed.
-
@phaedrux All wires have either soldered or fastened connections. These are rather thick 1mm^2 wires with thick insulation. I just tested them and they read exactly motor resistance on the poles on the Duet connector side.
@deckingman The config.g in the original post is the original, I just removed wifi name and password. Motors can be also ruled out, as the nearly 1 year old Nema 17 behave exactly like the brand new Nema 23... Connections can be also ruled out, as these are two separate wires that I tried on 5 separate drivers on 2 separate motors and I use exactly the same type of wiring for the 6 other motors that never have an issue.
Slowly I'm coming to conclusion that there is a bug in the firmware...
EDIT: New findings: Setting extruder microstepping to 256 made it better, but this is not a solution as a single step would have too little torque and they still make knocking sounds, which means they would lose steps under load. I guess the firmware rounds the steps up on lower microstepping. @dc42 This could be, uh, a bug? I summon the firmware gods for clarification! If the resolution is less than required oscillation then it should suppress the oscillation. Does the firmware force 1 microstep movement if required movement is less than microstep for PA? I probably don't know what I'm talking about, but please help.
-
@edgars-batna I've just spent quite a bit of time going through your config files. Sorry to be a pain but just to be clear, you are saying that the config without pressure advance prints fine but the one with pressure advance is crap like in the video? What I mean is, there isn't some other fault crept in coincidentally with you enabling pressure advance? You can simply change M572 D0:1 S0.5 to M572 D0:1 S0.0 and it'll resort to printing just fine yes?
The reason I ask is that there are what look like a couple of anomalies but if it prints fine then it's nothing to worry about.
I'll tell you what looks odd anyway........You have the mixing ratio set to 0.5:0.5. Normally with a push-pull arrangement such as you have you'd set both extruders to 1.0:1.0 otherwise they would run at half speed (as in a mixing hot end). But further up, you set micro stepping to 8X for the extruders, then you set the steps per mm to 88(ish), then you change the micro stepping to 16X. I'm pretty sure that this will effectively change the steps per mm to 176 (88 x 2) which would make the extruders run at double speed and cancel out the 0.5:0.5 mixing ratio thing.
So if the steps per mm should be 88 @16 micro-stepping for those extruders, then ideally you ought to set the micro stepping to 16x in your first M350, take out the second M350 and set mixing ratio to 1.0:1.0.
Maybe - just maybe, there is some interaction between mixing ratio set like that and pressure advance that hasn't yet come to light until now........Long shot - just speculating....
The only other thing I noticed is that all your M569 commands have B, F and Y values which are firmware 2.02 and later - i.e. something new that has recently been added. Again, just speculation on my part but could this be the cause of the problem? Could there be some interaction between these values and the pressure advance algorithm? As this is something new in firmware 2.02 I see no harm in taking those parameters out and simply using M569 Pn Sn.
I'll keep thinking - this is bugging me.
-
@deckingman said in Extruder motors skip steps with pressure advance enabled:
@edgars-batna I've just spent quite a bit of time going through your config files. Sorry to be a pain but just to be clear, you are saying that the config without pressure advance prints fine but the one with pressure advance is crap like in the video? What I mean is, there isn't some other fault crept in coincidentally with you enabling pressure advance? You can simply change M572 D0:1 S0.5 to M572 D0:1 S0.0 and it'll resort to printing just fine yes?
Thanks for going through the file and don't worry about being a pain. Yes, changing PA to 0.5 (or any value, actually) causes step skips to varying degrees depending on the value, 0.5 being that video.
I'll tell you what looks odd anyway........You have the mixing ratio set to 0.5:0.5.
Yes, it's intentional. Basically, if it's set to 1.0:1.0 mix ratio, then the WebControl reports wrong time estimations. This way it extrudes the correct amount, while "fixing" the filament-based estimated time left. I've gone through many iterations with my extruders and I'm 100% sure it extrudes the right amount as long as the steps are not lost.
I'll try setting it to 1.0:1.0 yet again, but I'm quite sure it didn't work. If mixing ratio somehow influences PA like this, then it's a bug. EDIT: Tried, no change.
The only other thing I noticed is that all your M569 commands have B, F and Y values which are firmware 2.02 and later - i.e. something new that has recently been added. Again, just speculation on my part but could this be the cause of the problem? Could there be some interaction between these values and the pressure advance algorithm? As this is something new in firmware 2.02 I see no harm in taking those parameters out and simply using M569 Pn Sn.
I've tried removing them to no avail. The motors are slightly less audible for me with those values. All motors run at those values, which would cause lost steps on X, Y, Z... The accelerations are quite high and any problems would pop up right away. EDIT: Tried, no change.
The thing about microstepping from my last post... Greatly increasing E microstepping has reduced the skips; This must be the first real sign of a parameter affecting the skips. I tried 64 before, but didn't notice much change. At 256 it is no longer marginal, it is totally noticable. That "crazy retract" is no longer happening, but the motors still knock.
-
@edgars-batna I've resorted to comparing your config with mine - not very valid because they are different animals. One thing I noticed is that you have a very high feedrate set for your firmware retraction M207 S3 R0.0125 F20000 Z0.5. So 20,000mm/min which is 333 mm/sec. That's kind of crazy high. Another long shot but could that interact with PA and cause a problem???? Easy to try by using (say) F3000 (50mm/sec).
Clutching at straws here............
-
@deckingman The E speed is limited to F4500. The F20000 is an arbitrary high value. Nevertheless I tried reducing it to F1000 and then reducing max speed to F1000, but it yielded no change.
-
@edgars-batna said in Extruder motors skip steps with pressure advance enabled:
@deckingman The E speed is limited to F4500. The F20000 is an arbitrary high value. Nevertheless I tried reducing it to F1000 and then reducing max speed to F1000, but it yielded no change.
Yeah, I knew the E speed would be limited, but from a conversation I had recently (about something else) with @wilriker, he was looking at the source code and seemed to be under the impression that the extruder jerk value was somehow used to calculate the acceleration for pressure advance. Hence there might have been a link to your problem. But you've tried it so that's another idea shot down........
I'm running out of ideas here. Another long shot - you don't have a config-overide.g file do you? If so, is there anything in it that might be overriding the changes you have made in config.g?
I'm starting to think that maybe there is a hardware problem. Maybe a faulty driver chip or some such. But that wouldn't explain why everything is fine until you enable pressure advance. Nothing makes any sense............
-
OK, so here is something else. I've looked at that gcode you posted which gives you the worse behaviour. Right near the start there is an M204 S10000. Now according to the Wiki, https://duet3d.dozuki.com/Wiki/GCode#Section_M204_Set_printing_and_travel_accelerations
quote - "RepRapFirmware applies the M204 accelerations to the move as a whole",
But according to the wiki, M204 uses P and T parameters - there is no mention of an "S" parameter.
However, if that M204 is being applied, then 10,000 mm^2 is crazy high acceleration.
IMO, the slicer shoudn't be f***ing around with configuration values like that. (I'm really starting to hate PE version of Slic3R now).
So try taking out that M204 from the gcode file. Better still, turn off all "advanced features" of Slic3R PE and slice the file in the most basic manner possible. Even better still, try another slicer such as non-PE Slic3R.
Of course, none of his explains why you can print that file fine without PA but maybe there is some interaction (by design or accident) between a high M204 value and PA.
Just another long shot but worth a try.
-
@deckingman 10000 mm^2 is actually less than half of what the printer can. It has ultra-light head and XY axis from carbon fiber rods. Look at the accelerations in config.g: M201 X24000 Y24000 Z1200 and top speed: M203 X96000 Y96000. I built this to rip people's hands off if needed. If I run one of my test macros that runs 400mm back and forth, XY reaches 1600mm/s. But, remember, this is just travel. Print needs completely different values.
Anyway, I just finished a print with 256 E microstepping and, while not perfect, the results are impressive. Layer consistency went from zero to hero. Still some blobbing, but at least barely any missed steps. This layer inconsistency was the issue I've been fighting all along and it took me 12 months of trial and error and until I was finished with tweaking the hardware...
Now, I find it a bit underwhelming that none of the Duet3D folks have anything to say, because the behavior appears like a bug to me. I can dig into code, too, but I'm so rusty with Linux. Last time I used it was like 2015. Don't get me wrong, Duet3D is darn impressive, but I think this issue might affect more people than just me as I've seen exactly the same inconsistent layer heights here around the threads and I bet it's pressure advance and I bet it goes away by increasing microstepping.
If only someone would like to try reproducing the issue...
I suspect that low E steps per MM and lowish E microstepping breaks PA. I'm talking below 100 steps/mm and 16 or lower E microstepping. I suggest that pressure advance won't work on any setup like this.
-
I hear what you say about the head being capable of acceleration of (double) 10000 mm/s^2. But my point was that, according to the Wiki, M204 applies to the entire move. That includes the extruder pushing filament through the hot end. Which in turn means that the melt rate of the filament has to accelerate at the same speed, which is kinda impossible. So the print head might be capable of ripping people's hands off, but there is no way on God's earth that the filament could be melted and extruded at those kind of speeds and accelerations. Non print moves fine but not extrusion moves.
Maybe I'm wrong but it'd explain the behaviour that's on your video. Or maybe as I said, there is some interaction between M204 and PA (yes, a bug if you like).
Anyway, easy to test to find out... -
@edgars-batna Oh and don't forget that in your config, you have the steps per mm set to 88 but then you change micro-stepping to 16X from 8X which gives you 176 steps per mm. If you remember, you did that deliberately so that you can set mixing to 0.5:0.5.
I kinda doubt that your E steps per mm and 16x micro stepping are what causes the problem because they are common values for non-geared extruders and AFAIK, nobody else has reported the same problem. But I admit that I'm clutching at straws and have run out of ideas.
-
So, finally reached the end of this thread.
@deckingman Just some info here:
M204actually does understand theSnnnparameter (although it is not documented) and will act as if you provided the value to bothPnnnandTnnn, i.e.M204 S50will translate internally toM204 P50 T50. But either way machine limits (i.e.M201) always take precedence.
Simplified example: in case you have setM201 X20 Y20 Z20 E20and then useM204 S1000000000it will still limit to the 20mm/sĀ² ofM201.@Edgars-Batna
That one out of the way: I also have ~100 steps/mm@x16 for E and used values for PA between 0.1 and 0.15 without having the issues described as you do. So I rather think it is some kind of issue with mixing extruders. We have seen issues there before. @deckingman should know.
You did ask about what happens if a extruder move is shorter than one microstep. There was a bug fixed with 2.02 regarding this where these extruder moves simply where dropped. Now it accumulates fractions of a microstep and once it has a full microstep accumulated it will issue this. (It should have been like that ever since but there was a bug).
A bit above you said that resetting mixing ratio to
1.0:1.0did not have any influence. Can you confirm that you also adjusted the steps/mm in this case?Also can you please once more post the block of settings with
M201(accel)M566(InstantDv in mm/min) (and/orM205- same but mm/s)M204(printing/travel accel)M92(steps/mm)M350(microstepping)M567(mixing-ratio)
as it is now? I lost track whether it is still the same as in
config.gin your OP or has changed in between.Manuel
Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
with probably always latest firmware/DWC (incl. betas or self-compiled)
My Tool Collection
