Omit breakup of x, y & z rapid moves

[PeterM]

This gets me more often than any other post related issue, if it is a post issue. As I read this line of my post

 

nobrk$ : no$ #Omit breakup of x, y & z rapid moves

 

I interpret it to mean, prevent three axis simultanous rapid moves. However, here is an example of a simple contour with a transform-rotate after after posting.

 

N1( 1/2 FLAT ENDMILL DIA. OFF. - 1 DIA. - .5)

( REGULAR TYPE CCOMP )

T1

M6

G0G90G49X-.19Y.4012A-15.

S955M3

G43Z1.H1M8

Z.1

G1Z-.0122F50.

G41D1X-.47F5.

Y-.1512

G40X-.19

G0Z.1

...{G54X-.19Y.4012Z.1A-45.}...

G1Z-.0122F50.

G41D1X-.47F5.

Y-.1512

G40X-.19

 

I added the ...{ }... to highlight the three axis rapid move. So why does this happen? Is there another switch that I have missed?

[Christian Raebild]

The three axis rapid move with the G54 is probably in the ptlchg0$ (null toolchange) postblock, and has all three axes forced out, as it is a change to a new WCS, where it is impossible for the post processor to "know" whether the "new" Z value is above or below the "prior" Z value.

 

In addition, the $ signs tells me it is a version X post you are working with. In a version X post, the question of whether rapid moves are to be broken up is set in the control definition, not in the post processor.

[PeterM]

Sorry about not mentioning x mr1 and I have also set the control def correctly. Do you have a suggestion as to a tactic or work around for this, I could set my retract and approach higher but it goes against my grain to waste cycle time and I am currently editing my files to strip out bad code, which is a different waste of time.

Thanks, Peter

[heeler]

Look in the ptlchg0 block that Christian mentioned. I have moved my Z call out down to the next line in the post. That way it can never be with the G54 XY call.

 

HTH

 

Glenn