Haik wrote:I am trying to choose the TC strategy that is optimal for my needs and could use a little help deciding.
My TC environment is:
Thermwood gantry CNC router- very rigid, very tight (repeatability +/- .002") used for woodwork.
Home switches- solid state proximity sensors (repeatability +/- .0005").
ATC spindle- ISO30 (RH) tool holder.
My thought so far is to use Master Tool Mode with the Tool Change Touch Plate (no probe) which would then...
Whan you say "ATC Spindle" does that mean that you have an ATC ability?
If you have an ATC, then I'd think that you want to run mach in ATC mode and the ATC script will take care of going to tool change position for each tool etc (so the steps below of "go to TCP by pressing a screen button" would not be needed).
Not having a probe is fine. Master Tool Mode just determines how offsets are calculated. With MTM, the offsets are relative to the master tool. Thus you have to pick a tool as the master, but the master does not have to be a probe tool.
Now then, with MTM, you have to use the master to set WC Z0 etc. That can be done with any tool type. It's just that if the master happens to be a probe tool, then it's easy to use a probing operation to set the zero point - it's a convenience, but not a requirement that the master be a probe tool.
Haik wrote:
-Reference against Z home switch for TC/Z position.
-Each TC will touch-off the TP to acquire TLO (for that tool's session).
When you start the machine, you do the ref-all home - that sets the physical location of the machine coordinates in space. This generally only needs to be done when the machine is started up (barring crashes or lost steps or something).
If you are doing manual tool changes (mach stop&Wait TC mode), the steps typically are
1) machine sees M6, starts tool change sequence
2) IF MSM TC Auto TCP is on, the spindle moves to the tool change position (TCP).
3) Machine stops spindle, pauses waiting for cycle start
4) human physically changes tool
5) if MSM TC Auto TLO is on, then the tool gets measured with the TCP TP and the TLO value for the tool is set into the tool table. Thus when the program applies TLO values (G43 Hx), the measured value form the tool table is what gets used.
This approach nicely handles tools mounted in colletts - as the measurement is done after the physical mounting.
If you have an ATC (mach ATC mode), the steps become
1) machine sees M6, starts tool change sequence
2) M6ATC script loads the tool by running the tool changer logic (this replaces the human changes the tool step). The ATC script is machine/tool change dependent and is user supplied. FYI, I have an example for the type of router that keeps the tools in rows at one end of the table etc.
3) if MSM TC Auto TLo is on, then the spindle goes to the TCP (really the tool measurement position now), the tool gets measured with the TP and the TLO value for the tool is set into the tool table.
This lets you run a tool changer, and measure every tool when it is mounted.
If you have an ATC and want to pre-measure the tools, then you'd
1) Fill the tool changer
2) T# M6 for each tool
3) go to TCP via screen button
4) measure tool with "measure tool" screen button (this gets the TLO value put into the tool table).
5) repeat for all tools in the changer.
Then we turn off TC auto TLO and the M6 will not cause TLO measurements (as they are assumed to already be in the tool table at the time the gcode runs).
This approach makes for shorter GCode run times - as the tool measurement time is not used on each M6. Shorter code run time, but each tool has teo be measured before the program is run.
Haik wrote:
I really like the idea of actively setting the TLO (as opposed to static variables stored in a tool table file). I'm not sure if MTM w/Probe is necessary.
S mentioned above, probe not required for MTM - really they are independent topics.
I don't run a production environment, so optimizing code run time is not my personal priority. Thus I like measuring each tool when it's mounted - that way if I moved a tool in it's holder (say between jobs), I don't get messed up by using a TLO value that was from before I moved the tool...
So I optimize to catch my own mistakes instead of optimizing code run time.
Haik wrote:
Does this seem good? Any ideas or thoughts are greatly appreciated!
--Haik
Hopefully this gives some food for thought...
Dave
P.S. Thanks for using the new forum!
