High level of StepErrors. What can cause them ?

dc42

That does look bad. My guess it that they are triggered by the combination of using pressure advance and a RDD extruder drive.

Connect a terminal emulator or Pronterface via USB and send M111 S1 P4 to enable Move debugging. Every time a step error is registered, it will report the details to USB. Run the print for a little while, then pause it and copy the error details for several step errors to a file. Don't post the contents directly here because it will be too long, but put the file on Dropbox or similar and link to it from a post here.

The other thing you can try is repeating the print with no pressure advance.

bot

One thing to try, too, would be to reduce micro stepping on the E axis.

You should be able to halve, or even quarter your steps generated for the E axis – high gear ratios, with such plastic flow, is going to require a LOT of steps.

Jarery

@dc42:

That does look bad. My guess it that they are triggered by the combination of using pressure advance and a RDD extruder drive.
The other thing you can try is repeating the print with no pressure advance.

The same print with pressure advance off, no other changes.

=== Move ===
MaxReps: 12, StepErrors: 0, FreeDm: 240, MinFreeDm 120, MaxWait: 4200683977ms, Underruns: 0, 0

So it went from StepErrors: 15494, to StepErrors: 0 by turning pressure advance off.

Catalin_RO

I preferred to not start a new thread on the subject. I have done some engraving with my CNC (firmware 2.0) and heard some bump noises so I decided to check for StepErrors. While seeing only 14 errors, I decided it is worth investigating. Some of the errors captured through USB are:

DDA: start=[203.292404 30.260700 76.495453 0.000000 0.000000] end=[203.293304 30.259602 76.495453 0.000000 0.000000] d=0.001420 vec=[0.633823 -0.773478 0.000000 0.000000 0.000000]
a=193.929138 reqv=13.333334 startv=5.315803 topv=5.315803 endv=5.263730 daccel=0.000000 ddecel=0.001420
cks=251 sstcda=25697 tstcdapdsc=25697 exac=0
DMW ERR: dir=F steps=1995 next=1986 rev=1996 interval=10000252 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=128 fmsdmtstdca2=d cc=6453 acc=0

DDA: start=[241.179703 31.427801 76.621552 0.000000 0.000000] end=[241.180298 31.429701 76.621552 0.000000 0.000000] d=0.001991 vec=[0.298930 0.954275 0.000000 0.000000 0.000000]
a=157.188095 reqv=13.333334 startv=6.451199 topv=6.451199 endv=6.402509 daccel=0.000000 ddecel=0.001991
cks=290 sstcda=38476 tstcdapdsc=38476 exac=0
DMY: not moving
DMW ERR: dir=F steps=1995 next=1986 rev=1996 interval=10000291 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=148 fmsdmtstdca2=d cc=11159 acc=0

DDA: start=[241.179703 31.427801 76.548248 0.000000 0.000000] end=[241.180298 31.429701 76.548149 0.000000 0.000000] d=0.001993 vec=[0.298559 0.953093 -0.049760 0.000000 0.000000]
a=157.382828 reqv=13.333334 startv=6.451195 topv=6.451195 endv=6.402384 daccel=0.000000 ddecel=0.001993
cks=290 sstcda=38428 tstcdapdsc=38428 exac=0
DMY: not moving
DMW ERR: dir=B steps=1995 next=1986 rev=1996 interval=10000291 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=148 fmsdmtstdca2=d cc=11159 acc=0

DDA: start=[241.179703 31.427801 76.495453 0.000000 0.000000] end=[241.180298 31.429701 76.495453 0.000000 0.000000] d=0.001991 vec=[0.298930 0.954275 0.000000 0.000000 0.000000]
a=157.187134 reqv=13.333334 startv=6.449716 topv=6.449716 endv=6.401015 daccel=0.000000 ddecel=0.001991
cks=290 sstcda=38467 tstcdapdsc=38467 exac=0
DMY: not moving
DMW ERR: dir=B steps=1995 next=1986 rev=1996 interval=10000291 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=148 fmsdmtstdca2=d cc=11159 acc=0

