Extruder motors skip steps with pressure advance enabled

Edgars Batna

@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.

deckingman

@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.

Edgars Batna

@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.

deckingman

@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............

Edgars Batna

@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.

deckingman

@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............

deckingman

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.

Edgars Batna

@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.

deckingman

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...

deckingman

@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.

wilriker

So, finally reached the end of this thread.

@deckingman Just some info here: M204 actually does understand the Snnn parameter (although it is not documented) and will act as if you provided the value to both Pnnn and Tnnn, i.e. M204 S50 will translate internally to M204 P50 T50. But either way machine limits (i.e. M201) always take precedence.
Simplified example: in case you have set M201 X20 Y20 Z20 E20 and then use M204 S1000000000 it will still limit to the 20mm/s² of M201.

@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.0 did 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/or M205 - 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.g in your OP or has changed in between.

deckingman

@wilriker Good to know about M201 taking precedence over M204 - thanks for clearing that up (but Slicers shouldn't mess about with these things IMO).

And yes, I had problems with PA messing with arc moves using a mixing hot end which took about a year to get resolved. But it's fine for me now using around 0.4 - 0.5 PA (but my steps per mm are about 400).

Edgars Batna

@deckingman I suppose wilriker's post clarifies what happens with M204, which I can confirm works as expected.

@wilriker Thanks for looking through it. The thread is as long as the story behind this. I've done like a dozen modifications to various parts of my printer over the last year, but I don't complain. The printer got at least twice better in all aspects now.

Regarding mixing: I've already tried disabling it. Behavior is the same. There's no need to adjust steps/mm for 1.0:1.0 mixing if I set the same value at double microsteps. I'm happy to rerun any tests if required.

To reiterate, if I change this:
M350 X16 Y16 E8:8 Z16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z2126.732 E88.208871:88.208871 ; Set steps per mm
M350 X16 Y16 E16:16 Z16 I1

to this:
M350 X16 Y16 E8:8 Z16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z2126.732 E88.208871:88.208871 ; Set steps per mm
M350 X16 Y16 E256:256 Z16 I1

Then it skips way less in the worst (third) gcode I originally posted, but it still skips. Trivial prints do not appear to visibly skip, but there are a few minor layer inconsistencies which are with high certainty caused by a skip that is simply inaudible. I repeat, skips are not sporadic and are load-independent; the skips are deterministic.

Regarding mixing,
1.0:1.0:
M350 X16 Y16 E16:16 Z16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z2126.732 E88.208871:88.208871 ; Set steps per mm
M350 X16 Y16 E16:16 Z16 I1
M567 P1 E1.0:1.0 ; set tool mix ratios more comments for greedy spam filter: let my posts alone!

0.5:0.5:
M350 X16 Y16 E8:8 Z16 I1 ; Configure microstepping with interpolation
M92 X80 Y80 Z2126.732 E88.208871:88.208871 ; Set steps per mm
M350 X16 Y16 E16:16 Z16 I1
M567 P1 E0.5:0.5 ; set tool mix ratios

M350 recalculates the steps/mm.

@wilriker said in Extruder motors skip steps with pressure advance enabled:

Also can you please once more post the block of settings

Until yesterday evening I ran with the values like in the original config.g. Then I tweaked the values a bit during a print (plus the E256 stepping config above):
M566 X2000 Y2000 Z600 E750:750 ; Set maximum instantaneous speed changes (mm/min)
M203 X96000 Y96000 Z800 E7500:7500 ; Set maximum speeds (mm/min)
M201 X24000 Y24000 Z1200 E1500:1500 ; Set accelerations (mm/s^2)
M906 X2100 Y2100 Z2000 E2400:2400 I40 ; Set motor currents (mA) and motor idle factor in per cent

M593 F20
M204 is per gode file, usually M204 S10000

The rest is same, still at 0.5:0.5.

@wilriker said in Extruder motors skip steps with pressure advance enabled:

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).

But I'm sort of seeing the exact opposite. Instead of accumulating, it sort of forces a single microstep movement. Maybe the firmware got corrupted? Should I reupload?

@wilriker said in Extruder motors skip steps with pressure advance enabled:

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.

I wouldn't move it out that fast. I can print most prints without too obvious problems at lower values, but then some prints just fail. Have you tried the exact gcode as I posted it? But I suppose it won't fit your printer... Maybe this is easier to work with: 0_1548425317168_EccentricGearTest 0 0.gcode

Would be interesting to see layer width consistency on your printer.

wilriker

@edgars-batna I looked into the file you posted. The first thing I noticed is that you sliced using volumetric extrusion. Just for testing could you slice that file again with volumetric extrusion disabled and see if this changes anything? Because that is something I don't use. And maybe you found an issue with volumetric extrusion and PA here.

