How do the intricacies of the model affect the chances of losing steps?

I'm running an open-loop stepper system from a Mesa6i25(5i25-family) card with LinuxCNC 2.8.

Over there I documented a struggle to leap from a software-step system to a Mesa-6i25, hampered by a few serious misunderstandings and misconceptions. However with help from the usual suspects, I persevered and finally returned to a new normal.

I successfully cut two models in wood using my customary setting of 120ipm, but the models were of the "flat" variety: low-relief text on a flat background.

The latest attempt is a deep-dish circular plaque for a wall-hanging, but not that deep: 3/4". I'll attach a picture.

The 1/2"-endmill roughing pass went fine.  For once, caution suggested I do a dry run of the finish pass, which uses a 1mm ball-end and the same, 120ipm, feed which "has always worked before."

After running over the relatively flat southern end of the disk, sounds from the machine indicated it was losing steps, but moments later it stalled, proving it.

My theory is that my MAX_ACCEL settings and STEPLEN as referenced over there are still wrong/too agrees, and that I didn't see it in the rough pass because the performance never approached the problematic zone.

Thank you for mulling this over.



 

Yes, Andy is on the money. The real world places different stresses on the motor. After an extensive amount of testing, I had some spectacular crashes until I reduced my accelleration.

The other times motors loose steps is when motors get hot and I experienced more spectacular crashes. The Lam drivers some of us use, reduce the current to the drive when at constant velocity to allow the motors to cool to attain higher performance. The motor only works hard when accelerating and descellerating) and the torque at constant velocity might only need to be 20% of that.

Andy, thank you for the quick response and Rod, for the 2nd.

I confess that I was so shaken by the re-appearance of a behavior I thought had been resolved that I couldn't do anything more but throw a Hail Mary and go to bed, hoping to awaken to the appearance of at least one possible way forward.

"What a relief"--increasingly--to find your posts this morning, and to know I'm not crazy. At least not yet. At least not completely.

I recognize 'G64' from this line in the programmed preamble to every MeshCAM-generated G-Code program file going back to time immemorial (note the line number, following 'N1 G55':

N2 G64 P0.001 ; set Path-blending tolerance

put in, I hasten to add, because it was recommended, but not necessarily absorbed. I did understand that it was about "how perfect" the machine had to adhere to commands.

I cannot believe that "a thousandth" wasn't a strict enough requirement to slow the machine down to avoid losing steps.  My first try will be to change this to "a millionth." :grin:

The documentation[1] (which I will shortly quote, because of the subject line) speaks of a second argument which I will next try:

G64 P0.001 Q0.0001 ; Stay w/i a thou of the commanded path, but combine steps w/i 0.0001 of each other

because it may well be that too many meaningless steps (I am after all trying to make Art, not components for moon shots) are causing needless tripping up.

If these work, I'll change my preamble, and if they don't I'll look at those MAX_ACCELERATION settings in the .ini file.

I'll put the G64 documentation in a separate post in this thread.

[1] link here because my balky network isn't transmitting my request to insert a link:
linuxcnc.org/docs/stable/html/gcode/g-code.html#gcode:g64

The section of G-code documentation re: G64 :

36. G64 Path Blending 

G64 <P- <Q->>

• P - motion blending tolerance
• Q - naive cam tolerance
• G64 - best possible speed.
• G64 P- <Q- > blending with tolerance.
• G64 - without P means to keep the best speed possible, no matter how far away from the programmed point you end up.
• G64 P- Q- - is a way to fine tune your system for best compromise between speed and accuracy. The P- tolerance means that the actual path will be no more than P- away from the programmed endpoint. The velocity will be reduced if needed to maintain the path. In addition, when you activate G64 P- Q- it turns on the naive cam detector; when there are a series of linear XYZ feed moves at the same feed rate that are less than Q- away from being collinear, they are collapsed into a single linear move. On G2/G3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 P- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines. Thus, line-arc, arc-arc, and arc-line cases as well as line-line benefit from the naive cam detector. This improves contouring performance by simplifying the path. It is OK to program for the mode that is already active. See also the Trajectory Control Section for more information on these modes. If Q is not specified then it will have the same behavior as before and use the value of P-.

G64 P- Example Line

G64 P0.015 (set path following to be within 0.015 of the actual path)

It is a good idea to include a path control specification in the preamble of each G code file.

I was messing around with things like:

G64 P0.000001
G64 P0.001 Q0.001

etc. while continuing to search for information about the implications of MAX_ACCELERATION settings in the .ini file.  From G64 I was attempting to learn if a stricter tolerance would force LinuxCNC's trajectory planner (I almost wrote plajectory tranner) to SLOW DOWN in intricate/complex regions.  Not really, was my experience.

However I observed that RELAXING the requirement to P0.01 DID result in the run continuing without "tripping/stumbling" noises, but thereafter noticed with another setting that P0.01 was overly smoothing the details I needed to keep.

That led me back to looking at my ACCELERATION settings in the .ini.

Meanwhile I'd found this observation from @tommylight (for which, again, I am indebted):

Acceleration of 750mm/s/s is ok for lite machines, but for heavy stuff 500 or 350 or 200 might be needed, depending on the moving mass. Although motors might do such accelerations, the load on everything can be so big as to cause premature failures.

In the end, I observed from the test runs that the machine ran more smoothly with MAX_ACCELERATION reduced in the .ini file from '90' (horrors!) to 20, with a default of 10 in/s/s.  (I tried to imagine 90 in/s/s, and it made me jittery.)  With these values in my .ini:

[TRAJ]
DEFAULT_LINEAR_ACCEL = 10
MAX_LINEAR_ACCEL = 20
# down from 90/120
[AXIS_X]
MAX_ACCELERATION = 20
# down from 90
[JOINT_0]
MAX_ACCELERATION = 20
STEPGEN_MAXACCEL = 25
# down from 90/112.25
# and same for [AXIS_Y|Z] and [JOINT_1|2]

operation is much more peaceable.

I'm confident now I'll be able to do the finish cut.

 

The acceleration looks workable.
For reference, it is possible to get Acceleration up to 5 m/sec/sec (200 in/sec/sec) on a stepper system with high voltage power supply, expensive high quality Lam drivers with their cooling boost feature enabled but the learning curve is littered with racked gantries and spectacular crashes!