Tie the workofs_out to a misc/real variable

[BBprecise]

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

[JParis]

Define value...

Just the offset number or positional info?

 

[BBprecise]

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.

[Colin Gilchrist]

1 hour ago, BBprecise said:

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

Is is possible? Yes, absolutely.

The values of misc. integers and real numbers are held in predefined variables:

mi1$, mi2$, mi3$, ... through ..., mi9$, and mi10$

mr1$, mr2$, ... through ..., mr9$, mr10$

The call to Work Offset output is done through 'pwcs'. I would add logic to the 'pwcs' Post Block to detect a value in your Misc Integer (I would use Misc Integers for this).

Is "G54" always your locked work offset value? If yes, you don't have to worry about using "-1". The default value for Misc. Integers is "0", so that would be easy to use "1" or "2" or another integer to force out G55, G56, or higher values.

[BBprecise]

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.  

[BBprecise]

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 Gilchrist]

19 hours ago, BBprecise said:

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.

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

[Colin Gilchrist]

By the way, you can use the Control Definition to edit the "displayed text" for MI5, so it tells you when you go into the operation, what that Misc. Integer is used for. (Technically, as the Post editor, you are telling the user what that control is used for. You may be both the editor and the user, but if anyone else uses the Post after you, or you do a bunch of other work on other machines, and come back to use the Post months later, having the 'label' for MI5 in the operation will help.

[BBprecise]

2 hours ago, Colin Gilchrist said:

By the way, you can use the Control Definition to edit the "displayed text" for MI5, so it tells you when you go into the operation, what that Misc. Integer is used for. (Technically, as the Post editor, you are telling the user what that control is used for. You may be both the editor and the user, but if anyone else uses the Post after you, or you do a bunch of other work on other machines, and come back to use the Post months later, having the 'label' for MI5 in the operation will help.

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.

2 hours ago, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

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.

[BBprecise]

On 11/17/2023 at 9:11 AM, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

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.

[BBprecise]

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.

[BBprecise]

On 11/17/2023 at 9:11 AM, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

Your edit induces the same behavior mine did. Hmmm.

[BBprecise]

16 hours ago, BBprecise said:

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.

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.

[Colin Gilchrist]

Glad you found the error.

Technically, I think that entire block could be deleted, and the 'call' to 'pworkofs' could be replaced with the line 'workofs_out = mi5$'.

The reason I say this is: the value of 'workofs$' variable never gets set to '-1'.

Users (post developers) used to think that "-1" meant that automatic work offset numbering is enabled which is technically true, but the variable 'workofs$' always gets assigned a value, starting from '0' and counting upwards. The variable is never stored with a value of '-1'.

The '-1' value is stored internally in the Binary NCI, and during the ASCII NCI Conversion process, the value of 'workofs$' will be assigned "the current work offset value, or if the plane changes, it will be automatically assigned the next available work offset value.

 

[BBprecise]

19 minutes ago, Colin Gilchrist said:

Glad you found the error.

Technically, I think that entire block could be deleted, and the 'call' to 'pworkofs' could be replaced with the line 'workofs_out = mi5$'.

The reason I say this is: the value of 'workofs$' variable never gets set to '-1'.

Users (post developers) used to think that "-1" meant that automatic work offset numbering is enabled which is technically true, but the variable 'workofs$' always gets assigned a value, starting from '0' and counting upwards. The variable is never stored with a value of '-1'.

The '-1' value is stored internally in the Binary NCI, and during the ASCII NCI Conversion process, the value of 'workofs$' will be assigned "the current work offset value, or if the plane changes, it will be automatically assigned the next available work offset value.

 

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.

 

[Colin Gilchrist]

1 hour ago, BBprecise said:

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.

 

-1 is absolutely fine to use as a control, if you are manually setting a value.

The 'workofs$' variable will never be set automatically to '-1'' by MP during the posting process (at runtime), when Automatic Work Offset Numbering is in effect in Mastercam.

When the value of '-1' is stored in the Binary NCI data (operation data in the Mastercam database), it is only used as a trigger by MP to load values into 'workofs$', based on "did the current Plane change from the previous plane".

Using -1 in the Misc Values, or setting '-1' to a user defined variable like 'workofs_out', is perfectly fine, and whatever makes the most sense to you, provided it works, is a great solution.

I just wanted to point out that even though the Operation in Mastercam shows '-1' when automatic work offset numbering is selected, that value gets overridden by MP during processing, where MP essentially controls the auto-incrementing.

You might be thinking to yourself, "well that's dumb... why would they do that...", but there is actually a great reason for this.

Nobody knows what you are going to select for a set of Operations, inside the Toolpaths Manager, at the time you press the "G1" button to Post. For example, you may have only selected Operations 1-3, 7, and 22-40 to Post. Or, you've got them all selected. If you are skipping Operations, MP needs to assemble the list of operations being posted first, and only then can it go through and check the stack of operations for 'plane changes'.

[BBprecise]

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.

 

[Colin Gilchrist]

I'm happy to help.

I'm with you though > I always always assign a Plane to a Work Offset Number, even if the planes are all '0' or '1', at least you know you are in control of the Work Offset value, and it won't just automagically change on you.

[gms1]

On 12/5/2023 at 8:16 AM, Colin Gilchrist said:

I'm happy to help.

I'm with you though > I always always assign a Plane to a Work Offset Number, even if the planes are all '0' or '1', at least you know you are in control of the Work Offset value, and it won't just automagically change on you.

I don't think I could do this any other way. I use offsets g54 thru g54.1p300 with up to 16 or 17 workplanes in a single program. I would never let mastercam auto assign planes because the amount of changes I make to programs hourly would shift and jockey work offsets out of order all the time.

[Colin Gilchrist]

On 1/24/2024 at 8:24 AM, gms1 said:

I don't think I could do this any other way. I use offsets g54 thru g54.1p300 with up to 16 or 17 workplanes in a single program. I would never let mastercam auto assign planes because the amount of changes I make to programs hourly would shift and jockey work offsets out of order all the time.

Exactly.

The whole "auto-increment the work offset" function was created and intended for Horizontal work. It allows you to program Front > Right > Back > Left planes, and get B0 G54, B90 G55, B180 G56, and B270 G57 > automagically. But this behavior does a terrible job at "advanced horizontal programming", where you may be cutting at B0, but on the left or right part, held on the B90 or B270 face, where you want a separate work offset, so you can make adjustments to each part/feature independently.