I am currently in the middle of converting my machine to 24V and thus I cannot print the file you provided anytime soon, sorry.

Ref corrupted firmware: it is quite unprobable that a corrupted firmware will have just this one thing reversed. But it surely cannot harm to reinstall it.

Edgars Batna

@wilriker Just a heads-up: I just reuploaded 2.02a and removed the second extruder from the config.g entirely and the behavior is the same.

Will try disabling volumetric extrusion.

Edgars Batna

Just for reference, these are the places with absolute worst behavior (Top+Lid+2.gcode in original post) from that video:

0_1548429374400_2f87729c-9521-4913-ab99-bbef2288c97d-grafik.png

Excerpt from gcode:
G1 X307.783 Y59.405 E0.01269
G1 X307.955 Y59.360 E0.01269
G1 X309.040 Y59.360 E0.07748
G1 X309.211 Y59.405 E0.01269
G1 X309.383 Y59.360 E0.01269
G1 X309.925 Y59.360 E0.03873
G1 X309.925 Y55.870 E0.24921
G1 X310.033 Y55.542 E0.02466
G1 X310.092 Y55.447 E0.00801
G1 X310.472 Y55.094 E0.03701
G1 X310.814 Y54.981 E0.02576
G1 X311.896 Y54.981 E0.07726
G1 X312.068 Y55.027 E0.01269
G1 X312.240 Y54.981 E0.01269
G1 X313.325 Y54.981 E0.07748
G1 X313.496 Y55.027 E0.01269
G1 X313.668 Y54.981 E0.01269
G1 X314.753 Y54.981 E0.07748
G1 X314.925 Y55.027 E0.01269
G1 X315.096 Y54.981 E0.01269
G1 X316.181 Y54.981 E0.07748
G1 X316.353 Y55.027 E0.01269
G1 X316.525 Y54.981 E0.01269
G1 X317.610 Y54.981 E0.07748
G1 X317.781 Y55.027 E0.01269
G1 X317.953 Y54.981 E0.01269
G1 X319.038 Y54.981 E0.07748
G1 X319.210 Y55.027 E0.01269
G1 X319.381 Y54.981 E0.01269
G1 X320.466 Y54.981 E0.07748
G1 X320.638 Y55.027 E0.01269
G1 X320.810 Y54.981 E0.01269
G1 X321.895 Y54.981 E0.07748
G1 X322.066 Y55.027 E0.01269
G1 X322.238 Y54.981 E0.01269
G1 X323.323 Y54.981 E0.07748
G1 X323.495 Y55.027 E0.01269
G1 X323.666 Y54.981 E0.01269
G1 X324.751 Y54.981 E0.07748
G1 X324.923 Y55.027 E0.01269
G1 X325.095 Y54.981 E0.01269
G1 X326.180 Y54.981 E0.07748
G1 X326.351 Y55.027 E0.01269
G1 X326.523 Y54.981 E0.01269
G1 X327.608 Y54.981 E0.07748
G1 X327.780 Y55.027 E0.01269
G1 X327.951 Y54.981 E0.01269
G1 X329.036 Y54.981 E0.07748
G1 X329.208 Y55.027 E0.01269
G1 X329.380 Y54.981 E0.01269
G1 X330.464 Y54.981 E0.07748
G1 X330.636 Y55.027 E0.01269
G1 X330.808 Y54.981 E0.01269
G1 X331.893 Y54.981 E0.07748
G1 X332.064 Y55.027 E0.01269
G1 X332.236 Y54.981 E0.01269
G1 X333.321 Y54.981 E0.07748
G1 X333.493 Y55.027 E0.01269
G1 X333.664 Y54.981 E0.01269
G1 X334.749 Y54.981 E0.07748
G1 X334.921 Y55.027 E0.01269
G1 X335.093 Y54.981 E0.01269
G1 X336.178 Y54.981 E0.07748
G1 X336.349 Y55.027 E0.01269
G1 X336.521 Y54.981 E0.01269
G1 X337.606 Y54.981 E0.07748
G1 X337.778 Y55.027 E0.01269
G1 X337.949 Y54.981 E0.01269
G1 X339.034 Y54.981 E0.07748
G1 X339.206 Y55.027 E0.01269
G1 X339.378 Y54.981 E0.01269
G1 X340.463 Y54.981 E0.07748
G1 X340.634 Y55.027 E0.01269
G1 X340.806 Y54.981 E0.01269
G1 X341.886 Y54.981 E0.07710
G1 X342.082 Y55.020 E0.01429
G1 X342.234 Y54.981 E0.01121
G1 X343.319 Y54.981 E0.07752
G1 X343.491 Y55.027 E0.01269
G1 X343.663 Y54.981 E0.01269
G1 X344.748 Y54.981 E0.07748
G1 X344.919 Y55.027 E0.01269
G1 X345.091 Y54.981 E0.01269
G1 X346.176 Y54.981 E0.07748
G1 X346.348 Y55.027 E0.01269
G1 X346.519 Y54.981 E0.01269
G1 X347.598 Y54.981 E0.07704
G1 X347.744 Y55.012 E0.01061
G1 X347.999 Y55.132 E0.02016
G1 X348.339 Y55.472 E0.03437
G1 X348.461 Y55.730 E0.02032
G1 X348.487 Y55.841 E0.00813
G1 X348.490 Y59.300 E0.24703

