Potential crash...Heads-up

[Redfire427]

We experienced a very strange situation that ALMOST resulted in a huge crash. Thank goodness I was standing at the controls and caught it in time. I have never seen this happen in 18 years of using Mastercam.

 

What happened was the work coordinate system changed between tools even though they were all written using G54. My program was written with roughly 10 operations using 7 different tools. Each operation was posted out as a single operation and measurements were taken at the machine to qualify the part. Once all the adjustments were made to the prove-out part, the entire machine group was posted out together. For some strange reason, the second and third tool were posted out as G55, however, once I saw the error, if I went back to Mastercam and posted out those operations, they switched back to G54. To make things even stranger, if I eliminated the first operation from my list of items to be posted, the tools that were incorrect before are now correct and two other tools are affected. Had I not caught it at the machine in time, I would have have taken out the spindle and the rotary table on our Makino.

 

I sent the file to In-house Solutions and they were stumped as to the cause. The temporary fix they sent back to me was to have my misc functions lock onto the first coordinate system. This "fix" has also failed. I will take it up with them tomorrow.

 

The only difference I can see that might be causing this issue is the fact that the file has 3 different machine groups based on the fact the work on the part was done on 3 different Makino's in our shop. All shop computers are new and identical as well as the install of Mastercam. If any one of our programmer/operators works on their own file without it being used by another machine, we do not see this issue.

 

I am sure there are lots of other users out there that use a common file for any given part and the work is done by different machines with different machine groups. Just thought I would make you aware to keep an open eye for this issue if you are using multiple machine groups.

 

Carmen

[Guest]

Did those tool paths have a different plane associated with them?

[cajahawa]

I've had that happen also, and like John said , I had the first cut in bottom view and the second in top view. When i posted them together it the second cut went to g55. I think you can change it in the view manager to assign g54 to both. Otherwise just post them out separately.

[Superman]

Were the operations imported from an earlier version of Mcam. Where misc intergers were used and not reset to the current settings

 

This is the first place I check for un-explained work offset outputs after checking planes

[Redfire427]

John,

 

No, they all share the same WCS. None of these operations were imported from anywhere. They were all created as new and then the similar operations were copied and pasted within the same machine group and just changed the chains/surfaces/parameters/etc.

 

To compound this problem even more, I did a test late today that is equally bizarre. Take a file, any file, that has a few operations in it. Post them out and check the offset valve ( assume G54 ). Now go into lets say, the forth operation and change the offset from -1 ( default for G54 ) to 1. Obviously this will make the operation dirty and will need to be regenerated. Regenerate this operation. Now in the first operation, go to misc functions and turn on the "lock on first WCS". This step is really not important, but will illustrate my point. Now post out this first operation and see what you get...............It will be G55 and it should NOT be. OK, now for the really crazy part. Go back to the forth operation you changed earlier and change the WCS back to -1 and regerate this operation. You are basically back to where you started. Now, post out anything you like and you cannot get rid of the G55. CRAZY. It appears once the WCS has been changed, it becomes modal and cannot be reset no matter what you try.

[Mr. Wizzard]

I've had the exact same thing happen to me. What irritates me is the multiple ways you can change settings. The settings, such as offsets, that can be set in the post, the Machine Definition, the Control Definintion, the planes manager, and the parameters for each operation DO NOT override one another as Mastercam says that they should!

This definitely provides frustration while I am programming things. You set them a certain way and they DO NOT work. I end up playing with the same settings in various dialoque boxes to get them to come out right from the post.

I completely understand where you are coming from. The settings should override like Mastercam says they should or get rid of the options! Just pick one place and have it work! Either the post OR the MD OR the CD OR the op's parameters!

[gcode]

You guys don't mention what post your're using

or what vintage. I've never experienced these

problems. The posts I use are mpmaster of X3

and X4 vingate doing HBM rotary work with up to a dozen work offsets and multiple origins

If I want just one offset, I leave all the planes at -1 and force the lock with misc9.

If I need multiple offsets, I set them all inside the View Manager.

I did have trouble in X2 days with some updated V8 and V9 posts performing in unexpected manners

so I replaced them with new mpasters.

One reason I may not be experiencing these issues is I try to avoid multiple machine groups in the same file.

[moeh]

We have MC files that hold ops for several different machines and have never seen this. One thing I have done though to prevent issues like this from making it to the floor is I wrote a program in VB that checks the code for common programmer mistakes, such as which work coordinate is being used, checks coolant for each op, checks look ahead for each op, etc. It has saved much time on the floor.

