pclamp in 5 axis

[savagkd]

Greetings all.

 

I've almost got this one dialed in. Only issue left is clamping.

 

I've started with the Generic Fanuc 5 Axis Mill Post, modified for a Mazak Variaxis i700.

 

The clamping posts good for 3+2, but in full 5 axis it posts unclamp/clamp between every line.

 

M46
M43
X-6.3018 Y-6.5409 Z11.671 C-336.117 A-76.538
Z4.471
G1 G93 Z3.671 F37.5
X-6.2812 Y-6.7398 F150.
X-6.2674 Y-6.8288 Z3.7073 C-335.999 A-76.527 F833.74
M47
M44
M46
M43
X-6.2308 Y-7.0963 Z3.8155 C-335.643 A-76.5 F278.52
M47
M44
M46
M43
X-6.2014 Y-7.3648 Z3.9225 C-335.287 A-76.482 F278.54

 

 

I think it's in plinout, but  I can't figure out the logic.

 

plinout         #Output to NC of linear movement - feed                   

 

      punclamp

 

      pcan1, pbld, n$, `sgcode, sgplane, sgabsinc, `sgfeed, pccdia,

 

        xout, yout, zout, p_out, s_out, `feed, strcantext, pscool, e$

 

      if nc_lout$ <> m_one & feed = zero, psfeederror

 

      pclamp

 

 

Or should I be looking in punclamp and pclamp?

 

punclamp        #Unclamp the rotary axis

 

      if use_clamp,

 

        [

 

        #Force both rotaries to unlock if multi-axis

 

        if cuttype <> zero & opcode$ <> three & opcode$ <> 16 & (p_lock = one | s_lock = one),

 

          [

 

          p_lock = zero, s_lock = zero

 

          pbld, n$, *s_slock, e$

 

          pbld, n$, *s_plock, e$

 

          ]

 

        else,  #Unlock the rotary axis if it is locked and moving

 

          [

 

          if p_inc, p_lock = zero

 

          if s_inc, s_lock = zero

 

          pbld, n$, s_slock, e$

 

          pbld, n$, s_plock, e$

 

          ]

 

        ]

 

 

pclamp          #Clamp the rotary axis

 

      if use_clamp & (cuttype = zero | opcode$ = three | opcode$ = 16 | tlplnno$ <> prv_tlplnno$),

 

        [

 

        if p_inc, p_lock = one

 

        if s_inc, s_lock = one

 

        pbld, n$, s_slock, e$

 

        pbld, n$, s_plock, e$

 

        ]

 

 

Any help here is greatly appreciated.

 

 

[savagkd]

Oops. Got a little ahead of myself.  There is one more issue. 

 

I need to break the rotation of the C axis if the rotation is 180.0 deg.  180 confuses the machine as to which direction to go +/-.

 

 

Colin,  I think this was discussed in Office Hours, I just can't find it.

[Colin Gilchrist]

For 'punclamp', look at the line of logic:

 

if cuttype <> zero & opcode$ <> three & opcode$ <> 16 & (p_lock = one | s_lock = one),

 

It breaks down as follows:

 

if

cuttype <> zero   (cuttype does not equal zero. cuttype zero is "toolplane" or 3+2 mode)

and

opcode$ <> three (opcode$ three is "drill toolpath")

and

opcode$ <> sixteen (opcode$ sixteen is 5X Drill)

and

(

p_lock = one     (checking the status of the 'p_lock' variable, indicates current state of rotary clamp)

or

s_lock = one      (checking the status of the 's_lock' variable, indicates current state of rotary clamp)

)

THEN

 

 

So you've got a logic condition that says, "If we aren't in these three specific modes, and one of the two rotaries (or both) are clamped, then set the Selector Variable to 'zero', and output the values based on modality.

 

It is the Modality that is forcing out the "unlock" codes.

 

Why? Because you've modified the "output" lines to "force" the unlock codes. You've got the Force output variable modifier (*) in front of the unlock codes.

 

The thing is, when all those conditions are "true" (you aren't in those three modes, and one or both rotaries are locked), you just want the post to unlock the rotaries one time.

 

We accomplish this through Modality. The string select function for Lock/Unlock strings use the exact same output string variable. The string is switched (clamp vs. unclamp), based on the value of the String Selector, which is a numeric variable.

 

When the value of the numeric variable changes, then we swap the strings in the output variable, and output the new "state" of that numeric variable. Then the next time we encounter this logic:

 

if cuttype <> zero & opcode$ <> three & opcode$ <> 16 & (p_lock = one | s_lock = one),

 

The conditions are still TRUE, but when we jump into the block, we set the "selector" variables to "zero" again, but they were already "zero" the last time they were output. So Modality takes over, and says, "is the current value different than the previous value"? If the "current" value is different, then we output the string. If the value is the same as the "previous" value, do not output.

 

So just remove the asterisk characters in front of 's_slock' and 's_plock', and you won't get redundant output of the unlock codes...

[savagkd]

Thank you Colin!
 
As always, your explanation is spot-on.
 
I'm still working on the 180 deg. rotation.  I'll check back if I can't figure it out.

[crazy^millman]

Colin would this be a good way to think about what you put up?

 

It breaks down as follows:

 

If (this is asking a question)

cuttype <> zero   (cuttype does not equal zero. cuttype zero is "toolplane" or 3+2 mode)

and (include this with the original question/condition)

opcode$ <> three (opcode$ three is "drill toolpath")

and (include this with the original question/condition)

opcode$ <> sixteen (opcode$ sixteen is 5X Drill)

and (include this with the original question/condition)

(

p_lock = one     (checking the status of the 'p_lock' variable, indicates current state of rotary clamp)

or (do either of these have what the questions/conditions are asking in or of them)

s_lock = one      (checking the status of the 's_lock' variable, indicates current state of rotary clamp)

)

THEN (now after all the questions or conditions are met we can proceed on from here to update outside conditions)

[Colin Gilchrist]

Hi Ron,

 

Yes, that's a pretty good way of breaking it down to look at it. With Boolean Logic, you are always looking to form a statement that will eventually evaluate to True/False.

 

If the result of the statement is "True", then you execute anything to the right of the "THEN" clause.

 

The "Then" clause in the MP Language is a simple comma (,).

 

With traditional MP logic statements, anything to the Right of the THEN clause gets executed, assuming the statement evaluates to True.

 

This can be confusing to some people. The other thing to keep in mind is that, as a best practice, you should only have one "action" if the result is "True".

 

Now this "action" can be to output a "multi-parameter" line of G-code, but if you want to perform "multiple actions", you should always wrap the "actions" in a User-Defined Post Block ([ ]), which starts and ends with a set of square brackets.

 

It might also help to look at the same structure, with the individual arguments to the Statement removed. Here is what that looks like, rewritten in English to make it easier to read:

 

 

 

IF <condition 1 is true> AND <condition 2 is true> AND <condition 3 is true> AND ( <condition 4 is true> OR <condition 5 is true>) THEN, ACTION.

 

The key is that there are 5 different conditions, and the first three must be true. For the 4th and 5th conditions, one of them must be true, but not both. (if both are true, that is OK too.)

 

If there is a False condition in any one of the "four" conditions (there are only 4 required "True" statements, since OR uses either True condition for the test.

 

By grouping the "OR" clause with parenthesis, it allows us to consider the truth value of either condition, and combine the results with the other three AND conditions.

 

Note that it is now possible to use Line Continuation to separate out the various "Conditions" for a logic statement. This makes a ton of sense when you start building Boolean Statements that use more than a couple conditions.

 

Take this code from 'parc' as an example:

      if (plane$ = 0 & arctype$ < five) | (plane$ = 1 & arctypeyz$ < five) |
        (plane$ = 2 & arctypexz$ < five) | full_arc_flg$ | arc_pitch$,
        [
        #Arc output for IJK
        # If you do NOT want to force out the I,J,K values,
        # remove the "*" asterisks on the *i, *j, *k 's below...
        if plane$ = zero, *iout, *jout, kout #XY plane code - G17
        if plane$ = one, iout, *jout, *kout  #YZ plane code - G19
        if plane$ = two, *iout, jout, *kout  #XZ plane code - G18
        !i$, !j$, !k$
        ]
      else,
        [
        #Arc output for R
        if abs(sweep$)<=180 | (plane$ = 0 & arctype$ = five) | (plane$ = 1 & arctypeyz$ = five) |
          (plane$ = 2 & arctypexz$ = five), result = nwadrs(srad, arcrad$)
        else, result = nwadrs(srminus, arcrad$)
        *arcrad$
        ]

Here we have an If/Else statement that is fairly complex. But like any complex thing, it is made from very simple building blocks.

 

There are actually 5 separate OR statements, separated by the OR clause (|) which is the "pipe" symbol.

 

Some of these statements are actually multiple conditions, because these statements also include the AND symbol (&).

 

If you include each separate condition in the IF statement line, there are a total of 8 different conditions being checked:

 

Condition 1 = plane$ = 0

Condition 2 = arctype$ < five

Condition 3 = plane$ = 1

Condition 4 = arctypeyz$ < five

Condition 5 = plane$ = 2

Condition 6 = arctypexz$ < five

Condition 7 = full_arc_flg$

Condition 8 = arc_pitch$

 

The first six conditions are pretty straightforward, but what about conditions 7 and 8?

 

Notice there is no "=" character in the statement itself. There is nothing to "compare" the value to. This is a bit of MP shorthand, meaning that we are checking the value of the individual variables: full_arc_flag$ and arc_pitch$.   <<<  The "statement" is "True", if the variables values are non-zero. Any "non-zero" value evaluates to "True", when included in a Boolean Statement.

 

In this second example, the use of parenthesis helps us to group conditions together.

 

Breaking it down into English, we have a more complex statement:

 

IF

(<Condition 1 AND Condition 2 are TRUE>) OR

(<Condition 3 AND Condition 4 are TRUE>) OR

(<Condition 5 and Condition 6 are TRUE>) OR

<Condition 7 is TRUE> OR

<Condition 8 is TRUE>

THEN >>> Perform ACTION

 

 

Now, something to note is that by using the OR statement, only a single one of those 5 different conditions needs to be TRUE, for the whole statement to evaluate TRUE. But, look at the first 3 different conditions. Because of the AND statement, both of the conditions must be True, for the statement to evaluate True.

 

For the last conditions (7 and 8), only a single condition must be True, for the statement to evaluate True.

 

So, assume that neither of the 5 different clauses evaluate to True. When that happens, then the "ELSE" clause comes into play. If all 5 of those conditions evaluate to FALSE, then the "ELSE" clause comes into play. So we will always execute the ELSE clause, if none of the 5 conditions evaluates to TRUE.

 

In the ELSE clause, there is another "nested" IF condition below the ELSE. So even though "ELSE" always executes when the IF condition evaluates FALSE, the nested IF statement below only allows output if one of the conditions is TRUE.

 

As a final piece of info, we can take these "multi-condition" statements, and use line continuation to break them up and make them more readable. This logic is the exact same as above functionally, but a little bit more readable:

                                             #IF THESE CONDITIONS ARE TRUE:
if         (plane$ = 0 & arctype$ < five) |  #Plane zero and not radius mode
         (plane$ = 1 & arctypeyz$ < five) |  #Plane one and not radius mode
         (plane$ = 2 & arctypexz$ < five) |  #Plane two and not radius mode
                            full_arc_flg$ |  #Cutting a Full Arc
                              arc_pitch$,    #Cutting a Helix
                                             #THEN WE DO THE FOLLOWING:L
        [
        #Arc output for IJK
        # If you do NOT want to force out the I,J,K values,
        # remove the "*" asterisks on the *i, *j, *k 's below...
        if plane$ = zero, *iout, *jout, kout #XY plane code - G17
        if plane$ = one, iout, *jout, *kout  #YZ plane code - G19
        if plane$ = two, *iout, jout, *kout  #XZ plane code - G18
        !i$, !j$, !k$
        ]
      else,
        [
        #Arc output for R
        if abs(sweep$)<=180 | (plane$ = 0 & arctype$ = five) | (plane$ = 1 & arctypeyz$ = five) |
          (plane$ = 2 & arctypexz$ = five), result = nwadrs(srad, arcrad$)
        else, result = nwadrs(srminus, arcrad$)
        *arcrad$
        ]

[crazy^millman]

Thanks Colin and know it may not be willing you certain friends sharing all that you do, but it is appreciated. :secret:

 

If I could ever really grasp Buffers then I would feel better about my post abilities.

[savagkd]

+1000 on the appreciation Ron!

 

I hope some day to be able to pay it foreword.

[Colin Gilchrist]

Thanks Colin and know it may not be willing you certain friends sharing all that you do, but it is appreciated. :secret:

 

If I could ever really grasp Buffers then I would feel better about my post abilities.

 

Did you catch the last thread on here where someone was asking for Buffer help?

 

Buffers aren't necessarily "easy", but once you learn the "structure", it isn't so bad.

 

What part is giving you issues? Understanding how to read/write? Or indexing? (< how to enter into buffer)

[crazy^millman]

Did you catch the last thread on here where someone was asking for Buffer help?

 

Buffers aren't necessarily "easy", but once you learn the "structure", it isn't so bad.

 

What part is giving you issues? Understanding how to read/write? Or indexing? (< how to enter into buffer)

 

Yes that thread along with this one and others have been copied and put into my Emastercam log file.

 

Well it all goes back to my need to use them for SYNC codes. I have wanted to develop a process using MP and mr triggers that will allow the programmer to pick the sync code number they want and have it post it out, but then track what is being used and update if needed or post out the next number in the logical sequence. When doing Triple Turret Work I have seen some good stuff, but nothing exact from Mastercam. Using the mr triggers I really think someone could dial something in that goes to the machine exactly like you need and be done. Most times it is very close, but still requires a little tweaking at the machine.

 

The other one I could never get working was Lathe tools increment the Digits correctly in the Tool List if the tool was called several times, but with different Diameter offsets.

 

Everything else I have ever thought you would need them for has pretty much been done by someone and works well so need need to reinvent the wheel.

 

Been trying to get my hands on the Machine Sim documentation to tie a post to it, but no luck so far.

 

We have great companies that provide what we need, but I am always trying to learn what I don't know. One day I will bit the bullet and learn VB, but until then will just work with those that know what they are doing.

[savagkd]

 

I need to break the rotation of the C axis if the rotation is 180.0 deg.  180 confuses the machine as to which direction to go +/-.

 

I finally got back to the 180 deg. rotation issue above.  Here is my solution.  I'm sure there are better ways, so please feel free to chime in.

int_p_out    : 0

fmt     2  int_p_out  #Note format

ppos_cax_lin    #Position the rotary axis before move - rapid
      if p_inc | s_inc,
        [
        sav_gcode = gcode$
        gcode$ = zero
        punclamp
          [
          if (p_inc - prv_p_inc) = 180, int_p_out = (p_out - 90),
          pbld, n$, sgcode, int_p_out, e$
          ]
          [
          if (p_inc - prv_p_inc) = -180, int_p_out = (p_out + 90),
          pbld, n$, sgcode, int_p_out, e$
          ]  
        pbld, n$, sgcode, p_out, s_out, e$
        pclamp
        !p_abs, !s_abs
        ps_cinc_calc
        gcode$ = sav_gcode
        ]

Thanks to all on this forum!