XYZ Rapid Crash Followup

[huskermcdoogle]

In response to my own thread where I was having trouble with MCAM posting things inconsistently from one instance to an other, is there a way to flag with the post any XYZ, XZ, or YZ combo rapid move, maybe toss in a M00 when that happens? So you don't get any surprises during proveout. Then you turn off the check once you know where they are or may be (safe ones) and post normally.

 

Just thinking. Hopefully we can come up with something to prevent this from happening again.

 

We have lapped the spindle, <.001" at 12 inches. Gonna have to be good enough till this order is done. Then out comes the spindle. Big Plus face is boned, slight crack at the drive key. Gonna probably need to replace the spindle, may not be able to be rebuilt. If it can it will probably go on the shelf as a spare.

 

Just plain a bummer situation.

 

Thanks for any help in advance.

 

Husker

[Newbeeee™]

Am I missing something...start of tool why not have xy position, then zrapid in on a separate line?

Then z retract, xy position, z rapid in again?

[huskermcdoogle]

Am I missing something...start of tool why not have xy position, then zrapid in on a separate line?

Then z retract, xy position, z rapid in again?

 

 

This is not on start of tool, but rather between operations with the same tool.

[gcode]

Reference points were being used to control Z rapid motion between tool paths.

 

An X5 file was opened and posted in X6.. Some reference point settings were not respected resulting in a destroyed spindle.

see this thread

[gcode]

has anyone done any work with the settings on the "Liner" page of the Control Def.

 

In early X days I spent a lot of time messing with these settings but have been running default settings for years now..

 

 

It seem that the right settings on this page might have prevented this..

 

.but the results I got with my experiments years ago lead me to wonder if these settings even do anything

[huskermcdoogle]

has anyone done any work with the settings on the "Liner" page of the Control Def.

 

In early X days I spent a lot of time messing with these settings but have been running default settings for years now..

 

 

It seem that the right settings on this page might have prevented this..

 

.but the results I got with my experiments years ago lead me to wonder if these settings even do anything

 

I have break rapid moves turned on. But I wonder if this is something the post should look at? Does a MPMASTER read this, or is this NCI related.

 

Husker

[Newbeeee™]

Reference points were being used to control Z rapid motion between tool paths.

 

An X5 file was opened and posted in X6.. Some reference point settings were not respected resulting in a destroyed spindle.

see this thread

Yes G, I read all this, but is this not sort of a post issue maybe?

I've never seen a XYZ rapid move - ever?

[Joe788]

Yes G, I read all this, but is this not sort of a post issue maybe?

I've never seen a XYZ rapid move - ever?

 

If you have clearance active, you'll get an XYZ rapid move if two successive operations at the same TPlane have different clearance values.

[Newbeeee™]

If you have clearance active, you'll get an XYZ rapid move if two successive operations at the same TPlane have different clearance values.

So can you not mod the post to output xy rapid with z on a separate line?

[gcode]

I think the Control Def is supposed to modify the NCI output per the settings on the "Linear" page.

 

If that is the case, you should get the desired nc output without having to modify the post

[Newbeeee™]

I think the Control Def is supposed to modify the NCI output per the settings on the "Linear" page.

 

If that is the case, you should get the desired nc output without having to modify the post

 

Just did what Joe said ref the 2x ops with different retract values.

Yep, although I've never done this (always had the same retract value as absolute for each plane), it did do the 3-way dash.

I think this is an accident waiting to happen surely? XY then Z has got to be the safest thing everytime?

 

G, just played with the linear settings which did nothing to the output.

Perhaps it's because I have an updated V9 post and the logic isn't there???

 

Does anyone (Colin ) know what's involved in a post mod to permanently split the Z from the XY?

[gcode]

G, just played with the linear settings which did nothing to the output.

that was my experience back in early X days..

 

It's been years since I even looked at that page.. but if those setting were set properly and worked properly

 

they should have prevented husker's crash..

 

note that they probably wouldn't prevent a lower Z to higher Z crash though

[gcode]

OK..

 

I loaded a default X6 machine def and modified a toolpath to force a 3 axis rapid using Reference points.

 

 

The default setting on the Linear Page is

 

"Break rapid moves-XY then Z for approach, Z the XY for retract"

 

to me this sounds like a three axis rapid should not happen

 

but it posts this

 

 

G3 X.8819 Y-1.9751 I.0214 J-.0452

G1 X.9034 Y-2.0203

G0 Z1.

( ROUGH .156R CUTOUTS )

( LEAVE .010 )

X-.9051 Y-2.0239 Z.5 <--------- crash into fixture

Z.15

Z.07

G1 Z-.03

X-.8836 Y-1.9787

 

 

 

 

the other option is

 

"break all moves with change in Z"

 

I get the same output when checking this.

 

 

I'm using a stock copy of a Mastercam 3X VMC machine def

Either I am misunderstanding the purpose of this page ... or it doesn't work

[Allan]

Just did what Joe said ref the 2x ops with different retract values.

Yep, although I've never done this (always had the same retract value as absolute for each plane), it did do the 3-way dash.

I think this is an accident waiting to happen surely? XY then Z has got to be the safest thing everytime?

 

G, just played with the linear settings which did nothing to the output.

Perhaps it's because I have an updated V9 post and the logic isn't there???

 

Does anyone (Colin ) know what's involved in a post mod to permanently split the Z from the XY?

 

I will depend on the post; if the rapid motion is coming from a common postblock like prapidout.

 