DDA: start=[248.634903 57.572197 76.648849 0.000000 0.000000] end=[248.634308 57.572498 76.648849 0.000000 0.000000] d=0.000667 vec=[-0.892128 0.451783 0.000000 0.000000 0.000000]
a=168.143250 reqv=13.333334 startv=12.195185 topv=12.195185 endv=12.185985 daccel=0.000000 ddecel=0.000667
cks=51 sstcda=67995 tstcdapdsc=67995 exac=0
DMW ERR: dir=F steps=1995 next=1978 rev=1996 interval=10000052 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=26 fmsdmtstdca2=d cc=3495 acc=0

DDA: start=[249.356415 56.330200 76.562347 0.000000 0.000000] end=[249.355988 56.333000 76.562248 0.000000 0.000000] d=0.002834 vec=[-0.150750 0.987952 -0.034996 0.000000 0.000000]
a=151.829193 reqv=13.333334 startv=7.663982 topv=7.696103 endv=7.672207 daccel=0.001625 ddecel=0.001209
cks=345 sstcda=47322 tstcdapdsc=47719 exac=0
DMY: not moving
DMW ERR: dir=B steps=1995 next=1986 rev=1996 interval=10000346 2dtstc2diva=u
accelStopStep=1144 decelStartStep=1144 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=177 fmsdmtstdca2=d cc=16447 acc=0

DDA: start=[203.071701 55.660698 76.495453 0.000000 0.000000] end=[203.072601 55.659599 76.495453 0.000000 0.000000] d=0.001420 vec=[0.633823 -0.773478 0.000000 0.000000 0.000000]
a=193.929138 reqv=13.333334 startv=5.316492 topv=5.316492 endv=5.264426 daccel=0.000000 ddecel=0.001420
cks=251 sstcda=25701 tstcdapdsc=25701 exac=0
DMX: not moving
DMY: not moving
DMW ERR: dir=B steps=1995 next=1986 rev=1996 interval=10000252 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=128 fmsdmtstdca2=d cc=6453 acc=0

DDA: start=[188.923798 56.853500 76.495453 0.000000 0.000000] end=[188.923798 56.853600 76.495453 0.000000 0.000000] d=0.000099 vec=[0.000000 1.000000 0.000000 0.000000 0.000000]
a=150.000000 reqv=13.333334 startv=12.463467 topv=12.463467 endv=12.462273 daccel=0.000000 ddecel=0.000099
cks=7 sstcda=77896 tstcdapdsc=77896 exac=0
DMW ERR: dir=B steps=1995 next=1874 rev=1996 interval=10000008 2dtstc2diva=u
accelStopStep=1 decelStartStep=1 2CsqtMmPerStepDivA=u
mmPerStepTimesCdivtopSpeed=3 fmsdmtstdca2=d cc=582 acc=0

The significant part of the config.g file is:

M584 X0 Y1:4 Z2 U3 W9 E5:6 P4

M350 X16 Y16 Z16 U16 W16 ; Configure microstepping with interpolation
M906 X2400 Y2400 Z2400 U2400 W2400 I50 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
;
; Set axis dynamic parameters
M92 X400.89 Y398.91 Z398.45 U888.89 W398.91 ; Set steps per mm
M566 X300 Y300 Z12 U12 W300 ; Set maximum instantaneous speed changes (mm/min)
M203 X2500 Y2500 Z2500 U1080 W2500 ; Set maximum speeds (mm/min)
M201 X150 Y150 Z150 U150 W150 ; Set accelerations (mm/s^2)

Even if I reduce M566 values I still see the missed steps. The problem hit me hard in the past when trying trochoidal machining at 2300mm/min and I saw it going away if keeping the feed rate below 1800mm/min. Now it was just normal milling with some arcs, but at only 800mm/min.

dc42

@catalin_ro, thanks for your report. I've put it on my list to investigate, although it probably won't happen until the weekend or next week.

All the errors are on the W axis, and all are very short deceleration-only moves. What is the W axis on your machine, and how are you using it?

Please provide your complete config.g file and a GCode file that provokes the problem.

Catalin_RO

This is the config.g file that I currently use for my WorkBee. Y is dual axis and W is the slave Y. The problem is very rarely visible but it makes a "bump" sound during the movements. I changed to an air cooled HF spindle lately, much quieter than the previous Kress one, and now the "bumps" are more obvious.

0_1528894002997_config.g

This is the GCode file that exhibits at some point the problem. If left running, it just happens. Initially I have though that the extra force require for pushing the cutter through the material was the problem, but the debug was done with the spindle off, just moving through air. From what I have observed in the past, it correlates with changes from straight line to arcs, but only in some very specific situations. Originally M566 was set at 900 for X, Y and Z, but reducing to 300 didn't improve things too much (apart from slowing down some files!).

