[LeeWay]

I hired him on 09. Her about a year ago. I think it has run it's course. She got a cushy girly job and he is looking into something else. I am happy to be a stepping stone. They are trained well and at least one has good manners.

[DigDug]

I had the same exact problem as the OP. Using SolidWorks and HSMXpress and same Tormach_NexGenCAM_110911.cps post.
When doing pockets with helical entry it would loose Z height over several parts. Always getting lower and lower into the part on
each new pocket. The Z axis would kind of make a clunking sound when plunging and retracting to the feed height. I checked tightness
of the gib and also the motor connection to the ball screw and all was good.

The fix was to change the option in HSMXpress under "Linking" to "Always use high feed". This setting is in the far right tab
when you are editing a toolpath. I have also found that using "Preserve radial rapid movement" works also and lets X and Y rapid fast
but limits Z to the highest feedrate set for the tool and not a G0 speed.

Hope that helps,
P.S. This is my first post

PCNC 1100 (no ATC)
Standard Tormach issue Mach3

[kirk_wallace]

(Just thinking out loud)

It seems, from my brief reading of this thread, that the original problem was solved by upgrading (or downgrading) the machine software. But, from my limited experience, when I hear of Z axis creeping, it is due to steps being missed by the stepper motor due to being overloaded, or rather, the force required to move the axis was higher than the motor could provide. Common stepper systems have _no_ positional feedback, so the software has no idea that steps may have been missed. The software has to assume that every step called for is completed properly. The key is in configuring the software to never call for steps in a way that can not be met. Therefore, the system performance needs to be measured to find the safe operating envelope, such as maximum speed, acceleration and any resonance zones, then the software needs to be configured to stay within the limits. Usually a safety factor of 10 or 20 percent is applied to make sure that common performance variations are still within limits. An accurate performance model is key, and if done properly the software will never ask for steps that might be lost.

Further, it is up to the machine operator to make sure the machine's performance envelope is maintained so that the software model matches the current machine performance. If the machine changes, the original performance will need to be restored or a new software model will need to be created.

For the Z axis the model has to take into consideration that gravity on the spindle will load the up motion more than the down motion. The model has to assume the worst case, so the limits need to be set to the up motion parameters.

Another side of this is how well the model is applied. A perfect model can fail if the software cheats or is occasionally blind to the limits. This may be why some versions of software seem to be better than others.

Also, g-code can have a hand in it. Normal feed rates are usually well below the machine's rapid rate, but there is nothing to stop a feed rate beyond a limit from being entered. In this case, the software should at least detect that the feed rate is beyond the model limits and fault out with a following error. Since stepper systems don't have positional feedback, this is the normal source of following errors.

So, if one starts losing steps, check for (maybe in reverse order); a change in the machine configuration file (performance model), or a change in the software (model application), or a change in the machine's physical condition or motor driver defect (model mismatch). Being familiar with the configuration file and how it works can be handy.

[SCzEngrgGroup]

Load was not an issue in the OPs problem. He saw the same position loss when "air cutting". It is the controllers (i.e. - Mach 3s) responsibility to never command a move that violates the acceleration and velocity limits set in the Mach3 Motor Tuning dialog. In the OPs case, Mach3 WAS, due to a bug, commanding moves that violated those limits. That was a well-known, well-documented, long-standing bug in many versions of Mach3 that was finally fixed a few years ago. The bug was that under certain circumstances, when transitioning from a 2-axis (i.e. X/Y) move, to a 3-axis (i.e. X/Y/Z) helical move, the acceleration ramp on the Z axis was skipped, which commanded the Z axis to change instantly from a stop to moving at high speed, which the hardware cannot do.

Regards,
Ray L.