It's been covered several times, here is the thread with the best explanation -> single axis rotation

quote: The Heidenhain posts that come with Mastercam don't work very well and I don't know enough about Heidenhain code to make the changes I need to the post. Which Hedienhain post(s) did you try?

Look for it in this string variable -> strtool

or... code: *e #Blank line

Millman, quote: Correct me if I am wrong but you can have a G41 or G42 on the same line or a G40 on the same line as a G03 or G02. The only thing is that you need to have enough room to engage cutter comp is all. I wonder if there is a parameter on the Hass that doesn't allow this Rekd? You're corrected You cannot activate/deactivate comp. on a G02/G03 circular motion block. Not on HAAS, not on FADAL, not on FANUC (even though I've had people claim they could). Heidenhain... maybe there is a Heid model that can. The only time I've ever seen this work (succesfully) is on a Giddings&Lewis HMC with a Numeripath-8000 controller. A few years ago I was in a car mfg. facility (a 'Big 3' plant where they make special stuff) and they were telling me "Oh yeah, we can do that". I did not beleive them, and they proved me wrong!

Ah... I see what you described. I know that using the 2-Buffer method, if there where FD comments output to the post, you did not need to [/i]output[/i] the FD comment to the NC file. Or you could output the FD comment anywhere you wished in the NC file. I know I tested that! But if no FD comments were in the MC9 file or you did not output them to the PST, then you got no 1st OP comment(s). A lesson to be learned here... Don't do post work late at night while watching TV Here is an easy fix for the 2-Buffer method. Alter the "poutput_comments" postblock to be this -> code: poutput_comments # Output any SOF Comments 'other' than any FD commnets if EndMarkerIndex > 0, # Comments AFTER the File Descriptor were saved to Buffer 2 [ size2 = rbuf(2, 0) # Get the size of Buffer 2 while (rc2 <= size2), [ stemp = rbuf(2, rc2) "(", stemp, ")", e # Output any "non" FD comments ] ] else, # There wwere NO FD comments, so any 'other' comments are still in Buffer 1 [ rc1 = 1 # Reset the read index to the start of Buffer 1 size1 = rbuf(1, 0) # Get the size of Buffer 1 while (rc1 <= size1), [ stemp = rbuf(1, rc1) "(", stemp, ")", e # Output any "non" FD comments ] ]

Millman, Adding the COMM_CNT : 0 would make that error disappear, but the output will not be correct. AVS, I thought that I'd changed all those 'one', and 'two', references. code: pscomm0 # Comment "pre-read" posblock if sof = yes, scomm0 = wbuf(one, wc1) # Save the string to Buffer 1 The 'one' in the above line is the reason for this in the 2-Buffer samples. You can add the definition for 'one' like you did -or- change the (one, wc1) to-> (1, wc1) I'm used to using the 'words' since they are defined in the MPFAN & MPMASTER type posts. code: m_one : -1 #Define constant zero : 0 #Define constant one : 1 #Define constant two : 2 #Define constant three : 3 #Define constant four : 4 #Define constant five : 5 #Define constant c9k : 9999 #Define constant Then I realized that people may be plugging this code into PSTs that don't have these definitions and changed 'em all back to digits. Missed that 'one'

quote: "Variable not defined: comm_cnt Post line number 742 Program execution halted due to error(s) in .pst" COMM_CNT is a pre-defined MP variable. You would not need to declare it. Contact your Dealer to upgrade your MC.

A quick look in the latest MPMASTER for each occurrence of "G43" reveals three places where you would need to make alterations -> In the PSTOP postblock -> * Change this -> pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, pfcout, *speed, *spindle, pgear, strcantext, e * To this -> pcan1, pbld, n, pfcout, e pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, *speed, *spindle, pgear, strcantext, e In the PTLCHG_COM postblock -> * Change this -> pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, pfcout, *speed, *spindle, pgear, strcantext, e * To this -> pcan1, pbld, n, pfcout,, e pcan1, pbld, n, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, *speed, *spindle, pgear, strcantext, e In the PTLCHG0 postblock -> * Change this -> pbld, n, sgabsinc, pwcs, pfxout, pfyout, pfzout, pfcout, e * To This -> pbld, n, pfcout, e pbld, n, sgabsinc, pwcs, pfxout, pfyout, pfzout, e

Subject: Separating File Descriptor (COMMENTS) from Operation (COMMENTS) As simple as (comments) may seem they are handled quite different than other NCI data. I cannot explain everything here (see the CHAPTER about 'comments' in the Post Processor Reference Guide) The short lesson is... MP reads the comment lines that appear before the PSOF and PTLCHG data in the NCI and saves them in an internal string array. (You cannot directly access this array from the PST.) When the PSOF and PTLCHG postblocks are processed the contents of this array are dumped to the NC file. Where the comments get output depends on if the 'comment' command word appear, and where is appears. This 'comment' command tells MP call the PCOMMENT postblock. The PCOMMENT postblock is called for each comment string that was saved in the array. If the 'comment' command does not appear in the PSOF and/or PTLCHG postblocks, MP will still call PCOMMENT, just at the start of the PSOF and PTLCHG postblocks. So the 'comment' command word lets you "place" the (COMMENT) where you want them in the toolchange code sequence. As mentioned earlier, you cannot access the internal string array, but you can do this... You can "see" (and capture) each COMMENT string as it is read from the NCI data file. Knowing this, we can save out the COMMENT strings into our own Buffer. MP has many 'pre-process' postblocks, such as PLIN0, PCIR0, etc. You probably don't see any of these in your PST, as there are rarely needed, but when you do need them - you can't beat 'em! You use the PSCOMM0 postblock to accomplish the "capture" of the start-of-file comments. This postblock is called immediately each time a comment is read in the NCI file. The comment string is passed to the PST in the 'scomm0' string variable. A critical note here... Since we have done an end-run around the posts usual comment processing, we must be sure to reset 'comm_cnt' -> comm_cnt = 0 # MUST clear MP's "internal" COMMENT buffer counter! If you don't the (COMMENT) will get output TWICE. Once by our special comment processing and again by the std. (internal) comment processing. By setting 'comm_cnt = 0' we make the PST think that there are NO comments in its (internal) comment array. That's all fine, but the method of how you capture them depends on what you want to do with the separated File Descriptor comments. "I just want to separate the File Descriptor Comments from the Operation Comments" really doesn't answer that! If you know that you are always going to output the FD comments to the NC file before the Operation comment, a method using ONE buffer file will suffice. -or- For a bit more flexibility you could use a method that involves TWO buffer files. (This method is not really much more work than the ONE buffer method) I submit for your perusal several sample Posts that implement both of these schemes. ONE Buffer & TWO Buffer versions of the std. MPFAN.PST and the MPMASTER.PST post processors. (See the FD-COMMENTS_POST.ZIP located in the Posts folder on the forum FTP) This really neat thing about this is that it is very easy to drop this code into a PST. Search the the "ADDED" tag to find the (3) areas where code was addled to the MPFAN.PST & the MPMASTER.PST samples. The 1st ADDED section is a self contained section of code that handles the buffering (writing to & reading from). The other 2 ADDED sections are the commands that dump the FD comments and OP comments (where you want them) to the NC file. The MPMASTER versions have a little bit different logic using the 'sof' flag because of how it uses a 'ptlchg_com' (Tool change common blocks) and the the MPFAN.PST does not. *IMPORTANT* (Other than "Make a BACKUP of your PST - BEFORE doing anything with it!") -> These methods depend on you having a "special" ending line in your File Descriptor. This "special" marker is defined in the string variable -> strEndMarker "*end*" # Look for this to designate the END of the 'file descriptor' COMMENT lines Note that it would be easy enough to restrict the search for this 'ending' marker so that it must appear at the START of the line, but if you accidently had a before it, you would not "see" it. You can use whatever string you wish. You could use "*" if you wish. It's just that this string cannot appear ANYWHERE else within the FD comment lines! "So choose wisely grasshopper"

The Manual Entry method is certainly a usable solution. quote: I believe they both come out as nci lines 1008 so I don't know of an easy way to separate the file descriptor from the first operation comment. This statement is correct, the File Descriptor Comments & Operation Comments are both '1008' in the NCI It is possible to break them up. But, you must have some method of designating one from the other. One way to to preface the File Descriptor Comments with some "special character" that will never appear in an Operation Comment. You could use something like '$', or '*', or maybe '(' [Many controls cannot handle nested '(' or ')' within a (COMMENT) line.] You would enter your File Descriptor text, something like this -> *This is the 1st line of my file descriptor *This is the 2ndt line of my file descriptor *This is the 3rd line of my file descriptor Note: The special prefix character can be srtipped out from each line so that it does not appear in the NC file. You Operation Comments could not contain the 'special character' -> This is the Operation Comment for Tool #1 If your are OK with that 'restriction', and willing to do a bit of post modification - it can be done. ----- Brett was too fast for me. Yes, you could also have some special 'throw away' line that ends the File Descriptor. That way you know that any '1008' [i[before[/i] that line are the File Descriptor and any '1008' comment after that is an Operation Comment. I'd prefer not to use the SUBOUT functionality since the Post may already be using that for other purposes. Use Buffer files to save off the Comments, and read 'em back in where you want them placed.

Actually, there are more than a dozen (industrial) MC customers in Hawaii. Sorry James, don't have a breakdown by island. It's been awhile since I've been to Kauai. Very relaxing place. quote: run up and down the Wiamea Canyon roadOnly problem I had was by the time I got up to Kokee Lodge, the fog was so thick you couldn't see much more than 10 feet. No choppers flying that day! James, enjoy...

CMR, It may be caused by some of the characters in that comment. Some controls do not allow certain characters in a (comment line). I'm not positive if the HAAS is one of them that is picky in that way.

CAMFUN, Your PCOMMENT postblock -> code: pcomment # Manual Entry - COMMENTS (on a block by itself) 1005,1006 if gcode=1005, pcomment1n # output comment with seq if gcode=1006, pcomment1 # output comment w/o seq if gcode=1007, pcomment1l # output comment with line The Operation Comment is 'gcode = 1008', which is not being tested for.

Add the "*" (asterisks) to to varaibles you want "forced" out. code: pcirm # Circular interpolation pcan n, sgplane, e n, sccomp, e pcan1, n, sgcode, *x, *y, z, pijk, pfr, strcantext, e pcan2 n, e Note that if this machine can do arcs in the XZ or YZ plane, you've got a problem with this PST code - since it will always force X & Y to output on every arc motion block.

Was not too concerned about a few empty folders. Start poking around in your Windows system are you will find a lot of old junk. Here are just a couple of them (XP Pro) -> Where USER ID = your logon profile ID C:Documents and SettingsUSER IDLocal SettingsTemp = (50 folders & 455 files) C:Documents and SettingsUSER IDUserData = (200 folders) These 200 folders are all like -> AZMJY9ER GT4LYVW5 IHCF2525 KLAVCL67 XKC9M81K But I'm not going to bother to delete 'em !

quote: Is it possible to setup MC to save all those temps file in the c:temp or read the Windows registry setting to get the temp file location? You can set the Tempoary File path in the configuration (The Data Paths on the Files tab page) quote: If MC can do this, we will end up having a single temp file location and no need to go thru all those hooplas to delete them... Does this really gain you much? If you leave the MC temp files in their own place, you know exactly what you are deleting. If you delete everything in your C:TEMP folder, you may have other programs on your system using that folder, and they may not like that. For Iskander teh multi-tasker. DEL can also do subdirectories (all least with Win 2000 & XP) ->> DEL C:MCAM91COMMONTEMP*.* /S /Q

James, You will get "numbered" sub-folders in C:MCAM91COMMONTEMP -> if you run multiple MC sessions at the same time. Each session needs it's own set of temp files. To see this... 1> Delete everything in that TEMP folder (including sub-folders) 2> Start up MC, and look at the contents of the TEMP folder. 3> Start up another session of MC, and look at the contents of the TEMP folder.

quote: The problem is that it doesn't show up in backplot, verify, or the graphics at the machineThat it does not show up on the graphics at the machine is interesting. You can set a maximum radius allowed, in the PST (altered or add if it does not exist) -> maxrad : 999 # Linearize any arc larger than this

James, Check it out in the MPMASTER.PST There is a 'hel_2100' option switch that when enabled will call thru to PCIROUT2 -> PHELOUT

James may be slow at math, but he can type pretty fast. MayDay, How you approach this depends on when/where you need the codes to output. If you can just turn ON the mode at the toolchange and off at the end of the tool - you can go wih James' method. BUT, If you need to turn the mode ON/OFF at each change in G0->G1 or G1->GO, that approach is not going to work for you.

Got to make you beg - just a little... Check out the MP_EZ-HiSPeed.ZIP in the Posts folder on the forum FTP site.

MayDay, Like this? This is not hard-coded in the 'sgcode' string selection. code: % O0001 (PROGRAM NAME - SURF-ROUGH-CONTOUR-ENTRY-EXIT-ARC ) (DATE, Day-Month-Year - 10-02-04 TIME, Hr:Min - 13:59 ) N100 G20 N102 G0 G17 G40 G49 G80 G90 ( 1/8 FLAT ENDMILL TOOL - 2 DIA. OFF. - 2 LEN. - 2 DIA. - .125 ) N104 T2 M6 N106 G0 G64 G90 G54 X9.75825 Y5.15887 S4278 M3 N108 G43 H2 Z3.06353 N110 G1 G64.1 Z2.71353 F6.16 N112 X6.44703 N114 G0 G64 Z2.96353 N116 Z3.06353 N118 X6.41202 Y5.25733 N120 G1 G64.1 Z2.71353 N122 X9.79326 N124 G0 G64 Z2.96353 N126 Z3.06353 N128 X9.79626 Y5.35579 N130 G1 G64.1 Z2.71353 N132 X6.40903 N134 G0 G64 Z2.96353 N136 Z3.06353 N138 Y5.45425 N140 G1 G64.1 Z2.71353 N142 X9.79626 N144 G0 G64 Z2.96353 N146 Z3.06353 N148 Y5.55272 N150 G1 G64.1 Z2.71353 N152 X8.6619 N154 X8.65585 Z2.71737 N156 X8.65525 Z2.71876

quote: My understanding is that all I should need to do is modify the post .txt file with the text that I want to input, then select it from the canned text dialog. Not quite... Mods will be need in the PST to support the functions that you define in the TXT.

James, FYI... It's not too difficult to do the Cinc helix format with the 'K' pitch for those machines.