Tool numbers changing ?

[Aeroguy]

Ok, I posted this in another topic to gripe mostly, but this really does irritate me because it has happened a few times now.

 

Had something weird happen to me recently. I had to change something in a toolpath, and after I accepted it, a number of totally unrelated toolpaths went dirty. Ok says I, and just recalculated them. Well unknown to me, aside from recaclculating them, they also changed the tool number for those particular toolpaths. So when I posted the whole thing out they had the numbers all wrong, and I totally scrapped the part because it obviously used the wrong tool for those particular paths. When I went back into MC and rooted through them all I found the problem.

Why the heck would MC do this ??

 

Anybody have a clue as to why this would happen, and better yet, how can I avoid this in the future?

[SledGeek]

Are you using X6 ? I've had the dirty op thing happen on several occasions as well. even when just turning on coolant or changing fd/spds. I don't know exactly what causes it . Did you update to the newest level of 6 yet and it's still happening. I downloaded the newest 6 but haven't installed it yet.

[GoetzInd]

I've had this happen to me twice using X6. Very hard to reproduce. As soon as I can, I'll send it in.

 

MIke

[Aeroguy]

Sorry, no we haven't upgraded to X6 yet. Managment is still a little leery about the whole thing. I am still using X5

[Thee Rickster ™]

I think he is running X5Mu1.

 

Aeroguy, I had someone tell me how to have this tool list show up in my

posted gcode.

 

It has saved my butt, along with a tons of manual individual tool editing, but

never the less I caught some drastic MC tool numbering or re- numbering

errors

.

%

O0000 (FC566A2D)

(DATE - FEB-03-2012)

(TIME - 6:45 AM)

