Pallet rotate post help

[JWIII]

Hello, I'm using a horizontal mill and after a tool change my post calls the work offset before the pallet rotate which is correct, but when it rotates to another side mid tool it calls the rotate and then the offset. Because I have a rotation shift in the offset, I need it to call the offset first. Anyone know where to fix in post? Thanks

[FROZEN]

This is how I have it for the NHX.

 

Code example

T11 M06 (1/2 FLAT ENDMILL)
(MAX - Z2.3)
(MIN - Z-.4)
M08
G54.2 P0 (ROTATION CANCEL)
G54.1 P1(CENTER OF ROTATION)
G90 G55
M11 (UNLOCK)
G00 G17 B180. X-.8069 Y-9.003 S10500 M03
M10 (LOCK)

Post example

if safe_index,
            [
            "G54.2 P0 (ROTATION CANCEL)", e$
            "G54.1 P1(CENTER OF ROTATION)", e$
            [if not(index), sgabsinc, pwcs], e$
            if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
            pbld, n$, pgear, e$
            pbld, n$, *sgcode,  pfcout, pspindleout, e$
            if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
            pbld, n$, pfxout, pfyout, e$
            ]
          else,
            [
            "G54.2 P0 (ROTATION CANCEL)", e$
            "G54.1 P1(CENTER OF ROTATION)", e$
            [if not(index), sgabsinc, pwcs], e$
            if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
            pbld, n$, pgear, e$
            pbld, n$, *sgcode, pfcout, pfxout, pfyout, pspindleout, e$
            if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
            ]
          phsm1_on        #must remain before G43
          pbld, n$, "G43", *tlngno$, pfzout, scoolant, e$
          phsm2_on        #must remain after G43
          ]
        else,
          [
          if fmtrnd(prv_cabs) <> fmtrnd(cabs),
            [
            if safe_index,
              [
              "G54.2 P0 (ROTATION CANCEL)", e$
              "G54.1 P1(CENTER OF ROTATION)", e$
              [if not(index), sgabsinc, pwcs], e$
              if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
              pbld, n$,  pfcout, e$
              if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
              pbld, n$, pfxout, pfyout, e$
              ]
            else,
              [
              "G54.2 P0 (ROTATION CANCEL)", e$
              "G54.1 P1(CENTER OF ROTATION)", e$
              [if not(index), sgabsinc, pwcs],
              if lock_codes = one & not(index) & rot_on_x, pbld, n$, *sunlock, sunlockcomm, e$
              pbld, n$,  pfcout, pfxout, pfyout, e$
              if lock_codes = one & not(index) & rot_on_x & cuttype = 0, pbld, n$, *slock, slockcomm, e$
              ]
            pbld, n$, pfzout, e$
            ]
          else,
            [
            "G54.2 P0 (ROTATION CANCEL)", e$
            "G54.1 P1(CENTER OF ROTATION)", e$
            [if not(index), pwcs], e$
            pbld, n$, sgabsinc,  pfxout, pfyout, pfzout, pcout, e$
            ]
          ]
        pe_inc_calc
        ps_inc_calc
        absinc$ = sav_absinc
        ]
      if lock_codes = one & cuttype <> last_cuttype & cuttype > 0, pbld, n$, *sunlock, sunlockcomm, e$
      if cuttype = zero, ppos_cax_lin
      if lock_codes = one & cuttype <> last_cuttype & cuttype = 0 & fmtrnd(prv_cabs) = fmtrnd(cabs), pbld, n$, *slock, slockcomm, e$
      if gcode$ = one, plinout
      else, prapidout
      pcom_movea
      if retractflg = 0 & op_id$ <> last_op_id,  #output if not forced output above with the G43
        [
        if mr1$ <> 2, phsm1_on
        if mr1$ = 2 & mr2$ <> last_mr2,
         [
         phsm1_on
         pbld, n$, "G43", *tlngno$, pfzout, e$
         ]
        phsm2_on
        ]
      c_msng$ #Single tool subprogram call
      plast
      toolchng0 = zero
 

 

also I'm using dynamic offsets, which work extremely  well. 

[crazy^millman]

Frozen you have 4 to 6 offsets for the dynamic work offsets and you can make a mi_$ or mr_$ set that to have that option. Nice work on the post mod.

[Leon82]

I would look in the null tool change block.

 

You may just have to swap the string order.

[Colin Gilchrist]

Your output will either come from 'ptlchg$' or 'ptlchg0$', if your Post was based on a Generic Fanuc style Post from CNC Software. If you started with MPMaster, then it's coming from 'ptlchg_com'.

There is typically a 'Safe Index' option, for positioning the Rotary, which can be enabled by a variable in the Post, or sometimes hooked up to a Miscellaneous Integer for controlling output at the Operation level.

The Rotary Axis in any 4-Axis Post, is output by the variable 'c$'. (Address Label is a function of Variable Format Assignment, regardless of the variable name internally.)

Typically, the Post will use 'pcout' or 'pfcout', as the Post Block Call that ultimately outputs the Rotary value.