The places are obvious as they sort of oscillate. Maybe underflow somewhere?

Oh my, it's 2019 and we still haven't figured out how to use double precision or at least exponential notation:

G1 X387.722 Y86.349 E0.00507
G1 X387.540 Y86.167 E0.01838
G1 X387.358 Y86.349 E0.01838
G1 X387.292 Y86.376 E0.00507
G1 X386.359 Y86.376 E0.06664
G1 X386.294 Y86.349 E0.00507
G1 X386.112 Y86.167 E0.01838
G1 X385.930 Y86.349 E0.01838
G1 X385.864 Y86.376 E0.00507
G1 X384.931 Y86.376 E0.06664
G1 X384.865 Y86.349 E0.00507
G1 X384.683 Y86.167 E0.01838
G1 X384.501 Y86.349 E0.01838
G1 X384.436 Y86.376 E0.00507
G1 X383.503 Y86.376 E0.06664
G1 X383.437 Y86.349 E0.00507
G1 X383.298 Y86.210 E0.01400
G1 X383.150 Y86.358 E0.01493
G1 X382.645 Y86.358 E0.03608
G1 X382.497 Y86.210 E0.01493
G1 X382.359 Y86.349 E0.01400
G1 X382.293 Y86.376 E0.00507
G1 X381.360 Y86.376 E0.06664
G1 X381.294 Y86.349 E0.00507
G1 X381.113 Y86.167 E0.01838
G1 X380.931 Y86.349 E0.01838
G1 X380.865 Y86.376 E0.00507
G1 X379.932 Y86.376 E0.06664
G1 X379.866 Y86.349 E0.00507
G1 X379.684 Y86.167 E0.01838
G1 X379.502 Y86.349 E0.01838
G1 X379.437 Y86.376 E0.00507
G1 X378.503 Y86.376 E0.06664
G1 X378.438 Y86.349 E0.00507
G1 X378.256 Y86.167 E0.01838
G1 X378.074 Y86.349 E0.01838
G1 X378.008 Y86.376 E0.00507

Maybe disabling volumetric extrusion could cause it to get worse as the values would be lower. I'll try...

Without cough volumetric extrusion cough cough:
G1 X165.838 Y66.956 E0.00211
G1 X165.656 Y66.774 E0.00764
G1 X165.474 Y66.956 E0.00764
G1 X165.408 Y66.983 E0.00211
G1 X164.475 Y66.983 E0.02771
G1 X164.410 Y66.956 E0.00211
G1 X164.228 Y66.774 E0.00764
G1 X164.046 Y66.956 E0.00764
G1 X163.980 Y66.983 E0.00211
G1 X163.047 Y66.983 E0.02771
G1 X162.981 Y66.956 E0.00211
G1 X162.799 Y66.774 E0.00764
G1 X162.617 Y66.956 E0.00764

Maybe I need absolute E values?

wilriker

@edgars-batna Absolute E values will be converted internally to relative ones as soon as that line of GCode is parsed so there will probably be no change in switching to this.

Still I'd like to know what happens if you print this file with regular relative extrusion. It still might be that there is a bug in the combination of PA and volumetric extrusion. Even though I did not find anything suspicious in the source code. But everything regarding movement is very complicated and distributed so it is easy to miss some aspects if you are not very familiar with the code.

Edgars Batna

@wilriker @deckingman I'm now running the EccentricGearTest in non-volumetric mode and the print speed feels like 150% than what was in volumetric mode and I'm sure it extrudes same amount of filament. The extruder motors still produce knocking sounds as if losing steps, but this time it's independent of E microstepping - same thing happens on 16 and 256.

0_1548436488558_EccentricGearTest 0 0 non-volumetric.gcode
0_1548436494441_EccentricGearTest 0 0 volumetric.gcode

Layer width is still inconsistent and I can hear the steps are lost.

EDIT: added files

Edgars Batna

@wilriker I'm in the code after all. First place I think needs some clarifying:

