X4 includes a (much) improved version of the X3 Post debugger including much better documentation on it's use. All posts, including X3 posts must be run through the update post chook. The chook updates the variable initializations and checks the post for logic errors and potentially changed parameters. There are many threads here regarding the update post process, you may want to read through some of them to see what you are up against.

I should add that automagically commenting out any line with rd_params$ could result in improper output if it was in fact setup correctly. So your mileage will vary....

quote: Paul, could a customize_x.update_mill file for updatepost.dll be made up to deal with this issue ?Possibly. The string entered into the customize.update file must match exactly (including any possible comments). If the line in the post is consistent then it should work. In the case above you would need to add a section like this: code: // Comment out rd_params$ - common in MPMaster posts 1.rd_params$ # Read parameters - pparameter 2.#rd_params$ # Read parameters - pparameter 3.TRUE 4.TRUE 5.TRUE The setting for 5. can be changed to FALSE if this line appears more than once in a post and you want to comment all of the occurances. I'd have one of your post guys give it a try if this is going to be a common issue.

Without looking at the .pst file my guess would be that it contains a rd_params$ command without the required rd_prm_op_no$ variable being set so it is attempting to read operation parameters for operation zero (and of course there is no operation #0). I would try simply commenting out any lines containing rd_params$ (put a pound character at the beginning of the line). The operation parameters are read at every tool change in any case so the call to rd_params$ is really redundant unless it is used to read parameters from an operation other than the one currently being processed (and I have yet to see a post actually using it for that purpose). If that doesn't fix the problem, send a zip2go over to me at [email protected] and I'll have a look (be sure to save the file before creating the .mcx or it will not be included in the zip2go file).

Open the .pst file in any text editor and change the setting of rpd_typ_v7$ to a zero. i.e. rpd_typ_v7$ : 0 #Use Version 7 style contour flags/processing?

thanhson, The folks in tech support forwarded your email over to me. I went through your post and fixed the errors. The single axis rotation error is being output because your tool planes have the X axis pointing in the opposite direction of your WCS (Top). If this is a 3-axis machine you should be able to set your WCS to the same plane as your tool plane to make those errors go away. I'd suggest getting with your reseller for some training so you can fully understand what the plane controls do.

This thread needs to be retitled "Another sure sign that the Apocalypse is coming!"... Jim admitting IN PRINT that he is wrong!?! Un-believable! Can someone sticky this so that it will remain available after Jim fires me? (Jim posting that I am fired incoming in 5.....4......3......2.....)

Why would you have to do this all over again?

Good morning gentlemen, sorry it has taken so long for me to chime in here, I just got back from vacation and I'm still trying to catch up on everything that piled up while I was away. Tony35, can you please send me a zip2go from X4 so I can take a look at your issues? The error log you displayed does not appear to contain any errors that should force it to appear unless you have the CD set to always display the error log. Peon, your error log displays errors that ABSOLUTELY should force the log to pop up. In your case I am happy to see that it is functioning exactly as it should. These lines: 08 Jun 2009 04:08:28 PM - <2> - PST LINE (734) - Missing a matching open bracket 08 Jun 2009 04:08:28 PM - <2> - RUN TIME - PST(785), NCI(94) - The math calculation/formula has an error show me that you have bad logic in your post and those areas should be fixed to ensure that you do not have any issues. Feel free to email me a zip2go and I will take a look for you. As far as the error "severity" changes go, gcode is correct, we fixed a bunch of issues relating to error reporting including adding in messages for errors that were previously missed. The idea with the update post log is to report any issues that are found when the post is updated. Some of the warnings reported there are just that, warnings and some can be ignored. Errors on the other hand should be looked at, either by you or your dealer. One of the biggest additions to the update post log is the parameter warnings. We felt that this was worth adding because the parameter values have changed over the past few versions and we wanted to ensure that you were at least notified that there may be an issue. In looking at an issue this morning we discovered that we missed a few common parameter changes ourselves when we updated our posts and we're working on modifying those posts and the update.post scripts to fix those parameters automatically in the update post process. I'll post something as soon as we have something available.

Has nothing to do with the CD or MD, it has to do with the Misc Values that you set in the operation parameters. mi1 typically determines whether work offset values are output (G92 or G54, G55 style in Fanuc controls, None or E1, E2, etc.. in Dynapath controls). Set the value back to 0 or check the "Automatically set to post values when posting" check box in the Miscellaneous values dialog and all will be well.

By the way, the use of the user defined variable as I have it above is really just optional. You could do the same thing by simply formatting mi4$ for output which would reduce this to 2 lines: fmt "E=" 4 mi4$ #Programmed Hood Height and then n$, "XG0", pfxout, pfyout, pfzout, [if mi4$ = 1, "E=TLLEN"], [if mi4$ > 1, *mi4$], *feed, *speed, *t$, *zclear, strcantext, e$ I tend to load the values into user defined variables by habit as this allows you to get back to the raw value if you ever needed it but in this case, the above would likely be just fine. Hope this helps

If you don't want 0 to output anything, I would go with: code: hood_adj : 0 #Hood Adjustment Value fmt "E=" 4 hood_adj Then in the psof$ and ptlchg$ postblocks: code: hood_adj = mi4$ n$, "XG0", pfxout, pfyout, pfzout, [if hood_adj = 1, "E=TLLEN"], [if hood_adj > 1, *hood_adj], *feed, *speed, *t$, *zclear, strcantext, e$ No need to use an additional misc real value. With the above, mi4$ = 0 results in nothing being output, mi4$ = 1 results in E=TLLEN being output and mi4$ > 1 results in E=whatever value was entered in mi4$.

I'd go with code: hood_adj : 0 #Hood Adjustment Value fmt "E=" 4 hood_adj Then in the psof$ and ptlchg$ postblocks: code: hood_adj = mi4$ n$, "XG0", pfxout, pfyout, pfzout, [if hood_adj = 1, "E=TLLEN", else, *hood_adj], *feed, *speed, *t$, *zclear, strcantext, e$

The MILL 4 - AXIS HMC.MMD is set up with the rotary axis along the world Z axis (where the FRONT plane is B0), not the Y axis as you are attempting to program it (with the TOP plane being B0). I have modified the 4-Axis VMC Machine Def for your use. You can grab it here. You will also need to modify the initialization of srot_z in the Generic Fanuc 4X Mill.pst to change the rotary axis label. Change: code: srot_z "C" #Label applied to rotary axis movement - rotating about Z axis - used when use_md_rot_label = no To: code: srot_z "B" #Label applied to rotary axis movement - rotating about Z axis - used when use_md_rot_label = no [ 03-09-2009, 11:21 AM: Message edited by: Paul Decelles from CNC Software ]

No, it should not remain locked once the posting process is finished. Put together a zip2go and send it to me at [email protected]. I will have a look on Monday.

The easiest method to launch multiple files in an editor is to add them to the list by using the setncstr function. You should be able to modify this code to work: code: sfile = spathnc$ + snamenc$ + sextnc$ #Set file path result = setncstr(2, sfile) #Add to edit list so file will open in editor #2 indicates add, 3 indicates remove from list Update sfile for each file you wish to add (don't forget to initialize any user defined variable you may use, including sfile).

CNCPAREDES, shoot me over an email containing your sim# and I'll be happy to help you. [email protected] [ 03-05-2009, 01:59 PM: Message edited by: Paul Decelles from CNC Software ]

No worries Phil, at least you are willing to approach it with an open mind. BTW, check your email...

Try pressing the play button. 30 seconds with the documentation wouldn't hurt either. And since reading is so passe' there is even a video tutorial available on mastercam.com

Changing (or adding) an initialization for sextnc$ in the post is not going to make a difference. The initial value for this variable is taken from the Control Definition setting (.nc in this case), any initializatrion in the post is basically ignored. You can override the value in the pprep$ postblock, which is the last postblock visited before the NC file is created (such as in a .set file) but that solution will not work for you in this case because you have not prompted for which machine you are posting to (I'm guessing you placed the question prompt in pheader$ or psof$). So, the only solution available is to rename the .nc file after processing using the ppost$ postblock. Here is the code you will need to achieve this: code: #Define variables used for file rename sorgncfile #Original NC file path and name sprgncfile #Renamed NC file path and name with no extension snoext #Empty string for file extension machine : 3 peof$ #End of file for non-zero tool #Place this this code at the end of the peof$ postblock... if machine = three, #If machine = 3 create new file name [ sorgncfile = spathnc$ + snamenc$ + sextnc$ sprgncfile = spathnc$ + snamenc$ + snoext ] ppost$ #Rename the NC file if machine = 3 if machine = three, #If machine = 3 remove .nc extension [ result = fclose(sorgncfile) #Close original NC file result = remove(sprgncfile) #Remove renamed file if one already exists result = rename(sorgncfile, sprgncfile) #Rename original NC file result = setncstr(2, sprgncfile) #Add to edit list so file will open in editor #2 indicates add, 3 indicates remove from list ]

Glenn, The debugger does list the user defined post blocks (the ones without the $) as long as they are not inside of the binned portion of a post. Why don't you give me a call next week. I'd be happy to set up a gotomeeting or something and I can walk you through the debugger, including the X4 enhancements (you are looking at the beta right?)

No.

Look in the help file in Mastercam: C-Hooks/NET-Hooks - supplied with Mastercam. It contains a complete list along with a description for each.

File extension information (from the Generic Prototrak 3X Mill.pst header): code: # -------------------------------------------------------------------------- #File Extensions: # The default file extension for this post is .CAM which is recommended for 2-1/2D programs. # When the customer loads the file as a .CAM, the control software converts the program to the .PT4 format. # This will allow the user to view / edit the programs thru the Program Event screen. # 3D Programs require a .GCD file extension. This tells the ProtoTRAK control that you want this file to # run directly, without converting. # If uploaded as a .GCD, the Program / Event screen will be disabled. In order to edit the program, # use the G-Code Editor in the Edit Mode. # When running the program, the controller will buffer in a few lines at a time from the memory device. # If the customer is okay with this, then he/she can use .GCD to run 2-D programs. # -------------------------------------------------------------------------- You can change the NC file extension in the Control Definition as needed. The post will work fine for SMX, SM, VM and MX3 controls.