Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Tool list at the end of M30


Recommended Posts

Hello everyone,
  I have a machine of which it is only using MACRO TOOLINGS such as:

#111 = 0 (3'' SHM 90DEG WR)
#35 = 0 (1/2 SPOTTER)
#103 = 0 (17/32 STUB DRILL)
#104 = 0 (21/32 STUB DRILL)
#105 = 0 (1/2 FINISH EM)
#106 = 0 (1/2 SPOTTER)
#107 = 0 (5/8-11 CUT TAP)

 On the other hand, it only works and runs at the end of M30 like this....
 

M30(11,416CHARS - 11.45KB)
%

#111 = 0 (3'' SHM 90DEG WR)
#35 = 0 (1/2 SPOTTER)
#103 = 0 (17/32 STUB DRILL)
#104 = 0 (21/32 STUB DRILL)
#105 = 0 (1/2 FINISH EM)
#106 = 0 (1/2 SPOTTER)
#107 = 0 (5/8-11 CUT TAP)

 

I did my post and I would like to move it down but I couldn't, would you guys please point out my mistakes?  Thank you.


=============== Post defined as ===========
fmt "#" 4 ToolNumber

#Region pMacroTools
# --------------------------------------------------------------------------
# Macro Toolings
# --------------------------------------------------------------------------
pMacroTools    #Comment for tool
      spaces$ = 0
      progno$ = progno$ + 1
      *ToolNumber, "= 0", no_spc$, scomm_str, pstrtool, scomm_end, e$
      spaces$ = sav_spc
#EndRegion pMacroTools

pwrtt$      # Write tool table, scans entire file, null tools are negative
           if HorizontalCellSystem = 2,  # No Tool List 
            [
             if tool_table = 1, pMacroToolings #Output tooltable
            ]

================================ POST OUTPUT================================
%
O6821(0042-06826 REV05 - OP1.NC)
#111 = 0 (3'' SHM 90DEG WR) ===========================> This section should be at the bottom....
#35 = 0 (1/2 SPOTTER)
#103 = 0 (17/32 STUB DRILL)
#104 = 0 (21/32 STUB DRILL)
#105 = 0 (1/2 FINISH EM)
#106 = 0 (1/2 SPOTTER)
#107 = 0 (5/8-11 CUT TAP)

(*)
(WORK OFFSET LIST)
(G54 B0.)
(XY0= CENTER)
(Z= TOP OF PALLE)
(*)
(G55 B180.)
(XY0= CENTER)
(Z= TOP OF PALLE)
(*)
N111( 3.0000, 3'' SHM 90DEG WR, CB, .110RAD, USED TOOL,)
(6FLTS .750LOC, 2.00STO)
P6822 M98(TOOLS SUB)
G0 G17 G40 G49 G80 G90
G91 G28 Z0 M19
G28 Y0. 
G28 X0.
T#111 M6(FINISH FRONT FACE, CUT#1)
G90 G54 B0. S6000 M3
(cutting....)
G5.1 Q1
M42
G91 G28 Z0. M5
G28 Y0.
G28 X0.
M1
T#111 M6(FIRST PROGRAMMED TOOL)
M30(11,416CHARS - 11.45KB)
%

#111 = 0 (3'' SHM 90DEG WR) ===========================> This section should be here
#35 = 0 (1/2 SPOTTER)
#103 = 0 (17/32 STUB DRILL)
#104 = 0 (21/32 STUB DRILL)
#105 = 0 (1/2 FINISH EM)
#106 = 0 (1/2 SPOTTER)
#107 = 0 (5/8-11 CUT TAP)

Link to comment
Share on other sites

You put your logic to "write" the output in 'pwrtt$'. <-- That Post Block is used to output a Tool Table, where the output is automatically sandwiched between 'pheader$' and 'psof$'. That is the way the Mechanism is built.

If you want output in a different place, then instead of making "output lines" (that get called from 'pwrtt$'), you need to store each line in a String Buffer.

To get output after the 'M30', you need to add some "buffer recall logic" to the end of the 'peof$' Post Block.

  • Like 1
Link to comment
Share on other sites
19 hours ago, Colin Gilchrist said:

You put your logic to "write" the output in 'pwrtt$'. <-- That Post Block is used to output a Tool Table, where the output is automatically sandwiched between 'pheader$' and 'psof$'. That is the way the Mechanism is built.

