What's new
What's new

Tool numbers in machine VS master tool list numbers.

Ryan at Sparrow

Aluminum
Joined
Nov 2, 2022
Location
North California, USA
Hello, I seem to have painted myself into a corner. I have a master tool list with every tool we use in the shop which has a unique 6 digit number assigned to each. I run Haas mills mainly, so for a while I was assigning a separate number from 1-200 to each tool. That way any of those tools can be the same number in any of my machines. It worked awesome! Until now.. because now we have more than 200 tools.

Let me explain one thing for context though, we are not a job shop. We make our own parts and have very standard tools we use in almost every machine. So for ease I thought having the same half inch endmill tool assembly as the same tool number in each machine would be nice. (And it was / is!) But it's not going to work anymore.

I'm not sure why Haas only gave us 200 tool offsets but obviously people have been figuring it out. So how are y'all doing it? Keeping a pocket table sheet at each machine that you have to sift through each time you're looking for a tool? Assigning the machine a "crib" number so that it only has access to a set group of 200 tools?

Let me know you're thoughts, and if you have any idea how to implement this on a lathe I'd be all ears as well!!!
 
Yup. You can have a master tool list with thousands of tools, but that number should have zero relation to what the tool number is in the machine, or what pot number its in.
 
Does the Haas have the ability to have multiple tool tables? You could do an "aluminum" and a "ferrous" tool crib. That way you get (up to) 400 tools?
 
Consolidate your tool library if you can. Recycle unused T numbers.

Barring that, you can either have unique tool libraries for each machine or implement some sort of tool mapping strategy.

I'm curious as to how common this issue is. If enough people encounter this problem, I can write an app that'll automatically change your T, H, and D numbers for you based on a user-specified tool map, unique to each machine. Upload "your-program.nc" and download "your-program-modified.nc".

For example:

T13/H13/D13 -> T1/H1/D1
T18/H18/D18 -> T2/H2/D2
T22/H22/D22 -> T3/H3/D3

etc.
 
Yup. You can have a master tool list with thousands of tools, but that number should have zero relation to what the tool number is in the machine, or what pot number its in.

Maybe that's how most HAAS shops run, but you don't have to. No reason you can't make a tool with a 4 digit number in the library, and then call it up with that same number at each of your machines.

Most controllers support some type of "tool management" that lets you program using group numbers for redundant tools and extra offsets. HAAS calls it "Advanced Tool Managment", and while last I looked it was not nearly as expansive as FANUC tool management, IIRC it does get you an extra couple thousand tool offsets.
 
Maybe that's how most HAAS shops run, but you don't have to. No reason you can't make a tool with a 4 digit number in the library, and then call it up with that same number at each of your machines.

Most controllers support some type of "tool management" that lets you program using group numbers for redundant tools and extra offsets. HAAS calls it "Advanced Tool Managment", and while last I looked it was not nearly as expansive as FANUC tool management, IIRC it does get you an extra couple thousand tool offsets.
Yes, that's true. You can call a tool as T1001, H1001, D1001, and assign any loaded tool number (or multiples) to that group. I've never been motivated to build a standard library though, since I run mostly prototypes and short runs. Might be worth considering as I get some longer running jobs though.
 
Consolidate your tool library if you can. Recycle unused T numbers.

Barring that, you can either have unique tool libraries for each machine or implement some sort of tool mapping strategy.

I'm curious as to how common this issue is. If enough people encounter this problem, I can write an app that'll automatically change your T, H, and D numbers for you based on a user-specified tool map, unique to each machine. Upload "your-program.nc" and download "your-program-modified.nc".

For example:

T13/H13/D13 -> T1/H1/D1
T18/H18/D18 -> T2/H2/D2
T22/H22/D22 -> T3/H3/D3

etc.
I'm interested to know what language you would write such an app in. I've been wanting to make a "post-post processor" for a while now that will automatically generate sub operation routines. But I don't know what a good language to do text manipulation would be. I figure python but would rather have input on the matter before diving in. I know that's unrelated to my original question but still haha
 
Maybe that's how most HAAS shops run, but you don't have to. No reason you can't make a tool with a 4 digit number in the library, and then call it up with that same number at each of your machines.

Most controllers support some type of "tool management" that lets you program using group numbers for redundant tools and extra offsets. HAAS calls it "Advanced Tool Managment", and while last I looked it was not nearly as expansive as FANUC tool management, IIRC it does get you an extra couple thousand tool offsets.
I don't know why but it feels wrong to give a tool a number from 1-200 and then call it all the time with a different 4 digit number. It seems like in any case I am going to have to have a spreadsheet next to the machine that ties one number to another. Unless I pull a Haas and say any tool over 200 is just going to be connected to 1200+ that way it is semi intuitive.

