ATLO enhancement request

[ChrisAttebery]

Hi Dave,

I had a problem the other day. I used a long drill that when in the TCP was too low to be safely moved over the part. It moved into position safely and the drilling op worked fine, but when it was done the tool retracted to the safe Z height in the g code, then plunged down to the tool change height, then moved to the TCP. Needless to say the drill bit didn't survive. I've since moved my TCP to the top of my Z axis, but that wastes time for 99% of my tools. So that got me thinking, since I'm using R8 tools every tool measurement has to move at least 4 inches before it gets into a reasonable range for even my longest tool. Would it be possible to give MSM a Tool Change Position and a Shank Offset? In my ideal flow the tool would go to the TCP at the top of the column, after Cycle Start was pressed the tool would rapid down to TCP - Shank Offset, then go into it's normal ATLO measurement. For the majority of my tools that would knock 40% off the measurement time.

One other thing that bothers me is that after the first ATLO sometimes mach will Z move first then do a X/Y move. Other times it will do a 3D move. I'm not sure why it does this. Any suggestions?

Thanks,


Chris

[DaveCVI]

Hi Chris,

Hi Dave,

I had a problem the other day. I used a long drill that when in the TCP was too low to be safely moved over the part. It moved into position safely and the drilling op worked fine, but when it was done the tool retracted to the safe Z height in the g code, then plunged down to the tool change height, then moved to the TCP. Needless to say the drill bit didn't survive. I've since moved my TCP to the top of my Z axis, but that wastes time for 99% of my tools. So that got me thinking, since I'm using R8 tools every tool measurement has to move at least 4 inches before it gets into a reasonable range for even my longest tool. Would it be possible to give MSM a Tool Change Position and a Shank Offset? In my ideal flow the tool would go to the TCP at the top of the column, after Cycle Start was pressed the tool would rapid down to TCP - Shank Offset, then go into it's normal ATLO measurement. For the majority of my tools that would knock 40% off the measurement time.

YEP, that is why I set my TCP to the top of my Z travel. Even then, you may not be safe - as this gives max distance between the tool tip and the touch plate (which in my case mounted on the table), but I often have a part mounted in a vise - so it's possible to mount and measure a tool that will be too log to get over to the part in the vise...

I have thought about doing part of the movement to the touch plate as a rapid, then the rest at the probe feed rate. But it creates an obvious catch 22... you'd know how much of the distance could be done as a rapid move.. if only we knew how long the tool was.... but, ah, we're measuring the tool in order to fins that out.

If I understand correctly, your suggestion is for the operator to be able to tell the machine that some amount of travel is always OK to do as a rapid movement. This is of course not true for all cases we can think of, but the trade off is saving ATLO time on most tool changes. I guess it falls in the GIGO category - if the Operator tells the control an unsafe amount for rapid Z travel, there will be a crash.

It's not an unreasonable idea for those doing production stuff where saving time = saving $.

I'll add this to my list of things to think about for a beta release (I've already got several irons in the fire for the next beta).

I would like to hear from other users too - would others like to have this ability in MSM? If so post a reply to let me know.

One other thing that bothers me is that after the first ATLO sometimes mach will Z move first then do a X/Y move. Other times it will do a 3D move. I'm not sure why it does this. Any suggestions?

Hum, to be 110% sure I need to go double check the code, but I'm pretty sure (99.9%) that MSM always leaves the tool at the TCP at the end of a tool change. Whatever the next move is (after the M6 sequence is complete) is not from MSM's ATLO process, it's from the running gcode program.

The movement will always be from the TCP to wherever the gcode says the next position is. The only mach feature I can think of that would impact that is the mach "Safe Z" ability (which IMHO should be named "I'll lull you into trusting me re Z until you are not looking and then I'm going to try to bite you").

Dave