Help with MTM/offset setup

[RNC]

hi guys, I'm using a trial of your scree set and firstly, I'm impressed with the layout, much better than stock Mach 3.

The functionality I'm after is probing, which I have working fine, but I'm scratching my head on the proper way to set offsets.

I have...

1) a 3 dimensional probe, set as the master tool, with its length from the spindle zero defined as PTL, in an RH holder.

2) all of my tooling in RH holders as well, with offsets defined as the difference between their PTL and the MT PTL. At the moment the probe is the longest so all other tools have negative offsets, per your manual.

3) this is all on a sieg kx3 running an Ethernet warp9 smooth stepper, just the 3 axes, no lathe.

4) I do not have a touch plate.

And this is the workflow I've attempted with (almost) success.


A) load Mach, zero all 3 axes at their home limit switches, TCP position is also at the home limits
B) generate g code of some sort, with my cam program set to pick a corner to start from as zero for all 3 axes
C) load the probe, issue t#m6 to tell Mach it's loaded, probe the appropriate corner
D) load/execute the g code in question, issuing g43h# for each tool change

Am I missing anything here? I do not issue g43 when loading the probe, should I be giving the probe a g43 as well or does MTM do that on its own?

Does the order in which the above take place matter? I know that's straying a bit into Mach's nuances and not yours, but I've seemed to randomly start out cutting air 0.05" high from the probed z face and don't know why.

[DaveCVI]

Hi,
In general I recommend that one develop the default habit of issuing the G43H# after a tool mount in order to turn on TLO in mach.
It's just easier to explicitly turn it on than to count on mach doing it for you.

When using the probe as the maser tool (when probe # DRO = Master tool # DRO), you can get away without doing this when you mount the probe/master tool...
In MTM, the TLO is always the difference between the PTL of the master and the PTL of the tool. In the case of the master (also the probe tool in this case) that equation will always result in a TLO value = zero (since PTL of master - PTL of master = 0). And since zero is the TLO value that mach applies when TLO is not active... you end up with the correct result.
But I find it easier (and safer) to just always turn on TLO when I want it on, and turn it off when I want it off - no need to remember things like the above special case then.

Now then, mach also has a habit of turning on and off TLO based on the TLO value for the mounted tool.
This drives me nuts. I've ranted about this before, but essentially this means that mach is changing the state of a gcode program in a way that is inconsistent with what the program calls for.
IMHO TlO should not, ever, be on turned on or off "auto-magically". Mach should do what the gcode instructed it to do!
But I can't change this (broken) aspect of mach3. S0, inside MSM, I have to trick mach to make things work....
In MTM, the MT TLO is always 0, and that causes mach to turn off TLO whenever the MT is mounted (as mach refuses to activate TLO when the TLO value is equal to zero). Argggg...
So what MS does is to set a very tiny and non-zero TLO value into the tool table for the MT (like a billionth of an inch). This causes the internal mach literal comparison test to 0 to fail and then mach leaves TLO active when the MT is mounted... (please excuse the glimpse into how the sausage is made).

Dave

[RNC]

Hi,

Now then, mach also has a habit of turning on and off TLO based on the TLO value for the mounted tool.
This drives me nuts. I've ranted about this before, but essentially this means that mach is changing the state of a gcode program in a way that is inconsistent with what the program calls for.
IMHO TlO should not, ever, be on turned on or off "auto-magically". Mach should do what the gcode instructed it to do!
But I can't change this (broken) aspect of mach3. S0, inside MSM, I have to trick mach to make things work....
In MTM, the MT TLO is always 0, and that causes mach to turn off TLO whenever the MT is mounted (as mach refuses to activate TLO when the TLO value is equal to zero). Argggg...
So what MS does is to set a very tiny and non-zero TLO value into the tool table for the MT (like a billionth of an inch). This causes the internal mach literal comparison test to 0 to fail and then mach leaves TLO active when the MT is mounted... (please excuse the glimpse into how the sausage is made).

Dave

Bingo, I think you've answered my question about getting weird results. I noticed the same yesterday after retracing my steps, that depending on the order in which I did things, the TLO changed seemingly on its own. I didn't know what the culprit was, but that explains it. Whether or not Mach screwed up the perfectly reasonable G code it was given, based on what you're telling me, depends on whether or not the probe was loaded during that session (and thus whether or not auto-TLO was disabled since the probe is the master).

It was a head scratcher for sure, because I'm sitting there looking at the file I imported in notepad, it's correct, and I'm looking at the numbers for the current machine position, and they're correct, but the machine is cutting air 0.8325 above the Z axis zero of the stock, which checked out perfectly with a micrometer when I stopped the machine and measured it, so I'm thinking "you stupid machine, what is your problem, you know where zero is why aren't you starting from it?"

Turns out the machine and CAM program are fine, it's Mach that thinks it knows better than me what I want to do.

Thanks! You've got an order coming when my trial runs out. The probing setups are the kicker, you've done very well with that and that's what I was primarily after when trying your software out.

Related side note, the only bug I've found, and forgive me because this is a machine that's new to me as well so I don't know reliable points of reference here...is that when I stop a program or trigger the emergency stop, it seems that I must close Mach, turn the machine off, turn the machine back on, and re-open mach for anything other than jogs and home referencing to work. I get a very brief blip of an error when, for instance, I e-stop while a program is running, close that program, re-zero the axes at their home positions, and load the probe, then go back to attempt to probe the corner of the stock again. The initial Z probe function doesn't move at all, I see a brief (split second) error output in the status field, and then the "probing fail" notification lights up.

Ever seen that before?

Based on the need to restart the machine itself I would wager it's an issue with the Smooth Stepper, but as I said the machine is new to me as well so I'm not sure on that.

[DaveCVI]

HI,

Related side note, the only bug I've found, and forgive me because this is a machine that's new to me as well so I don't know reliable points of reference here...is that when I stop a program or trigger the emergency stop, it seems that I must close Mach, turn the machine off, turn the machine back on, and re-open mach for anything other than jogs and home referencing to work. I get a very brief blip of an error when, for instance, I e-stop while a program is running, close that program, re-zero the axes at their home positions, and load the probe, then go back to attempt to probe the corner of the stock again. The initial Z probe function doesn't move at all, I see a brief (split second) error output in the status field, and then the "probing fail" notification lights up.

Ever seen that before?

Based on the need to restart the machine itself I would wager it's an issue with the Smooth Stepper, but as I said the machine is new to me as well so I'm not sure on that.

I've not seen that here - but it's been a while since I ran SS setup. I tend to run the PP as that is the definition of what mach 3 should be doing.
I'll try to see about testing this again with the SS, but it could be a while since I have the main mill torn apart for a tool changer installation.

Dave

[RNC]

No worries, it's a minor nuisance.

I'll see if I can catch the exact error and reproduce it so you've got more to go on with that.