Also, Haas has ATM which they call Advanced tool management, I call it Atrocious Tool Management. As you create new tool groups they aren't sorted numerically so it becomes a giant mess as you continue to add tools in unless you know exactly what's going into the machine when you buy it and most people don't. It makes it a nightmare when trying to figure out what tool number is in what group while the machine is running. Also, depending on the software version you may or may not be able to assign tool life limits based on feed time or usage limits. The biggest issue which is fixed in newer softwares thankfully is that the tool would crash if the tool number was 200 or higher. Cost us 2 weeks of downtime to figure out what was happening with that one... doesn't help that our work probe was tool 200 :(
 
I'm interested to know what language you would write such an app in. I've been wanting to make a "post-post processor" for a while now that will automatically generate sub operation routines. But I don't know what a good language to do text manipulation would be. I figure python but would rather have input on the matter before diving in. I know that's unrelated to my original question but still haha

PHP.

Python wouldn't provide much of an advantage here since it's just text parsing. PHP would be needed anyway to render the web interface and provide database connectivity (for the tool library and mapping tables).

If I were writing a G-code simulator, then for sure I would use Python.
 
Maybe that's how most HAAS shops run, but you don't have to. No reason you can't make a tool with a 4 digit number in the library, and then call it up with that same number at each of your machines.

Most controllers support some type of "tool management" that lets you program using group numbers for redundant tools and extra offsets. HAAS calls it "Advanced Tool Managment", and while last I looked it was not nearly as expansive as FANUC tool management, IIRC it does get you an extra couple thousand tool offsets.
Yes, that's true. You can call a tool as T1001, H1001, D1001, and assign any loaded tool number (or multiples) to that group. I've never been motivated to build a standard library though, since I run mostly prototypes and short runs. Might be worth considering as I get some longer running jobs though.


Do either of you know how this works for other machines? I ran a Doosan, which we had to pay (a considerable sum) to have "extended tool numbers" which got us 400 tools. I made up a spread sheet of 400 tools, which varied speeds and feeds based on material type, and loaded the whole thing into Solid Works. It worked really well. Pretty slick anyway for a hillbilly that is inept with computers.

When I bought my Brother, I was seriously disappointed to find out I could only have 99 tools, and changing tools and pots is cumbersome. Currently I just use random numbers, but it is getting irritating for several reasons, and I would very much like to have a standard tool list again. It would be convenient, to have those same numbers in the machine.
 
Doesn't Haas have a barcode scanner that can load tool information?
If that didn't work maybe you can have your 'post-post processor' read the code and write the variables controlling the tool offsets to the header of your program?
 
Do either of you know how this works for other machines? I
Very intimately.

FANUC tool management can handle way more than 400 tools, but ultimately it is up to the builder to decide how/if they want to implement it. Most decide to build their own tool management on top that uses builder specific features.

I have run Makinos, Matsuuras, and DMG MORIs with 4/6 digit tool numbers and thousands of tools in the library.

The engineer told me that my Okuma M560V could only handle up to 4 digit tool numbers when I got it, but I modified the tool change macro to accommodate 6 digit numbers, and now have a library of over 1000 tools that have saved data and offsets on the controller.

My other machines here have Siemens and Heidenhain, and we don’t even use tool numbers on those, just thousands of unique names. That’s a whole lot easier, but it’s another discussion entirely.
 
Last edited:
Do either of you know how this works for other machines? I ran a Doosan, which we had to pay (a considerable sum) to have "extended tool numbers" which got us 400 tools. I made up a spread sheet of 400 tools, which varied speeds and feeds based on material type, and loaded the whole thing into Solid Works. It worked really well. Pretty slick anyway for a hillbilly that is inept with computers.

When I bought my Brother, I was seriously disappointed to find out I could only have 99 tools, and changing tools and pots is cumbersome. Currently I just use random numbers, but it is getting irritating for several reasons, and I would very much like to have a standard tool list again. It would be convenient, to have those same numbers in the machine.
The Speedio C00 control has 10 sets of 99 offsets standard. New D00 control machines more. If you go to Edit mode, Directory of Memory and select Data Bank, you can choose Tool Data 1, Tool Data 2, up to Tool Data 5 in inch and metric. Same with work offsets etc... pm me if you would like to discuss further.
 
The Speedio C00 control has 10 sets of 99 offsets standard. New D00 control machines more. If you go to Edit mode, Directory of Memory and select Data Bank, you can choose Tool Data 1, Tool Data 2, up to Tool Data 5 in inch and metric. Same with work offsets etc... pm me if you would like to discuss further.
So haas doesnt have anything like this, do they?
 
The Speedio C00 control has 10 sets of 99 offsets standard. New D00 control machines more. If you go to Edit mode, Directory of Memory and select Data Bank, you can choose Tool Data 1, Tool Data 2, up to Tool Data 5 in inch and metric. Same with work offsets etc... pm me if you would like to discuss further.
Can a program select the "bank" at runtime? (e.g. is there some syntax like T535 or some such to get tool 35 out of bank 5?)
 
Hmm, good question. At first sight I don't see that this is possible from g-code? It can be done via external interaction over the ethernet interface though (ie as part of loading the program)
 
D00 control machines (new Xd1/Xd2 models) have 198 tool offsets and 300 work offsets standard. They do also have 5 sets of 198 tool offsets in Inch mode and 5 sets in Metric Mode. These are accessible in Edit mode, under the Directory of Memory, Data Bank screen. These are not accessible from the program. Must be selected before running a program.
Have you considered using G10 codes in your programs to write in the offsets automatically with every program?
 
Load with G10 of course functions just fine, but doesn't solve the issue I am on about (but maybe I'm the only one who works this way.)