dev branch
GCodes.cpp:2333
volumetricExtrusionFactors seems to be used squared when only one E parameter is present, why?

		if (eMoveCount != 0)
		{
			// Set the drive values for this tool
			float eMovement[MaxExtruders];
			size_t mc = eMoveCount;
			gb.GetFloatArray(eMovement, mc, false);

			if (mc == 1)
			{
				// There may be multiple extruders present but only one value has been specified, so use mixing
				const float moveArg = eMovement[0] * distanceScale;
				float requestedExtrusionAmount;
				if (gb.MachineState().drivesRelative)
				{
					requestedExtrusionAmount = moveArg;
				}
				else
				{
					requestedExtrusionAmount = moveArg - virtualExtruderPosition;
					virtualExtruderPosition = moveArg;
				}

				// rawExtruderTotal is used to calculate print progress, so it must be based on the requested extrusion before accounting for mixing,
				// otherwise IDEX ditto printing and similar gives strange results
				if (moveBuffer.moveType == 0 && !doingToolChange)
				{
					rawExtruderTotal += requestedExtrusionAmount;
				}

				for (size_t eDrive = 0; eDrive < eMoveCount; eDrive++)
				{
					const int drive = tool->Drive(eDrive);
					float extrusionAmount = requestedExtrusionAmount * tool->GetMix()[eDrive];
					if (extrusionAmount != 0.0)
					{
						if (gb.MachineState().volumetricExtrusion)
						{
							extrusionAmount *= volumetricExtrusionFactors[drive];
						}
						rawExtruderTotalByDrive[drive] += extrusionAmount;

						// Don't count extrusion done in filament loading or tool change macros towards total filament consumed, it distorts the print progress
						moveBuffer.coords[drive + numTotalAxes] = extrusionAmount * extrusionFactors[drive];
#if HAS_SMART_DRIVERS
						if (moveBuffer.moveType == 1)
						{
							SetBit(moveBuffer.endStopsToCheck, drive + numTotalAxes);
						}
#endif
					}
				}
			}
			else
			{
				// Individual extrusion amounts have been provided. This is supported in relative extrusion mode only.
				if (gb.MachineState().drivesRelative)
				{
					for (size_t eDrive = 0; eDrive < eMoveCount; eDrive++)
					{
						const int drive = tool->Drive(eDrive);
						float extrusionAmount = eMovement[eDrive] * distanceScale;
						if (extrusionAmount != 0.0)
						{
							if (gb.MachineState().volumetricExtrusion)
							{
								extrusionAmount *= volumetricExtrusionFactors[drive];
							}
							rawExtruderTotalByDrive[drive] += extrusionAmount;

							// Don't count extrusion done in filament loading or tool change macros towards total filament consumed, it distorts the print progress
							if (moveBuffer.moveType == 0 && !doingToolChange)
							{
								rawExtruderTotal += extrusionAmount;
							}
							moveBuffer.coords[drive + numTotalAxes] = extrusionAmount * extrusionFactors[drive] * volumetricExtrusionFactors[drive];
#if HAS_SMART_DRIVERS
							if (moveBuffer.moveType == 1)
							{
								SetBit(moveBuffer.endStopsToCheck, drive + numTotalAxes);
							}
#endif
						}
					}
				}
				else
				{
					platform.Message(ErrorMessage, "Multiple E parameters in G1 commands are not supported in absolute extrusion mode\n");
				}
			}
		}

DriveMovement.cpp:241

		mp.cart.accelStopStep = (uint32_t)((dda.accelDistance + accelCompensationDistance) * effectiveStepsPerMm) + 1;

DriveMovement.cpp:249

		mp.cart.accelStopStep = (uint32_t)(dda.accelDistance * effectiveStepsPerMm) + 1;

and some others where a +1 is added. How do I interpret this? Does this mean acceleration will occur for a full microstep? Shouldn't this be rounded instead of forced to +1?

I'm fresh to the code and I can't wait to fix my printer, so any help is much appreciated... Need to figure out how to build this so I can break my machine for good and move on...

wilriker

@edgars-batna I couldn't help and had to get my machine back working to try to print the EccentricGearTest non-volumetric. Only a couple of layers though because I only sloppily set it back to working condition and it was unable to cope with the high jerk for Y. Anyway, until I stopped it there were no observable skipped steps for the extruder. running with PA at 0.1s. Also no issues reported in M122 (which I would not expect also on your side).

Ref double application of volumetricExtrusionFactors: a couple of lines above that it will multiply requestedExtrusionAmount with the current extruder's mixing-ratio. In your case at 0.5 this will half the extrusion amount for this extruder. And this value will then be multiplied to convert it back from volumetric to "regular" extrusion. So I don't see anything wrong there.

About this +1 I would have to read the code more in depth to answer that. Maybe @dc42 can step in here?