[Redfire427]

I just had In-House Solutions log into my computer to look at the problem and so far they don't know why this problem occurs. Once you change a WCS in the parameters of a toolpath, it gets locked into the WCS Manager. Even when you change the WCS's in all the toolpath to the same WCS, the change you made earlier remains in the WCS Manager. So. what I'm trying to say is, even though visually your toolpath shows you it is G54, when you post it out, it's not.

 

We also tried the mpmaster post and got the same result. This issue is tied to the framework of Mastercam rather than an external issue.

[Jim Evans from CNC Software]

Without seeing the part and post I can only take a guess at to what is happening but before I do let me add some information here.

 

First, the default work offset value in Mastercam operations is -1. This -1 is a flag to Mastercam to figure out the work offsets automatically. Now if you DO NOT want mastercam to figure them out, then set it to something other than -1 (what to set it to is based on your post setup).

 

Mastercam puts work offset holders in the binary nci which is the data for the operations. The actually Work offsets does NOT get set until you select the ops and press the post button. so in the case where you are doing each operation separately and getting G54 - that is becuase onyl one op so it uses the first available Work offset (0 in the NCI) produce G54 in the NC, but when all together you get G54 and G55 doesn't surprise me but somewhere Mastercam found a change in Plane or tool origin and incremented those ops to G55 (1 in the NCI). The actually offset isn't calculated until it goes through the operations selected for output.

 

Mastercam use a changge in Toolplane (view) and/or a change in tool origin when deciding when to add a new Work offset and when to use an existing one.

 

 

second, The actual values that need to be entered in the Work offset field of the operation all depend on how you post is setup. posts leaving CNC Software are setup to handle a value of 0 and up. 0 represents the first work offset value (G54 - fanuc, E1-fadal, etc), a value of 1 represents the second work offset value (G55/E2 as precious example), a value of 2 represents the 3rd and so on. So in the above post where PM changed the work offset value from -1 (auto) to 1 and got a G55, that is exactly what he just told his post to do. Now the problem with that is the other ops that have -1 - auto - will try and match an exisiting work offset so because they are the same plan and origin as the ops set to 1, they also will get set to 1 - because they were set to -1 and left it up to mastercam to figure out.

 

Lastly, leaving work offsets to -1 without undestanding the rules built into Mastercam can be frustrating but you can always force the work offset values by setting the actual value in the operations and can do so for a bunch of ops at one time using the edit common parameters function.

 

PM, I suggest you send the original file to [email protected] and let us take a look at it and we can figure out what is causing it to go from G54 to G55 so you have atleast a heads up as to what the trigger was so as to be on the lookout for it. It is very possible that Mastercam did exactly what it was supposed to do with the offset values, but that doesn't mean it's not an issue. when you send it to QC, refer to this thread in the email so they can followup on your issues and my comments.

[neurosis]

I just had the same thing happen to me this week. I thought that I was going crazy. I am using mpmaster for X4.

 

So far this has happened to me twice and luckily it was caught both times.

[Redfire427]

Jim,

 

Thanks for the response. This is not my first rodeo. In-house has made a video of the issue and forwarded it to the appropriate parties. The big kicker here is that once you change the work-offset in the toolpath, it shows you that you are using a different work-offset than the other toolpaths as it is supposed to. However, go back to that toolpath and change it back to the same work offset as all the other toolpaths. It "appears" to be correct. It is not. Go to the WCS Manager and you will see another work-offset associated to the toolpaths. This is absolutelt incorrect.

[Jim Evans from CNC Software]

PM,

 

One of my QC staff gave me a heads up that they have received emails from your reseller and are following up on them.

[Redfire427]

Thank-you in advance Jim.

[RandleXX]

I have had this same thing happen a couple of times.

Now I search every posted code for offest errors.

[Mjölnir]

Same here. When I'm going to leave a machine run unattended I always check the posted code for offset errors. Same with programs using multiple offsets.

 

The habit goes back to v9 when I used to have lots of offset troubles with transformed toolroads. Those problems have gone away since but the habit remains.

 

Now when it happens it's dealt with just like any other work around. Especially since without a fixed bug list we have no way of knowing whether or not these things ever get fixed.

 

It takes way less time to check the code than it does to rework bad parts or repair damaged equipment.

[Watcher]

HI folks!

 

What if you guys create a buffer and array to list all workoffsets used in the program at the header... If later on someone figure out what is going on you can disable it with a switch...

 

JM2C

[Watcher]

quote:

