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:

How the buffer knows.


Recommended Posts

This is a pretty advanced question. I think for the most part I have a basic understanding of how buffers work. I have read the MP ref guide on this a few times now and I think I grasp the essentials. Can someone check my facts? To set it up I'll define a buffer.

 

fbuf 1 0 5 1

 

So we have buffer number one, don't keep, record count of five and initialize the buffer.

The 5 is the coulombs, not the number of lines right? So if in my buffer i have;

 

01 02 03 04 05

06 07 08 09 10

11 12 13 14 15

 

and do a string_1 = rbuf(1, 2) I should get a return of

 

"06 07 08 09 10"

 

right?

 

now let's say that earlier in the post I defined an implied array of;

 

b1_1    :   0

b1_2    :   0

b1_3    :   0

b1_4    :   0

b1_5    :   0

 

Now I want to get b1_1 to equal line one coulomb one, b1_2 to be line one coulomb two and 3,4 & 5 to follow suit. So would I just run;

b1_1 = rbuf(1,1) and then auto-magically the MP fills in 2-5? So if I read b1_3 i would get a return of 03. Okay, assuming that is all okay lets say I want to write to a line. b1_1 = 06 and the rest increment one till you get to b1_5 = 10. So then I run b1_1 = wbuf(1, 4) and my array in my buffer would be the same as line 2 that starts with 06. Does that all sound right?

 

Also is this a typo in the MP Ref? It's the only part that really stumps me. If it's not can you explain why?

#MP Post Processor Reference Guide (Vol. 2) pg. 24

fmt 4 b1_y # assign format statement to variable b1_y
b1_x : 0 # initialize three consecutive variables
b1_y : 0
b1_z : 0
rc2 : 1 # read counter for buffer 2
  
            #ahaslam edit# shouldn't this say fourth, because b1_x was first right? also added # to make the lines the same color

#In this case, if you use b1_x in the rbuf or wbuf function, the third variable in the list will be rc2 because MP will have already declared the b1_y variable prior to the b1_x variable through the fmt function.

Okay, that's all. Thanks guys (and girls, are there any girls on this forum? I have only ever known one female machinist... she was crazy)

Link to comment
Share on other sites

The place I think you are getting screwed up is that there are really two types of Buffers. There are String Buffers, and Numeric Buffers.

 

Since X came out, there is now an additional parameter on the 'fbuf' definition line, that indicates if the buffer is a String buffer or a Real number buffer.

 

fbuf 1 0 5 1 0    <-- 5th parameter = zero, means it is a real number buffer.

 

fbuf 1 0 5 1 1    <-- 5th parameter = one, then it is a String buffer.

 

MP doesn't care how many Columns you have in a Real Number buffer, but, each function in MP can only utilize a single variable in the function call. That means when you Read and Write from/to a buffer, you must have set all of your variable values before you write to the buffer.

 

So the variable in the 'rbuf' or 'wbuf' function is always the "first" variable in the list of ordered variables.

 

This means you need to set all of your variables, before you write to the buffer file.

#you start by initializing the variables:

b1_1    :   0
b1_2    :   0
b1_3    :   0
b1_4    :   0
b1_5    :   0
counter :   1 #Initialize to '1' so we start with the first record in the list

#Then you have to call them inside a post block. Here I do it in 'pwrtt$'
pwrtt$

      b1_1    =   t$
      b1_2    :   cc_pos$
      b1_3    :   tlngno$
      b1_4    :   tloffno$
      b1_5    :   tldia$
 
      #OK, so we've set all five values, now we write to the buffer

      b1_1 = rbuf(1, counter)

 

If you look above, this many also answer your question about the MP Ref Guide with the 'rc2'. In their example, 'rc2' is a separate variable, it is not part of the buffer definition!

 

Whenever you read from, or write to, a buffer file, the 2nd variable in the 'rbuf' or 'wbuf' function call is a counter type variable. It is known as this type, because the value of the variable is automatically indexed every time it is used in the function call.

 

So in the code above, we started by setting the variable named "counter" to '1' when we initialized the variable. That means the first time it is called in the 'wbuf' function, we write to record (line) number 1. Then, as soon as the function returns (we continue on in the post block), the counter variable is incremented to '2'.

 

Ok, so 'pwrtt$' is going to be called for the Start of File, and every "Tool Change" and "Null Tool Change" event. But, something magic happens during the pre-read loop. (Ok, its not really magic, it happens by design.) When MP reads the tool change, it looks at the tool number being used. The first time any tool number is called, MP signs the tool number positive. Then, as it goes through the NCI file, any additional tool changes that use the same tool number get signed negative. This neat trick allows the post writer to write some "default" logic that says, if the tool number is positive, then call 'ptooltable'. If the tool number is negative, then ignore it. This ensures you don't get duplicate entries in your Tool Table.

 

Ok, so on the next Tool Change in your program, the 'pwrtt$' gets called again. Now usually, when we are "writing" values to the buffer, every variable in our Implied Array should be set to the value of another variable. Why? Because we are trying to capture these values from the NCI file, and write them to the buffer file, so that we can "look ahead", or "look behind", and perform other "data sorting operations".

 

So at the next tool change:

