pwcs not outputting

[So not a Guru]

I have this postblock:

penableTCP

       n$, scoolant, e$
       n$, "G05.1 Q1", e$ #Activate AICC
       tool_length_off = t$
       n$, "G90", *pwcs , e$
       n$, "G43.4 L1 P3 H", *tool_length_off, e$ #Activate TCP using selected Tool Length Offset
       tcp_enabled = 1

But when it is called in the codefile, it ignores the "*". When I run the debugger and it calls that line, it looks like this:

What happened to my asterisk??  The use_first_wcs switch is set to no.

use_frst_wcs

[Tim Johnson]

pwcs is a postblock in which is already forced. * not needed.

 

My pwcs postblocks;

 

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = two | wcstype > three,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = zero
        if sav_mr8 = 1, workofs$ = sav_workofs
        if workofs$ < 0, workofs$ = 0
        if workofs$ <> prv_workofs$ | (force_wcs & toolchng),
          [
          if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,
            [
            p_wcs = workofs$ - five
            "G54.1", *p_wcs
            ]
          ]
        force_wcs = sav_frc_wcs
        !workofs$
        ]

pwcs2            #G54+ coordinate setting at toolchange modified for [#900]
      if wcstype = two | wcstype > three,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = zero
        if sav_mr8 = 1, workofs$ = sav_workofs
        if workofs$ < 0, workofs$ = 0
        if virt_tlplnno <> prvtp | (force_wcs & toolchng) | mi6$ = 1
         | cantext$ = 54,
          [
          if virt_tlplnno = 2 & tlplnno$ < 7,
            [
            p_wcs = 900
            "G54 P[#", no_spc$, *p_wcs, no_spc$, 93
            ]
          if virt_tlplnno <> 2 | (virt_tlplnno = 2 & tlplnno$ > 6),
            [
            if sav_mi2 < 40 | sav_mi2 > 3000,
              [
              g_wcs = 59
              *g_wcs
              ]
            else,
              [
              p_wcs = maxoffset
              "G54 P", no_spc$, *p_wcs
              ]
            ]
#    ***************************************************************************
          ]
        force_wcs = sav_frc_wcs
        !workofs$
        ]

 

[So not a Guru]

Mine is different

pwcs            #G54+ coordinate setting at toolchange
      if workofs$ <> prv_workofs$ | (force_wcs & toolchng > zero),
        [
        if workofs$ < 6,
          [
          g_wcs = workofs$ + 54
          *g_wcs
          ]
        else,
          [
          p_wcs = workofs$ - five
          "G54.1", *p_wcs
          ]
        ]
      !workofs$

Either way, I still need to know why it is not outputting and why the force output asterisk is not appearing in the debug window.

[Colin Gilchrist]

It is not outputting because 'pwcs' is not a variable.

'pwcs' is a Post Block. It is a reusable "chunk" of code. Think of it as a "subprogram call".

The reason you are not getting output is because of Modality.

I know you are hot to trot on getting your posts dialed in, but you're missing some fundamentals about how the MP Language itself works. You're creating more work for yourself because you are "breaking" some of the mechanisms that are in place for tracking and controlling output to the NC File.

So, why isn't it outputting any code???

There is Boolean Logic at the start of 'pwcs' that checks two conditions:

1. is the current value of 'workofs$' different from the 'previous value' of that variable?
2. OR
3. is 'force_wcs' enabled and is the variable 'toolchng' greater than zero?

In this case, there are two distinct options that use an "or" condition. One of these must be true in order for you to get output.

In your case, neither of these conditions is true.

You have already output the Work Offset value on a prior line. <--- THIS IS MODALITY. The current value is the same as the previous value, so you will not get output. (This is "as designed"!) This is the "first" logic condition that is checked. The value is false, so we check the 2nd condition...

The 2nd Condition looks at the values of 2 different variables, using the "AND" condition. So both of these must be true, in order for the whole statement to be true.

When MP checks this 2nd condition, it finds that regardless of the value of 'force_wcs', the second part "toolchng > zero", is False.

You need to manipulate the variable values, in order to get output from that Post Block.

toolchng_flag : 0 #Initialize flag variable for saving/restoring value

penableTCP

       n$, scoolant, e$
       n$, "G05.1 Q1", e$ #Activate AICC
       force_wcs = yes$
       toolchng_flag = toolchng
       toolchng = one #Set var to force pwcs output
       n$, "G90", pwcs, e$
       toolchng = toolchng_flag #Restore value
       n$, "G43.4 L1 P3", *tlngno$, e$ #Activate TCP using selected Tool Length Offset
       tcp_enabled = 1

 

To fix the issue, simply set the variables used in the logic correctly, and voilà, you'll get the output.

In the code above, I created a new "flag" variable that I used to save the "current" value of 'toolchng'. Then I set the value of 'toolchng' (and force_wcs), and called 'pwcs'. Because those values are now set to evaluate to "true", the rest of the block will be executed. If you look farther down in 'pwcs', you can see that either 'g_wcs' or 'p_wcs' will be output, because both of these values are already "forced". You just have to get past the Boolean logic conditions in order for that code to execute.

 

 

[So not a Guru]

1 hour ago, Colin Gilchrist said:

I know you are hot to trot on getting your posts dialed in, but you're missing some fundamentals about how the MP Language itself works. You're creating more work for yourself because you are "breaking" some of the mechanisms that are in place for tracking and controlling output to the NC File.

I didn't break this one, it was already like this when I got here . I do however break a lot of things, pretty regularly. luckily I do a lot of backing up, it makes recovering from my merry paths of destruction a bit easier. This is a really screwy post that appears to have had a lot of fingers in it over the years (some of those fingers seem to be as clumsy as mine)

1 hour ago, Colin Gilchrist said:

When MP checks this 2nd condition, it finds that regardless of the value of 'force_wcs', the second part "toolchng > zero", is False.

Thanks, that makes sense and I should have caught it.

1 hour ago, Colin Gilchrist said:

In the code above, I created a new "flag" variable that I used to save the "current" value of 'toolchng'.

So if I create & initialize any variable, with the "_flag" suffix, it will save the present value of that variable?

[Colin Gilchrist]

No, using "flag" is just a personal preference on the naming convention. You must explicitly "save and restore" the values by writing your own code to do just that.

If you look at my example, I am saving the "current" value of 'toolchng' into 'toolchng_flag', then I manually set 'toolchng' to '1'.

After the call to 'pwcs', I restore the saved value.

Why do it that way? Why not just "set toolchng to 1", and be done?

The 'toolchng' variable is used in the encrypted portion of the Post, and there are several places where that variable can be set.

The reality is that we have no idea what value it holds currently, but if we just randomly "set it to 1", then that could screw up processing somewhere else. So we just need to save the current value, whatever it happens to be, then we can manipulate the value, use the variable to do something locally, and then restore the original value so that we don't "break" the processing somewhere else.

You will often see variables names that start with 'sav_'. These are simply user defined variables that the Post writer creates, and is responsible for manipulating. All "user defined" variables are manually created, so MP doesn't "know" about them and what you intend to do with them. This is different from a "predefined" variable, that is created by MP. These variables end with a dollar sign ($). MP can, and does, manipulate these all the time. Most often, by extracting parameters from the NCI file, and loading the values into the predefined variables.

[So not a Guru]

Ok, I understand. So that is why there are so many string variables that use some combinations of these "_sav_", "_brk_", "_str_" & "_prv_" . They are personal naming preferences that different coders use. Is that correct?

I can't begin to tell you how much I appreciate your help. You have a wonderful gift for putting things in such a way that others can grasp difficult concepts.