If you want output in a different place, then instead of making "output lines" (that get called from 'pwrtt$'), you need to store each line in a String Buffer.

To get output after the 'M30', you need to add some "buffer recall logic" to the end of the 'peof$' Post Block.

Thank you for confirming what I was thinking would have to happen. Those pesky buffer files.

Link to comment
Share on other sites
15 minutes ago, C^Millman said:

Thank you for confirming what I was thinking would have to happen. Those pesky buffer files.

Lol. Yeah, a buffer is needed. It is pretty darn easy with a String Buffer though. Assemble the string, and write it to the Buffer file, using a Write counter variable.

In 'peof$', start by reading 'record 0', which tells you how many rows are in the buffer. Initialize a counter variable, and set it to '1'. In the while statement, compare the counter to the value of the 'record 0' variable, to see if there are more records to read.

 

Link to comment
Share on other sites

If  you are in 2017/2018/2019, you don't need a buffer to do this.  The new tool table (x_tooltable$) can be called from any post block and is much more efficient than the old pwrtt$ method.

Implementing x_tooltable$ in your post may take some time, but it's a much faster way to access tool table data.

  • Thanks 1
  • Like 1
Link to comment
Share on other sites
3 hours ago, jeff.D said:

If  you are in 2017/2018/2019, you don't need a buffer to do this.  The new tool table (x_tooltable$) can be called from any post block and is much more efficient than the old pwrtt$ method.

Implementing x_tooltable$ in your post may take some time, but it's a much faster way to access tool table data.

Awesome got an example of doing this?

Link to comment
Share on other sites
2 hours ago, C^Millman said:

Awesome got an example of doing this?

Yes, it's quite simple really.

First, find the initialization for tooltable$ and comment it out.  Once commented out, replace it with x_tooltable$ and initialize it to 1

 #tooltable$  : 3     #Removed, no longer needed with x_tooltable$
x_tooltable$  : 1     #

Next, find and comment out pwrtt$ and pwrttparam$.  With the enhanced tool table they are no longer needed.

#pwrtt$          #Pre-read NCI file
#      if tool_info > 1 & t$ > 0 & gcode$ <> 1003, ptooltable

#pwrttparam$     #Pre-read parameter data
#      #"pwrttparam", ~prmcode$, ~sparameter$, e$
#      if prmcode$ = 15346, comp_type = rpar(sparameter$, 1) #Cutter compensation type - 0=computer, 1=control, 2=wear, 3=reverse wear, 4=off
#      if prmcode$ = 10010, xy_stock = rpar(sparameter$, 1)  #Capture stock to leave (XY)
#      if prmcode$ = 10068, z_stock = rpar(sparameter$, 1)   #Capture stock to leave (Z)

Now we need to merge the logic from pwrtt$ and pwrttparam$ into a new post block, ptooltable$.

So, before we had the ptooltable post block that was called from pwrtt$.

#ptooltable      #Tooltable output
#      sopen_prn, *t$, sdelimiter, pstrtool, sdelimiter, *tlngno$,
#        [if comp_type > 0 & comp_type < 4, sdelimiter, *tloffno$, sdelimiter, *scomp_type, sdelimiter, *tldia$],
#        [if xy_stock <> 0 | z_stock <> 0, sdelimiter, *xy_stock, sdelimiter, *z_stock],
#        sclose_prn, e$
#      xy_stock = 0  #Reset stock to leave values
#      z_stock = 0   #Reset stock to leave values

Now we have everything in the new post block, ptooltable$ (note the dollar sign)

ONE@ : 1

s1013 : ""
fmt "TOOL DIA. - " 1   toolDiameter

ptooltable$
      if tt_count$ = ONE@,
      [
        comp_type = opinfo(15346, 0)
        xy_stock = opinfo(10010, 0)
        z_stock = opinfo(10068, 0)
        s1013 = opinfo(1013, 0)
        toolDiameter = rparsngl(s1013, 2)
        sopen_prn, *tt_tool$, sdelimiter, pstrtool, sdelimiter, *tt_tlngno$,
          [if comp_type > 0 & comp_type < 4, sdelimiter, *tt_offset$, sdelimiter, *scomp_type, sdelimiter, *toolDiameter],
          [if xy_stock <> 0 | z_stock <> 0, sdelimiter, *xy_stock, sdelimiter, *z_stock],
          sclose_prn, e$
        ]

