Buffer Files - How they work explained

[Colin Gilchrist]

Hello Everyone,

 

I know I've helped several people over the years with Buffer Files in the MP Language, and I thought I'd create a post here on Emastercam to help shed some light on how they work.

 

NUMERIC BUFFER FILES

 

There are two types of buffer files available in the MP Language; Real Number Buffers and String Buffers.

 

• A String Buffer is simply an ASCII Text File that has 1 string per Row. (A "Row" is also known as a "Record" when describing Buffers.)
• A Real Number Buffer is a file that "you tell" how many variables to put on each Row. (Record)

When you look at a Numeric Buffer, the Buffer Definition line tells you how many variables to store on each line. The tricky part about this whole thing is that MP does not store variables in "rows". MP only stores variables in "columns" of variables. That one aspect of the whole thing is probably the hardest part to wrap your head around.

 

When you define a Buffer File, you have to define more than just "the buffer definition". You need an Ordered List (column) of Numeric Variables to go with your buffer definition. In fact, you may need "multiple" ordered lists of variables, depending on exactly what you need to "do" with the data in the buffer.

 

In addition to your Ordered List, you need some "helper" variables that get used with Buffer Functions, in order to get the "size" (number of rows of data), and that get used as a "read" and a "write" counter.

 

Summary for creating a buffer file:

 

• You need a "buffer definition". (more on this later) This defines the buffer number, and the number of variables to store on each record. (row)
• You should define a "size" variable. This is used when reading "record zero" to get the number of rows the buffer contains.
• You should define a "read" and a "write" variable, and initialize them to '1' minimum. Do not initialize a read or write counter to zero!
• You should define a minimum of 1 "ordered list" of variables (column). The number of variables in this list must match the number of variables you defined the buffer with. Otherwise, if your list is "shorter" than the number of real variables in your buffer, the "read/write" routine will affect the "next" variables defined below your ordered list. This is bad.
• In many cases, you will need 2 or more "ordered lists" of variables, in order to compare values retrieved from the buffer file.

 

Buffer Definition

 

You define a buffer using the 'fbuf' function. There are 5 numeric values that follow the 'fbuf' command.

fbuf 2 0 6 1 0

• The first value (1-10) is the "buffer number".
• The next value (0-1) is the "read" flag. This determines if you want to "read" data when initializing the buffer. For example, you can store data in an external Text File, and tell MP you want to "fill" the buffer up with data from this file.
• The 3rd parameter tells MP how many variables are stored in each Record (Row). By definition, this also determines how many variables are read from the column of variables defined in the PST file.
• The 4th Parameter is the "keep" flag. This determines if MP should "write the buffer file to a Text file", once the processing is complete. You can use the "keep" flag to help you when "debugging" buffer file data. (Did my data get stored? What value is in each parameter?)
• The 5th Parameter was added with the start of "Mastercam X". This is the String/Real parameter. A value of '0' tell MP the buffer is a Real Number buffer. A value of '1' tells MP that the buffer is a String Buffer.

 

So, we've defined a Real Number Buffer as "Buffer #2", and told MP that there are 6 numeric variables that get stored on each Record (Row) of data. Now we need some additional variables to work with our buffer:

b2_op_num  : 0
b2_op_id   : 0
b2_gcode   : 0
b2_tl_num  : 0
b2_dia_off : 0
b2_tlngoff : 0


c2_op_num  : 0
c2_op_id   : 0
c2_gcode   : 0
c2_tl_num  : 0
c2_dia_off : 0
c2_tlngoff : 0

n2_op_num  : 0
n2_op_id   : 0
n2_gcode   : 0
n2_tl_num  : 0
n2_dia_off : 0
n2_tlngoff : 0


size2   : 0
rc2     : 1
rn2     : 2
wc2     : 1

sbufname2$ : "C:\TEMP\buffer2_data.txt"

fbuf 2 0 6 1 0

So, what do we have now?

 

We have 3, ordered lists of variables. The intent here is to name the variables with "the buffer number" as some part of the variable name, and to help identify the purpose of each variable.

 

• The 'b2' variables are going to be our "write" variables. We fill each variable in the list before we perform the "write" command.
• The 'c2' variables are going to be our "current" variable values. When we read from the buffer, we "index", or determine "which row" to read based on some need that we have. We may want to read each row sequentially, starting at the beginning of the buffer, or we may need some other type of "key" or "index" value to grab a "specific" row.
• The 'n2' variables are going to be our "next" variable values.
• We have also initialized the "buffer name" string variable with the full path and file name of the buffer data file, when we "keep" it.

 

 

 

One of the most important things to understand here is that the "index" variable for the Column (list) of variables is the single variable that we will call in the Read or Write function. For this reason, I've also kept the order of each list the same, except for the starting characters which identify the purpose of each list.

 

OK, sweet. We've got a buffer. But they don't "do anything" by themselves. We must fill the buffer with data, and then read data from that buffer file during processing in order to get any use out of the buffer file.

 

