Post Trick

[Josh Kinney -Elite Engineering]

Thanks to Min Xu for this.

 

Here's the history.....

 

I wanted to be prompted if the Length offset or diameter offset didn't match the tool number. I also wanted to be prompted if the coolant was off. Only problem was I have 360 Op's, which Op was the offender? Min Xu at CNC made a chook for me that would grab the Op # and place it in the prompt. This was great but was a major PITA to implement and keep track of in the post.

 

Fast forward to X5. My chook no longer works so I fire off an email to Min....

 

EDIT:

Paul is working on a cleaner method to accomplish this. Look down below for his solution

 

Josh-

[Paul Decelles]

"Do you mind if I post this email on emastercam?"

 

LOL. Guess it doesn't matter if he minds or not eh?

 

BTW, if you just read the parameter as a string (i.e. if prmcode$ = 15240, sOpSeqNo = sparameter$) rather than converting the string to a numeric value and then formatting it as an integer, you can just output it directly without the need for the no2str function. Would be cleaner if you are not actually using the numeric value for anything else.

[Josh Kinney -Elite Engineering]

My apologies, I had this all typed up awaiting a response and must've hit "submit" instead of "preview". I tend to proof read my posts a lot before submitting them. I'll gladly pull it down if needed....

 

Thanks for the advice, I'll clean that up.

[Newbeeee™]

Big thanks for posting this. We'll be adding this somewhen...

[Paul Decelles]

No worries Josh, I'm sure Min will not mind. Just bustin balls

[MIL-TFP-41]

Very cool idea. We have some machines that need to have the dia/length offset match, and some machines that we need to add 30 to the dia offset. Either way looks to be easy & slick to add to the post.

[ThRaSH]

We do something similar to this in an Active Report checklist.

We check coolant state, but not length offset or diameter offset.

I believe both parameters are available to Active Reports, so I'll have

to add these to see if they match the tool number. Never had an issue with

them not matching, but better safe than sorry and it wouldn't hurt to check them.

[Mic6]

and I thought I was cool moving my comment line around in the post! :blink: Crazy stuff right there

[Josh Kinney -Elite Engineering]

Paul,

I'm having a hard time implementing your method. can you elaborate a little?

 

Thanks,

 

Josh-

[Paul Decelles]

Email Josh...

 

For those of you playing along, you will likely wonder what I did for Josh, here is the break down.

 

The first thing Josh needed was to capture the operation number value from parameter data. In order to do so we need a user defined string variable to hold the data:

 

sOpSeqNo 	: ""	#Operation manager displayed operation number 

 

For simplicity, we place the new initialization at the top of the post where all of the other string initializations appear.

 

Next we need the logic in pparameter$ to capture the value:

 

pparameter$ 	#Read operation parameters
 	#rd_params is used to call pparameter postblock and read the parameters of the operation specified in rd_param_op_no
 	#"pparameter", ~prmcode$, ~sparameter$, e$
 	if prmcode$ = 15240, sOpSeqNo = sparameter$ 	#This is the operation manager operation number

 

(I removed the additional parameter read he had for clarity here)

 

Next we need to use that data for output. Josh was looking to concatenate strings to build a single string for error output. To do this I created the error strings as "global formulas". Global Formulas get their values at output which means that the sOpSeqNo value will be correct when the error message is used.

 

#These messages are defined as global formulas so they can pick up the value os sOpSeNo as needed
stoollengthoffserror = "Operation " + sOpSeqNo + ": TOOL LENGTH OFFSET DOES NOT MATCH TOOL NUMBER"
stooldiameteroffserror = "Operation " + sOpSeqNo + ": TOOL DIAMETER OFFSET DOES NOT MATCH TOOL NUMBER"
scoolantisoffserror = "Operation " + sOpSeqNo + ": COOLANT IS TURNED OFF"

 

Now the information needs to be output. Josh had three lines of code containing 'mprint' functions to output the error messages based upon certain conditions. These three lines of code appeared in psof$, ptlchg$ and ptlchg0$ (start of file, tool change and null-tool change). Redundant logic like this is better handled by placing it in a user defined postblock, in turn called by the three locations.:

 

ptlchg_errorcheck  #Check for common toolchange errors
 	if tloffno$ <> t$, [if mprint(stooldiameteroffserror, 2) = 2, exitpost$] #Diameter
 	if tlngno$ <> t$, [if mprint(stoollengthoffserror, 2) = 2, exitpost$] #Length
 	if coolant$ <> one, result = mprint(scoolantisoffserror, 1) #Coolant

 

You will note that the mprint functions above include two styles.

 

The first: "[if mprint(stooldiameteroffserror, 2) = 2, exitpost$]" displays two buttons, 'Ok' and 'Cancel'. The buttons return a value when pressed with 'Cancel' returning a value of 2. The logic above exits posting when a value of 2 is returned.

 

The second: "result = mprint(scoolantisoffserror, 1)" simply displays an 'Ok' button. It just stops processing until the Ok button is pressed and then continues on.

 

The calls to ptlchg_errorcheck are pretty straightforward with the exception of the call placed in ptlchg0$. ptlchg0$ is called in several conditions when the tool number has not changed. These include two operations sharing the same tool, depth cuts and multi-passes. For Josh's purposes we really only want the error messages to be output here if the operation has changed and we need to check for errors again. If we do not add additional logic, we will get redundant error messages any time an error appears in an operation with depth cuts or multi-passes.

 

So in psof$ and ptlchg$ we just need a line like this:

 