We also have to change the pstrtool post block to use the new opinfo function. 

stoolString : ""

pstrtool
      stoolString = opinfo(10094, 0)
      if stoolString <> sblank,
      [
        stoolString = ucase(stoolString)
        stoolString
      ]

 

What that done, we can call x_tooltable$ from any post block and start tool table processing.

  • Thanks 1
Link to comment
Share on other sites
8 hours ago, jeff.D said:

Yes, it's quite simple really.

First, find the initialization for tooltable$ and comment it out.  Once commented out, replace it with x_tooltable$ and initialize it to 1


 #tooltable$  : 3     #Removed, no longer needed with x_tooltable$
x_tooltable$  : 1     #

Next, find and comment out pwrtt$ and pwrttparam$.  With the enhanced tool table they are no longer needed.


#pwrtt$          #Pre-read NCI file
#      if tool_info > 1 & t$ > 0 & gcode$ <> 1003, ptooltable

#pwrttparam$     #Pre-read parameter data
#      #"pwrttparam", ~prmcode$, ~sparameter$, e$
#      if prmcode$ = 15346, comp_type = rpar(sparameter$, 1) #Cutter compensation type - 0=computer, 1=control, 2=wear, 3=reverse wear, 4=off
#      if prmcode$ = 10010, xy_stock = rpar(sparameter$, 1)  #Capture stock to leave (XY)
#      if prmcode$ = 10068, z_stock = rpar(sparameter$, 1)   #Capture stock to leave (Z)

Now we need to merge the logic from pwrtt$ and pwrttparam$ into a new post block, ptooltable$.

So, before we had the ptooltable post block that was called from pwrtt$.


#ptooltable      #Tooltable output
#      sopen_prn, *t$, sdelimiter, pstrtool, sdelimiter, *tlngno$,
#        [if comp_type > 0 & comp_type < 4, sdelimiter, *tloffno$, sdelimiter, *scomp_type, sdelimiter, *tldia$],
#        [if xy_stock <> 0 | z_stock <> 0, sdelimiter, *xy_stock, sdelimiter, *z_stock],
#        sclose_prn, e$
#      xy_stock = 0  #Reset stock to leave values
#      z_stock = 0   #Reset stock to leave values

Now we have everything in the new post block, ptooltable$ (note the dollar sign)


ONE@ : 1

s1013 : ""
fmt "TOOL DIA. - " 1   toolDiameter

ptooltable$
      if tt_count$ = ONE@,
      [
        comp_type = opinfo(15346, 0)
        xy_stock = opinfo(10010, 0)
        z_stock = opinfo(10068, 0)
        s1013 = opinfo(1013, 0)
        toolDiameter = rparsngl(s1013, 2)
        sopen_prn, *tt_tool$, sdelimiter, pstrtool, sdelimiter, *tt_tlngno$,
          [if comp_type > 0 & comp_type < 4, sdelimiter, *tt_offset$, sdelimiter, *scomp_type, sdelimiter, *toolDiameter],
          [if xy_stock <> 0 | z_stock <> 0, sdelimiter, *xy_stock, sdelimiter, *z_stock],
          sclose_prn, e$
        ]

We also have to change the pstrtool post block to use the new opinfo function. 


stoolString : ""

pstrtool
      stoolString = opinfo(10094, 0)
      if stoolString <> sblank,
      [
        stoolString = ucase(stoolString)
        stoolString
      ]

 

What that done, we can call x_tooltable$ from any post block and start tool table processing.

Thank you I appreciate your time and effort putting that up. Not your average user so mind sharing your back story?

Link to comment
Share on other sites
On 5/6/2018 at 6:40 PM, So not a Guru said:

We have different views of "easy" :P

Here is my view of "easy". I used the "old school buffer method", mostly because that new fancy stuff isn't in the "Generic" posts yet. I'm sure that is the way going forward, but I'm guessing there are over 100,000 existing copies of MPMaster, "in the wild", that are still based on the "X-Style" processing logic.

So, here is how I would do it with a String Buffer.

