Your logic is no good. You can't use the brackets like that. Use this: code: ldrill$ #Canned G81 drill cycle, lathe pdrlcommonb if feed > .008, feed = .008 pcan1, pbld, n$, *sg80_f, "G99", prdrlout, pfzout, pffr, strcantext, e$ if initht$ > refht$, pbld, n$, sg00, "Z.1", e$ pcom_movea

Do you generally feed up out of your work piece? If that G00 wasn't there, wouldn't the machine feed at 40 IPM all the way home?

Ok, let me say this again to try to make it clear. COMMENT$ IS NOT A VARIABLE, IT IS A COMMAND. You CANNOT do this: comment$ = wbuf(7,wc7) And AGAIN, I believe that you DO NOT need to use a buffer to achieve the output you desire here. Please, just humor me. Try adding the logic that I showed for pcomment2. Specifically the: code: if gcode$ = 1008, #Operation comment [ sopcomment = scomm$ #Load comment into user defined variable sopen_prn, scomm$, sclose_prn, e$ #Output comment ] (Be sure to initialize sopcomment somewhere) Remove all of the buffer stuff (hell, just comment it all out if you absolutely cannot trust me) and just add sopcomment in your pdrlcst$ post block, replacing buf_comment.

Sorry, just reread what I put above and realized I forgot to remove the pwritbuf7 from the code snippet for psof$. You would also need to add the comment$ command prior to outputting sopcomment. Of course this would lead to the comment buffer being dumped so you'd likely want to completely comment out the operation comment output in pcomment2 to keep it from coming out at the top of psof$. You could then just put sopcomment anywhere else in psof$ that you desire the operation comment to be output.

Ron, I'd like to help but I still do not understand exactly what it is you are trying to achieve. From this: code: if drillcyc$ = 10, #Bore/Boss [ pdrlcommonb pbld, n$, *sg00, *prorefht, e$ pbld, n$, *strg659810, *prnrefht, e$ pbld, n$, *strg659814, diadwell, [if shftdrl$ = zero, *zbossdep], [if radclear, *radclear], [if offupdate > 0,*offupdate], [if trueposzone > 0, *trueposzone], [if toolupdate > 0, *toolupdate], [if drl_prm10$ > 0, *drl_prm10$], e$ pbld, n$, *strg659810, *prnrefht, e$ pbld, n$, *sg00, *prorefht, e$ if drl_prm10$, [ spaces$ = 0 preadbuf3 sdprint, "[", *buf_comment, "]", e$ ##Not working Like I would want RDB it would appear that you are simply attempting to save off an (operation?) comment and to output it in a specific location in psof. If this is true, you are completely over complicating things in attempting to use a buffer. All you need to do is to load the comment into a string variable in pcomment2 and then output it where you desire. Something like: code: pcomment2 #Output Comment from manual entry scomm$ = ucase (scomm$) if gcode$ = 1005, sopen_prn, scomm$, sclose_prn, e$ #Manual entry - as comment if gcode$ = 1006, scomm$, e$ #Manual entry - as code if gcode$ = 1007, sopen_prn, scomm$, sclose_prn #Manual entry - as comment with move NO e$ if gcode$ = 1026, scomm$ #Manual entry - as code with move NO e$ if gcode$ = 1008, #Operation comment [ sopcomment = scomm$ #Load comment into user defined variable sopen_prn, scomm$, sclose_prn, e$ #Output comment ] if gcode$ = 1051, sopen_prn, scomm$, sclose_prn, e$ #Machine name if gcode$ = 1052, sopen_prn, scomm$, sclose_prn, e$ #Group comment if gcode$ = 1053, sopen_prn, scomm$, sclose_prn, e$ #Group name if gcode$ = 1054, sopen_prn, scomm$, sclose_prn, e$ #File Descriptor And then: code: psof$ #Start of file for non-zero tool number ##### Custom changes allowed below ##### pwritbuf7 if ntools$ = one, [ skip single tool outputs, stagetool must be on stagetool = m_one !next_tool$ ] if drillcyc$ = 10, #Bore/Boss [ pdrlcommonb pbld, n$, *sg00, *prorefht, e$ pbld, n$, *strg659810, *prnrefht, e$ pbld, n$, *strg659814, diadwell, [if shftdrl$ = zero, *zbossdep], [if radclear, *radclear], [if offupdate > 0,*offupdate], [if trueposzone > 0, *trueposzone], [if toolupdate > 0, *toolupdate], [if drl_prm10$ > 0, *drl_prm10$], e$ pbld, n$, *strg659810, *prnrefht, e$ pbld, n$, *sg00, *prorefht, e$ if drl_prm10$, [ spaces$ = 0 sdprint, "[", sopcomment, "]", e$ #Output operation comment again would work just fine. The only reason I can think of to write this data to a buffer is to save the information for use later (in another operation after the comment has changed).

Wait a minute... Unless I am completely mistaken, if you start at the bottom and go CCW and up (internal thread with the tool spinning CW), reversing it means you must move CW and down (with the tool spinning CW). So, one way HAS to be climb milling while the other HAS to be conventional. No?