pwrtt$

      b1_1    =   t$
      b1_2    :   cc_pos$
      b1_3    :   tlngno$
      b1_4    :   tloffno$
      b1_5    :   tldia$
 
      #OK, so we've set all five values (again), now we write to the buffer

      b1_1 = rbuf(1, counter)

At this point, we've got two Rows in the buffer file:

1  1  1  41  0.5
3  3  3  43  0.1875

(nothing says we have to use "T2" for the second tool. It could be "T3", like in this example.)

 

We should also make sure that we have another variable that is the "read" counter. Best practice is actually to make sure you always define two separate "arrays" of variables. One that you use to write, and the other you use to read.

 

So now, let's say in 'psof$' and 'ptlchg$' we can write logic to read from the buffer file:

#Above in our post, we've also defined some "read" variables

b1_1r  : 0
b1_2r  : 0
b1_3r  : 0
b1_4r  : 0
b1_5r  : 0
rc1    : 2   #Set read counter to '2', so that we read the "next" tool change
size1  : 0   #Size variable


psof$    #Start of file for non-zero tool

      size1 = rbuf(1, 0) #Read record "0" to get number of rows in buffer
      if size1 > 1, b1_1r = rbuf(1, rc1) #Start reading at "row 2" for "next" tool

In that logic, I first used a call to 'rbuf' to read record (row) number Zero of buffer number 1. Record zero always holds the "size" or "number of rows that currently exist" in the buffer file. I added an "if" logic condition to only read the 2nd row of the buffer, if the buffer has more than 1 row. We can't "know" that, unless we read record zero, so its a handy feature that gets used often.

 

Once we call 'rbuf', then all five variables in the array, starting with the 'indexing' variable called in the function get populated with values. This happens every time we read from the buffer. The buffer functions always read and write to the entire array. This means that you cannot just read a single value from a specific column. You must read all the values, from each column in the row. That means you always need to use the "first" variable in the implied array list, and the indexing value, and when writing, you need to set each value before you make the "wbuf" call.

 

So reading "record 2" in 'psof$', the following variables have now been set:

b1_1r  : 3.
b1_2r  : 3.
b1_3r  : 3.
b1_4r  : 43.
b1_5r  : 0.1875
Link to comment
Share on other sites

Here are some summary tips for using Real Number Buffers:

 

  • Always make two lists of variables; a "read" list, and a "write" list.
  • Always make two counter variables; a "read" counter and a "write" counter.
  • Make sure you use the "fifth" parameter to indicate a "real number" buffer (0) or a String buffer (1).
  • Set every variable in the "write" array, before you write to the buffer (even if you set a value to '0').
  • When reading from a buffer, use the 'first' variable in the list always. This sets all of the values from that specific record.
  • The read/write counters are incremented by '1' every time the buffer is read from, or wrote to.
  • You can disable the 'auto incrementing' of the read/write counters by setting 'buf_no_index$' to '1', but be very careful if you do this. That means that you as the post writer are now responsible for setting the value of the counter before you call (read or write) the buffer function.
  • If your Buffer is a String Buffer, then you can only read/write a single string at a time to/from the buffer. (no "implied" string arrays with a buffer file) You can manipulate the string (concatenate, or any other string function) before you write it to the buffer, as long as the number of characters doesn't exceed the "MAX_PATH" windows string setting. (typically 1024 or 2048 characters). And, like any other string variable, the read/write string variable names must start with the 's' character...
Link to comment
Share on other sites
  • 7 years later...

One job ago, I had a buffer that wrote all of the work offsets used in a program on a horizontal mill and listed them, as well as used programmable parameter input (G10) to set all of the work offsets relative to the top of pallet, center of rotation.  Worked great, EXT, G54-59, P1-48, and even DFO.  Fast forward several years, and I can't seem to get a buffer to work to simply list all of the work offsets being used by a program.  I want a quick reference for the programmer or anyone else to see which work offsets are being used, when they look at the header.  Can anyone enlighten me?

Link to comment
Share on other sites
2 hours ago, bd41612 said:

One job ago, I had a buffer that wrote all of the work offsets used in a program on a horizontal mill and listed them, as well as used programmable parameter input (G10) to set all of the work offsets relative to the top of pallet, center of rotation.  Worked great, EXT, G54-59, P1-48, and even DFO.  Fast forward several years, and I can't seem to get a buffer to work to simply list all of the work offsets being used by a program.  I want a quick reference for the programmer or anyone else to see which work offsets are being used, when they look at the header.  Can anyone enlighten me?

Where are you filling the buffer with data, before reading?

You should be capturing the buffer data in 'pwrtt$' (Tool Table), and then outputting (and sorting if necessary) at the beginning of 'psof$'.

Link to comment
Share on other sites

Hi Colin,

Trying buffer 4.  I did not have anything in psof$ as mentioned...  How would I sort, it's been a while?  Ultimately, I'm looking for a text string, not a workofs$.

pwrtt$          #Pre-read NCI file
      if tool_info > 1 & t$ > 0 & gcode$ <> 1003, ptooltable
      if gcode$ <> 1001, plast_recd
      pcur_recd
      if gcode$ = 1003,
        [
        size3 = rbuf (one, zero)
        rc3 = one
        if rc3 < size3, preadcur_nxt
        ]
#      pwritbuf4
            workusedg = workofs$
            workusedg = wbuf(4, wc4)
      pwritbuf5

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...