0_1528894066967_Enclosure - Inputs.Part1 - Kyocera EGR1250-060 - 24kRPM.g

Catalin_RO

Hi, the attached file exhibits the problem very close to the beginning. I have not done any debug capture on it, but the "bumps" are clearly there!

[0_1529257674474_Enclosure lid.Part1 - Sorotec 90deg V-mill - 20kRPM.nc](Uploading 100%)

dc42

Thanks that will be helpful.

Catalin_RO

I had some more files that made it happen and did some more studies on the generated machining paths. There is no problem if the start/stop of the arc is tangential to the straight move before/after it (both the arc first/last segment and previous/following line are collinear). But when it isn't, the algorithm has problems! And the problem can't be avoided by reducing maximum jerk. Sometimes even reducing the feedrate doesn't help at all.

dc42

@catalin_ro, this is on my list to investigate when I return from vacation. Please keep your sample file available because I haven't downloaded it yet.

dc42

@catalin_ro said in High level of StepErrors. What can cause them ?:

Hi, the attached file exhibits the problem very close to the beginning. I have not done any debug capture on it, but the "bumps" are clearly there!

[0_1529257674474_Enclosure lid.Part1 - Sorotec 90deg V-mill - 20kRPM.nc](Uploading 100%)

Looks like that file upload failed or the link isn't right. Can you upload it again please?

Catalin_RO

@dc42 0_1531489285217_Enclosure lid.Part1 - Sorotec 90deg V-mill - 20kRPM.gcode

dc42

Thanks.

I am trying reproduce the step errors using the original file. Can you tell me what the W axis is used for, and when it is activated? The M584 command in config,.g hides it normally.

dc42

PS - I have just run the file that you just uploaded, with no step errors reported. However, the original errors you were getting were related to movement of the W axis (that's what "DMW" means), and I can't see anything in the GCode file that would cause W to move. Is there something else I need to do before starting the print, other than using G92 to pretend that the machine is homed?

dc42

@jarery said in High level of StepErrors. What can cause them ?:

@dc42:

That does look bad. My guess it that they are triggered by the combination of using pressure advance and a RDD extruder drive.
The other thing you can try is repeating the print with no pressure advance.

The same print with pressure advance off, no other changes.

=== Move ===
MaxReps: 12, StepErrors: 0, FreeDm: 240, MinFreeDm 120, MaxWait: 4200683977ms, Underruns: 0, 0

So it went from StepErrors: 15494, to StepErrors: 0 by turning pressure advance off.

Hi @Jarery ,

Please can you provide your config.g problem and a GCode file that provokes these step errors.

Catalin_RO

@dc42 I will re-run it and see what is going on this time. The W axis is the slave Y axis and, indeed, there is no GCode sending commands specifically for it except for the ones in the homing scripts. And those scripts show it strictly during Y axis homing. The complete homing scripts are at https://forum.duet3d.com/topic/4669/ooznest-workbee-screw-driven.

dc42

@catalin_ro said in High level of StepErrors. What can cause them ?:

@dc42 I will re-run it and see what is going on this time. The W axis is the slave Y axis and, indeed, there is no GCode sending commands specifically for it except for the ones in the homing scripts. And those scripts show it strictly during Y axis homing. The complete homing scripts are at https://forum.duet3d.com/topic/4669/ooznest-workbee-screw-driven.

Thanks. Are the debug messages produced shortly after Y homing, or at intervals during the print?

Catalin_RO

@dc42 Only at intervals during the print. And only with some GCode files.

dc42

@catalin_ro, thanks. I found the problem. The hidden W axis was being moved sometimes, because the stale data for it in the move queue records from earlier moves when it was not hidden was not being cleared out when the same move queue records were re-used with the axis hidden. Had you connected a stepper motor to the output of driver 9, you would have seen it moving! This was definitely worth investigating.

I have fixed this in 2.02beta2. Please try it (carefully!) when I release it - later today I hope.

Catalin_RO

@dc42 That is great news! This single problem prevented me from using the fastest possible feedrate and I also had to reduce the jerk in order to avoid it in most cases.

When the new firmware is released, I will do some air cutting and see how it goes!