Possible to output 1st xy before 1st rotary move

[lowcountrycamo]

This post is by Postability, for an Okuma MU4000 vertical B and C trunnion mill.  Yes I will contact reseller tomorrow, but I am trying to learn posting best I can.  I took the last Basic Post class Colin held. I missed the Multi axis class I'm sorry to say.  I looked at the post and it is somewhat different from the others I have read into.  Anyway, when this mill makes a tool change, the rotary moves first. If B goes more than -90 degrees, which is the side we work most, long tools will hit the side of the trunnion as it moves to the 1st xy position.  Today I had to edit several places  to avoid crashes.  I know pfxout and pfyout outputs x and y but what outputs B and C.   Could changing this cause other problems if the order was changed?  Just so I said it, I know better than moving without understanding what I am doing.

Thanks,

Steve A

[Frank Caudillo]

In the multi-axis post I've worked with at my shop the B/C outputs are handled in the ptiltout and protout (for B and C, respectively). I haven't tried moving them around before but that might be where you want to look, as well as where those postblocks are called from other postblocks. 

[crazy^millman]

Need to be very careful. Can you do a Point toolpath or Curve 5 Axis path with the long tools to control everything and avoid a post edit? Sorry, but I put this back on programming a better process to handle this verse going in a editing a post to do something you should be able to do. Put up a sample part and what you need to accomplish if you can't get it figured out and I will be to show you what I mean to sort it out.

[So not a Guru]

1 hour ago, lowcountrycamo said:

but what outputs B and C

Look for ptilthome & prothome, for B & C homing.

For "C" look for  pcout ( or pfout for forced output) & for "B" look for paout (or pfaout)

[Colin Gilchrist]

For most of the 5X Posts, the math calculations are "binned" (encrypted), but the "output Post Lines", are typically not encrypted. I believe Dave does that with his Posts.

The methods I would use to "parse" a Post, and figure out what is going on, are pretty universal:

1. Typically, variables are at the top of the Post. These will start in the 1st Column. So, skip down to find the "Post Block" sections.
2. All "output" Post Lines will end with 'e$', in a Generic Post. Dave does something different, he ends his output lines with a "Post Block Call", to a block called 'pe'. As you can probably guess by the "naming convention" he used, the 'pe' Post Block basically looks like the code snippet below.
3. So I would search for 'pe' to get an idea of where the output is coming from.
4. Make a backup copy of the Post, BEFORE you start messing around.
5. Did I say make a BACKUP? Nope. F-That. Make 3 BACKUPS. Always be sure you can get back to where you started...
6. Start by identifying an area you want to know more about. Maybe it looks like "motion" output, or "tool change" output, or whatever. Go to the "top" of the Post Block (all "indented" code is part of the "block", until you hit a new Post Block name in the 1st Column).
7. Add a String Literal comment line to the Top and Bottom of the section of code. See 2nd code snippet below. Add a comment like "(PSOF-START)", e$ at the top of the block, and "(PSOF-END)", e$ at the end of the block of code. Then Post the code out. Look for your comment markers.
8. Now, add a "middle" comment line. That way you can start narrowing down exactly "where" inside the Post you are getting output.
9. If you want to get "fancy", add a Switch variable that can be used to turn on/off the debugging code.
10. Once you've identified "where" the output is coming from, edit the output of the block. If you need to "Break up" the output, make sure you follow the output format structure. So if there is a single output line: ( n$, sgcode, pfxout, pfyout, p_pout, p_sout, e$), make sure you keep the "form" the same, by adding the proper 'start' and 'end' lines. See 2nd snippet.

 

pe      #Post Block for Ending Post Line, use in case an "alternate" EOL character is needed.
      if machine_type = 1,
        [
        omitcrlf$ = no$
        ]
      if machine_type = 2,
        [
        eob$ = 7
        prv_eob$ = 9
        omitcrlf$ = yes$
        ]
      if machine_type = 3,
        [
        eob$ = 36
        prv_eob$ = 9
        omitcrlf$ = no$
        ]

      #EOB and PRV_EOB values are now set, and OMITCRLF is now set, output EOB characters
      e$
 

 

2nd snippet:

frc_debug   : no$  #Force Debugging strings?



