Post Processor Problems

[Cedge]

Hi,

I'm running WF2 build m050 with a Fanuc robodrill mill.

I've had problems with the beginning of sequences.The tool shouldrapid to X0 , Y0 and Z(clearance height) and from there continue cutting but instead it's onlymoving toZ5(clearance). missing the X and Y and thereforepassingthrough the job on thefirst cut,G01 X0. Y0. Z-.2 F150.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[JayCrook]

Hi Cedric,
I have a couple of questions. Does the post output correctly when you start at a point other than X0,Y0? I'm making an assumption that the tool rapids to a point Xn,Yn,Z5.0 then feeds to first Z and feeds across/through the part. This may indicate that the post is not processing the first GOTO statement in the NCL file.

Jay.

[Cedge]

Hi Jay,

Yes, the post outputs correctlyif the start is apoint other than X0, Y0. Francois pointed out that thepost thinksthe table is in the tool change position (X0,Y0)and therefore does not require outputting the X and Ybut in actual fact thetable isstill inthe home position.

So far the possible solutions are:

Setting the tool change position under the NC post processorto a dummyvalue like (X0.001, Y0.001)

Or David suggested setting the parameter START_MOTION to Z_LAST

Both seem logical even if they don't address the problem directly. Will try both on monday unless there is a reason for not doing so?

Thanks all for the help 🙂

[AustinN.C.,Inc.]

Cedric,

The solutions should be to set the tool change position in the post to some
value other than "Current X/Y" or X0/Y0. Since the machine is not at X0 Y0
at tool change. Adding a small decimal value to the X & Y values for tool
change is a good idea, that way they will not be considered modal.

Fred Nemecek
Austin N.C., Inc.
512/458-1112 x119



_____

[dford]

Cedric,

I'm assuming Gpost. I dealt with this sort of issue myself, but it was long enough ago that a lot of the details escape me.

You might need to be careful about using a dummy tool change position in the post. I think I recall this being incompatible with motion analysis in multax posts (HMC w/B axis for example). If the B was not at zero degrees, the post did not correctly interpret the approach vector because it considered the dummy tool change position to be at the 0,0,1 vector, not the current vector

To get the position addresses to repeat, I ended up using FIL to "empty" the contents of the last B/X/Y/Z outputs at each tool change and workshift change (dblcom 356-381) which forced those addresses to be output again.

To get motion analysis to process correctly at all vectors - In the "tool change coordinates" panel I didn't specify any coordinates, and for "motion analysis option for RAPID, GOTO/pt after LOADTL" I selected "Output XY, then Z-move, assume advance move".

Maybe there was a better solution, or maybe I was doing something else wrong to create the situation in the first place, but the above has been working well for me.

Regards,
Dave Ford
NC Programming Mgr.
G.W. Lisk Co.
Clifton Springs, NY 14432
(315) 462-4381

P Please consider the environment before printing this email - be green, keep it on the screen!