prapidout       #Output to NC of linear movement - rapid               
     pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
       pxout, pyout, pzout, pcout, strcantext, scoolant, e$
     #Modify following line to customize output for high-speed toolpath
     #tool inspection/change points
     if rpd_typ$ = 7, pbld, n$, "M00", "(TOOL INSPECTION POINT - POST CUSTOMIZATION REQUIRED)", e$

 

 

You could break it up like:

 

 

prapidout       #Output to NC of linear movement - rapid               
     pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
       pxout, pyout, pcout, strcantext, scoolant, e$
     pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
       pzout, pcout, strcantext, scoolant, e$

     #Modify following line to customize output for high-speed toolpath
     #tool inspection/change points
     if rpd_typ$ = 7, pbld, n$, "M00", "(TOOL INSPECTION POINT - POST CUSTOMIZATION REQUIRED)", e$

 

That would force the Z to be output after the XY output.

 

 

HTH

Allan

[Newbeeee™]

Thanks Allan,

I'll shoot a mail to my reseller about this when I'm back at work.

[huskermcdoogle]

Thanks Allan,

I'll shoot a mail to my reseller about this when I'm back at work.

 

I would want it to break up based on the Z direction which would be good for 99.9% of cases. XY then Z- or Z+ then XY. Clear as mud right.

 

Any light that you can shed on the variables to read to achieve this? The logic itself shouldn't be bad.

 

Husker

[K2csq7]

Compare the current Z value to the previous.

if zabs < prv_zabs, 
xout, yout, e$
zout, e$
if zabs > prv_zabs, 
zout, e$
xout, yout, e$

 

 

^just thinking outloud....

[huskermcdoogle]

Compare the current Z value to the previous.

if zabs < prv_zabs, 
xout, yout, e$
zout, e$
if zabs > prv_zabs, 
zout, e$
xout, yout, e$

 

 

^just thinking outloud....

 

Thanks for this. Here is what I ended up doing. Works great. Posting the bad file without regenerating results in good code... I only have a few questions regarding some of the other stuff going on in here (X4 MPMASTER updated to X6, with some other mods of mine).

 

What are the following and what mods to where they appear would you suggest?

 

pccdia

pcout

 

Also, any thoughts on if this is sufficient?

 

 

prapidout       #Output to NC of linear movement - rapid 
     sav_gcode = gcode$
	if convert_rpd$ = one,
		[
		gcode$ = one
		feed = maxfeedpm
		ipr_type = zero
		]
if zabs < prv_zabs,
	[
	pcan1, pbld, n$, sgplane, `sgcode, [if gcode$ = 1, sgfeed], sgabsinc, pccdia,
		pxout, pyout, pcout, [if gcode$ = 1, `feed], strcantext, scoolant, e$
	pbld, n$, `sgcode, sgabsinc, pccdia, pzout, pcout, strcantext, scoolant, e$
	]
if zabs > prv_zabs,
	[
	pcan1, pbld, n$, sgplane, `sgcode, [if gcode$ = 1, sgfeed], sgabsinc, pccdia,
		pzout, pcout, [if gcode$ = 1, `feed], strcantext, scoolant, e$
	pbld, n$, `sgcode, sgabsinc, pccdia, pxout, pyout, pcout, strcantext, scoolant, e$
	]
if zabs = prv_zabs,
	[
	pcan1, pbld, n$, sgplane, `sgcode, [if gcode$ = 1, sgfeed], sgabsinc, pccdia,
		pxout, pyout, pcout, [if gcode$ = 1, `feed], strcantext, scoolant, e$
	]

     gcode$ = sav_gcode

 

 

Husker

[K2csq7]

pccdia

has to do with cutter comp.... it calls the postblock that handles the cutter comp. I try to leave that alone wherever possible...lol

pcout

is the call to the postblock that handles the output for your rotary.

 

As for sufficiency of your mods....

I am no expert, what I do in situations like this is to post the code with the backed up post (hope you backed up before these mods) then post with the newly modified post and run the 2 gcode programs through the file compare option in cimco to verify expected results.

[Machineguy]

In a pinch, would a "force Tool Change" in the following ops from the main one using the same tool work? At least it would get the tool back to home then pick up the next set of tool height values.

Just thinking out loud.

[spade117]

I will depend on the post; if the rapid motion is coming from a common postblock like prapidout.

 

prapidout #Output to NC of linear movement - rapid
pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
pxout, pyout, pzout, pcout, strcantext, scoolant, e$
#Modify following line to customize output for high-speed toolpath
#tool inspection/change points
if rpd_typ$ = 7, pbld, n$, "M00", "(TOOL INSPECTION POINT - POST CUSTOMIZATION REQUIRED)", e$

 

 

You could break it up like:

 

 

prapidout #Output to NC of linear movement - rapid
pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
pxout, pyout, pcout, strcantext, scoolant, e$
pcan1, pbld, n$, sgplane, `sgcode, sgabsinc, pccdia,
pzout, pcout, strcantext, scoolant, e$

#Modify following line to customize output for high-speed toolpath
#tool inspection/change points
if rpd_typ$ = 7, pbld, n$, "M00", "(TOOL INSPECTION POINT - POST CUSTOMIZATION REQUIRED)", e$

 

That would force the Z to be output after the XY output.

 

 

HTH

Allan

 

This works if the next operation is using the same work offset as the previous operation, but not if the tool is moving to a different work offset.

 

I thought this was something that I fixed in the past, but as each new release of mastercam comes out, it is something that reverted back. I can't find the older thread where this was discussed.

 

Does anyone know how to make it break the lines while moving from one work offset to a different one?