Z retract in ptoolend$

[So not a Guru]

In one of our mill posts the mr3 is set to "Full retract after operation", but it retracts at every pass of an operation. As an example, if I have a pocket with depths set, it will fully retract after each depth pass.

Is there a predefined variable for multiple passes? I found pass$, but it is only for wire.

[Guest]

1 hour ago, So not a Guru said:

In one of our mill posts the mr3 is set to "Full retract after operation", but it retracts at every pass of an operation. As an example, if I have a pocket with depths set, it will fully retract after each depth pass.

Is there a predefined variable for multiple passes? I found pass$, but it is only for wire.

Have you tried going into this section, there is a section you could break  into for the actual toolchange

ptlchg1002$

Quote

ptlchg1002$      #Call at actual toolchange, end last path here                        
      tseqno = t$
      if op_id$ <> prv_op_id$, pset_mach   #Set rotary switches by reading machine def parameters
      if cuttype <> one, sav_rev = rev #Axis Sub does not update to rev
      pspindle
      whatline$ = four #Required for vector toolpaths
      if gcode$ = 1000,
        [
        #Null toolchange
        ]
      else,
        [
        #Toolchange and Start of file
        if gcode$ = 1002,
          [
          #Actual toolchange
          pretract
          ]
        if stagetool = one, prv_next_tool$ = m_one
        prv_xia = vequ(xh$)
        prv_feed = c9k
        ]
      !op_id$
      !opnumber

 

[So not a Guru]

Thanks John, I don't have that postblock in this post, but I think I can add it & direct my mr3 to use it.

[So not a Guru]

22 minutes ago, So not a Guru said:

Thanks John, I don't have that postblock in this post, but I think I can add it & direct my mr3 to use it.

Apparently that postblock is in the encrypted psb file.

So, that wont work.

[Guest]

Purchased post, go to the writer

Easiest and then they have your updates on file as well

[So not a Guru]

12 minutes ago, JParis said:

Purchased post, go to the writer

Easiest and then they have your updates on file as well

Not in this case, the post was provided by Onsrud with the machine & they don't have a clue about the psb file, I've asked.

[Guest]

Well, wherever your mr3$ is being output from this code with some minor mods would still be usable to set a condition for output

 