The variable 'c$' isn't used to output to the NC File though. It is for internal calculations of the rotary value. This is due to both "Modality" and because there is an Absolute/Incremental Switch that is typically set by 'mi2$'.

Since the Rotary can be output as either ABS or INC, there are different variables formatted for each output type.

The variables 'cabs', 'cinc', and 'index_out'.

There is a switch that is read typically from the Machine Definition, which tells the Post "the machine supports full rotary", or, "the machine only supports indexing to certain increments". This index increment is typically 1 degree, or sometimes 0.1 degree.

So normal rotary output will either come from 'cabs' or 'cinc', provided you are not in Index mode. (There is also a 'force_index' variable switch at the top of the Post.)

You mentioned you were running a Horizontal, so I assume you need "B" output for your rotary.

A quick way to narrow down the output variable, is to temporarily rename those Format Assignment Strings from "B", to "B1", "B2", and "B3", and then Posting a NC File with several Tool Change events, and check the code.

[nickbe10]

Another option is to enable the full retract on rotation switch in the header.

We ran all our small quick 15K - to 20K machines this way, the time cost was minimal and the safety was bullet proof.

Doesn't suit all machines.

[JWIII]

On 10/2/2020 at 6:26 PM, Colin Gilchrist said:

Your output will either come from 'ptlchg$' or 'ptlchg0$', if your Post was based on a Generic Fanuc style Post from CNC Software. If you started with MPMaster, then it's coming from 'ptlchg_com'.

There is typically a 'Safe Index' option, for positioning the Rotary, which can be enabled by a variable in the Post, or sometimes hooked up to a Miscellaneous Integer for controlling output at the Operation level.

The Rotary Axis in any 4-Axis Post, is output by the variable 'c$'. (Address Label is a function of Variable Format Assignment, regardless of the variable name internally.)

Typically, the Post will use 'pcout' or 'pfcout', as the Post Block Call that ultimately outputs the Rotary value.

The variable 'c$' isn't used to output to the NC File though. It is for internal calculations of the rotary value. This is due to both "Modality" and because there is an Absolute/Incremental Switch that is typically set by 'mi2$'.

Since the Rotary can be output as either ABS or INC, there are different variables formatted for each output type.

The variables 'cabs', 'cinc', and 'index_out'.

There is a switch that is read typically from the Machine Definition, which tells the Post "the machine supports full rotary", or, "the machine only supports indexing to certain increments". This index increment is typically 1 degree, or sometimes 0.1 degree.

So normal rotary output will either come from 'cabs' or 'cinc', provided you are not in Index mode. (There is also a 'force_index' variable switch at the top of the Post.)

You mentioned you were running a Horizontal, so I assume you need "B" output for your rotary.

A quick way to narrow down the output variable, is to temporarily rename those Format Assignment Strings from "B", to "B1", "B2", and "B3", and then Posting a NC File with several Tool Change events, and check the code.

Thanks for your help, if the pallet rotate at tool change is correct, but the rotate mid tool is not, is it still coming from ptlchg$

[nickbe10]

9 minutes ago, JWIII said:

Thanks for your help, if the pallet rotate at tool change is correct, but the rotate mid tool is not, is it still coming from ptlchg$

Typically null tool changes are handled by ptichg0$

[JWIII]

I think it's this part around line 899, but when I moved 901 to 899 to move the wcs before pallet rotate it didn't post wcs at all. Any ideas?

Thanks

[Leon82]

I believe You can use *pwcs or  to force it out

 

If you analyze the statement there it's saying if The cut position is not equal to the last position Do something. So you probably need it after that line

[crazy^millman]

5 hours ago, JWIII said:

I think it's this part around line 899, but when I moved 901 to 899 to move the wcs before pallet rotate it didn't post wcs at all. Any ideas?

Thanks

You have a bought post and if you reached out to your reseller if on post maintenance they can get the change made for you.

[JWIII]

We were a little slow to get things going and maintenance expired

[crazy^millman]

Throw up a .z2g with the post attached and I will be glad to assist you get this sorted out. Don't want to attach here PM and I will give you my email address to email it to me.

[JWIII]

21 hours ago, crazy^millman said:

Throw up a .z2g with the post attached and I will be glad to assist you get this sorted out. Don't want to attach here PM and I will give you my email address to email it to me.

Thanks for the offer, but I keep finding more and more wrong with my post. I think we're just going to have to get it fixed.

[JParis]

1 minute ago, JWIII said:

Thanks for the offer, but I keep finding more and more wrong with my post. I think we're just going to have to get it fixed.

It may not so much be wrong but more that it's not for that machine/control..but yeah, at times it's better to let the professionals handle it

[crazy^millman]

11 minutes ago, JWIII said:

Thanks for the offer, but I keep finding more and more wrong with my post. I think we're just going to have to get it fixed.

Well I run into a lot of situations where it is the Chocolate, Vanilla, Almonds and Peanuts issues than something wrong with the post. People are all different and they want certain things certain ways. 99% of the time the code out of the box will make good parts, but not be exactly like someone wants. That is preference issues and easily taken care of just need it detailed out and sample code given to make those changes.