Buffers, buffers, buffers I hate buffers....help please

[Steve Landkamer]

Good Afternoon folks,

 

I am so close I can taste victory, but my last tools buffer information is coming out twice.

 

(PROGRAMMER: G)

(WORK OFFSET)
G10 L2 P1 X0.0 Z3.6

(TOOL LIST)
(TOOL - 1 OFFSET - 1 TOOL = OD ROUGH RIGHT - 80 DEG.)
(TOOL - 12 OFFSET - 12 TOOL = OD 55 DEG RIGHT	 )

(TOOL OFFSETS)
DEBUG*******START OF OUTPUT*******DEBUG rc5 1. size5 9.
G10 L10 P1 R2.591
G10 L12 P1 R1.367
DEBUG*******END OF OUTPUT*******DEBUG rc5 4. size5 9.
DEBUG*******START OF OUTPUT*******DEBUG rc5 4. size5 9.
G10 L10 P12 R3.587
G10 L12 P12 R3.249
DEBUG*******END OF OUTPUT*******DEBUG rc5 7. size5 9.
DEBUG*******START OF OUTPUT*******DEBUG rc5 7. size5 9.
G10 L10 P12 R3.587
G10 L12 P12 R3.249
DEBUG*******END OF OUTPUT*******DEBUG rc5 10. size5 9.


M00

 

Here is my Buffer that I created:

# --------------------------------------------------------------------------
#Buffer 5, testing to store misc real values
wc5		 : 1	 #Initial count for write buffer 5
rc5		 : 1	 #Initial count for read buffer 5
size5		 : 0	 #Buffer 5 size
g10z		 : 1	 #Saved mr9$ value
g10x		 : 1	 #Saved mr10$ value
gten_tool	 : 1	 #Tool number capture
fbuf 5 0 3 0 0
# --------------------------------------------------------------------------

 

Here is my pwrtt post block with my added code see (#STEVE ADDED):

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
 ]

 mr9$ = wbuf(5,wc5)	 #STEVE ADDED
 mr10$ = wbuf(5,wc5) #STEVE ADDED
 t$ = wbuf(5,wc5)		 #STEVE ADDED


 #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$

 

Here is my output postblock that is called from LSOF in this case:

ptooloffsets # Output of Tool Offsets for G10

		 rc5 = 1
		 size5 = rbuf(5,0)						
		 " ", e$
		 "(TOOL OFFSETS)", e$			
		 while rc5 <= size5,
		 [
		 "DEBUG*******START OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging
		 g10z = rbuf(5,rc5)
		 g10x = rbuf(5,rc5)
		 gten_tool = rbuf(5,rc5)
		 "G10 L10", *gten_tool, *g10z, e$
		 "G10 L12", *gten_tool, *g10x, e$
		 "DEBUG*******END OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging
		 ]
	 " ", e$

 

What kind of trap do I need to build to keep the (in this case) second tools information from coming out a second time?

[Chris McIntosh]

Steve,

 

There are a couple of issues here:

 

1) the way you are writing to the buffer is not quite right (although the way you read the parameters back in corrects for this). You have correctly defined a buffer size of 3, as you are wanting to store the mr9$, mr10$ and t$ variables. When you write to a buffer using wbuf, the post will fill a complete row in the buffer. The proper way to fill the buffer would be:

g10z = mr9$
g10x = mr10$
gten_tool = t$
g10z = wbuf(5,wc5)

This way you are filling a single row with all the data necessary rather than filling the first entry in the buffer for three separate rows.

 

Then, when reading back in, the code would look like:

ptooloffsets # Output of Tool Offsets for G10

rc5 = 1
size5 = rbuf(5,0)
" ", e$
"(TOOL OFFSETS)", e$
while rc5 <= size5,
[
"DEBUG*******START OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging
g10z = rbuf(5,rc5)
"G10 L10", *gten_tool, *g10z, e$
"G10 L12", *gten_tool, *g10x, e$
"DEBUG*******END OF OUTPUT*******DEBUG", *rc5, *size5, e$ #used for debugging
]
" ", e$

The single rbuf statement will fill the g10z, g10x and gten_tool variables.

 

2) The post will pass through pwrtt$ for each operation, so you need to make the decision as to when you want to write to the buffer. Once per tool? Every operation? when the tool number changes?

 

The reason you are having an issue in this specific example is because the post passes through pwrtt$ one final time at the end of the file (gcode$ = 1003), so you will need to add a simple if statement to avoid duplicating the last tool (modifying the code from above):

if gcode$ <> 1003,
[
g10z = mr9$
g10x = mr10$
gten_tool = t$
g10z = wbuf(5,wc5)
]

 

You will need more logic added to the if statement depending on when you want to write code to the buffer.

 

Let me know if you need any other help.

[Steve Landkamer]

