Yeah, it's the one thing that always irked me when only posting a few operations and the post is set to auto number planes. The 1st operation is always G54 regardless of what it posted as when you post the entire program. Been burned by that a few times, so that's when I started putting a value in the plane manager any time more then 1 plane will be used and this was 20+ years ago. For the most part it wouldn't make a difference 'cause usually when I only select individual operations I'm only looking for the toolpath itself so I just paste the changes, but when I add a toolpath on another plane and paste that whole toolpath in, that offset value is gonna bite ya. For what I know about posts, it was obvious to me that the -1 was more like a trigger to the MP to determine how many different planes are used and to assign a new offset value to each one. This is probably the easiest way, but can also burn you like in my instance above which is why in my 5x posts I have it set to always use G54. All of my horizontal mills have Fanuc controls and none have dynamic offset so I made myself get in the habit of manually assigning an offset to every plane. I can already program crashes enough on my own, I don't need any help. Thanks for the help and education Colin.

Yeah, after looking at it and running it thru my head I was thinking it could be deleted as well. I suppose that you could make the workofs_out switch in the post setup section like an off/on enable/disable switch for automatic plane numbering with a 0 or 1 you could accomplish the same thing. A 0 would disable auto plane numbering and the post would either always use G54 or use the value in plane manager. A 1 would enable auto numbering and would ignore any value in plane manager and increment each as it's used by 1. I suppose if you wanted to add more control you could add some logic to the post that would say "If workofs_out = 0 and value in the plane manager is equal to or greater then 0 then workofs$ equals value in plane manager , else workofs$ equals 0. Which is already in there for the most part except it doesn't look for a value in the plane manager. Seems as -1 was an easier way to how to control workoffsets, but again I'm no post genius.

So in pworkofs I changed the 1st line to if workofs_out >= 0, workofs$ = mi5$ and so far I haven't seen any odd behavior or unexpected moves.

Your edit induces the same behavior mine did. Hmmm.

So after some testing, my edit resulted in some unexpected behavior. Now between every operation Mastercam/Post processor seems to think I want a mid op retract as it sends the Z home unlocks the rotary axis's, positions them (which seeing both operations are in same plane nothing would move), lock the rotary axis's and posts the next operation.

Colin, here is my pworkofs block in my post. pworkofs #Find current work offset separate from output for use in ptlchg0, etc if workofs_out >= 0, workofs$ = workofs_out if workofs$ = -1, workofs$ = 0 Thanks.

Yeah, I've already edited the Control Definition. I've used Integers and Reals for other things in the past. Thanks for the reminder though. I'm out of the office all of next week and been running machines today so I'll get back to this when I get back. Thanks Collin.

So I put workofs$ = mi5$ in my post here and it seems to work correctly for a simple drill toolpath anyways. pwcs #G54+ coordinate setting at toolchange if wcstype = 2 | wcstype > 3, [ sav_frc_wcs = force_wcs if sub_level$ > 0, force_wcs = 0 pworkofs if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof, [ workofs$ = mi5$ if workofs$ < 6, [ g_wcs = workofs$ + 54 *g_wcs ] else, Could it really be that simple or am I missing something? Thanks.

Colin, yes G54 is always my locked work offset. If I put workofs_out as -1 in my post, I will get a different offset for every plane which can be a lot. Only way to change that would be to manually put a 0 in the offset column on plane manager for every plane which because we typically only ever have 1 station on the table is a nuisance. Hence why I have 0 in my post. I want to leave the post behavior the way it is so I don't have problems with previous files among other things. I'll see about adding logic to 'pwcs' to use mi5$ and how I want to do it numbering wise. Here goes nothing.

Hey Jon, Status would probably have been a better word to use instead of value. In the post setup switch section of my post, workofs_out is set to 0 which forces the post to always use the G54 work offset to keep MC from using a different work offset number for every rotation. This works 99.99% of the time as I usually only have 1 station on the table at a time. On my current part we'll have 3 stations/operations set up on the table at the same time. With the way the post is now it will post out G54 for each station which isn't what I want. I want to do G54 for station 1, G55 for station 2 on so on. I was hoping that I could set the status of that switch using a misc integer. Say I put a -1 in mi5 the post will use whatever workoffset I've assigned that plane/view in MC plane manager or if I put a number it would use that number as my work offset. I prefer to use the former so I don't have to worry about setting mi5 in every operation. Hopefully this explains what I'm looking for better.

Is it possible to set the value of workofs_out in a post processor to use a misc or real value?

For the last 20+ years we've been using Cimco. But before that we used a program called Quicklink. We used Quicklink when our programming pc was running windows 3.x and Quicklink was a DOS program. Simple but worked. Only have 1 machine left that uses RS232, the other 20 or so use either memory cards or thumbdrive.

I'm with you, I've been using MC the last 15yrs dead ahead every day, before that I bounced in and out of programming to be close to 20yrs of using MC and I don't even remember when tip comp was introduced. Besides why have a complete page dedicated to doing the exact same thing as the little calculator that has been under the depth field in a drill cycle? Only difference is that the user has to add/subtract the amount they want to break thru manually instead of entering it in a field.. And it's not like you can leave the tip comp enabled so it's active for every drill toolpath cause sometimes you just can't drill deeper and MC can't tell the difference between selecting the back edge of a hole or the full dia. depth of a hole. All MC see's is a point to use as a depth. I never understood the intent of Tip Comp page anyways. Maybe just to old school and stuck in my ways seeing as I started on ver. 5.5.

Yeah, the material is 17-4ph condition 1025. By far not the worst stuff we machine, but not exactly aluminum. We're still looking for a more fool proof way to measure the slot, but haven't found anything yet.

I believe we have a 2mm ruby probe for this slot. Originally they were only using the probe to set the orientation of this slot on a future operation. I measure the width of the slots in 5 spots because I was trying to catch any deviation in the width of the slot so right now so I'm adjusting the tool diameter with a macro. I've never used the experience value so I'd have to look in to that some more if I'm able to use the built in slot width measuring routine. As they say, the only way to know for sure is to try it. Thanks.