Do this instead... Open the .pst file and search for pprep$ If it exists, add fastmode$ = no$ to the post block If it doesn't, add the post block (I usually add it right at the top of the post after the 1st (header) line: code: pprep$ fastmode$ = no$ Now you don't have to go into the CD at all. Just remember to delete (or comment out) the logic when done debugging.

50 bucks says you didn't save the file Save the file and post again. The variable is correct, it is even used in all of our generic posts like Generic Fanuc 4X Mill.pst: code: pheader$ #Call before start of file "%", e$ sav_spc = spaces$ spaces$ = 0 *progno$, sopen_prn, sprogname$, sclose_prn, e$ #sopen_prn, "PROGRAM NAME - ", sprogname$, sclose_prn, e$ sopen_prn, "DATE=DD-MM-YY - ", date$, " TIME=HH:MM - ", time$, sclose_prn, e$ #Date and time output Ex. 12-02-05 15:52 #sopen_prn, "DATE - ", month$, "-", day$, "-", year$, sclose_prn, e$ #Date output as month,day,year - Ex. 02-12-05 #sopen_prn, "DATE - ", *smonth, " ", day$, " ", *year2, sclose_prn, e$ #Date output as month,day,year - Ex. Feb. 12 2005 #sopen_prn, "TIME - ", time$, sclose_prn, e$ #24 hour time output - Ex. 15:52 #sopen_prn, "TIME - ", ptime sclose_prn, e$ #12 hour time output 3:52 PM spathnc$ = ucase(spathnc$) smcname$ = ucase(smcname$) stck_matl$ = ucase(stck_matl$) snamenc$ = ucase(snamenc$) sopen_prn, "MCX FILE - ", *smcpath$, *smcname$, *smcext$, sclose_prn, e$ sopen_prn, "NC FILE - ", *spathnc$, *snamenc$, *sextnc$, sclose_prn, e$ sopen_prn, "MATERIAL - ", *stck_matl$, sclose_prn, e$ spaces$ = sav_spc

comment$ is not a variable, it is a command. You cannot save its value. The post guide does a pretty decent job explaining exactly what the command does but in a nutshell it basically tells MP to dump the contents of the comment buffer. What happens to the individual comments at that point is really up to you to decide. If you are simply looking to capture a comment for output later in the operation in which it appears you can do so by checking for the relevant gcode like we do in our .set files ie. code: pcomment2 #Output Comment from manual entry sopcomment = snull scomm$ = ucase(scomm$) if gcode$ = 1051, smachname = scomm$ #Machine name if gcode$ = 1052, sgrpcomm = scomm$ #Group comment if gcode$ = 1053, sgrpname = scomm$ #Group name if gcode$ = 1008, sopcomment = scomm$ #Operation comment However, if you are looking to use comments in subsequent operations then you will need to buffer the data.

V9: smcpath X: smcpath$ Sorry, can't help with the other issue. I'd suggest contacting your reseller for that.

If the NCI file contains an arc (2 or 3 gcodes) and you are getting linearized output it is generally due to the arc failing one of the arc check routines selected in the Control Definition. These routines are dependent upon the tolerances also set in the CD. I would suggest posting the file using one of the generic posts to see if the arcs process correctly. If they do, then I would suggest comparing the Arc and Tolerances pages from the 2 CD's to determine if any of the settings may need to be adjusted.

Since someone previously mentioned a string selector, I thought I'd throw an example of that out there as well... code: # -------------------------------------------------------------------------- programmer : 0 fq 3 programmer "Enter Programmer's Number [1=Dustin,2=Joe]" # -------------------------------------------------------------------------- # Programmer Name Selector sprog0 #Leave blank sprog1 "DUSTIN" sprog2 "JOE" sprogrammer fstrsel sprog0 programmer sprogrammer 3 -1 # -------------------------------------------------------------------------- pheader$ #Call before start of file while programmer < 1 | programmer > 2, q3 #force programmer to enter a 1 or 2 scomm_str, *month$, "/", *day$, "/", year$, " ", *hour, ":", *min, [if time$ < 12, "AM"], [if time$ >= 12, " PM"] " EC-400 ", *sprogrammer, scomm_end, e$ While a string selector will work, it really does not make much sense to use it in this situation. The point of a string selector is to allow for modal output of strings. Obviously this string is only going to be output once so this mechanism really is not necessary.

Yes sir. All user defined variables (string or numeric) must be initialized before they can be used. I guess I assumed that he had initialized the variable, thanks for pointing out the omission. A quick look in the error log or posting through the debugger (X3) will help in figuring out when variables are not initialized. Edit - I just spotted another thing that may be causing a problem. In the initial post you had the fq setup as: code: fq 3 programmer "Enter Programmer's Number [1=Dustin,2=Joe]" Later you have it as: code: fq 3 pick "Enter Programmer's Number [1=Dustin,2=Joe]" It was correct the first time...