if gcode$ = 1000,
        [
        #Null toolchange
        ]
      else,
        [
        #Toolchange and Start of file
        if gcode$ = 1002,
          [
          #Actual toolchange
          pretract
          ]

 

Pretract would be my guess for where you would need to set the check...but without knowing your post, that is only a guess

[So not a Guru]

2 hours ago, JParis said:

Well, wherever your mr3$ is being output from this code with some minor mods would still be usable to set a condition for output

 

if gcode$ = 1000,
        [
        #Null toolchange
        ]
      else,
        [
        #Toolchange and Start of file
        if gcode$ = 1002,
          [
          #Actual toolchange
          pretract
          ]

 

Pretract would be my guess for where you would need to set the check...but without knowing your post, that is only a guess

John, I'm confused (kind of a regular state for me). I would have thought this wou ld have been op_id$ = 1000, not gcode$ = 1000

[So not a Guru]

This is my reference return postblock:

prefreturn      #Refernce return 

      if tcp_enabled = 1,
        [
         pdisableTCP
        ]
         n$, "G91 G28 Z0.", e$
         n$, "G91 G28 C0. A0.", e$
         n$, "G90", pwcs, e$
	 if nextop$ = 1003,
	 	[
		 pdisableTCP
		 ]
     else,
	 	[
		penableTCP

	
I have tried 
    if tcp_enabled = 1 & gcode$ = 0

I've also tried it with gcode$ = 1000; and op_id$ = 0; and op_id$ = 1000

 

But, I'm still getting the code output at every pass, instead of at the end of the operation.

[Tim Johnson]

Try this,

prefreturn      #Refernce return

      if tcp_enabled = 1,
        [
         pdisableTCP
        ]
      if gcode# = 1002, #<<<<<<<<<<<<
        [                            #<<<<<<<<<<<<
        n$, "G91 G28 Z0.", e$
        n$, "G91 G28 C0. A0.", e$
        n$, "G90", pwcs, e$
        ]                          #<<<<<<<<<<<<
  if nextop$ = 1003,
   [
   pdisableTCP
   ]
     else,
   [
  penableTCP

If that doesn't work, try replacing gcode$ with nextop$.

 I don't know where prefreturn is being called.

[Tim Johnson]

Do a search for prefreturn in your post. If it shows up you will know where it's being called from.

[Colin Gilchrist]

Zeke,

Even though this is a purchased post, there is a good chance it was originally based on the V9 version of the Generic Fanuc 5X Mill Post.

It does sound like there has been some modifications done to the Misc Values though, as "mi7$" and "mi8$" usually control the "retract" options. You do have a few things that are now quite correct in how you are approaching this however, so hopefully some of this information will help you understand how the MP 5X Posts are processing the NCI data a little better.

1. The variable 'op_id$' is an internal variable that is held by Mastercam for each Operation in the Operations Manager. It is not necessarily sequential, or designed to be output in numeric order. It also usually will not be equal to the Operation Number in the Ops Manager. It's sole purpose is to designate which collection of "paths" belong to the same "Operation" in the Ops Manager.
2. Even though the 'op_id$' number doesn't necessarily match the "current Operation" being processed, it can be used to "see" if you are still processing "the same op", or "a new op". We do this "typically" in 'ptlchg1002$', but as you've noticed, this block is inside the PSB section of the post. Still, if you look at the logic that JP posted up, you can see a good example of "how we test to see if the OP has changed: if op_id$ <> prv_op_id$, pset_mach   #Set rotary switches by reading machine def parameters. This logic tests the value of 'op_id$', and compares it to the previous value of 'op_id$'. If the values are the same, we are still processing the same Operation. If the values are different, then the current value of 'op_id$' does not equal the previous value of 'op_id$', and we are now processing a "new" operation.
3. To "test/prove" this for yourself, select all the Operations in the Ops Manager, then hold down SHIFT + CTRL, and Right-click on the Operations. You should see a few new options in your Right-Click Menu. Choose "No" when asked if you want to display "dead sections". Look at the code that comes up in the Editor. This is "raw" binary NCI Data, before it is converted to ASCII. (Actually, this is more like "hybrid" data, since the "binary" NCI is literally zeros and ones, and this is still ASCII displayed data.) Search for 'op_idn'. This is the internal 'op_id$' value for each operation.
4. So, why all the confusion in the first place? When you create an Operation in Mastercam with either 'Depth Cuts' or 'Multi-passes' enabled, Mastercam will output a Null Tool Change (NCI Gcode = 1000) for each of the passes or depth cuts. That is right. For each pass, we process a Null Tool Change event.
5. Remember that the most consistent part of Post Processing is the Method that is used by MP to process the NCI data. NCI data is always processed two lines at a time. The first line in the NCI sets the value of 'gcode$'. So yes, every time you process a Null Tool Change event, the value of 'gcode$' will be 1000. The value of 'gcode$' is always either 1000, 1001, or 1002, at a Tool Change Event. The only other code for a "start of Op" event is '1003', which is the End of File NCI Gcode.
6. All 'NCI G-code' values call a pre-defined post-block. This is the Entry Post Block, and is the location inside the PST Script where MP.DLL will "jump to", to start the processing.
7. Even though there is an "Entry" Post Block, for each 2-line set of NCI data, the post will still also call "Preparatory" Post Blocks, before the Entry Post Block is called. This is super important, because we can override processing and variable values, if we know the calling order of the Post Block Calls.

Are you 100% sure that the value of 'mr3$' is what is causing your Retracts? What is the value of 'mi7$' and 'mi8$'?

Are you 100% sure that the "retracts" are "post created"? Have you looked at the NCI data to see if there are "Retract moves" in the NCI data?

When you look at the Generic Fanuc 5X Mill Post, here is the comment for 'mi8$':

#Toolchange retracts:
# Mi8 is used to control retracts at tool changes and null toolchanges.
# Mi8 for tool changes applies to the approach to the part to the retract
# from the part at the next toolchange (unless changed in a null tool
# change).  Null toolchange control at a null toolchange uses the current
# setting and previous setting of mi8.  Through a null toolchange, the
# setting of mi8 at the retract applies to the approach.

For 'mi8$', I suspect you have a value of '1', or '3', or '4', or any negative value. Any of those values will cause a retract, that is generate by the "approach/retract" routine inside the PSB portion of the post. Basically, use '2' or '0' if you want to shut off the Retract behavior!

[So not a Guru]

5 hours ago, Colin Gilchrist said:

1. To "test/prove" this for yourself, select all the Operations in the Ops Manager, then hold down SHIFT + CTRL, and Right-click on the Operations. You should see a few new options in your Right-Click Menu. Choose "No" when asked if you want to display "dead sections". Look at the code that comes up in the Editor. This is "raw" binary NCI Data, before it is converted to ASCII. (Actually, this is more like "hybrid" data, since the "binary" NCI is literally zeros and ones, and this is still ASCII displayed data.) Search for 'op_idn'. This is the internal 'op_id$' value for each operation.

Are you 100% sure that the value of 'mr3$' is what is causing your Retracts? What is the value of 'mi7$' and 'mi8$'?

Are you 100% sure that the "retracts" are "post created"? Have you looked at the NCI data to see if there are "Retract moves" in the NCI data?

 

Colin, that SHIFT + CTRL right-click info is awesome!!

    -1 2301774 OP72  M  G-2       SOS - start of nci section, alive: Y, op_idn: 72, opcode: 3
    0 2301816 OP72  M  G-4       START CUT - start of cut marker
    1 2301874 OP72  M  G-6       START PASS - start of pass marker
    2 2301932 OP72  M  G1011     2. 0. 1. 0. 0. 0. 0. 0. 0. 0.
    3 2302038 OP72  M  G1012     0 0 0 0 0 1 1 2 2 0

It is definitely the mr3$ that is causing the retracts, I'm calling my prefreturn postblock from the ptoolend$ postblock.

ptoolend$        #End of tool path, before reading new tool data               
      #Determine if cancelling mapping mode

      if top_map,
        [
        if tlplnno$ <> end_tlplnno$ | workofs$ <> end_workofs$ | end_rot_type$
          | not(end_opcode$ <= 16 | end_opcode$ = 19),
          map_mode = zero
        ]

      if end_gcode$ = 1000, #Null toolchange
        [
        toolchng = m_one
        #Filter retract if toolplane is the same toolplane path
        if tlplnno$ = end_tlplnno$ & (end_opcode$ <= 16 | end_opcode$ = 19),
          tlch_ret_app = m_one
        pretract_mov
        pg69
        ]
	  if mr3$ = 1,
	  	[		
		prefreturn
		]

 

Interestingly, although this post (that is definitely created from the Generic Fanuc 5X Mill Post) has the mi7$ & mi8$ setup basically the same as the original (tlch_ret_app = abs (mr8$)), changing the value in mr8$ doesn't seem to change the nc file in any way (I did try commenting out the "tlch_ret_app =m_one" line).

On a side note, I can't find anything in the NCI reference about the "G-2" thru "G-7" G-codes. Is there somewhere else in the documentation that covers these?

Thanks for the info, I'll keep pluggin' along.

 

[So not a Guru]

15 hours ago, Tim Johnson said:

Try this,

prefreturn      #Refernce return

      if tcp_enabled = 1,
        [
         pdisableTCP
        ]
      if gcode# = 1002, #<<<<<<<<<<<<
        [                            #<<<<<<<<<<<<
        n$, "G91 G28 Z0.", e$
        n$, "G91 G28 C0. A0.", e$
        n$, "G90", pwcs, e$
        ]                          #<<<<<<<<<<<<
  if nextop$ = 1003,
   [
   pdisableTCP
   ]
     else,
   [
  penableTCP

If that doesn't work, try replacing gcode$ with nextop$.

 I don't know where prefreturn is being called.

I tried all of the combinations of this I could think of, but no joy. Most likely due to the gcode$ = 1000 restriction that Colin pointed out.

 

[Tim Johnson]

Did you search for the  prefreturn call in your post?

 

The way I control NCI 1000 and 1002 is thru ptoolend$

 

ptoolend$        #End of tool path, before reading new tool data
      !speed, !spdir2
#      if mi8$ = 1, n$, "G69", e$ #moved to 1002 section 08-22-2008 (809-965)
      if nextop$ = 1000,
        [
        prvtpsub = virt_tlplnno
        ]
      if nextop$ = 1002,
        [
        cantext_54 = 0
        cantext_55 = 0
#     ****** moved from probing cycle for multiple offsets***2011-08-20*********
        prvprb_x = 0
        prvprb_y = 0
        prvprb_z = 0
        prvprb_b = 0
#     **************************************************************************
        prvtpsub = 0
        plane$ = 0
        if sav_mi8 = 1, n$, "G69", e$ #moved from above 08-22-2008 (809-965)
        n$, sgplane, e$
        if machine <> 60, phsm_off
        prv_tloffno$ = c9k
        sav_mac_tloffno = 0
        sav_mi6 = 0
        sav_mi8 = 0
        if s_popen_flg = 1,
          [
          s_pclos, e$
          s_popen_flg = 0
          ]
        psub_end_st
        subout$ = 0 #main NC program

#        if sav_mi2 = 3112 | sav_mi2 = 3612 | sav_mi2 = 3712, "#539=#540", e$

        if sav_cantext = 51 & sav_mi2 = 37, "#539=#540", e$
        if vari_540_flg = 1,
          [
          "#540=-9999", e$
          vari_540_flg = 0
          ]
        tooldiawarn = 0
        t$ = c9k
        if (machine = 60 & prvtool = 59) | (machine = 80 | machine = 480
         | machine = 800 & prvtool = 4),sys43_Bax_cl = 1
        pcoolantoff
        if sav_mi2 > 41 & sav_mi2 <= 44, "#181=-9999", e$
        ]

 

 

[So not a Guru]

11 minutes ago, Tim Johnson said:

Did you search for the  prefreturn call in your post?

 

The way I control NCI 1000 and 1002 is thru ptoolend$

 

ptoolend$        #End of tool path, before reading new tool data
      !speed, !spdir2
#      if mi8$ = 1, n$, "G69", e$ #moved to 1002 section 08-22-2008 (809-965)
      if nextop$ = 1000,
        [
        prvtpsub = virt_tlplnno
        ]
      if nextop$ = 1002,
        [
        cantext_54 = 0
        cantext_55 = 0
#     ****** moved from probing cycle for multiple offsets***2011-08-20*********
        prvprb_x = 0
        prvprb_y = 0
        prvprb_z = 0
        prvprb_b = 0
#     **************************************************************************
        prvtpsub = 0
        plane$ = 0
        if sav_mi8 = 1, n$, "G69", e$ #moved from above 08-22-2008 (809-965)
        n$, sgplane, e$
        if machine <> 60, phsm_off
        prv_tloffno$ = c9k
        sav_mac_tloffno = 0
        sav_mi6 = 0
        sav_mi8 = 0
        if s_popen_flg = 1,
          [
          s_pclos, e$
          s_popen_flg = 0
          ]
        psub_end_st
        subout$ = 0 #main NC program

#        if sav_mi2 = 3112 | sav_mi2 = 3612 | sav_mi2 = 3712, "#539=#540", e$

        if sav_cantext = 51 & sav_mi2 = 37, "#539=#540", e$
        if vari_540_flg = 1,
          [
          "#540=-9999", e$
          vari_540_flg = 0
          ]
        tooldiawarn = 0
        t$ = c9k
        if (machine = 60 & prvtool = 59) | (machine = 80 | machine = 480
         | machine = 800 & prvtool = 4),sys43_Bax_cl = 1
        pcoolantoff
        if sav_mi2 > 41 & sav_mi2 <= 44, "#181=-9999", e$
        ]

 

 

Yes, I am calling prefreturn from my ptoolend$ postblock as well.

Thanks, I was able to get this to work by adding "& nextop = 1002" to the prefretract call in my ptoolend$ postblock.

ptoolend$        #End of tool path, before reading new tool data               
      #Determine if cancelling mapping mode

      if top_map,
        [
        if tlplnno$ <> end_tlplnno$ | workofs$ <> end_workofs$ | end_rot_type$
          | not(end_opcode$ <= 16 | end_opcode$ = 19),
          map_mode = zero
        ]

      if end_gcode$ = 1000, #Null toolchange
        [
        toolchng = m_one
        #Filter retract if toolplane is the same toolplane path
        if tlplnno$ = end_tlplnno$ & (end_opcode$ <= 16 | end_opcode$ = 19),
          tlch_ret_app = m_one
        pretract_mov
        pg69
        ]
	  if mr3$ = 1 & nextop$ = 1002,
	  	[		
		prefreturn
		]
      else,
        n$, " ", e$

 

I appreciate the help.

[Tim Johnson]

No problem...

[So not a Guru]

Well, it seems I haven't got it completely working right, but I'm on a better track.

[Tim Johnson]

Is the "else" statement for the "if mr3$ = 1 & nextop$ = 1002" statement

or is it for one of the other two?

[So not a Guru]

14 minutes ago, Tim Johnson said:

Is the "else" statement for the "if mr3$ = 1 & nextop$ = 1002" statement

or is it for one of the other two?

That's what I ended up having to change to get it completely working correctly. I had to change that to another "if" statement.  It now is this:

ptoolend$        #End of tool path, before reading new tool data               
      #Determine if cancelling mapping mode

      if top_map,
        [
        if tlplnno$ <> end_tlplnno$ | workofs$ <> end_workofs$ | end_rot_type$
          | not(end_opcode$ <= 16 | end_opcode$ = 19),
          map_mode = zero
        ]

      if end_gcode$ = 1000, #Null toolchange
        [
        toolchng = m_one
        #Filter retract if toolplane is the same toolplane path
        if tlplnno$ = end_tlplnno$ & (end_opcode$ <= 16 | end_opcode$ = 19),
          tlch_ret_app = m_one
        pretract_mov
        pg69
        ]
	  if mr3$ = 1 & nextop$ = 1002,
	  	[		
		prefreturn
		]
	  if mr3$ = 0 & nextop$ = 1002,
	  	[		
		pretract
		]