Max tool depth..

[Rekd™]

I'm using a .set file to generate a setupsheet template that I am importing into a database. The setup sheet is supposed to give me the max depth value for each tool. The problem is that it's spitting out 0.000 for the first tool, then all the other tools are 1 tool behind. In this example,

 

tool 1 goes to Z.0048

tool 2 goes to Z-.0002

tool 3 goes to Z-.0180

 

As you can see in the example below, the first tool is at Zero, then .0048, then -.0002, and the -.018 is dropped.

 

I know it has to do with the first tool being called from psof, and the others being called from ptlchg, but I cant get it to work.

 

Any ideas?

 

This is the results of running the setup sheet:

 

Note the location of the bold text in the 8th column from the left, it is the depth..

(sample)

01;0.1250;4;01;01;1.0000;0.5000;0.0000;1/8 CB EM 4FL TIALIN;71240-12530S000 psof p__0:372

(end sample)

 

code:

---

StartPart: psof

ProgramName = 101655-01L REV J.NCF psof

MastercamName = 101655-01L REV J.MC9 psof

CompanyName = NONE psof pcustomer

ProgramNumber = O0001 psof

ProgramDate = 08/13/03 psof

MaterialType = ALUMINUM inch - 6061 psof

WorkOffset = G55 psof

StockSize = X 2.4900 Y 1.0500 Z 0.2800 psof p__2:438

StockOrigin = X.8303 Y3.3764 Z.01 From Part Zero psof p__4:453

PartOrigin = Z0 Top, X0 Y0 on Back Left Corner psof p__6:461

StartTools: psof

ToolID;ToolNumber;Dia;Flutes;TLO;CRC;Len;FLen;Depth;ToolDescription;MfgCode psof

01;0.1250;4;01;01;1.0000;0.5000;0.0000;1/8 CB EM 4FL TIALIN;71240-12530S000 psof p__0:372

02;0.0938;4;02;02;0.5000;0.3000;0.0048;3/32 CB EM 4FL TIALIN;71240-09430S000 ptlchg p__0:372

03;0.2500;1;03;03;2.0000;1.5000;-0.0002;1/4 CHAMFER MILL;72110-2500SS090 ptlchg p__0:372

EndTools peof

CycleTime = 0 Hrs, 4 Min, 44.97 Sec peof

---

Below are the psof and ptlchg sections of my post.

code:

---

psof          # Output of setup sheet header          ()

pwritbuf1

"StartPart:", E

"ProgramName = ", progname, ".NCF", e

smcname = ucase(smcname)

"MastercamName = ", smcname, ".MC9", e

pcustomer

#pmachine

"ProgramNumber = ", progno,e

"ProgramDate = ", month, "/", day, "/", year, e

"MaterialType = ", stck_matl,e

pwcs

if stck_ht > 0 & stck_wdth > 0 & stck_thck > 0,

[

"StockSize = X ", stck_ht, " Y ", stck_wdth, " Z ", stck_thck, e

]

else, "StockSize = Undefined", e

 

#========================================================

# Allow grafical output to be disabled

#========================================================

if grfc_stck = yes,

[

#========================================================

# If any stock values are empty, disable grafical output

#========================================================

if stck_ht > 0 & stck_wdth > 0 & stck_thck > 0,

 

[

 

"StockOrigin = ", stck_x, " ", stck_y, " ", stck_z, " From Part Zero", e

if stck_crnr = 0,

[

"PartOrigin = Z0 Top, X0 Y0 Centered on X and Y", e

]

if stck_crnr = 1,

[

"PartOrigin = Z0 Top, X0 Y0 on Back Left Corner", e

 

]

if stck_crnr = 2,

[

"PartOrigin = Z0 Top, X0 Y0 on Back Right Corner", e

]

if stck_crnr = 3,

[

"PartOrigin = Z0 Top, X0 Y0 on Front Right Corner", e

]

if stck_crnr = 4,

[

"PartOrigin = Z0 Top, X0 Y0 on Front Left Corner", e

]

if stck_crnr = 5,

[

"PartOrigin = Z0 Bottom, X0 Y0 on Back Left Corner", e

]

if stck_crnr = 6,

[

"PartOrigin = Z0 Bottom, X0 Y0 on Back Right Corner", e

]

if stck_crnr = 7,

[

"PartOrigin = Z0 Bottom, X0 Y0 on Front Right Corner", e

]

if stck_crnr = 8,

[

"PartOrigin = Z0 Bottom, X0 Y0 on Front Left Corner", e

]

 

]

]

 

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

