Post Wiki

round_opt$ initialization possible change. Note ticket# in title:

From: Technical Support Inbox Technical.Support@mastercam.com Date: Tue, Sep 13, 2022 at 2:40 PM Subject: RE: Re:[## 32491 ##] FW: Profile toolpath not posting correctPlease REF 32002 2nd submission

Hi Steve,

You summed up my understanding of these situations with this, “It's like the 0.06 radii is the perfect value to make the math fail.”

You can initialize round_opt$ to 10 in your post and that will address this one. My understanding is that we’re considering adding the same initialization to our release posts.

round_opt$ : 10 # Enforce rounding up for digits greater than 5

You can find documentation on round_opt$ here:

https://extranet.mastercam.com/CNCExtranet/Technical/Posts/Resources/mp-ref/index.htm#pages/round_opt.htm?Highlight=round_opt

Don Boire | Technical Services

# --------------------------------------------------------------------------
#Buffer 6, reorder tool table
# --------------------------------------------------------------------------
wc6           : 1       #Initial count for write buffer 6
rc6           : 1       #Initial count for read buffer 6
size6         : 0       #Buffer 6 size

string6 : ""                 #Buffer 6

fbuf 6 0 80 0 1         #Buffer 6

The “80” used to be the marker for whether the buffer was for strings. Don't ask me why, but if it was “80” each record could be a string of unlimited length. Now the “1” at the very end of the line indicates the string vs “0” for numeric The “80” is now a character limit on the string buffer! So a client just had an error as they exceeded 80 characters in their strings. Silly mastercam non backwards compatability. I switched the “80” to “150” to increase the string length, and the problem went away

1. All masters should not have generic machine def name. Change name to custom CQ Post for ….. to make less generic
2. All Masters need P+ plug in (and all other MU's at the same level)
3. Prevent next_tool$ output if tool numbers matching (force tlchg)
   1. if abs(next_tool$) = abs(t$), !next_tool$ added to toolchange block

NOTE: this has been dialed in for one client all permutations including separate file subs logic “CQM_DOOSAN_5700_4X_VMC” for “Linear Machining Tech”

# CQI 11/24/20 - MU-0068, pcoutrev duplicate call calc correction, rjj

This MU wasn't properly implemented in the Haas mills. The below reset was missing. Worth checking all other masters. CQMILL is correct already.

protretinc      #Reset the C axis revolution counter
      if frc_cinit & rot_on_x,
        [
        rev = zero
        sav_rev = zero
        last_move_rev = zero  #MU-0068 - Reset
        cabs = zero
        csav = zero
        indx_out = zero
        if index, pel, pindxcalc, pindex
        else, *cabs
        prvcabs = zero
        !csav, !cabs
        ]

Turn CQM_LUCAS_30DCS108_HMC_DYNAPATH_3X for Longwall Assc into a DynaPath conversational master post. (Ancient format)

Use CQM_HAAS_EC_4X under Northrop Grumman Corp (Baltimore - Airport) [ #57083 ] to build proper tool inspection for CQM masters.
Note pretract_insp and pretract_cool_off_insp and pcool_on_insp. This was built for X-style coolant. Test V9 style coolant.

Improvements for simultaneous 5-axis style toolpaths in Brodeur machine YCM AGG A ABOUT Z post to move into RAH plugin and Master

1. All masters should not have generic machine def name. Change name to custom CQ Post for ….. to make less generic
2. All Masters need P+ plug in (and all other MU's at the same level)

Another issue from chuck ops not being real mastercam ops :(

Example files from Sikky Mfg B601_REV01 DS30 CTR.ZIP 6-29-2021 ticket #12562

This issue happens because of outputting only 1008 op comments in chuck ops. Proposed solution is allowing all comments here, not just 1008, this will flush the earlier comments. Test carefully

Before:

pxyzcout2 #Polar conversion, Cross cut, Right/Left Face cut

    #Drill polar is toolplane drilling toward center
    #if not a coincident axis (Face cut)
    if (y_axis | (opcode$ = three & abs(cuttype) <> two)), pxyzcout0

After maybe?

pxyzcout2 #Polar conversion, Cross cut, Right/Left Face cut

    #Drill polar is toolplane drilling toward center
    #if not a coincident axis (Face cut)
    if ((y_axis & not(millcc)) | (opcode$ = three & abs(cuttype) <> two)), pxyzcout0

New info as of 7/8/2021, I found a new method that I don't think is perfect yet. This was implemented for Haas DS-30 Y lathe Post for Sikky Mfg. I have emailed before and after PST's to myself to review the new method against some of the ideas below.

If all this logic is not paired up, the readcur goes out of sequence:

      if readcur_CQP0001 > 0, readcur_CQP0001 = readcur_CQP0001 - 1      #need to pair with any ptoolend$ in pchuck$
      toolend_flg = one
      ptoolend$
      toolend_flg = zero

Adding a second ptoolend$ to a pchuck without the readcur_CQP0001 stuff takes readcur out of sequence. So my 2020 band aid always has to pair with the ptoolend$ calls in pchuck:

        if readcur_CQP0001 > 0, readcur_CQP0001 = readcur_CQP0001 - 1       

In future, change logic maybe to:

      toolend_flg = two
      ptoolend$
      toolend_flg = zero

in pchuck, and have an if toolend_flg = 2 & readcur_CQP0001 > 0,

readcur_CQP0001 = readcur_CQP0001 - 1  inside ptoolend$ top.

put the above inside ptoolend$ top and set all toolend_flg = 2 in all miscops and it should solve everything at once.

If making this mod don't forget to remove any other instances of if readcur_CQP0001 > 0, readcur_CQP0001 = readcur_CQP0001 - 1 from other spots

prapidout #Output to NC, linear movement - rapid

    pcanneddone
    if interp_flg & (abs(cuttype) = 4 | abs(cuttype) = 2) & cutpos2$ = 0,
      [
      if abs(cuttype) = 4,   #position C then XZ for approach to interpolation on the OD
        [
        pcan1, pbld, n$, psgplane, pexct, psgcode, pcout, pscool, strcantext, e$
        pbld, n$, pexct, pxout, pyout, pzout, e$
        ]
      else,                 #position C and X then Z for approach to interpolation on the face
        [
        pcan1, pbld, n$, psgplane, pexct, psgcode, pxout, pcout, pyout, pscool, strcantext, e$
        pbld, n$, pzout, e$
        ]
      ]
      

Likely need to force out a new and different warning once if pydisable is triggered for client to know axis has been switched The pchecky warning is not worded quite right for this situation where the Y is disabled but the cut still happens

# --------------------------------------------------------------------------
# Parameter information lookup tables, see pparameter
# --------------------------------------------------------------------------
fprmtbl 1 5 #Rough cut parameters
        13343 depthcc
        13580 clearcc
        10202 xstckcc
        10203 zstckcc
        10214 directcc

fprmtbl 2 4 #Finish cut parameters
        13341 ncutscc
        10101 depthcc
        10102 xstckcc
        10103 zstckcc

fprmtbl 3 5 #Groove cut parameters
        13358 stepcc
        13138 directcc
        13352 dopeckcc
        10316 depthcc
        13364 clearcc

fprmtbl 104 4 #Thread cut parameters
        10811 xmaj_thd
        10813 zstrt_thd
        10814 zend_thd
        10819 face_thd

fprmtbl 17000   7   #Table Number, Size - Machine Definition parameter table
        17391   axis_label   #Axis label - 1=X,2=Y,3=Z
        17402   rot_dir      #Rotary direction
        17408   rot_index    #Index or continuous
        17409   rot_angle    #Index step
        17410   rot_type     #Rotary type
        17101   all_cool_off #First coolant off command shuts off ALL coolant options
        17102   v9_coolant   #Use V9 coolant option

# Control Definition Parameters
fprmtbl 18000   1    #Table Number, Size
#       Param   Variable to load value into
        18171   write_ops    #Enable write NC operation information

# Toolpath Group Parameters
fprmtbl 19000   0    #Table Number, Size
#       Param   Variable to load value into

pl_retract
  ...  
  if last_tool_op = 67, pbld, n$, "G59", *sg28ref, "B0", e$

This line is output by default in the Puma and possibly the Lynx, but only applies to a sub spindle machine, and even then may not be across the board. We have no way currently to identify the # of spindles a client has inside the post, so we can't limit this to sub machines only. Best to just comment out and only add on request.

Two changes. Test broader implications and implement:

pg76$            #G76 threading
      comment$
      gcode$ = zero
      lrapid$
      sav_xa = vequ(copy_x)
      #if thdface$ = zero, copy_x = thdx2$ #CQ CALC
      #else, copy_z = thdx2$               #CQ CALC
      if thdface$ = zero, copy_x = thdx3$  #CNC CALC
      else, copy_z = thdx3$                #CNC CALC
      if thdface$ = zero, copy_z = thdz2$
      else, copy_x = thdz2$

...\\
...\\

pg76new         #G76 threading new style
      pbld, n$, *sthdgcode, *nspring$, *thdpull, *thdang, #*thdlast$, #AG- removed thdlast
        *thdfirst$, *thdfinish$, e$ #SLK added *thdfirst$, 9/4/15
      pbld, n$, *sthdgcode, pfxout, pfzout, *thddepth$, *thdfirst$,
         *thdrdlt, pffr, e$ #SLK rem *thdrdlt, 9/4/15   #ADDED thdrdlt here####

Source: Latest MPLFAN has a swiss cheese of random additions to the lathe canned cycle area that are required. Will take some work to pin down how it differs from our master and add in the additions.

Issue with last op if from a different stream affecting the 1st op's turret/spindle settings. The first op instead picks up the final ops turret/spindle settings without this change:

Issue in pwrtt$:

Before:

pwrtt$           #Buffer toolchange information, tooltable = 3 calls on 1003
      if gcode$ = 1001, psetup
      pcut_cctyp
      if opcode$=104 | opcode$=105 | opcode$=three | opcode$=16, cc_pos$ = zero
      if gcode$ <> 1001, plast_recd
      pcur_recd
      if gcode$ <> 1003, cc_pos$ = zero
      !opcode$, !tool_op$
      if gcode$ = 1003,
        [
        size1 = rbuf (one, zero)
        rc1 = one
        if rc1 < size1, preadcur_nxt
        if cc_1013$ = zero, cc_pos$ = zero
        ]
      lathtype = lturret$ + spindle_no$ * two
      pset_stream_CQP0010
      #if you want repetitive tool output, keep the abs( ) in ptooltable and remove the >= t$ from the pwrtt call to this block
      if (tool_info = 2 | tool_info = 3) & gcode$ <> 1003 & op_id$ <> last_op_id & t$ >= 0, ptooltable
      last_op_id = op_id$
      if t$ >= zero, tcnt = tcnt + one
      ptravel
      pwritbuf5

Move these 2 lines above the gcode 10003 reset of the 1st ops settings:

      lathtype = lturret$ + spindle_no$ * two
      pset_stream_CQP0010

Final result:

pwrtt$           #Buffer toolchange information, tooltable = 3 calls on 1003
      if gcode$ = 1001, psetup
      pcut_cctyp
      if opcode$=104 | opcode$=105 | opcode$=three | opcode$=16, cc_pos$ = zero
      if gcode$ <> 1001, plast_recd
      pcur_recd
      if gcode$ <> 1003, cc_pos$ = zero
      !opcode$, !tool_op$
      lathtype = lturret$ + spindle_no$ * two
      pset_stream_CQP0010
      if gcode$ = 1003,
        [
        size1 = rbuf (one, zero)
        rc1 = one
        if rc1 < size1, preadcur_nxt
        if cc_1013$ = zero, cc_pos$ = zero
        ]
      #if you want repetitive tool output, keep the abs( ) in ptooltable and remove the >= t$ from the pwrtt call to this block
      pfind_workofs_tool
      if (tool_info = 2 | tool_info = 3) & gcode$ <> 1003 & op_id$ <> last_op_id & t$ >= 0, ptooltable
      last_op_id = op_id$
      if t$ >= zero, tcnt = tcnt + one
      ptravel
      pwritbuf5

This appears to fix but more testing is needed for master.