Suddenly Skipping Steps
-
@ccs86 said in Suddenly Skipping Steps:
Have you ever tried switching from stealthchop to spreadcycle at too high of a speed? It's like that.
And it wasn't in stealthchop for sure?
-
For sure. I could never get that transition to work well for me, so I force spreadcycle on X and Y now.
-
@ccs86 said in Suddenly Skipping Steps:
4000mm/s/s doesn't seem very high for travel moves in this era.
@ccs86 said in Suddenly Skipping Steps:
4000 mm/s/s travel accel is "too high"? The speed boat race guys are running 100,000+
For a Maestro though? I'm not sure. Will have to see what DC42 thinks.
What are the motor specs by the way?
-
@phaedrux said in Suddenly Skipping Steps:
What are the motor specs by the way?
https://www.omc-stepperonline.com/download/17HM19-2004S.pdf
https://www.omc-stepperonline.com/download/17HM19-2004S_Torque_Curve.pdf
-
Any thoughts @dc42?
-
I think he's away today, but he did have the same thought as I had about low jerk, perhaps specifically Z jerk if mesh compensation was enabled.
-
The low Z jerk + mesh comp is a good thought. It makes sense...
But, I have my mesh taper at 1.5mm and the first layer shift is at Z=3.5mm
-
back to the drawing board then.Other than my previous thoughts on low jerk high accel I'm not sure what else to think.
-
@phaedrux said in Suddenly Skipping Steps:
back to the drawing board then.Other than my previous thoughts on low jerk high accel I'm not sure what else to think.
What would be the mechanism that low jerk / high accel could cause this behavior?
-
Back EMF limiting the available acceleration?
-
@phaedrux said in Suddenly Skipping Steps:
Back EMF limiting the available acceleration?
Could that still be the cause when the issue only arises just after a sequence on tiny travel moves? I can run even higher acceleration, with the same low jerk, using longer straight line travels, and never have this issue.
It really feels like the motion planner/controller is confused by this sequence.
Maybe someone else could dry run this gcode with a cold extruder and large Z offset to see if the behavior is the same.
-
I'll see if I can get to my printer this afternoon, though I don't have a Maestro running at the moment.
Would you be able to try it with higher jerk and/or lower acceleration?
-
When I get time, I'll try to isolate the actual section of code and create a new file with just that. Will be much faster to experiment with how settings affect the behavior.
-
@ccs86 said in Suddenly Skipping Steps:
It really feels like the motion planner/controller is confused by this sequence.
I remember there was a bug report about "not being able to print small circles". That sounds similar to your issue I think.
But it was solved soon....so it shouldn't happen again in a newer FW? -
@dc42 Have you gotten a chance to look at this at all?
I did more testing by making a reduced version of the gcode file to test, with no heater or fan calls, and skipping ahead to Z24.4
What I found so far:
-
The issue does not repeat every single time. Even with no changes to the settings or code, the issue may or may not happen.
-
Increasing my XY jerk from 6 mm/s to 15 mm/s made no improvement, maybe slightly worse.
-
Starting from Z24.4, then pausing at the first skipped step tends to happen at Z24.7. But, if I strip out the beginning code and start right at Z24.7, the glitch does not occur in the same spot. So, this isn't some bad instruction alone. It must be a combination of a code sequence, and a specific condition the motion controller is in.
-
Lowering the travel acceleration has the capacity to avoid the issue. Instead of my normal M204 P2660 T4000, if I run at P2000 T2000 I haven't reproduced the issue. It seems possible that this is just buying the motion controller more time to catch up.
The attached gcode should be safe for anyone else to test, just look at the intro code, to make sure the homing sequence is compatible with your setup, or modify to match your machine. I don't want anyone driving a nozzle into their bed for me!
-
-
@CCS86 I think he's deep into input shaping atm, but I will pass on your updates, and I will see if I can run your test gcode, but I don't have a maestro running atm.
-
@phaedrux said in Suddenly Skipping Steps:
@CCS86 I think he's deep into input shaping atm, but I will pass on your updates, and I will see if I can run your test gcode, but I don't have a maestro running atm.
I would gladly put this issue on ice for chance at input shaping working on a Maestro board!
-
.......?
-
@ccs86 your M122 report indicates a possible problem with the rate of execution of moves:
Scheduled moves 15909, completed moves 15909, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 1, 1], CDDA state -1
The first underrun number is the number of lookahead underruns, i.e. there were not enough spaces available in the move queue to do full lookahead. This type of underrun causes movement to be slower when there are very many short decelerating segments in succession.
The second figure is the number of prepare underruns. This indicates that the step interrupt service routine wanted another move, but although there was one it had not been prepared for execution. I think this caused the symptom you reported.
The third figure is the number of "no move" underruns. This indicates that the step interrupt routine wanted another move but none was available. It is normal to get one of these in certain situations, for example at the end of a print.
So the question is, why did a prepare underrun occur. It can only mean that the Move task either was not scheduled at an appropriate point, or the CPU was too busy servicing interrupts or executing higher priority tasks to attend to it. I will investigate it.
-
@ccs86 until I have a fix, I think a workaround may be to increase the movement queue length using M595. Try M595 P60 or M595 P80. Increasing the movement queue length will reduce the amount of RAM available, which you can check with M122. Look at the value of "Never used RAM" when the machine has been printing.