This looks fine: scomm_str, *month$, "/", *day$, "/", year$, " ", *hour, ":", *min, [if time$ < 12, "AM"], [if time$ >= 12, " PM"] " EC-400 ", *sprogrammer, scomm_end, e$ Although the * is not really needed, it will not hurt anything. Just put the logic in like I have it and all will be well.

Just do this: code: pheader$ #Call before start of file while programmer < 1 | programmer > 2, q3 #force programmer to enter a 1 or 2 if programmer = 1, sprogrammer = "Dustin" else, sprogrammer = "Joe" You don't need a separate postblock, nor do you need to do anything in psof$.

pheader$ is called before psof$ so basically you are posting the info before you prompt for it. Move the pcollect call to the top of pheader$. Personally, I wouldn't put the logic into a separate postblock at all, I'd just put the logic right at the top of pheader$ itself. I limit separate postblocks to code that I need to re-use in other areas. [ 09-10-2008, 11:52 AM: Message edited by: Paul Decelles from CNC Software ]

Your MD was not corrupted, unless you consider labeling both On and Off as "On" as being corrupted The NCI did not turn the coolant on because the operations had coolant set to off (ok, the selection said On - but it was really off). The first clue to this was the fact that the options for Mist and Thru-tool were still enabled (they gray out when flood is turned on). I just sent him your MD with the label fixed and your .mcx with the coolants turned on in all ops (they were off in all ops except the last). quote: could also be your .operations file...do a search here for "coolant bug" if the machine def you're using in the local file has the box checked to support coolant commands in post processor for backward compatibility (this is in the machine general parameters) AND your .operations file's machine def is X style coolant they will cancel each other out... Cancel each other out? Hmmm. Not that I have seen. The only thing this will affect is your ability to set the default values for operations, not the actual setting that you put into the operations you create.

quote: How can I change the post so it does not move the table to the g28 position every time the tools change? If you are using the Generic Haas 4X Mill.pst you can just change the setting for tlchg_home: tlchg_home : no$ #Zero return X and Y axis prior to tool change? quote: Also on a second not how could I change the post to output a move to a g154 p99 position if I set it to the front of the machine for a part change position. If you are using the Generic Haas 4X Mill.pst, you can make the change in the pretract post block. Look for the following lines: code: if nextop$ = 1003 | tlchg_home, pbld, n$, *sg28ref, "X0.", "Y0.", protretinc, e$ else, [ if frc_cinit & rot_on_x, pbld, n$, *sg28ref, protretinc, e$ ] Modification would look something like this: code: if nextop$ = 1003 | tlchg_home, pbld, n$, "G154", "P99", protretinc, e$ else, [ if frc_cinit & rot_on_x, pbld, n$, *sg28ref, protretinc, e$ ]

Wait a minute.... Are you saying that we don't suck?!?

Misc Value labels and (default) values are stored in the post processor. Check the selected path that appears in the CD Manager for the .pst file - then check the read only attribute for that file in that location (you may also need to check to make sure you have write access to that folder). Lastly, open the file in a text editor, scroll to the bottom of the file and look at the post text sections (look in the post parameter reference guide (page 4) for more information on how this area functions.

Ron, fmt R28= 4 thfncuts$ #number of rough cuts needs to be: fmt R28= 4 thdncuts$ #number of rough cuts

You are missing the comma after: if (abs(dia_mult) = 2) You also have an ampersand rather than an asterisk in: &thdz1 And you need to remove the space between the asterisk and the variable here: * thdtype You are also missing the s on thdncut Try: code: if abs(dia_mult) = 2, sR19_setting = "R192" else, sR19_setting = "R191" pbld, n, *thdx1, *thdz1, *thdx1, *thdz2, *thdlead, *thdfinish, *thdncuts, *nspring, sr19_setting, *thddepth, e pbld, n, *thdtype, e Alternately you could set up a string selector for sR19_setting but this way will work fine.

thdncut = user defined variable thdncuts$ = pre-defined variable which holds the value from the 8th position of the 200 NCI line. quote: A big question is how do you determine which variables are defined and post variables and which ones are not without documentation to tell us otherwise. Is it always going to be a hit or miss type of thing till it comes out??? Well, yes and no. First off, it does not appear that any of you looked in the .err file to check for errors - which would have told you that thdncut$ was not correct. The information for this is also in the v9.1 post guide and even appears on page 9-40 of the 1997 Post Guide book And, since you are a beta tester you will also get to see some new stuff for X3 before any of these other guys do which I think will help alot. [ 04-14-2008, 04:41 PM: Message edited by: Paul Decelles from CNC Software ]

Check you mail.

Post text is stored in the .pst file, not the .control file. A given post processor can only be added once to a .control file as a Control Definition is defined by a product type and post. You have two choices. Either make a copy of the post, change it's name and add it to the .control file as a new CD (and then import the previous post text sections) or create a new .control file, add the post and import both the post text and other settings from the original .control file. In either case, I would suggest taking the time to visit the Multimedia Page on the Mastercam website. There are videos and other information available there which will help explain how this all works.