First, define a String Buffer, and some variables to go with the buffer (read/write counters, size variable, and at least 1 string variable, to "write and read" from the buffer:

# --------------------------------------------------------------------------
# Buffer 6 - Tool List String Buffer
# --------------------------------------------------------------------------
b6_str : "" #String to read/write from buffer
b6_temp : "" #Extra "temp string"
rc6    : 1 #Read Counter
wc6    : 1 #Write Counter
size6  : 0 #Size variable

fbuf 6 0 256 0 1

In the "pmacrotools" Post block, I use "Dress String" to convert 'ToolNumber' into a "formatted string", make sure 'strtool$' is converted to 'uppercase', then use String Concatenation, to add the "bits of string data" together, to form the completed string.

I then "write that string" to the Buffer File, with the single 'wbuf' line of code. Since 'pwrtt$' gets called for "every tool change event", we also need to consider how we deal with "null" tool changes.

If you only want a "single entry" for clearing the data, then you need to use the "Tool Number" signing mechanism to do that. (For the first occurrence of each T# that is used in your Program, the variable 't$' will hold the decimal value of your Tool Number, signed Positive, for the 1st occurrence of each Tool! After the tool has been "used" in a Tool Change event, the  next time the Tool Number is repeated, the value of 't$' is signed negative for each subsequent occurrence tool change event.

That is why I added the '& t$ > 0' to the logic...

# --------------------------------------------------------------------------
# Tooltable Output
# --------------------------------------------------------------------------
pmacrotools    #Comment for tool
      b6_temp = drs_str(2, ToolNumber) #This "converts" the Numeric Variable 'ToolNumber' into a Formatted String!
      if strtool$ <> sblank, strtool$ = ucase(strtool$)
      b6_str = b6_temp + "= 0" + scomm_str + strtool$ + scomm_end
      b6_str = wbuf(6, wc6) #This line, will "write" each Tool String, into the buffer.
      b6_str = sblank, b6_temp = sblank #clear strings before next "pwrtt loop call"

pwrtt$      # Write tool table, scans entire file, null tools are negative
           if HorizontalCellSystem = 2,  # No Tool List 
            [
             if tool_table = 1 & t$ > 0, pmacrotools #Output tooltable
            ]
            
            

 

Then, we just need to recall the data in peof$ to get the output at the end. Easy.

peof$            #End of file for non-zero tool           
      pretract
      .
      .     (some lines omitted for clarity)
      .
      .
      "%", e$
      #Buffered Tool List Recall Logic
      if HorizontalCellSystem = 2 & tool_table = 1,
        [
        size6 = rbuf(6, 0) #Get actual number of rows
        while rc6 <= size6, #while read counter, less or equal, to "last row number"
          [
          b6_str = rbuf(6, rc6) #read each row, starting with 1. 'rc6' auto-increments!
          n$, b6_str, e$ #Output each string from buffer to NC File
          b6_str = sblank #reset the string for next loop pass
          ]
        ]

 

That was about 20 minutes worth of effort...

 

 

  • Thanks 1
  • Like 1
Link to comment
Share on other sites

Thanks Colin. This is unbelievably helpful, :respect: I haven't been attempting any work with buffers, because I wasn't quite clear on how the structure worked. This is a wonderful example for me to start diving in.

My wife will appreciate you giving me something else to keep me outta her hair for a couple of weekends :D

Link to comment
Share on other sites

To be fair Hugh, this is also about the most simple example, because it uses a String Buffer.

This type of buffer is more limited in how you deal with the data, since you are limited to reading or writing a single string at a time into, or out from, the buffer file.

When you are dealing with a "real number buffer file", each Row of data (also known as a Record), will contain multiple "columns" of numbers. This means if you define your Real Number Buffer, with "10" real number variables, then each time you read or write (from/to) the buffer, you are reading or writing all 10 of the numbers at once.

  • Like 1
Link to comment
Share on other sites
On 5/16/2018 at 12:00 AM, Colin Gilchrist said:

Here is my view of "easy". I used the "old school buffer method", mostly because that new fancy stuff isn't in the "Generic" posts yet. I'm sure that is the way going forward, but I'm guessing there are over 100,000 existing copies of MPMaster, "in the wild", that are still based on the "X-Style" processing logic.

So, here is how I would do it with a String Buffer.

First, define a String Buffer, and some variables to go with the buffer (read/write counters, size variable, and at least 1 string variable, to "write and read" from the buffer:


# --------------------------------------------------------------------------
# Buffer 6 - Tool List String Buffer
# --------------------------------------------------------------------------
b6_str : "" #String to read/write from buffer
b6_temp : "" #Extra "temp string"
rc6    : 1 #Read Counter
wc6    : 1 #Write Counter
size6  : 0 #Size variable

fbuf 6 0 256 0 1

In the "pmacrotools" Post block, I use "Dress String" to convert 'ToolNumber' into a "formatted string", make sure 'strtool$' is converted to 'uppercase', then use String Concatenation, to add the "bits of string data" together, to form the completed string.

I then "write that string" to the Buffer File, with the single 'wbuf' line of code. Since 'pwrtt$' gets called for "every tool change event", we also need to consider how we deal with "null" tool changes.

If you only want a "single entry" for clearing the data, then you need to use the "Tool Number" signing mechanism to do that. (For the first occurrence of each T# that is used in your Program, the variable 't$' will hold the decimal value of your Tool Number, signed Positive, for the 1st occurrence of each Tool! After the tool has been "used" in a Tool Change event, the  next time the Tool Number is repeated, the value of 't$' is signed negative for each subsequent occurrence tool change event.

That is why I added the '& t$ > 0' to the logic...


# --------------------------------------------------------------------------
# Tooltable Output
# --------------------------------------------------------------------------
pmacrotools    #Comment for tool
      b6_temp = drs_str(2, ToolNumber) #This "converts" the Numeric Variable 'ToolNumber' into a Formatted String!
      if strtool$ <> sblank, strtool$ = ucase(strtool$)
      b6_str = b6_temp + "= 0" + scomm_str + strtool$ + scomm_end
      b6_str = wbuf(6, wc6) #This line, will "write" each Tool String, into the buffer.
      b6_str = sblank, b6_temp = sblank #clear strings before next "pwrtt loop call"

pwrtt$      # Write tool table, scans entire file, null tools are negative
           if HorizontalCellSystem = 2,  # No Tool List 
            [
             if tool_table = 1 & t$ > 0, pmacrotools #Output tooltable
            ]
            
            

 

Then, we just need to recall the data in peof$ to get the output at the end. Easy.


peof$            #End of file for non-zero tool           
      pretract
      .
      .     (some lines omitted for clarity)
      .
      .
      "%", e$
      #Buffered Tool List Recall Logic
      if HorizontalCellSystem = 2 & tool_table = 1,
        [
        size6 = rbuf(6, 0) #Get actual number of rows
        while rc6 <= size6, #while read counter, less or equal, to "last row number"
          [
          b6_str = rbuf(6, rc6) #read each row, starting with 1. 'rc6' auto-increments!
          n$, b6_str, e$ #Output each string from buffer to NC File
          b6_str = sblank #reset the string for next loop pass
          ]
        ]

 

That was about 20 minutes worth of effort...

 

 

Thank you Colin.  I wonder how many buffer that I am allowing to have in the post?  I think I have around 9 or 10.

Link to comment
Share on other sites

10 is the max. So, you'll have to evaluate what you are using the buffers for, and decide what functionally is important to you.

Also, it depends on "where in the process" you are capturing data. For example, this action requires a String Buffer. But, we only use the String Buffer in 'pwrtt$', during the Pre-Read loop. Then, we need the data again, in 'peof$'.

Technically, you could "fill the buffer" with data in 'pwrtt$', then "write" the buffer data to a file on disk (hard drive). Then, you could "re-initialize" the buffer with an empty file, which would clear it out. Then, you can use it for something different while processing NCI data. Finally, in peof$, you 'clear' the buffer data again, and "re-load the buffer" with data from the file you wrote to disk.

However, I think the better solution is to revisit your buffer logic, to see what can be combined or eliminated.

  • Like 2
Link to comment
Share on other sites
46 minutes ago, Colin Gilchrist said:

10 is the max. So, you'll have to evaluate what you are using the buffers for, and decide what functionally is important to you.

Also, it depends on "where in the process" you are capturing data. For example, this action requires a String Buffer. But, we only use the String Buffer in 'pwrtt$', during the Pre-Read loop. Then, we need the data again, in 'peof$'.

Technically, you could "fill the buffer" with data in 'pwrtt$', then "write" the buffer data to a file on disk (hard drive). Then, you could "re-initialize" the buffer with an empty file, which would clear it out. Then, you can use it for something different while processing NCI data. Finally, in peof$, you 'clear' the buffer data again, and "re-load the buffer" with data from the file you wrote to disk.

However, I think the better solution is to revisit your buffer logic, to see what can be combined or eliminated.

Mastercam buffers still something my brain has never been fully able to wrap around. :unsure:

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...