I think I might have found the culprit here. I can duplicate the problem only if I turn on "use tools step, peck, coolant" option on the tool settings page of your machine group. If this is toggled on, then the change does NOT stick. With it off it is working fine. Check your setting and try it and let me know what happens.

I've been using Tab and the mouse as well and still not able to see the problem in MU3. I'll keep playing with it to see what I can dig up. Iw as able to see the problem at one time, but like I said earlier I thought we addressed this in one of the X4 MUs.

Gramby, How are you going from field to field - Enter, tab, mouse???

Gramby, I'm trying to duplicate this in MU3 right now and can't. If I remember correctly the Depth cut order radio button was one of the items not retaining it's setting but it seems to be working for me, but as I stated earlier it does depend on your steps. Please list the steps you are performing in order so I can follow the exact same steps.

PM, One of my QC staff gave me a heads up that they have received emails from your reseller and are following up on them.

What version of X4 are you guys using? I thought we had fixed this behavior and I will follow up on the specific version we did so in. The problem stems from when the edit field gets validated. It should get validate (value accepted and retain) when either using Enter to exit the field, Tab to move from one field to another or even clicking on another page in the interface. Obviously the Apply button would validate the entire page as well. I can't remember the exact steps to cause the problem, but that is why you don't see it every time as it is tied to either enter/tab and then switching pages. Like I said I'm pretty sure we fixed it and i will need to go through the versions and log to figure out if we did and what versions.

Without seeing the part and post I can only take a guess at to what is happening but before I do let me add some information here. First, the default work offset value in Mastercam operations is -1. This -1 is a flag to Mastercam to figure out the work offsets automatically. Now if you DO NOT want mastercam to figure them out, then set it to something other than -1 (what to set it to is based on your post setup). Mastercam puts work offset holders in the binary nci which is the data for the operations. The actually Work offsets does NOT get set until you select the ops and press the post button. so in the case where you are doing each operation separately and getting G54 - that is becuase onyl one op so it uses the first available Work offset (0 in the NCI) produce G54 in the NC, but when all together you get G54 and G55 doesn't surprise me but somewhere Mastercam found a change in Plane or tool origin and incremented those ops to G55 (1 in the NCI). The actually offset isn't calculated until it goes through the operations selected for output. Mastercam use a changge in Toolplane (view) and/or a change in tool origin when deciding when to add a new Work offset and when to use an existing one. second, The actual values that need to be entered in the Work offset field of the operation all depend on how you post is setup. posts leaving CNC Software are setup to handle a value of 0 and up. 0 represents the first work offset value (G54 - fanuc, E1-fadal, etc), a value of 1 represents the second work offset value (G55/E2 as precious example), a value of 2 represents the 3rd and so on. So in the above post where PM changed the work offset value from -1 (auto) to 1 and got a G55, that is exactly what he just told his post to do. Now the problem with that is the other ops that have -1 - auto - will try and match an exisiting work offset so because they are the same plan and origin as the ops set to 1, they also will get set to 1 - because they were set to -1 and left it up to mastercam to figure out. Lastly, leaving work offsets to -1 without undestanding the rules built into Mastercam can be frustrating but you can always force the work offset values by setting the actual value in the operations and can do so for a bunch of ops at one time using the edit common parameters function. PM, I suggest you send the original file to [email protected] and let us take a look at it and we can figure out what is causing it to go from G54 to G55 so you have atleast a heads up as to what the trigger was so as to be on the lookout for it. It is very possible that Mastercam did exactly what it was supposed to do with the offset values, but that doesn't mean it's not an issue. when you send it to QC, refer to this thread in the email so they can followup on your issues and my comments.

We received your email and our policy with the sim emulator issues is that you will need to contact your reseller for help evaluting the machine and trying to remove the emulator. Just an FYI, if none of the suggests provided work, you will need to format your hard drive to remove it. Not plesant I know, but it has been needed in the past.

Gcode, I can't reproduce the multiple points created with facing either. tried both changing the oepration and regening a dirty op, regen cleaned op multiple times, etc. I am using actual point data created by me for my point selection. The only time I can get the system to create points is the first time I create the operation and just sketch pick to locations, then I get 2 points created on the active level. Even here doing regens both on clean and dirty operations I can NOT get extra points or even those points to be recreated on the new active level. If you have an example, please send it up. Thanks!

Mayday, No problem. Whenever you have time to get files, great. in the meantime we will keep poking around based on the information above and see what can dig up.