# Start Tool List |

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

 

"StartTools:", e

"ToolID;ToolNumber;Dia;Flutes;TLO;CRC;Len;FLen;Depth;ToolDescription;MfgCode", e

psepline

psetup # Call to toolchange info

!op_id #Added (04/22/03)

 

ptlchg0 # Null tool change ()

comment

!op_id #Added (04/22/03)

 

ptlchg # Output of time calculations for the last tool run ()

if op_id = prv_op_id, ex # Added (4/22/03)

if t = prv_t, ex # Added (4/22/03)

 

pttltime

psepline

psetup # Call to toolchange info

!op_id #Added (04/22/03)

 

---

TYIAFAYH

 

'Rekd teh stumped

 

[ 08-13-2003, 04:14 PM: Message edited by: Rekd ]

[Müřlıń®]

yo...dude.....you musta stumped everyone....lol

 

Itsabout a foot or two over my head......

 

 

Bump-o-rama......

 

 

Murlin

[Trevor Bailey]

Have you looked at what Dave did with the mpmaster? Is this the post you started with? You should be able to pull his logic into yours. I will play wiht it later on tonight.

 

If you solve it by the time I post again, let me know what you came up with.

[crazy^millman]

Hey Rekd The old fadal post use to do the same thing for the offset call. I wane in and changed the starting variable for that incremental call in the Varaible definations and that fixed it. It was nothing to do with anything in the way the program was spitting it out. It was just that the varible to start the counting was 0 in stead of one. It seems weird but it sounds like it is doing a null tool for the frist as a 0 then working from that number. If the value is set to 1 that might just do the trick.

 

Since I dont know the post and what machine it for I am a guessing.

 

Good luck

 

Crazy Millman

[Roger Peterson]

Rekd, I beleive the buffer file that contains the min max values is done through the pwrtt postblock in the .set files. Because one record is written before any movement has occured you need to initialize the read counter to a value of 2 instead of 1 as if you would be writing these values at a toolchange.

 

 

HTH

[Allan Brown]

Those min max values are only available after a section is run. We need to buffer them out in pwrtt (tool table post block used in NCI pre-prossing) then read them in with +1 offset counter - like what Roger said.

[crazy^millman]

Hey Rekd you able to get this worked out?

 

Crazy Millman

[Rekd™]

No, not yet.

 

I'm about to give up and beg for handouts.. What really sux0rs is that I had it working before..

 

'Rekd teh hates not being able to figure this out..

[Roger Peterson]

REKD, search for "rc1" and make sure it is initizlized with the value of 2 not 1. That is the first step. Let us know...

[Rekd™]

quote:

---

REKD, search for "rc1" and make sure it is initizlized with the value of 2 not 1. That is the first step. Let us know...

---

It's initialized at 2.

 

Here's the buffer routines..

 

code:

---

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

# Buffer 1 Read / Write Routines

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

pwritbuf1 # Write Buffer 1 ()

if gcode = 1002 & op_id = prv_op_id, b1_gcode = 1000 #Added (4/22/03)

!op_id #Added (4/22/03)

 

b1_gcode = gcode

b1_zmin = z_min

b1_zmax = z_max

b1_gcode = wbuf(1, wc1)

 

preadbuf1 # Read Buffer 1 ()

size1 = rbuf(1,0)

b1_gcode = 1000

min_depth = 99999

max_depth = -99999

while rc1 <= size1 & b1_gcode = 1000,

[

if rc1 <= size1, b1_gcode = rbuf(1,rc1)

if b1_zmin < min_depth, min_depth = b1_zmin

if b1_zmax > max_depth, max_depth = b1_zmax

]

 

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

# Buffer 2 Read / Write Routines

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

pwritbuf2 # Write Buffer 2 ()

b2_gcode = gcode

if gcode = 1002 & op_id = prv_op_id, b2_gcode = 1000 #Added (4/22/03)

!op_id #Added (4/22/03)

b2_ccomp = ccomp

b2_gcode = wbuf(2, wc2)

 

preadbuf2 # Read Buffer 2 ()

size2 = rbuf(2,0)

b2_gcode = 1000

b2_ccomp = 0

comp = ccomp

while rc2 <= size2 & b2_gcode = 1000,

[

if rc2 <= size2, b2_gcode = rbuf(2,rc2)

if b2_ccomp <> 0, comp = b2_ccomp

]