Chris you ROCK dude!

 

That got me going in the right direction. The Volume 2 PDF from way back does not due buffering justice.

 

Thanks again!

[Craig-B]

Steve, I hate them to, you are doing a lot better than me, I wish I can get that good with it. I'm trying to do something similar with the tplane origin, but output as a sub segregated by the rotations in the program for my HMC post.

[Steve Landkamer]

Steve, I hate them to, you are doing a lot better than me, I wish I can get that good with it. I'm trying to do something similar with the tplane origin, but output as a sub segregated by the rotations in the program for my HMC post.

 

Craig,

It made my head hurt but I am getting a better understanding. Note I did not say proficient I can now try to do simple parlor tricks. :-)

You may want to look in a Lathe post at the tool stuff usually in buffer#1 it may be in there for your taking.

But any guy named "Craig B" that knows "F" Macros this shouldn't be to hard.

[Craig-B]

LOL Note: I can do some basic custom macro B stuff, but I'm no expert. I'm still failing on my pipe dream of trying to get Mastercam to post a parametric lathe program for part families in Fanuc Custom Macro B. for a 4 axis lathe.

 

(HEAD 1)

N8G0G28U0.(TOOL - 8 OFFSET - 8)

M100

G0T0899

M26

G50S#119

G96S#120M3

