Manual Tool Change - Getting Somewhere at Last

After a couple of days of frustration, a result of combining my old way of working coupled with how I thought it should work, I finally got somewhere today.

Just using MDI commands at the moment but I can successfully change tools and have the tips contact the workpiece at Z zero. No programmed tool changes as yet.

There is one problem remaining I don't understand.

I have the tool setter on the right end of the table in a marked position, I use the "SET G37 ETS POSITION" button  to register the tool change position and  the XYZ values are set appropriately, see the posted image.  Initially I can move off this position and reliably return to it with the "MOVE TO G37 POSITION" button.

First tool change works, tool comes down on the ETS centre, all fine but the next tool change comes down about 10 mm to the left and I quickly move the ETS to match. On every subsequent tool change there is another 10mm error, the error accumulates. The ETS XYZ position numbers don't change but the "MOVE TO G37 POSITION" button goes to this new, incorrect position.

What's even stranger is when jogging the X axis I hit the MAX soft limit too early, or crash through the MIN LIMIT and hit the end stop as if something is changing the homed G53 values.

I've looked through the g370 and g371 remapped (new) o-codes that do the work and can't see anything obviously amiss.

Am I missing something basic here? Any hints as to what's is happening?

Ken.

 

Not getting very far sorting this out.

Tried going back to inch mode, there's a lot of "if it's G21 multiply by 25.4" in the Tormach python. That didn't fix it.

The error is proportional to the distance X and Y have to move to get to the tool measuring position. The error is not small, if the table has to move 350mm the error is about 60mm. Affects both X and Y, and maybe Z.

The displayed X and Y DRO values say the table is at the right place but it's not. Doing G53 G0 X 0.0 hits the home switch and estops.

 It looks like something is breaking the relationship between the G53 machine co-ords and the physical table position.

How is this possible? Is there any way a bit of python or g code subroutine can do this?
  

tommylight wrote:

Are you sure the scaling is right?

Thanks for you reply, Pretty sure, I've used versions of PathPilot for several years and what I machine comes out the right size.

If scaling was not right moves would still be repeatable even is they didn't finish in the correct positions. 

It's only the G37.1, move to tool change position that is giving me trouble. Every time I run it the position it finishes is at an X position to the left of where it should be.  And the error accumulates, every run finishes more to the left. The DROs show the tool change position as set but the table is not at that position.  Affects both X and Y, and I assume Z.

G37.1 is an O-word subroutine and bit of python prolog.
  
About to try turning on some debug flags.

Very weird what's happening.

 

I've given up on this, spent hours on it, can't see what's wrong.

Might come back to it when I'm in a better mood.

Just to close off this ancient post from nearly two years ago.

Manual tool changes prompted from running G code work perfectly with no software mods.

The erroneous G37 / G37.1 positioning turned out to be an INI file problem, not scaling as "tommylight" suggested but an unintended alteration to X acceleration.