High level of StepErrors. What can cause them ?

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!