[brianbonedoc]

I think there may be a simple answer but I cant figure it out.

I have program drilling a bunch of different sized holes, and I only have one or 2 chucks, how can I set the Z height for each drill size while the program is running?

It seems like PP wants all the tool offsets in the table before the program runs?

Thanks in advanced!

[LeeWay]

I am not sure, but there is always the option of making each tool change it's own program. Kinda like the cave man approach to cnc machining.

[pickled]

If you guys figure this out I'll be very interested because it sucks to have to do prototyping and have all your tools "known". It made me fire up the M3 controller for a while when I was working on a new project. PP is awesome, but a bit rigid for my taste...a lot of us have to work on the fly to stay ahead.

[bevinp]

Do I understrand this correctly? PP doesn't allow you to zero or change the Z ht during manual tool changes as Mach 3 does?
Not good!
Bevin

[LeeWay]

I only use the lathe, but even then I think the tool table must be defined. Even for the QCTP. Each tool you swap out would need setting before hand. That is my understanding anyway.

[bevinp]

I have just emailed Tormach on this question.
I am (or was) about to swap out my Mach3 with the Tormach PP Controller. I'll wait to see what they say.

I'm a little surprised if it is correct and a fix is not on the list.

However, I probably have enough tool holders to allow me to start using the tool table. And it would be nice to not have to zero each tool during the program for my usual 2 or 3 quantities. And as LeeWay says, the cave man approach will work for prototyping.

[LeeWay]

Hopefully we are overlooking something. It just doesn't seem right that you cannot reset G54 or G55 etc. on the fly.

[cncbasher]

you could do this simply with an additional sub file , it's no different to linuxcnc , the simple manual probing sequences could be added
give me a few days , and i'll sort it.

as i need to get a major problem sorted here and out the way

i presume this is as a manual machine so no toolchanger is fitted , also are you using a z tool height setter ?
as theirs a number of ways to do this .

[Uman]

I think there may be a simple answer but I cant figure it out.

I have program drilling a bunch of different sized holes, and I only have one or 2 chucks, how can I set the Z height for each drill size while the program is running?

It seems like PP wants all the tool offsets in the table before the program runs?

Thanks in advanced!

If drill bit length precision is not critical and is manual tool load, then this is option.

Create a PP tool# for each drill bit
Declare the length for each tool# drill bit
Call out each tool# in program
Hot swap bit in chuck and set length with Stop-Loc set-up tool to match PP tool# length declared

Stop-Loc is sold by Tormach Tormach Inc.

-uman

[cncbasher]

far easier is if your using a tool z setter for example the xhc , is to change the tool and then let the machine measure the length , and then carry on untill the next change .
although this is meant more for mills than drills , as you need to take into account the cone angle etc , if your drilling a through hole , as against a blind hole .
which is the way i do it .

but every ones machine is different .
it is normal in production to have all the tools pre measured in a tooltable , as uman suggests a simple collar made for the drill size and locked at a specific point, makes for easy and repeatable drill changes
easy to make to, out of some scrap .. we all have scrap dont we ! .

[mountaindew]

Hopefully we are overlooking something. It just doesn't seem right that you cannot reset G54 or G55 etc. on the fly.

I complained months ago about not having access to offsets while code is executing, be it g54-g59 and tool offsets work the same way. PP requires the user to stop code execution set a start point and then fiddle around with any offsets like g54 or tool lengths then user must restart program.
As I mentioned above I use 2 or more offsets in every program and would use cam operations to set proper offsets and prompt user for input if required. Now I have to do this on the mdi line with manual keyboard input . Drove me nuts for a while then I redesigned my cam programs to prompt me with text to type the values in hehe lol kind of silly and very very error prone but I adapt

[brianbonedoc]

Yes those workarounds will work - but I recall using Mach3 this was no big deal. I kind of sucks to have to stop the program just to adjust a drill length offset.

I guess I could by 5 more drill chucks. . .

[JW_55Degrees]

A variation on Uman's workflow assuming TTS and manual tool changing.

1) Allocate tool numbers for each hole diameter needed in the job.
2) Put the drill bit fully in the chuck and measure the length with height gauge. Enter this length for the appropriate tool# in the tool table.
3) Repeat for all other drills - the depth of a hole will not be critical and so the back face of the inside of the chuck will be an accurate enough datum provided drill is fully inserted.
4) Run the job putting the appropriate drill in the chuck at each tool change. The mill will not know there is only one chuck in use :-)