I'll try to explain. In my (crazy, not commercial, shop) I use a set of mostly permanent universal tool numbers (across mills.) [40 taper mills - so maybe silly to apply this to something like the Brother mill-turn.] In this system, for all jobs in the system (since at least 2018) tool numbers refer to the same tools [1]. So for example T109 is always a 1/2" 4 flute carbide square corner endmill (generally a helical.) So long as the library is smaller than 200 (or 198) that works fine. Tools which are Heidenhain (5-axis) specific (never used on the 3-axis mills) might have higher numbers since they'll never appear on the 3-axis mills, so basically T201 and up are "bound" to the DMU.

And so, I *don't* want T27 to be a drill on Monday and an endmill on Wednesday. Loading it with G10 isn't an issue (I import tool setter data that way today) - rather, it's about organization and libraries and avoiding confusion.

One could of course write software that maps from a master library (say the CAD system generates tool numbers from T1000 to T9999) to some set of in-machine tool numbers, and spits out a list of what to change, new labels, etc. But now T1023 (the 1/2" endmill) might be T#53 on one machine and T#14 on another. Which is confusing. And yes, I move the same holders back and forth across the 40 taper machines, and move the programs as well.

[Though, now that I've typed that out, it occurs to me I could make it work in practice. It's not hard software, just have to spec it carefully.]

I'll note that unlike others, in my system tool holders generally hold the same tool "forever" (getting new instances as things wear out.) I make labels that say what it is (T109:S500C4P) which I stick on the holder such that I can see what's in the spindle. etc. [Clearly this is NOT how many shops operate.]

I basically make one-offs, as part of charity/research projects, and it's quite common that tool build time exceeds run time. So for me the ideal machine has an enourmous tool changer and as often as possible all tools needed for the job are already in the machine....

This model of operation is why a controller with say 10000 tool entries that allows syntax like T8943 (which loads from say pocket 13) appeals to me.

I fully grok that speedio's don't have giant tool changers, my interest is basically in the newish mill-turn - a practical sized version of a b-axis lathe. 198 tool entries I could live with. (The 30 taper isn't going to share tools with the 40 taper mills anyway and moving programs back and forth would be very odd.)

[1] There are exceptions and evolutions to all of this which are uninteresting unless you have terrible insomnia...
 
Load with G10 of course functions just fine, but doesn't solve the issue I am on about (but maybe I'm the only one who works this way.)

I'll try to explain. In my (crazy, not commercial, shop) I use a set of mostly permanent universal tool numbers (across mills.) [40 taper mills - so maybe silly to apply this to something like the Brother mill-turn.] In this system, for all jobs in the system (since at least 2018) tool numbers refer to the same tools [1]. So for example T109 is always a 1/2" 4 flute carbide square corner endmill (generally a helical.) So long as the library is smaller than 200 (or 198) that works fine. Tools which are Heidenhain (5-axis) specific (never used on the 3-axis mills) might have higher numbers since they'll never appear on the 3-axis mills, so basically T201 and up are "bound" to the DMU.

And so, I *don't* want T27 to be a drill on Monday and an endmill on Wednesday. Loading it with G10 isn't an issue (I import tool setter data that way today) - rather, it's about organization and libraries and avoiding confusion.

One could of course write software that maps from a master library (say the CAD system generates tool numbers from T1000 to T9999) to some set of in-machine tool numbers, and spits out a list of what to change, new labels, etc. But now T1023 (the 1/2" endmill) might be T#53 on one machine and T#14 on another. Which is confusing. And yes, I move the same holders back and forth across the 40 taper machines, and move the programs as well.

[Though, now that I've typed that out, it occurs to me I could make it work in practice. It's not hard software, just have to spec it carefully.]

I'll note that unlike others, in my system tool holders generally hold the same tool "forever" (getting new instances as things wear out.) I make labels that say what it is (T109:S500C4P) which I stick on the holder such that I can see what's in the spindle. etc. [Clearly this is NOT how many shops operate.]

I basically make one-offs, as part of charity/research projects, and it's quite common that tool build time exceeds run time. So for me the ideal machine has an enourmous tool changer and as often as possible all tools needed for the job are already in the machine....

This model of operation is why a controller with say 10000 tool entries that allows syntax like T8943 (which loads from say pocket 13) appeals to me.

Yup, sounds a lot like our shop. I guess we will just suffer lol
 








 
Back
Top