G0G54Z[9.3+#132]M8

X3.

X.4148

G1Z[8.63+#132]F#121

X.5296

Z[8.73+#132]

G0Z[9.3+#132]

X.3

G1Z[8.63+#132]

X.4348

Z[8.73+#132]

G0Z[9.3+#132]

X.27

G1Z[8.615+#132]

X.5296

Z[8.715+#132]

G0X.8236

Z[8.6+#132]

G1X-.0313

G0Z[8.7+#132]

X3.

M9

G0G28U0.M5

G0T0888

M101

/M01

M102

 

(HEAD 2)

 

N8(TOOL - 8 OFFSET - 8)

(STEADYREST UNCLAMP/CLAMP)

M61(UNCLAMP)

G04P500

G0G30U0.

G0G54Z[#141-1.0]

M60(CLAMP)

G04P500

N203(END)

M100

M101

/M01

M102

[The Cathedral]

LOL Note: I can do some basic custom macro B stuff, but I'm no expert. I'm still failing on my pipe dream of trying to get Mastercam to post a parametric lathe program for part families in Fanuc Custom Macro B. for a 4 axis lathe.

 

 

I have a future project to do the same thing.

 

I've written macros for damn near every machine in our shop to do things from helical boring, angle boring, hobbing, threadmilling, 3.5 axis orientation, etc... Now i need to get Mastercam to fill out the macro call line. My current project is having Mastercam output that line, while I still program Mastercam like normal so I can run an accurate simulation. Getting it to do one hole is easy; having it be modal (G66/G67) is giving me a problem.

[Craig-B]

Can you try doing a string select like the g-codes (*sgcode,)in the post something like the following. Then just use (*sgmodal)

 

# --------------------------------------------------------------------------

# Macro modal codes

sgmodal0 : "G66" #Modal Call

sgmodal1 : "G67" #Modal Cancle

sgmodal : ""

fstrsel sgmodal0 gmodal sgmodal 2 -1

gmodal : 999

# --------------------------------------------------------------------------

[Colin Gilchrist]

Chris nailed most of the important points, but I'll add my 2 cents here.

 

The most important thing to understand with numeric buffers is that the buffer read and write functions work with Implied Arrays. This means if you define a Real Number (Numeric) buffer with 3 records per row, when you read or write to that buffer, you are either reading or writing 3 pieces of data.

 

That means that it is good practice to set all three variables before you make the 'wbuf' call, as Chris pointed out.

 

The next thing that you need to thing about is when to write data to the buffer. This is more about learning how the calls to 'pwrtt$' work. When the command variable 'tooltable$' is set to '3', this enables the "Tool Table" output. MP will perform a "pre-read" of the NCI data. During this pre-read, the motion calls (0, 1, 2, 3, 11) are skipped, and only the Tool Change data is read. These are the 1000 (Null Tool Change), 1001 (Start-of-File Tool Change), and 1002 (Actual Tool Change) codes. In addition, MP will read some data from the lines that precede the Tool Change Call. This will include things like Tool Plane Origin, Tool Plane Matrix, Tool Data, ect.

 

When this pre-read loop is taking place, the first time a tool is read by MP, that tool number will be set to a positive integer value that equals the tool number. This allows the logic in 'pwrtt$' to check and see if the tool number is greater than zero. If it is, then a call is made to 'ptooltable' and that tool number gets written to the tool table as a comment.

 

The next time a Tool Change comes up in the NCI that uses the same tool number, that tool variable (t$) is signed Negative, and the integer value matches the tool number. This allows the logic in 'pwrtt$' to skip that tool change, and not output redundant comments to the tool table.

 

I think that is what Chris was alluding to with the #2 statement above about writing logic to capture "every tool" or "every operation". You have to make some logic decisions because if you use Multi-passes or Depth Cuts, you generate a Null Tool Change event in the NCI. So you often need to check the value of 'op_id$' or 'tool_op$' to see if the operation is a new operation, or if you are just processing a depth cut for example.

 

When you read or write from a buffer, the read and write function both use 2 parameters. The first parameter is the buffer number that you want to perform the read or write operation on. The second parameter is the "index" variable.

 

Consider the following code:

 

g10z = wbuf(5,wc5)

 

That statement tells MP to write 3 variables to the buffer, starting with the variable 'g10z' and using the next two numeric variables defined (implied array). It uses the value of 'wc5' to decide which record to write the data to in the buffer. This is the "index" variable, and should generally be initialized to the value of '1', so that you start writing to the first record in the buffer file, and don't try to write to record zero.

 

Every time you make a call to 'wbuf', that index variable is automatically incremented by '1'. This is another hugely important thing to understand. The read and write counters get incremented automatically every time you make a read or write call to the buffer file.

 

You can stop that auto-increment behavior by setting 'buf_no_index' to '1'. This command variable can be set "on-the-fly" if you wish or at the top of the post to turn off that auto-increment behavior.

 

I might have to create a Post Class that covers Buffer Files in-depth...

 

Thanks,

[Peter - Avivi CNC Solutions]

Yepp, buffers are very powerful tools in MP, I use it whereever I can.

Mostly I need infos (and records) from each operations, so here is my method to write them and my 0.02$

pwrtt$		  #Pre-read NCI file
 if op_id$ <> prv_op_id$,
    [
    pWriteBuffer_1
    pWriteBuffer_2
    pWriteBuffer_3
    pWriteBuffer_4
    pWriteBuffer_5
    ]
  !op_id$

[crazy^millman]

I might have to create a Post Class that covers Buffer Files in-depth...

 

Just tell me where to sign up and I will be there.

[Bill Craven]

I hate "me too" posts. But in this case: ME TOO!

[Colin Gilchrist]

Thanks Ron, I'll take your and Bill's request as enough interest to warrant a class. I'll talk with Derek about setting one up.

[Steve Landkamer]

Sign me up also Colin!

Also thanks for the great information!

[The Cathedral]

Hey, sign me up. I'm always down for learning anything.

[Colin Gilchrist]

Hello Everyone,

 

Due to popular demand, we've created a class that covers Buffer Files for MP-based Post Processors. The class itself is 12 hours. There are 8 hours of lecture/presentation, and 4 hours of interactive question and answer time. The class will be taught on 2 Saturdays, 4 hours per day, with the Office Hours being held on Tuesday and Thursday evenings.

 

I'm hoping to start the class on May 24th, but the start date will depend on the number of people that sign up. The nice thing is that this is only a 2 week commitment.

 

This is an advanced level class in how to use Buffers with the MP Post Language. As always, all class sessions will be recorded and available to view on the Eapprentice.net website as your personal reference material.

 

If you've always wanted to learn how to use Buffer files, or had questions about them, but nobody to ask, this is the class for you.

 

Thanks and best regards,

MP Buffers.pdf

[Mick]

That would be a really good course.

[Reko]

Please, save a spot for me Colin.

[crazy^millman]

Colin I will be glad to sign up. Not sure if I can make both Saturdays, but since it will give me access to the recorded session I will be glad to pay for it. Buffers have always puzzled me so be nice to seen it explained and then have a question and answer process following it.

[Colin Gilchrist]

That would be a really good course.

 

Thanks Mike. I think it is a great subject and am really looking forward to teaching it.

 

Please, save a spot for me Colin.

 

Done. Thanks for the interest!

 

Colin I will be glad to sign up. Not sure if I can make both Saturdays, but since it will give me access to the recorded session I will be glad to pay for it. Buffers have always puzzled me so be nice to seen it explained and then have a question and answer process following it.

 

Thanks Ron. It will be great to have you, and I look forward to answering everyone's questions. I think the "Office Hours" portions of the classes are probably the most valuable. Sometimes it really helps to be able to ask a question in a live environment. I think the discussion those questions generate really contribute to the information that everyone learns.

[Colin Gilchrist]

One more week to sign up for this class...

 

http://www.eapprentice.net/shop/live-training/mp_buffer_files/

[crazy^millman]

I was wondering about this today. Guess I missed the posting or email about it. Thanks for putting that back up.

[Colin Gilchrist]

Thanks Ron. Hope you can make it.

 

[Mick]

Sorry it wont happen for me. It will be a really good class though.

[Reko]

Just signed up... Looking forward to it!