Chris, thanks for helping clear it up. Where and when is facing forgetting the points? what is being used that shows the points are forgotten. I'm playing around with it try to get it go forget points and obviously I am missing something because it is keeping my points.

Mayday, i can't seem to duplicate the grove op issues you are experiencing. So can you send up a part with steps to reproduce or just give me the exact steps here. Facing drops the points every time, please define drops. If you haven't these should be sent ot QC at [email protected].

F-20 is probably a F-2. -2 in the NCI means it is a rapid move and no feed is present. Look at your drilling code and change fr$ to fr_pos$ or frplunge$ as suggested above. Depending on how old the post is it may need to be update some because the NCI layout for drilling changed back a few version and when using fr worked back then it doesn't now.

There is still something wrong in the post in that the selector variable with a value should never have a value out of range. Now this error probably occours because of WHERE and WHEN the string selector is being used int he post under the case you found. Again, easy to fix and address with the post and the MCX. I'm betting without seeing the post is is being caused by sgcode and the gcode selector variable. sgcode in a post is used to produce the G), G1, G2, G3 and G4 output and is based on the value of gcode. Gcode gets it's value from the NCI and if you try to us sgcode at the wrong time, it will NOT have a valid value - it's the internal NCI gcode used in our 2 line NCI structure. Just a guess without seeing the post and the MCX.

hmm....uninstalling X3 should be causing this issue for the first time unless you are now pointing to a different file. Do all drill ops cause this error during posting or just in this particular file?

The problem is realted to the value in the string selector variable. Because it shows a value of 1011 - which i know is the NCI value for Misc Values I would say that the string selector is being used at the wrong time. Did you recently make a change to your post? Without looking at the post to evaluate the string selector and how it is being used I can even point you to a specific area. Contact your reseller and send them a Zip2go file and it should be an easy fix.

Ron, The problem is definitely the use of the postblock variable pfxout in those formulas. The older version would have reported this as well if you check the error log. I'm not sure how MP would handle it as it processed but I'm guessing it would ignore the pfxout and continue on with the calculation or it would use the value already in the target variable to the left of the = sign. PFXOUT postblock is just used to control forcing of the X output, based on Abs/Inc setting. Hope this helps!

There is nothing in the MP language that will give you that type of information. You could write a utility that queried the login ID, wrote it out to a TXT file and then in your post open the TXT file as a buffer and read it in. Just a thought. I'll definitely add a enhancement request for MP to see if there is something that we can do behind the scenes and store it off in a predefined variable.

zoober, Post the area of the post around line number 2351 and make a note on which line of the code you displayed is line number 2351 and let me have a look.

Ron, after another quick look.. Are these the lines causing the problem? code: zsinsurf = (pfxout + drl_prm2$) in our posts pfxout is a postblock and not a numeric variable? Check your post to make sure pfxout is NOT a postblock

ron, it sure would be nice to have some lines numbers up with the code otherwise we will beat ourselves to death trying to help.

The line being reported to have the duplicate is the second occurrence. You need to search your post for other occurrences of the same variable to find the problem and then determine which one is correct.

drilling more than one hole causes 2 predefined postblocks to output. the first hole of every operation goes through the appropriate firs thole drilling postblock (pdrill, ptap, ppeck, etc). All subsequent holes in a drill cycle will go through the _2 postblocks (pdrill_2, ptap_2, ppeck_2, etc). Now all custom drill cycles will go to pdrlcst on the first hole and pdrlcst_2 on subsequent holes in the operation. If you want to use custom drill cycles then you will need to use the pdrlcst and pdrlcst_2 postblocks to check on the specific custom drill cycle and then make calls to new user defined postblocks for each specific cycle. If you are still having problems I suggest you contact your reseller.

Entry point errors usually mean the wrong version of a DLL is being used. without knowing much about your system and install it could be simply a pat issue pointing to the wrong version of updatepost. Check your config paths and make sure everything is pointing to where you installed X4.

Randy, The FS2 section is NOT predefined or standard, however posts that leave CNC do try to follow the same definitions but anyone can add, delete and modify this section as needed so it becomes the post writers choice here. ofcourse even with thew above error you would get NC output but the numerical formatting would not be correct. Format statement #1 would have been used automatically for formatting the output of the varible because #21 was not defined. Now if we were not reporting these errors you could potentially have a problem at the machine depending on what the value was and what the value was being used for.