---

Thanks again for the help..

 

'Rekd

[Roger Peterson]

Rekd, try moving:

 

b1_gcode = gcode

 

above:

if gcode = 1002 & op_id = prv_op_id, b1_gcode = 1000 #Added (4/22/03)

 

 

I think that will take care of it, if not...

[Rekd™]

Roger, it didn't work. Thanks for trying though.

 

'Rekd teh Punt on 2nd down...

[Roger Peterson]

rekd, I know the mill.set writes more records to the buffer file than what you are. Did you change the # of records to 3.

 

fbuf 1 0 3 0

 

also by changing it to this:

 

fbuf 1 1 3 0 it will save your buffer file so you can check it out when posting is completed. Try that and post what is in the saved buffer file. The file will have the same name as your nci file with a different extension. I'm not sure what the extension is but it'll be in your nci directory.

[Rekd™]

Roger,

Here are my fbuf settings; ( I changed it to 2, didn't work, so then I tried 4, and after re-booting my computer, I put it back to 3 )

 

code:

---

fbuf 1 1 3 0    #Min / Max

fbuf 2 0 2 0 #Saved ccomp

---

And here's the buffer results file;

 

quote:

---

1001.000000 0.000000 0.000000

1002.000000 0.000000 1.000000

1000.000000 -0.088889 1.000000

1000.000000 -0.088889 -0.088889

1000.000000 -0.187778 -0.088889

1000.000000 -0.187778 -0.187778

1000.000000 -0.286667 -0.187778

1000.000000 -0.286667 -0.286667

1000.000000 -0.385556 -0.286667

1000.000000 -0.385556 -0.385556

1000.000000 -0.484444 -0.385556

1000.000000 -0.484444 -0.484444

1000.000000 -0.583333 -0.484444

1000.000000 -0.583333 -0.583333

1000.000000 -0.682222 -0.583333

1000.000000 -0.682222 -0.682222

1000.000000 -0.781111 -0.682222

1000.000000 -0.781111 -0.781111

1000.000000 -0.880000 -0.781111

1000.000000 -0.880000 -0.880000

1000.000000 -0.978889 -0.880000

1000.000000 -0.978889 -0.978889

1000.000000 -1.077778 -0.978889

1000.000000 -1.077778 -1.077778

1000.000000 -1.176667 -1.077778

1000.000000 -1.176667 -1.176667

1000.000000 -1.275556 -1.176667

1000.000000 -1.275556 -1.275556

1000.000000 -1.374444 -1.275556

1000.000000 -1.374444 -1.374444

1000.000000 -1.473333 -1.374444

1000.000000 -1.473333 -1.473333

1000.000000 -1.572222 -1.473333

1000.000000 -1.572222 -1.572222

1000.000000 -1.671111 -1.572222

1000.000000 -1.671111 -1.671111

1000.000000 -1.770000 -1.671111

1002.000000 -1.770000 1.000000

1000.000000 -0.060000 1.000000

1000.000000 -0.077500 1.000000

1000.000000 -0.092500 1.000000

1000.000000 -0.129000 1.000000

1000.000000 -0.137500 1.000000

1000.000000 -0.141000 1.000000

1000.000000 -0.185000 1.000000

1000.000000 -0.077500 1.000000

1000.000000 -0.092500 1.000000

1000.000000 -0.129000 1.000000

1000.000000 -0.137500 1.000000

1000.000000 -0.141000 1.000000

1001.000000 -0.185000 1.000000

---

Note that this post is from a different MC9 file than my original thread; on this one the first tool cuts Z0, the second one cuts Z-1.77, but shows the first 2 tools at Z0.

 

Thanks for taking the time to help me, Roger.

 

'Rekd

[crazy^millman]

Ok rekd I would ask a stupid question but choose not too. I then looked at the HAAS post sent with the basic 9.1 Mastercam to gauge my response on. I ran into soemthing crazy on toolchanges when the gcode call forthe 1002 or the 1000 was set the wrong way when doing 5 axis toolchanges wit hthe Thermwood post. Maybe I am way out in left feild in this but if you equal your frist part on the equation to a varible equal too a nulltool change will you not add a extra tool to the buffer given you the difference of adding the extra tool which would be nothing but a value of space is added to the buffer thus giving you the z.00 information of something that does not exist in the mastercam program for operation but added by accident with the value 1000 calling the null toochange varible in your post.

 

Example below I think sorry if I am wrong but wihtout asking the stupid quesiton for you to send me the post this is the best I could come up with having what I got to work with.

 

ptlchg1002 #Call at actual toolchange, end last path here

sav_rev = rev #Axis Sub does not update to rev

pspindle

whatline = four #Required for vector toolpaths

if gcode = 1000,

[

#Null toolchange

]

else,

[

#Toolchange and Start of file

if gcode = 1002,

 

The part where it says if gcode equals 1000 then it complete the condtion statement of a null toochange which could possible add the z.00 that you are getting I only think this where you have this

quote:

---

if gcode = 1002 & op_id = prv_op_id, b1_gcode = 1000

---

I do know if this is right and dont have the post to play with to figure it out so given my best try.

 

Good Luck

 

Crazy Millman

 

[ 08-19-2003, 12:17 AM: Message edited by: Millman^crazy ]

[Roger Peterson]

The problem is that 1002 line right after 1001. You shouldn't have a toolchange directly after the start of file, odd. In pwrtt are you calling pwritbuf2?

[Rekd™]

quote:

---

In pwrtt are you calling pwritbuf2?

---

Yes, as well as pwritebuf1.

 

Would it be possible to email you my .pst file to look at if you have time? (Note that I changed the .set extension to .pst, it works the same either way)

 

Thanks.

 

'Rekd

[Roger Peterson]

Send away, I will be out for a couple days but will look at it asap.

 

 

later,

[Rekd™]

It's in the mail, Roger.

 

Thanks again!

 

'Rekd

[Rekd™]

Roger,

 

I was under the impression that post blocks weren't used unless they were called. (kind of like subs and functions in VB)

 

Knowing this will require a complete re-think and re-training of my post editing capabilities and strategies.

 

The post works great now, thank you so much for your time and help. If you're ever in SD, look me up and I'll toss some steaks on the barbi and fix you a Rekd Rum & Coke!

 

'Rekd teh greatful

[chris m]

quote:

---

I was under the impression that post blocks weren't used unless they were called

---

I have had some 'WTF is that?' run-ins that seemed to be related to my (apparent) misconception here as well

 

Strange....

 

C

[Roger Peterson]

rekd, I never got the post. It sounds like you figured it out? What was the problem?

 

 

enquiring minds want to know...

[Rekd™]

Oopsie,

 

Roger Martin sent me an email, so I sent the post to him, thinking it was you, Roger Peterson. I should have realized that I was sending the post to CNCSoftware, not Prototek.

 

At any rate, here is how it was fixed..

 

quote:

---

Matt,

 

This was a bit of a challenge.

 

I noticed that the postblock calling order seemed 'out of sync'.

The tool info for the 1st tool was being output BEFORE the call to check for

the Z MAX/MIN !

 

 

*** WAS THIS ->>

 

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

# Start Tool List |

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

 

"StartTools:", e

 

"ToolID;ToolNumber;Dia;Flutes;TLO;CRC;Len;FLen;Depth;ToolDescription;MfgCode

", e

psepline

psetup # Call to toolchange info

!op_id #Added (04/22/03)

 

 

===========================================================================

 

I started to flip-flp the calls to psepline and psetup, then took a closer

look. It looks like the 'psepline' postblock outputs all the tool data?

I don't think that was the intent. I assume that 'psetup' was supposed to do

that.

 

*** WAS THIS ->>

 

psetup # Output of toolchange information ()

if output_z = 1, preadbuf1

if look4comp = 1, preadbuf2

 

psepline # Output the 'separator' line ()

#### "Start New Tool", e

 

# ===================================================================

# Output all tool data on one line. Extra spacing creates column formatting

# ===================================================================

 

 

So I moved 'psepline' to be above 'psetup', like this ->

 

 

psepline # Output the 'separator' line ()

#### "Start New Tool", e

 

psetup # Output of toolchange information ()

if output_z = 1, preadbuf1

if look4comp = 1, preadbuf2

 

# ===================================================================

# Output all tool data on one line. Extra spacing creates column formatting

# ===================================================================

 

 

The reason I asked about the EXACT version of MC is...

The "ADDED" postlines documented on the SET-FIX.TXT are NOT needed if you

are running v9.1 'SP1' (or higher). Having them in there should not be a

problem, but they are NOT needed.

 

 

Roger Martin

Post Processing Services

CNC Software

 

 

---

Thanks to both Rogers for the help and support.

 

'Rekd