Eliminating Forced Tool Change on Same Tool #

[BK]

Okay I know it's a lame topic, what I need to know is how to get MC to quit forcing a toolchange on a tool that is used as a spot drill as well as a chamfer tool.

 

The tool has the same physical tool # but I haven't found a way to make it stop trying to do a toolchange when it goes from spot drilling to chamfering.

 

In all prior versions you would always get the question when you were going to post . . .

Multiple tools using the same number, generate a tool change in the NCI?

 

You'd tell it no and you would have code the way it should be . . . spot drill, chamfer, spot . . .

 

I have sent a z2g file to MC QC but haven't heard anything yet.

 

I apologize if this is a newb question. We are busy and I haven't had much time to use X yet.

 

Thanks in advance,

Bob

[Psychomill]

First place I'd look is on the tool parameter page, right below your feedrate inputs is button that says "force tool change". Uncheck it....

 

 

[Roger Peterson]

BK do you have two tools defined with the same tool #? Or, do you have one tool defined and you are using it as both a chamfer mill and a spot drill?

[J Coulston]

I ask the same question a few days ago, no answer yet.

 

quote:

---

Same question no answer yet

How do I prevent X from posing a tool change when using multiple tools (roughing, finishing speed/feeds) with the same tool number?

 

In V9 when posted I would get the following dialog

 

"Multiple tool using the same tool number found! Generate a tool change in the NCI?"

 

Click no and all was good.

 

Force tool change is deselected in X.

---

[BK]

BK do you have two tools defined with the same tool #? Or, do you have one tool defined and you are using it as both a chamfer mill and a spot drill?

 

That's exactly what I am doing. I have a 3/8" x 90 degree carbide spot drill that is tool #2. It has it's own speed, feed and spot drill cycle.

 

I also have a 3/8" x 90 that is also #2 that is defined as a chamfer mill. It has different feed rates obviously.

 

V9 used to ask when posting, X doesn't and I haven't found a setting to control it yet.

 

Sent a z2g to MC QC but haven't heard back.

 

Bob

[kinglouie V]

ok, stupid question (I mean mine), but do you have it listed twice in your toolmgr? Or did you just pick the tool already there on the chamfer op??

[Psychomill]

BK, instead of having two tools (even though they are same), just use one tool. Have one 3/8 x 90 show in the tool list and use it to spot, chamfer or whatever. Having the two tools in your list is causing the tool change.

[Tim Johnson]

I haven't played with X much yet but I have V9 files with 4 tools with the same tool number (deep/shallow roughing, finishing sides/floors) and almost all my files will have at least one set of duplicate tooling. If you use just one tool and change the parameters manually you run into the problem of 1. another programmer clicking on the tool to look at the parameters and changing cutting data, 2. slower programming speed caused by having to look up the different cutting data for a certain process and entering them, 3. typos from entering the info manually, ect... IMHO this is a big problem if X can't keep from forcing tool changes.

[kinglouie V]

quote:

---

BK, instead of having two tools (even though they are same), just use one tool. Have one 3/8 x 90 show in the tool list and use it to spot, chamfer or whatever. Having the two tools in your list is causing the tool change.

---

yeah, what he said....

[Psychomill]

You may have some issues with X if you're trying to go from a V9 programmed part ( in the duplicate tooling anyway ). Maybe someone else here knows a work around. Personally, I don't see any reason to have duplicate tooling, but thats ok too.

 

To answer some other stuff about X though....

 

If I understand this correctly, tooling can be localized to the file. This can be independant of the main "tool library". So, if someone else changes something in tool on file, it doesn't affect the main library info as long as the person doesn't save the tool to it.

 

2. You can control this through operation defaults for all types of cuts rather than creating a tool for particular cuts.

 

3. That can happen anywhere at any point.

 

However, your point is taken. This will be an issue for you if your existing library won't work the way it has up to now. Maybe the post has to be modified to accept or "see" tools as tool numbers rather than type of tool??? Not sure...

 

[J Coulston]

From MC help.

 

quote:

---

Force tool change

 

When the same tool is used in successive operations, this option causes a tool change code (1002) to be written to the NCI file instead of a null tool change (1000), so that an event can be triggered between the two operations.

---

MC should post without generating a tool change between tools.

 

This worked correctly in V9 it must be broke now.

[BK]

These are all good points, here is the reason I use two different tools . . .

 

I use a tool libraray with all of the speeds, feeds and cycles defined with the tool.

 

In this case the spot drill has a feed of 20IPM, a G82 spot drill cycle as well as a 30 milisecond dwell (5 revolutions of the tool when it hits the Z target).

 

The chamfer tool has a feed of 70IPM and obviously no dwell.

 

The one problem that occurrs when other people program is they will just use the chamfer tool for everything which would work if they would look at the feed, dwell etc but that never happens, so we end up with programs spot drilling at 70IPM with no dwell at all, not cool.

 

I still haven't heard back from MC as to how to control this.

 