For quicker changes, if these are needed, use two chucks - one for the odd numbered tools and the other for the even. This means they do not need to be identical chucks as you always use the one you measured the drill in. Now provided you drill the holes with an odd then an even tool you can change the drill bit while the previous tool is drilling its holes.

Unless you have a large number of changes the risk of making a mistake with this "double buffering" might make it better to use only one chuck. A block of wood drilled to make an ad hoc drill stand with the holes numbered with tool # reduces the risk of brain farts.

JW

[cncbasher]

if people require , i'll look and see if it can be changed .
as i'm making quite a few modifications , i need a list ..,.. and more hours in a day

[brianbonedoc]

JW - thanks for the tips - that's what I ended up doing and it worked fine.

[bevinp]

I just received this reply from Daniel Rogge:
"You cannot change tool length offsets while a program is paused for tool change. We recommend measuring tools before starting the program, even for Mach 3 users. If this is a deal breaker for you then you should stay with Mach 3".

It seems that whatever alternative workaround is devised, PP still requires all programs to have offsets entered for every tool, no exceptions. Also from Daniel's email there is no intention by Tormach to modify PP. A disappointing attitude.

I guess this mean that PP requires every tool change line requires T and H parameters otherwise it doesn't run it.

[pickled]

Man that's an interesting POV. The whole concept is that there are times when the user doesn't GAF about the tool lengths at all and wants a system robust enough to assign a new vertical work offset on the fly. I didn't buy 2 Tormachs to shave 7 seconds off my cycle times I bought the machines because they would allow our product development cycles to handle being compressed by outside forces. If I'm on hour 3 of a 5 part program and have an end mill lose a flute end due to some odd vibration (caused by lack of rigidity/fixturing design that isn't optimal) I just want to be able to limp through that phase and, pause at a logical point, pop in a fresh horse re-reference and move on. I design my z datums around points on my fixture that are absolute and can be swept off with a rag, dried and touched off on again if necessary. Having to input probing codes and/or have multiple files to baby sit in order to get the flexibility that was offered in the Mach3 is kind of odd. My logic has not always been known to be conventional though so your mileage may vary.

[JW_55Degrees]

I am very wary of using Pause (Feedhold) in Mach 3 as the machine's response on resuming the program is unpredictable. I don't think I am alone in finding this. There are certainly cases when being able to jog around and reset offsets during a Pause would be very useful but, as Mach 3 did not do this reliably, I avoid resuming after any Pause. So far as I know PathPilot lets you Feedhold and then Cycle Start anywhere in a program (even in loops or subroutines). The action is immediate and totally reliable. Perhaps one day the code might be updated but I would not want the ability to do changes on the fly to degrade the current Feedhold performance.

JW

[LeeWay]

I find the feed hold to work well with version 3.043.062. It slowly comes to a stop. Then I back up the code appropriately to a starting point and hit "set next line". Never skips a beat that way.

On my new CRP router, it has an ER20 collet. No real way to set up tools before the fact. I ordered an Auto Z touch plate with it. It makes very short work of changing a tool and setting an accurate Z height. Umm.....in Mach 3.
I will be using a similar tool in my Novakon mill. I do it manually now with a yellow pages sheet, but much better accuracy can be had with the touch plate.
I think it is a shame that PP is unwilling to include such a valuable feature.

If I break a tap on the Novakon with Mach 3, it is a simple and quick matter to replace it. Now most of the taps I buy are just about identical, but there is a slight variance between them. That variance must be measured.
I think PP not including it is short sighted and a bit of a hobble. It will cause extensive time sucks for some in certain situations.

Same thing about tool breakage on a lathe. You gotta start all over in some cases and it could cost some cash in a wasted part and time.

[bevinp]

JW,
It's not really "on the fly" because the change to tool offset is done during the pause while the tool is changed. So it is not threatening the realtime Pause/Feedhold/Stop functions in any way. I agree that those functions were unreliable in Mach3 and reportedly are excellent in PP.

But the topic in this thread is PP not being able to change a static stored value that is otherwise not being accessed or actioned by PP. Seems to be a straightforward programming change with no consequences since the changed value will not be accessed until the Z axis is commanded to move.

It seems more a case of "doing it this way only" by a pedantic program designer.
Bevin
PS. Like your bow tie.