psof$        	#Start of file for non-zero tool number     		
 	pcuttype
 	toolchng = one
 	ptlchg_errorcheck  #Check for common toolchange errors

 

Note: For those of you using mpmaster based posts, you can place the above call in ptlchg_com and omit the calls in psof$ and ptlchg$ as they both call that common post block.

 

In ptlchg0$ we need some additional logic like this:

 

ptlchg0$ 		#Call from NCI null tool change (tool number repeats)                    	
 	pcuttype
 	pcom_moveb
 	pcheckaxis
 	c_mmlt$ #Multiple tool subprogram call
 	comment$
 	if op_id$ <> prv_op_id$, ptlchg_errorcheck  #Check for common toolchange errors when the operation has actually changed

 

op_id$ is the internal operation id number assigned to a given operation. The logic above simply checks to make sure that it has changed. Each numeric variable is automagically assigned a prv_ version when it is initialized. The previous value is updated when the variable is output or when we force the update if the variable is not used for output (as in this case) - this is called 'modality' (and that is as far as I am going in terms of explaining it here...

 

We need to make sure that the previous value of op_id$ is updated at each tool change. This is easily accomplished by placing the following command either at the end of the psof$, ptlchg$ and ptlchg0$ post blocks OR at the bottom of the ptlchg1002$ postblock:

 

 	!op_id$  #Force update of prv_op_id$ value without outputting the value to the NC file

 

Note: I would suggest doing a search for !op_id$ before adding it, it may already exist in your post.

 

Note #2: If you are interested in editing your own posts, I would highly suggest attending a basic post processor training class like the one offered here at CNC Software (Our training schedule is available here: http://mastercam.com/Support/Training/Default.aspx) or at your local reseller (if available). Two or three days spent attending training can make the difference between pulling the hair out of your head and having the confidence to make post edits easily and quickly.

[EX-wccprogrammer]

late.

[EX-wccprogrammer]

ptlchg_errorcheck  #Check for common toolchange errors
 	if tloffno$ <> t$, [if mprint(stooldiameteroffserror, 2) = 2, exitpost$] #Diameter
 	if tlngno$ <> t$, [if mprint(stoollengthoffserror, 2) = 2, exitpost$] #Length
 	if coolant$ <> one, result = mprint(scoolantisoffserror, 1) #Coolant

This section of code will output coolant warning if mist or tool coolant is used. To accurately warn coolant is off, replace:

coolant$ <> one

with:

coolant$ = zero

 

Great Stuff Guys, Thanks. This code is going in all 24 of my custom posts.

[Bryan Johnson]

Instead of prompting you to correct offsets and coolant setting, why not modify the post to CORRECT these setting, and then maybe 1 prompt that notifies you of corrections.

IMO, offsets are far too critical for me to assume that they were entered correctly on the parameter pages, plus there is the need to post the same file to multiple machines that may have different rules for "D" values.

 

Build your process for the rule, NOT the exception.

 

 

 

 

[Josh Kinney -Elite Engineering]

Instead of prompting you to correct offsets and coolant setting, why not modify the post to CORRECT these setting, and then maybe 1 prompt that notifies you of corrections.

IMO, offsets are far too critical for me to assume that they were entered correctly on the parameter pages, plus there is the need to post the same file to multiple machines that may have different rules for "D" values.

 

Build your process for the rule, NOT the exception.

 

The post can't go back into MasterCam and put the right numbers in the offsets. I would rather have a clean MasterCam file instead of relying on the post to clean everything up for me. I understand sometimes you want to use Diameter Offset #30 for Tool #3. This is the exception and if you know on Op #10 you specified a different offset well then hit "OK" when prompted.

 

If you have machines with different rules for "D values" then you need another post for that specific machine.

[Jimmy Wakeford from Barefoot CNC]

For tool length/offset equalling tool # I have this in our haas posts at psof and ptlchg before tool call:

.....

tlngno$ = t$

tloffno$ = t$

pbld, n$, *t$, sm06, e$

........

 

For on the fly coolant commands while posting you can do this:

 

Declare these:

test_cool_1 : 0
test_cool_2 : 0
fq 1 test_cool_2 "Turn coolant on? 0=no 1=flood 2=mist 3=tool"
s_1st "Coolant not on for op "
s_2nd 
scomm_sav 

 

In psof and ptlchg:

if coolant$ = 0,[
	s_2nd = s_1st + scomm_sav
	test_cool_1 = mprint(s_2nd)
	q1
	coolant$ = test_cool_2
]		

 

And to capture operation comment (must have a comment for each op) put this in pcomment2:

pcomment2       #Output Comment from manual entry
       scomm$ = ucase (scomm$)
scomm_sav = scomm$

 

It will tell you what op coolant is not turned on in, then asks what coolant you'd like. I tried getting it to change the question string, but was unable to do it, thats why it tells then asks.

 

This will allow you to keep posting and let you go back and fix op coolant settings afterward.

[Josh Kinney -Elite Engineering]

Just a little update. Here's what I use for my errors.

 

stoollengthoffserror = "OPERATION # " + sOpSeqNo + " - TOOL # " + stoolno + " - LENGTH OFFSET IS SET TO #" + stoolngno

stooldiameteroffserror = "OPERATION # " + sOpSeqNo + " - TOOL # " + stoolno + " - DIAMETER OFFSET IS SET TO #" + stooloffno

scoolantisoffserror = "OPERATION " + sOpSeqNo + ": COOLANT IS TURNED OFF"

 

This will tell me what operation, what tool number and what the offset number is since I sometimes use multiple offsets for the same tool. This allows to me either continue or exit posting.

 

Josh-