(T1 - 3/8 FLAT ENDMILL - H1 - D21 - D0.3750")

(T2 - 1/2 FLAT ENDMILL - H2 - D22 - D0.5000")

(T3 - LTR. V DRILL - H3 - D23 - D0.3770")

(T4 - 5/8 FLAT ENDMILL - H4 - D24 - D0.6250")

(T5 - 1/2 DRILL - H5 - D25 - D0.5000")

(OVERALL MAX - Z2.)

(OVERALL MIN - Z-1.9389)

N100 G17 G40 G80 G90 G54

.

I could not even begin how to do the post modification

I believe i sent it to my reseller or(if you have current maintenance)

I did a share desk top and they walked me through it.

 

Some one on the forum may have had me send my post to them and

they fixed it, either way if is a pretty good safe guard.

 

Cheers

[Aeroguy]

Thanks Rick, but my post already gives a tool list at the begining of the programs. Doesn't really help me much when there are 15 or 20 tools and 30 or 40 different toolpaths in a single program. You could call me lazy I guess, but I just don't have the time to sit down and go through every single posted program to make sure that everything is in order. Call me crazy, but thats the way it is.

[Aeroguy]

Perhaps I am not explaining myself properly. When I say that MC is changing the tool numbers, what I mean is that it is replacing the tool I had programmed the toolpath with, with another tool already in my tool list, but it is keeping the cutter path calculated with the original tool. ie. I programmed with T14 - 1/8 Endmill and it replaces it with T25 - 3/8 Ballnose

[Thee Rickster ™]

That is understood and is exactly something that has happened to me a few times.

(as well as a few other tool magically going dirty and messing things up)

 

The header will show you the tool and tool # and offet

 

I have had MC decide for me (on occasion) that I did not need H's and D's, and once i posted the

file i did not send it to the machine until I manually changed them.

 

reselecting the .mmd fixes a ton of issues as some things just dont stick.

 

The safeguard i describe takes me minute or two, just to look at the gcode header

and my tool sheet and make sure the tool numbers jive.

 

with out another MU to X5 we are $hit out of luck on X5 bugs

That is why I tell you of my safe guard.

 

I am slowing converting to x6 by using X6 for Enc's and very simple molds till

i am comfy.

 

HTH

[K2csq7]

I had this happen once.

So once again I put a checkpoint in my post. (wont help if your running lights out)

 

Here is the beginning of EVERY toolpath for my milling machines.

 

 

N100 G00 G91 G28 Z0.
N110 G00 G17 G20 G40 G49 G80 G90 G94 G98 H00
N120 (.500 TLO CHECK FROM TOP OF PART)
N130 M06T01
N140 M00
( CONFIRM T1 H1 D1 DIA = 0.1875 )
N150 M11 (UNLOCK C)
N160 G00 G17 G90 G54 C0. X0. Y-10.44 S100 M03
N170 M10 (LOCK C)
N180 G43 H1 Z1.5
N190 G94 G01 Z.5 F20.3
N200 M00 (.500 TLO CHECK )

 

 

Notice right after the toolchange, there is a program stop, when the operator looks at the control to see why it stopped, he immediately notices the next line that is RIGHT IN HIS/HER FACE.

CONFIRM tool #, height offset #, diameter offset #, and the ACTUAL diameter of the tool being used. These are NOT values that I enter manually. They are pulled from the toolpath parameters

 

Just noticed I don't have the tool nose rad in there... oh well, gotta live a little on the edge!

 

**** me once, shame on you.

**** me twice, shame on me.

 

Let me know if you want some assistance implementing this.

[Aeroguy]

Yeah its great and all putting little notes and stuff in, which is something I do all the time, but in order for that to work you would need to have an operator that either:

 

A - Can read english

B - Actually cares

 

Most of the guys here are a 1 or the other, and in some cases both. Things go wrong, they just shrug their sholders and say....

" duh me dunno what happened, go ask programmer "

 

Now I am not placing any blame here because at the end of the day it's my program and I take responsibility for it. I do the best I can but when random stuff like this happens, what am I supposed to do?

[K2csq7]

.... Flip burgers?

[Aeroguy]

.... Flip burgers?

 

Very useful. Thanks

[CJep]

^^^^

 

I have had MC decide for me (on occasion) that I did not need H's and D's, and once i posted the

file i did not send it to the machine until I manually changed them.

 

Have you checked the "tool offset registers" setting in the control def?

 

To get the H & D values it needs to be set to "Add to Tool" and if the values are to match the number the values need to be set to zero.

 

Not certain why these values would have changed if you had them set prior, but stranger things have happened.

[Thee Rickster ™]

Have you checked the "tool offset registers" setting in the control def?

 

Yes!

 

And every-time Mc decides to magically switch my SAVED control def back to

its default, I put the settings back in and get back try to make up the lost time

resetting all the tool parameters on already made paths!

[neurosis]

I had this happen once.

So once again I put a checkpoint in my post. (wont help if your running lights out)

 

Here is the beginning of EVERY toolpath for my milling machines.

 

 

N100 G00 G91 G28 Z0.
N110 G00 G17 G20 G40 G49 G80 G90 G94 G98 H00
N120 (.500 TLO CHECK FROM TOP OF PART)
N130 M06T01
N140 M00
( CONFIRM T1 H1 D1 DIA = 0.1875 )
N150 M11 (UNLOCK C)
N160 G00 G17 G90 G54 C0. X0. Y-10.44 S100 M03
N170 M10 (LOCK C)
N180 G43 H1 Z1.5
N190 G94 G01 Z.5 F20.3
N200 M00 (.500 TLO CHECK )

 

 

Notice right after the toolchange, there is a program stop, when the operator looks at the control to see why it stopped, he immediately notices the next line that is RIGHT IN HIS/HER FACE.

CONFIRM tool #, height offset #, diameter offset #, and the ACTUAL diameter of the tool being used. These are NOT values that I enter manually. They are pulled from the toolpath parameters

 

Just noticed I don't have the tool nose rad in there... oh well, gotta live a little on the edge!

 

**** me once, shame on you.

**** me twice, shame on me.

 

Let me know if you want some assistance implementing this.

 

 

Its really sad that you have to have a check like that in your posts. Having said that, I would like to see how you have implemented it. <grin>

 

Ive had my H and D values borked on several occasions when I have to change jobs from machine to machine and manipulate tool numbers. I have learned to become very vigilant in making sure that the values both change and stick when I do this now. I will not send a program to our machines until I have went through it 100% to make certain that everything looks the way that it should. Yes, it takes ALLOT of time. But we have a couple of operators that sound like what Aeroguy has. Barely speak english and dont pay much attention to what they are doing.

 

 

This is one of the things that I wish CNC would fix. This has been an issue for me since I started using Mastercam and is what I consider a MAJOR issue that could cause lost parts and/or machine crashes if gone unnoticed. In some respects it is a little better but it is not even close to being fixed. When I go in to my tool manager and change the tool numbers I would expect that the H and D values would change accordingly per the Machine Def that I am using but they do not. And even when they do, it seems that sometimes the operations that use these tools do not update.

 

So when we move a job from our Fanuc Controlled machine that has Type C memory and 40 tools, to our Yasnac controlled machine that has Type A memory and 20 tools, it becomes a horrible night mare. I have to go through every tool in the tool manager and change the tool number, H value, D value. Then go through every single operation and make sure that they have updated properly. Even then, I post the program and search through every tool to make sure that they have updated properly. What should be a 10 minute ordeal ends up taking some times hours. Especially on the parts that have 100+ operations. Most times I will have to re-gen ALL of the operations whether they have dirtied or not because the tool names will not show in the tool list. They show as "NULL TOOL". I have talked about this particular issue (null tool) as well and it has been a problem for a long time now.

 

 

 

I am beginning to put together a procedure for converting older files to the new version of Mastercam. I probably should have done this from day one. I wonder if some of the problems that we experience are due to old Machine Definitions that are saved in the Mastercam files. I "usually" update them, but I find myself forgetting to do this at times. It is more often than not, old files with old definitions that end up being moved to other machines. I dont know if that has anything to do with the issue but it will be one less thing to add to the equation if we make sure that the MDD are always updated. It would be nice if CNC would add a feature that asks you if you would like to update the machine definition when you open old files in a new version.

[K2csq7]

Having said that, I would like to see how you have implemented it. <grin>

 

Ive had my H and D values borked on several occasions when I have to change jobs from machine to machine and manipulate tool numbers. I have learned to become very vigilant in making sure that the values both change and stick when I do this now

 

 

LOL, your gonna love this!

Look what happens if my T & H aren't the same.

 

 

N250 G91 G28 Z0.
N260 M00
M00
( T & H DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!! )
M00
N270 T227 M06
N280 M00
( CONFIRM T227 H228 D227 DIA = 1.7500 )
M00
( T & H DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!! )
M00
N290 M11 (UNLOCK C)
N300 M11 (UNLOCK 
N310 G00 G17 G90 G54 C0. B0. X-4.2637 Y-.8667 S152 M03

 

 

And if the T & D don't match...

 

N410 G91 G28 Z0.
N420 M00
M00
( T & D DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!! )
M00
N430 T307 M06
N440 M00
( CONFIRM T307 H307 D310 DIA = 1.0000 )
M00
( T & D DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!! )
M00
N450 M11 (UNLOCK C)
N460 M11 (UNLOCK 
N470 G00 G17 G90 G54 C0. B0. X5.5604 Y3.4685 S534 M03

 

 

Here is the love....

 

ptlchg_com      #Tool change common blocks




  	if t$ <> tlngno$, pbld, "M00", e$ "(", "T & H DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!!", ")", e$ "M00", e$
  	if t$ <> tloffno$, pbld, "M00", e$ "(", "T & D DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!!", ")", e$ "M00", e$
     if force_output | sof,
       [
       result = force(ipr_type,ipr_type)
       result = force(absinc$,absinc$)
       result = force(plane$,plane$)
       ]
     pcom_moveb
     pcheckaxis      #Check for valid rotary axis
     c_mmlt$ #Multiple tool subprogram call
     if sof & scomm_sav <> snull,
       [
       spaces$ = 0
       n$, pspc, scomm_str, *scomm_sav, scomm_end, e$
       spaces$ = sav_spc
       ]
     if sof = 0, scomm_sav = snull
     comment$
     pcomment3
     pmisccheck
     pcan




       if tlcg = 1 | (prv_feed = 20.3 & t$ = prv_t$),
         [
         if stagetool <= one, pbld, n$, "(", "LOAD", *t$, ")", e$               	
         ]
       else,
         [
         if stagetool <= one, pbld, n$, *t$, "M06", e$
         ]
       n$, "M00", e$
       "(", "CONFIRM", *t$, *tlngno$, *tloffno$, *tldia$, ")", e$


  	if t$ <> tlngno$, pbld, "M00", e$ "(", "T & H DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!!", ")", e$ "M00", e$
  	if t$ <> tloffno$, pbld, "M00", e$ "(", "T & D DO NOT MATCH!!!!!!!!!!!!!!!!!!!!!!", ")", e$ "M00", e$

     spaces$=0
     if output_z = yes$,
       [

 

 

It would be easy to put a misc integer in here to override this when/if you wanted the number to be different.

Or an exitpost$ if you don't trust your operators to see this stuff. But I always do a quick scan of the code before sending it to the floor and the !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! are pretty easy to spot.

 

Sorry for the long post/thread hijack.

[neurosis]

That is awesome Keith. Thanks. Looks very simple and yet effective.

[K2csq7]

Anytime.

[Brando]

Keith A-1 that post is GOLD!!!

i hope they fix this issue soon, if i had a swear jar on my desk today i would have filled it for sure

[Zoffen]

how about just assigning H and D in the post to always be the same as the tool number....???

Force H and D to be the same as T.

This bug caused a crash once so i forced it in my post...problems solved!

[Tinhman]

I never have to worry about this because I am using

H#3020 (For Variaxis)

and

H#51999 (For all mazak machine)

 

HTH

[Mike Whitten CAD/CAM Contractors]

Hello Aeroguy,

 

I am wondering if you are using tool holders. X5 MU1 and earlier versions worked well for me until I started using tool holders in X5 MU1. When using tool holders on a fairly busy job, it would sometimes get confused and scramble my t#'s as you are explaining. I believe that there are more people here with the issue as I have seen other posts on this. Because of this issue and the fact that the tool holder is not defined in the tool def as it should be, I feel that it is just safer to use custom tools in X5 MU1. I have not tried tool holders in X6 yet, so I am not sure if this issue has been corrected.

 

Thanks,

[Aeroguy]

Hi Mike,

Yes I am using tool holders in X5. I always use them in fact. I have had similar tool changing problems when ever I change the holder after calculating a toolpath, but I had realized this already and would check things over accordingly.

My big problem is that recently they are just changing at what I perceive to be as a random occurence.

[dfedwards]

I have had this problem and it seems to definitely be related to toolholders. I use toolholders all of the time because this data is collected and printed in my setup sheets but the whole tooholder mess is buggy. I have learned to assign toolholders after I have completed programming and before creating my AR Setup Sheet. If I have to use toolholder before I finish programming the entire part (if I need to check clearance, etc.) I have learned to keep that tool assembly sacred (tool number, holder etc.) and never create another tool from a tool that already has a holder assigned to it (this seems to be where the tool renumbering issues come from). For example, if I have a 3/4 X .125R bull mill defined, Do not modify and choose create new tool, I have learned to create new tools from scratch. Just my 2 cents.

[rocheey1]

I have had this problem and it seems to definitely be related to toolholders. I use toolholders all of the time because this data is collected and printed in my setup sheets but the whole tooholder mess is buggy. I have learned to assign toolholders after I have completed programming and before creating my AR Setup Sheet. If I have to use toolholder before I finish programming the entire part (if I need to check clearance, etc.) I have learned to keep that tool assembly sacred (tool number, holder etc.) and never create another tool from a tool that already has a holder assigned to it (this seems to be where the tool renumbering issues come from). For example, if I have a 3/4 X .125R bull mill defined, Do not modify and choose create new tool, I have learned to create new tools from scratch. Just my 2 cents.

 

I had this problem for months on X5/X5MU1. Usually D offsets, sometimes H Offsets. I even tried writing a NetHook to scan down the operations looking for this, but it only reported what it saw in the Operations manager - which usually displayed the Offsets correctly. A complete reinstall seemed to help this.