---

Especially since without a fixed bug list we have no way of knowing whether or not these things ever get fixed.

---

Bug list? Oh... nevermind...

[RandleXX]

quote:

---

What if you guys create a buffer and array to list all workoffsets used in the program at the header... If later on someone figure out what is going on you can disable it with a switch...

---

Thanks Watcher!!

 

I like this idea. List all offsets used in the header so the operator can make a quick check that everying looks good. Now, I just need to figure out how to add it to my posts..

[Bob W.]

I had the same thing happen with a typical I do every day. Basic program using one work offset and whammy, a G55 showed up in there. Now I take nothing for granted and I run EVERYTHING through dry run in the machine before starting. If it was a systematic thing Mastercam does I would have seen it hundreds of times given how I program. It happened once in four years of programming and I hadn't done anything out of the ordinary. I also told Chris Rizzo about it and he ran accross the same issue a few days later. My experience with this was in X3.

[bogusmill]

I've had this same problem for years. If I ever came off -1 or 0, even starting new paths in a new machine would not allow me to get back to posting G54. I have resorted to setting G54 & G55 to same settings to get comfortable with MC again.

[Zoober]

Here is a good start for those of you wanting the G10 offset output in the header.

Looks like this - you could always comment them if you just want a list, but I feed the G10's right to the machine.:

 

code:

---

(***********************************************)

(*********** WORK COORDINATES START **********)

G90 G10 L20 P1 X-.005 Y-19.0905 Z-3.13 B0. ( B0. )

G90 G10 L20 P2 X.005 Y-19.0905 Z3.13 B0. ( B180. )

G90 G10 L20 P3 X-2.7973 Y-19.0905 Z1.4043 B0. ( B243.43 )

 

G11

(*********** WORK COORDINATES END **********)

 

M1

 

G0 G17 G20 G40 G80 G90

N90010(B0 - RGH AND FINISH FACE TO 10.00)

G91 G0 G28 Z0.

G90 G17 G80 G49

---

code:

---

 # --------------------------------------------------------------------------

# Buffer 6 - G10 work offset preloads write, sort, read, output routines

# --------------------------------------------------------------------------

#This section is designed to write the work offsets preloads to a buffer file, then sort them

#into accesding order and eventually output the preloads to the NC output files. These sections

#only get called if the use_g10wcs flag is on.

# Work offset preload buffer

 

test : 0 #Result variable

cnt1 : 0 #Loop counter number 1 for sort

cnt2 : 0 #Loop counter number 2 for sort

wc6 : 1 #Initial count for write buffer 6

rc6 : 1 #Initial count for read buffer 6

size6 : 0 #Buffer 6 size

 

 

tox3 = tox6 #Figures X Offset from machine zero

toy3 = toy6 - 25.5905 #Figures Y Offset from machine zero

toz3 = toz6 #Figures Z Offset from machine zero

 

fmt W 4 workofs6 #Buffer 6

fmt P 4 pofs6 #Buffer 6

fmt X 2 tox6 #Buffer 6

fmt Y 2 toy6 #Buffer 6

fmt Z 2 toz6 #Buffer 6

fmt B 15 cabs6 #Buffer 6

fmt X 2 tox3 #Buffer 2 X Offset from machine zero

fmt Y 2 toy3 #Buffer 2 Y Offset from machine zero

fmt Z 2 toz3 #Buffer 2 Z Offset from machine zero

 

 

workofsn : 0 #Temporary data for swap in buffer2

pofsn : 0 #Temporary data for swap in buffer2

toxn : 0 #Temporary data for swap in buffer2

toyn : 0 #Temporary data for swap in buffer2

tozn : 0 #Temporary data for swap in buffer2

coutn : 0 #Temporary data for swap in buffer2

 

fbuf 6 0 6 0 0 #Buffer 6

 

# --------------------------------------------------------------------------

preloadwcs #Output G10 preloads from Buffer6

#This postblock is called from the PSOF postblock and is designed to output the WCS

#preloads to the beggining of the NC output file and only if the use_g10wcs flag is

#active.

pg10sort #Sort preload buffer in accesnding order before output

 

#read preload buffer and output preloads

rc6 = 1

size6 = rbuf (six, 0)

#"(***********************************************)", e$

*e$

"(***********************************************)", e$

"(*********** WORK COORDINATES START **********)", e$

while rc6 <= size6,

