too many G54's

[Toby]

I,m currently trying to dial in my 4th axis post and all is good but one thing. The resultant G-Code program has a boat load of G54's on their own line. This is fine to call up once every tool but not a "million" times throughout the tools. Where might be a good place to start looking in the post?

------------------

Toby Baughman

Magic Mfg

[Allan]

sounds like the MPHASS.pst.

Change to Mpfan.pst or get your dealer to look at it.

[Toby]

Actually it's the new Mpfanbax post and it works great on our LeBlond Makino Horiz other than this one problem.

------------------

Toby Baughman

Magic Mfg

[Guest CNC Apps Guy 1]

Please specify what VERSION your Post is from. I had to search for that post.

MPFANBAX is a standard post in Mastercam Version 7.2

I'll step down off my soap box now.

Search for "pwcs". This is the variable that outputs G54. It should for the most part only be in "psof" and "ptlchg".

You could try to put a "#" at the front of the line where it is in "prapid", 'plin", and "pcir".

Try that.

James Meyette

[Toby]

I am using the 7.2 version. Here's what a portion of G-code looks like:

X5.075

G0 Z2.8

( B0,PARTIAL CENTER TO Z1.5 )

G54

X-.6002 Y13.6

G1 Z2.5114 F120.

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z2.3429

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z2.1743

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z2.0057

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z1.8371

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z1.6686

X-.1941 Y11.9711

G3 X.1941 I.1941 J.0484

G1 X.6002 Y13.6

G54

X-.6002 Y13.6

Z1.5

I checked the post and it appears to already have the "#" on the prapid,plin,and pcir lines should i put them on another line?. Here's what my post lines look like:

prapid #Output to NC of linear movement - rapid

pcom_moveb

if mi1 > 1, pwcs_2

ppos_cax_lin

prapidout

pcom_movea

pzrapid #Output to NC of linear movement - rapid Z only

prapid

 

plin #Output to NC of linear movement - feed

pcom_moveb

if mi1 > 1, pwcs_2

if ctype = zero, ppos_cax_lin

plinout

pcom_movea

------------------

Toby Baughman

Magic Mfg

[Guest CNC Apps Guy 1]

make the "mi1 > 1, pwcs_2" look like this

# mi1 > 1, pwcs_2

in the plin, pcir, prapid lines.

Try that,

James Meyette

[Toby]

I tried that and got the same result as shown above. It must be getting the pwcs from another area of the post.

------------------

Toby Baughman

Magic Mfg

[Guest CNC Apps Guy 1]

(find fastmode in your post first) set fastmode to '0" ,bug2 to 20, and bug3 to

and then post your programs again. It should tell you what section of the post is generating the extra "G54"s.

James Meyette

[Toby]

James,

with bugs on all the instances of "G54" is the culprit of the ptlchg0 area. Here's my post section. What do you think?

 

ptlchg0 #Call from NCI null tool change (tool number repeats)

if workofs <> prv_workofs,

[

sav_nobrk = nobrk

nobrk = zero

]

pctype

prv_x = vequ (xa)

x = vequ (xr)

gcode = 0

pspindle

pcom_movbtl

pzclrot

pindex

comment

pbld, n, sgplane, e

if prv_spdir1 <> spdir1, [spindle = 1], pbld, n, *spindle, e

if prv_speed <> speed | prv_spdir1 <> spdir1,

pbld, n, *speed, *spindle, pgear, e

if use_g10 = yes, pbld, n, *sgcode, "G10", "L2", pworkofs, *tox, *toy, *toz

pbld, n, pwcs, e

pbld, n, scoolant,e

pbld, n, pfxout, pfyout

------------------

Toby Baughman

Magic Mfg

[This message has been edited by toby (edited 12-08-2000).]

[Dennis at CAD/CAM Consulting]

Tony,

3rd line up from the bottom of ptlchg0

put a # in front of it. You don't need it.

# pbld, n, pwcs, e

That shold get rid of the extra G54s.

Hope that helps,

Dennis

[Toby]

It worked like a champ thanks. If you look at my example above with the g54-s gone there is a xy redundant callout. Is there a quick fix for this as well?

------------------

Toby Baughman

Magic Mfg

[Guest CNC Apps Guy 1]

Try this,

pworkofs, tox, toy, toz

James Meyette

[Dennis at CAD/CAM Consulting]

Toby,

The null toolchange ptlchg0 is also forcing out the x and y positions at the end of ptlchg0. Put a # in front of the last line of ptlchg0 to look like this

# pbld, n, pfxout, pfyout

That should get rid of the redundant XY output. BE CAREFUL WHEN RUNNING THIS!. Someone probably put those things in ptlchg0 because of a problem somewhere else. I haven't found it yet but I am sure you will.

Hope that helps,

------------------

Dennis Neil

email: [email protected]

http://dennisne.home.netcom.com

[Toby]

I put a line skip in to prevent a forced xy position and it worked somewhat ok. The potential problem I found is that when the part rotates to another side and with the same tool it will put the needed x or y or xy position on the canned cycle line as shown below in the g-code:

N100 T100 M06

( B90, 3/8" SPOTTER, 1X FOR .5781" DRILL )

M11 B90. M10

G0 G90 G54 X.505 Y.37 S6000 M3

G43 H1 Z5.2 M8 M754 T300

G98 G81 Z4.85 R5.07 F15.

G80

G0 Z6.30

M11 B270. M10

( B270, 3/8" SPOTTER, 1X FOR .5781" DRILL )

G98 G81 X-.505 Z4.85 R5.07 F15.

G80

It would be nice to force a xy move only on rotations. I wouldn't mind this small amount of redundancy.

------------------

Toby Baughman

Magic Mfg

[Dennis at CAD/CAM Consulting]

Tony,

Earlier we took out the

# pbld, n, pfxout, pfyout

out of ptlchg0 by putting the # in front of it.

Try this instead,

" if c <> prv_c, pbld, n, pfxout, pfyout"

This way the x and y are only output if the rotary position is changed. I'm not sure how this might work with toolplanes changing but, it should...

------------------

Dennis Neil

email: [email protected]

http://dennisne.home.netcom.com

[Toby]

Its close but not quite there. This adjustment took care of the forced xy position on rotary moves but I got back the redundant xy moves within the tool. Could this be due to different tool planes?

------------------

Toby Baughman

Magic Mfg