There is a mechanism inside MP that helps us in that respect. It is called the NCI Pre-Read Loop. Our NCI data is read twice. (if 'tooltable$' is set to '1' or '3').

 

During the Pre-Read loop, MP makes calls to 'pwrtt$' to ostensibly write Tool Table data. But we are going to use it for an additional purpose; to get Tool data for the "current" and the "next" Tool Change events.

 

So, we add some data to 'pwrtt$' to write data to our buffer:

pwrtt$    #NCI Pre-Read, blah, blah, blah

    .
    .
    if op_num <> prv_op_num, #If processing a "new" operation
      [
      b2_op_num = op_num #Get actual Operation Number from 'pwrttparams'
      b2_op_id = op_id$
      b2_gcode = gcode$
      b2_tl_num = t$
      b2_dia_off = tloffno$
      b2_tlngoff = tlngno$

      wc2 = op_num #set "write counter" to actual operation number
      b2_op_num = wbuf(2, wc2) #Write all 6 column variables to a single buffer record (row)
      ]
      !op_num #Update op_num to make sure 'prv_' value gets stored for each op

So there we have placed data into the buffer. (You can test this by turning on the "keep" flag in the buffer definition, and setting the "full path and file name" of the buffer.)

 

 

 

 

[Colin Gilchrist]

Now, what do we "do" with the data. We need to read data from the buffer file to be able to "do anything" with it.

 

Typically, we do this at a Tool Change event, but not always. There are many ways to use a buffer file.

 

Here is an example in 'psof$':

psof$   #Start of File for non-zero tool

      rc2 = op_num       # Here, we get 'op_num' from 'pparameter$', because it is "normal" processing.
      size2 = rbuf(2, 0) # This line reads "record zero" of the buffer, which always holds the # of rows.
      if rc2 = size2, rn2 = rc2  # Prevent Buffer Read Overflow
      c2_op_num = rbuf(2, rc2) #We just read 6 variables from buf 2, and put them in an ordered column.
      if rc2 < size2, rn2 = rc2 + one #increment "next" counter
      n2_op_num = rbuf(2, rn2) # We get the "next row", unless we are at the end of the buffer.

So with those few lines of code, we have set our "current read counter" variable to equal the value of the current "Operation Number" listed in the Ops Manager. On the next line, we get the total size of the buffer. This gives us the total number of "rows" inside the buffer file. (For example, if we only post a single operation, then our buffer only holds '1' record.)

 

On the 3rd line of code, we check to see if 'rc2' is equal to 'size2'. If that is the case, we force the "next read counter" variable to be equal to the "current" value. This prevents Buffer Overflow. (Underflow? I always get those terms mixed up...)

 

Finally, on the 4th line of code, we read all six variables from the row. This is done by setting 'rc2' equal to the 'op_num' value, which makes sure we grab the correct row of data. Then, we place each Parameter of numeric data into an Ordered List of variables (column), starting with the Index Variable 'c2_op_num'. So now, our column of six variables, starting with that particular index variable, holds each piece of data from the row we read.

 

The 5th line of code checks to see if the Buffer Size is bigger than the value of the "current read counter", and if it is bigger, then we set 'rn2' to be equal to 'rc2', and then add '1' to it for an increment. (if it is "equal", then we end up reading the same "row" as we did above.)

 

Finally, we read the "next" operation that was written to the Buffer. This means we read the "next row (record)" of data, and place all 6 variables into an ordered list, starting with 'n2_op_num'.

 

 

Please note that this isn't really "functional code" from a post development point of view, it is just an example of how data gets stored into the buffer, and then how that data gets read back out from the buffer. I'm sure I can dig out a better "working" sample from somewhere, but I thought I'd start with this as an abstract example, to help explore the mechanics of how buffers work, behind the scenes.

 

Most of the time, a buffer uses a "while" loop to go through each row in the buffer file, one after the other. You place code inside the body of the 'while' loop to "do something" with the data, before the body completes, and the test is evaluated again.

 

Hope that helps,

 

Colin

[jlw™]

Some one make it a sticky.

[crazy^millman]

Thank you sir, Really appreciate you willingness to share what you have learned.

[bigjohn]

I just love this stuff. I cannot have enough of it.

 

Thanks Colin. 

[bigjohn]

Sorry duplicate post.

[cncgotoguy]

I can't for the life of me get the variable for the NC file name to go in the buffer file. I've successfully named the buffer file and chosen a location, but when I add the snamenc$, I can't get it to work.

This works: "C:\Users\bilbroughb.TRESKE\Desktop\A working Folder\BEN.txt"

This doesn't: "C:\Users\bilbroughb.TRESKE\Desktop\A working Folder\" + snamenc$ + "BEN.txt"

 

I got one variable to go in there... "C:\Users\bilbroughb.TRESKE\Desktop\A working Folder\" + smon9 + "BEN.txt"

 

Attached is the post, line 977 to 985 of the post is where I am naming the buffer file.

MAKINO BUFFER FILE.PST