[

workofs6 = rbuf (six, rc6)

#"workofs6 = " *workofs6, e$ #debug

#"*pofs6 = ", *pofs6, e$ #debug

 

if workofs6 < 6,

[

pofs6 = pofs6 + 6

pbld, n$, *sgabsinc, "G10", "L2", *pofs6, *tox3, *toy3, *toz3,

"(", *cabs6, ")" e$ #Offsets G54 - G59

]

else, pbld, n$, *sgabsinc, "G10", "L20", *pofs6, *tox3, *toy3, *toz3, "B0.", "(", *cabs6, ")", e$

#Extended offsets g54.1 P1 - P48

]

*e$

"G11", e$

 

"(*********** WORK COORDINATES END **********)", e$

 

pg10sort #Sort preload work offsets in accending order

#This postblock is designed to sort the wcs preload buffer in accending order. This

#postblock is called

#from the preloadwcs postblock. DO NOT MODIFY this post block unless you are

#absolutely sure of what you

#are doing.

rc6 = 1

size6 = rbuf (six, 0)

 

cnt1 = 1 #intialize counters

cnt2 = 1 #intialize counters

 

while cnt1 < size6, #loop 1 - loop 1 time less than the size of the buffer

[

size6 = rbuf (six, 0)

while cnt2 <= size6 - cnt1, #loop 2 - loop 1 less every time

[

rc6 = cnt2 #set buffer read counter to current loop counter value

#(Current record to read)

workofs6 = rbuf (six, rc6) #Read current and next record from buffer

workofsn = rbuf (six, rc6)

if workofsn < workofs6, #Check and swap records if next offset is less

#than current

[

wc6 = cnt2 #initalize write counter to current loop counter value

#(current record to write)

workofsn = wbuf (six, wc6) #Swap records by writing back into buffer.

#Next into current, current into next

workofs6 = wbuf (six, wc6)

]

cnt2 = cnt2 + 1 #increment loop counter 2

]

cnt2 = 1 #Reset loop counter 2 to start at record 1

cnt1 = cnt1 + 1 #increment loop counter 1

]

 

pg10wcs_writbuf #Buffer 2 works offset preload buffer

#This postblock is called from pwrtt and only if the use_g10wcs flag is active.

#This postblock is designed to write out the WCS and tool origin information to the

#preload buffer. The preload buffer will be scanned and checked to see if the WCS was

#already

#written to the buffer, if not the wcs is written to the buffer.

test = 0

size6 = rbuf(six, 0) #Get size of buffer

 

#read buffer and compare current workofs value with one read from buffer.

#If current workofs matches one already in buffer set flag to not process.

 

while rc6 <= size6,

[

workofs6 = rbuf (six, rc6)

if workofs$ = workofs6, test = 1

]

 

#If workofs doesn't match one in the buffer, write it to the buffer

# with the P value and tool origin.

 

if test = 0,

[

cabs6 = atan2 (m7$, m9$)

workofs6 = workofs$

pofs6 = workofs$ - 53

if workofs6 < 54, pofs6 = workofs$ -5 #Extened offsets P1 - P48

tox6 = tox$

toy6 = toy$

toz6 = toz$

#cabs6 = cout

workofs6 = wbuf (six, wc6)

]

rc6 = 1 #reset read counter for next pass

---

[Redfire427]

UPDATE.......

 

In my continuing saga with strange things happening, I found a somewhat related matter yesterday that ended up with a crashed machine. Here are the details......

 

I had to make a replacement part for a mold that was built last year. The toolpaths were written in X2 as that is what we were using at the time. I opened the file in X4 and ran most of the toolpaths without incident. One of the toolpath called for a tool that I did not have it stock, so I created a new toolpath with a slightly different strategy. Unknown to me, Mastercam created a new tool plane all on its own and applied it to this new toolpath. Even though the WCS stayed the same, Mastercam created a new WCS called "new view 1" that used the same X & Y coordinates, but a different Z value. I posted out the code for two toolpaths using the same tool. The first toolpath ran fine and when it made the transition to the second toolpath, the tool and holder buried itself into the stock and stalled the machine ( crash ). To say the least, I am pissed.

 

This issue is easy to duplicate and In-house Solutions is making a video of this issue and forwarding it to CNC Software for evaluation.

 

Be on the look-out when using a previous generation file in X4. We were able to duplicate this problem on any of of installed seats and In-House Solutions found the same error on their end. This crash has the potential to turn into a $50K repair bill. I would hate to see anyone else suffer the same consequences.

 

Keep your eyes open for changing WCS's as well as changing toolplanes. You will not have any warning whatsoever.

 

Carmen