As many here have said in all prior versions when you go to post and it asks about duplicate tool numbers you just tel it no and it is edit free.

 

Thanks for the info,

Bob

[Ray Culver]

Having two tools (even with the same parameters) forces the system to ouput a tool change code (1002). Internally, the tools have a unique identifier and this is what the system uses to detect a tool change, not the tool number. The tool number to the system is just like a 'comment' (i.e. it don't mean much).

 

I'm sure you can tweak your post to compare tool #'s from the current tool to the previous tool and disregard the 1001 values to detect a tool change.

 

But you're right - the question that appeared in version 9 is not in X. I'm checking into that now...

[Ray Culver]

The message is back (except when running batch).

 

 

 

[BK]

Ray how did you get that prompt to appear? This is exactly what I was referring to.

 

I have 1000's of programs with this same scenario so I need to find a fix once I start using X ful time.

 

Thanks,

Bob

[BK]

quote:

---

The message is back (except when running batch).

---

What did you have to do to get the prompt to return?

[Ray Culver]

I changed the source code. It was a bug.

[BK]

quote:

---

I changed the source code. It was a bug.

---

So will this be addressed as a service pack? I'm glad you found the problem!

 

I haven't been using X much yet since we are very busy but noticed this deal right away.

 

Thanks for looking into this,

Bob

[BK]

quote:

---

I haven't played with X much yet but I have V9 files with 4 tools with the same tool number (deep/shallow roughing, finishing sides/floors) and almost all my files will have at least one set of duplicate tooling. If you use just one tool and change the parameters manually you run into the problem of 1. another programmer clicking on the tool to look at the parameters and changing cutting data, 2. slower programming speed caused by having to look up the different cutting data for a certain process and entering them, 3. typos from entering the info manually, ect... IMHO this is a big problem if X can't keep from forcing tool changes.

---

I agree, I know you can spot drill with a chamfer tool but you can't chamfer with a spot drill. Having the right speed, feed and dwell is critical for the spot drill, the chamfer tool is just another contouring tool.

 

This has always been one thing that I think is is huge PITA, if you have a lot of operations with a variety of very specific speeds and feeds, depth of cut, finish allowance if you then change the tool number it changes all of the cutting parameters to what is defined with the new tool.

 

Just my $.02

[Psychomill]

quote:

---

I agree, I know you can spot drill with a chamfer tool but you can't chamfer with a spot drill.

---

You can't????

 

Just trying to understand the need for having so many duplicate tooling.

 

If I understand correctly, you're trying to minimize the amount of "programmer input" by presetting speed, feed, DOC, dwell, no dwell, coolant, no coolant, stepover, max length, etc, etc, .... for each type of cut?

[BK]

quote:

---

I agree, I know you can spot drill with a chamfer tool but you can't chamfer with a spot drill.

---

Oops . . . my bad, at least now in 9.2 you can use a spot drill, countersink, or chamfer mill to chamfer. I seem to remember in the past that you couldn't chamfer using a spot drill? Or maybe it was that you couldn't chamfer if the tool was defined as a countersink.

 

In any case at least it is being addressed, I have probably 1500 programs at least that have this "condition".

[BK]

quote:

---

If I understand correctly, you're trying to minimize the amount of "programmer input" by presetting speed, feed, DOC, dwell, no dwell, coolant, no coolant, stepover, max length, etc, etc, .... for each type of cut?

---

That's exactly it. I use tool libraries that have all the cutting parameters (speed, feed, DOC, stepover, finish allowance, canned cycle, coolant (splash, through, air blow)) defined in the tool description.

 

If someone else is not familiar with these things it is a lot easier to end up with known good settings for all cutting parameters instead of relying on people to calculate the correct values . . . you know how that goes . . . I know let's drill some Invar at 10k at 80 IPM!

[Psychomill]

Gotcha,

 

I see the dilemma now....

 

This would still cause a problem in the old files, but how about setting up the tool libraries as according to type of materials used? Actually, you could do this in V9 and earlier also. If you set up the material library accordingly, with the proper adjustments to your tool rates, would that minimize your "duplicate" tooling?

[Tim Johnson]

Let's say I'm using a 1/2" three flute end mill in alum. I rough it out using .25 deep cuts at 9168 rpm and 220 ipm. I also want to put a 32 finish on the floor. I run that at 15000 rpm and 90 ipm. I also use the same tool for a 64 finish contouring the part perimeter at 15000 rpm and 180 ipm. You can use the one tool and manually make the changes on the other operations but then you have to look up all the cutting data, calculate the feed/speeds for each process, and hand type them in, Or go to the tool library and pick the material folder (probably already there if you were previously picking tools), grab the tool for the process and you're done. Duplicate tools are also nice when another programmer is fixing a revision a few months later (common at our shop), goes into an operation and clicks on that tool to look at the parameters. It's real easy to click OK rather than cancel when leaving the operation and if only one tool is listed then the part and/or tool may be scrapped.