psof$            #Start of file for non-zero tool number
      if frc_debug, "PSOF START", e$
      
      probe_head$
      ptravel
      pwritbuf5
      pcuttype
      toolchng = one
      if ntools$ = one,
        [
        #skip single tool outputs, stagetool must be on
        #stagetool = m_one
        !next_tool$
        ]
      tooltotal = rbuf(4,0)  #Reads total tool and null tool changes
      if toolcountn <= tooltotal, nexttool = rbuf(4,toolcountn)
      else, nexttool = first_tool$

      if tool_table = 2, ppredstck
      if tool_table = 3, pmetastck

      spaces$=0
      if output_z = yes$ & tcnt > 1,
        [
        scomm_str, "OVERALL MAX - ", *z_tmax, scomm_end, e$
        scomm_str, "OVERALL MIN - ", *z_tmin, scomm_end, e$
        ]
      spaces$=sav_spc
      if frc_debug, "PSOF MIDDLE-before smy_comm output", e$
      smy_comm, e$
      
      smy_comm = strtool$
      if frc_debug, "PSOF MIDDLE-after smy_comm output", e$
      if plane$ < 0 | opcode$ = 3 | opcode$ = 16, plane$ = 0
      pbld, n$, *sgcode, *smetric, "G40", "G80", scomm_str, no_spc$, smy_comm, no_spc$, scomm_end, e$
      pbld, n$,  *sgplane, *sgabsinc, e$
      inhibit_probe$
      sav_absinc = absinc$
      absinc$ = one
      if wcstype <= one, #Work coordinate system
        [
        pfbld, n$, sgabsinc, *sg28, "Z0.0", e$
        pfbld, n$, *sg28, "X0.0", "Y0.0", e$
        pfbld, n$, "G92", *xh$, *yh$, *zh$, e$
        ]
      else,
        [
        pbld, n$, sgabsinc, *sg28, "Z0.0", e$
        ]
      absinc$ = sav_absinc
      sav_mi9 = mi9$
      sav_workofs = workofs$
      if sav_workofs < 0, sav_workofs = 0
      ptlchg_com
      sof = 0
      if frc_debug, "PSOF END", e$

 

 

[Zoffen]

^^^^^^^^^^^^^^^^this^^^^^^^^^^^^^^^^^^^^^!!!!!

When doing some heavy post developing i did the same thing and it saved me a ton of time and agrivation figuring things out. I didn't add logic for a debug switch i would just uncomment the debug lines when i needed to figure something out.

Ex:

  #">>DEBUG: ptlchg_com-------------------------------------------------------------------------", e$
    #----Save variables 

    gcode$=0
    mr9_sav=mr9$
    mi1_sav=mi1$
    mi9_sav=mi9$
    toolpathlinkstyle=mi5$
    comp_type_sav=comp_type
    tool_op_sav=tool_op$
    result = force(ipr_type,ipr_type)
    result = force(plane$,plane$)
    plookahead_off
    pcom_moveb
    c_mmlt$ #Multiple tool subprogram call
    ptoolcomment
    #DEBUG
    #"---------------------->>>>>>>>>>>>>>>", *MCX_OPNUM, e$
    #"---------------------->>>>>>>>>>>>>>>", *LAST_MCX_OPNUM, e$
    #"---------------------->>>>>>>>>>>>>>>", *xform_op_id$, e$
    #"---------------------->>>>>>>>>>>>>>>", *last_xform_op_id, e$
    #"---------------------->>>>>>>>>>>>>>>", *op_id$, e$
    #END DEBUG

I probably should have made the variable that output  with a "~" instead of a "*" to not affect anything but it seemed to work well for what i was trying to accomplish

good luck and as colin said make 10 backups!!!!!!

[crazy^millman]

You tear off modfying one of Postability's post please make sure to send them your version so when there is an update they don't nuke all your hard work and effort making you do it all over again.

[Colin Gilchrist]

2 hours ago, Zoffen said:

^^^^^^^^^^^^^^^^this^^^^^^^^^^^^^^^^^^^^^!!!!!

When doing some heavy post developing i did the same thing and it saved me a ton of time and agrivation figuring things out. I didn't add logic for a debug switch i would just uncomment the debug lines when i needed to figure something out.

Ex:

  #">>DEBUG: ptlchg_com-------------------------------------------------------------------------", e$
    #----Save variables 

    gcode$=0
    mr9_sav=mr9$
    mi1_sav=mi1$
    mi9_sav=mi9$
    toolpathlinkstyle=mi5$
    comp_type_sav=comp_type
    tool_op_sav=tool_op$
    result = force(ipr_type,ipr_type)
    result = force(plane$,plane$)
    plookahead_off
    pcom_moveb
    c_mmlt$ #Multiple tool subprogram call
    ptoolcomment
    #DEBUG
    #"---------------------->>>>>>>>>>>>>>>", *MCX_OPNUM, e$
    #"---------------------->>>>>>>>>>>>>>>", *LAST_MCX_OPNUM, e$
    #"---------------------->>>>>>>>>>>>>>>", *xform_op_id$, e$
    #"---------------------->>>>>>>>>>>>>>>", *last_xform_op_id, e$
    #"---------------------->>>>>>>>>>>>>>>", *op_id$, e$
    #END DEBUG

I probably should have made the variable that output  with a "~" instead of a "*" to not affect anything but it seemed to work well for what i was trying to accomplish

good luck and as colin said make 10 backups!!!!!!

Good catch on using the Tilde to perform "debugging" output.

If you use the Tilde, be aware there is a Command Variable that should be initialized: bug4$.

When set to Zero or a positive integer value, all of your debugging output will be rounded, according to the Format Statement assigned to the variable. If you want to get truly "raw" variable output, set 'bug4$ : -1'. The negative one setting will tell MP to ignore the variable formatting assignments.