Sorry I am late into this, haven't been looking in here since the new forum went live. We ran into an issue early in X7 with file paths in some foreign languages that I thought were resolved, this may be related in some way. I'd like to see if we can determine your issue so we can address it so others do not have the same issue. Our best bet to start is to look at your exception log file as this should contain information that will help. If you could email me that file along with the full path that you were trying to post to I will hand it over to my developers so they can have a look. The log file can be found by opening Windows Explorer and typing %TEMP% into the address bar. This will bring you to your system temp folder. The file we need is 'CodeExpert.Exception.log' If you can email that to [email protected] and mark it attention Paul I will jump on it as soon as it comes in. Thanks

Use the Lathe Chuck Misc Op. Set the right spindle to 'Un-clamp' and check 'Eject stock'.

http://www.emastercam.com/board/index.php?showtopic=25229entry173003

bug4$ is used to determine output of a variable when a tilde appears in front of it. (i.e. ~xabs) This is an 'old school' method for quickly seeing what the value is without the formatting usually applied for output without launching the debugger, placing a watch on the variable, adding a break point and processing to the point where you need to know the value. We added the comment several versions ago to help explain the difference in output when bug4$ is initialized to a zero versus a positive number.

Justinu and Machineguy, I am sorry but I am going to need example files so we can see the issues you are describing. I'll be happy to take a look and get the issues addressed if you can get files to me. Shoot the files over to QC and tell them I asked for it. Thanks

Op. 3 - You need to fix your lead in, it is going the wrong direction Op. 4 - You will need to change your defined jaw step so the geometry you are trying to cut is not behind the face of the jaws (try changing your width step to 1.0 from 1.7). I would also recommend rechaining to include the chamfer at the end of the chain and to extend the end of the contour in lead out settings so op. 7 does not plunge into the remaining stock with the entire insert Op.5 - Turn on the 'Extend contour to stock' option so the tool cuts all of the stock and does not start embedded in the remaining stock (if you end far enough in op 4 this is less of an issue). Your boring bar definition for T6 (operation 8) is bad. You will need to modify the settings or select a different tool

Font and Font Size are not currently definable in Code Expert. It is something that we are working on adding for the next major release (along with a bunch of other enhancements). The best you have for now is the zoom capability as mentioned.

Mick, We have been doing work in this area and I am hoping your issue is addressed in the next release. Would you mind sending us your file exhibiting this error so we can have a look? Shoot it over to [email protected] and let them know that I asked for it. Thanks, Paul

The error is caused by the setting of rotaxtyp$ which is set to 1 or -2 based upon the Z Axis orientation in the Machine Definition in modern 4-axis Mill posts (i.e. Generic Fanuc 4X Mill.pst, MPFan.pst, MPMaster.pst, etc... derived posts) - look for the psynclath$ postblock, that is where it is set. You have a considerable amount of work to do if you desire to change that setting and covert the post to properly process 5-axis motion. Send your resume to the post group if you do manage to get it working

*e$ does the same thing.

I would recommend adding .all as another NC extension so Code Expert can associate it as an NC file. Go to the 'File' tab at the top left corner of Code Expert, click 'Options', go to 'Editor', 'All Languages', 'NC', 'File Extensions'. Enter all in the text field. Click OK. That should do it

We have already fixed this for the next major release and I am working to add it to an upcoming MU.

Michael, This issue has been addressed and the fix will be included in an upcoming SP or MU.

We'll see if we can get the vbscript help rolled into Code Expert's help for the next release. And, I do have good news on the saving with no extension issue. We will have a solution for this in the next release.

I really do wish everyone did everything the same way. Imagine how much easier life would be if everyone did everything my way We can't even get people to agree on default settings, never mind for all of the settings that would go into building operation libraries (especially (gasp) metric defaults). Be careful what you ask for, you could end up doing everything Thad's way!

One additional question... Were you in the CD Manager itself? (i.e. Settings drop down - Control Definition Manager - Open a File) or were you trying to edit the CD via the Machine Definition manager?

Easiest to do: pbld, n$, sg00, "G53", [if nextop$ = 1003,"Y0"], "Z0." e$ in pretract and nothing in peof$. We call that an "inline boolean". You will see other examples of that type of thing in other output lines in modern posts (ie posts developed after X was released). I should likely also point out that getnextop$ must be initialized to 1 in your post for the logic to work (should already be in your post but add it if it is not). getnextop$ : 1 #Build the next variable table

If you are getting line numbers output with nothing else it is most likely due to the n$ format being set to non-modal. This commonly occurs with old posts that have been updated. Prior to X MP treated n as a "special" variable and ignored the non-modal setting on a format statement, this is no longer the case. Look for the fmt for n$, find the fs or fs2 it is using and make sure it does not have an n at the end. You may have to create an additional fs or simply point to another pre-existing fs to fix the issue.

Um. No. All of the clamping/unclamping logic is exposed. You should be able to modify the lines like: #Lock rotary axis if use_clamp & (cuttype = zero | opcode$ = three | opcode$ = 16), in p_goto_strt_tl, ptlchg0$ and pclamp. opcode$ 3 = drilling, opcode$ 16 = 5-axis drilling. Remove those parts of the logic and clamping on drilling will not occur. ie #Lock rotary axis only for toolplane rotary positioning if use_clamp & cuttype = zero,

Please keep in mind that the calls to pcan, pcan1 and pcan2 are used to determine output for all canned text options, not just x-style coolant. Moving the calls may in fact fix your desired output in this specific case but may also adversely affect any other canned text output you may desire during a toolchange. Leaving the calls where they are and adding additional output flags and variables may in the end be a much better solution. Of course the logic is going to be a bit more complicated - but then again, nothing worth doing is ever easy eh?

Check the NC Precision setting in your control definition. This controls the precision at which arc error checking routines (among other things) are performed and will subsequently affect output. If your setting is .0001 you will not see five place output in arcs in your NC code.

This should help. The attached .zip file contains a simple post I threw together a while ago for post training. It dumps all of the available comments. Comments-X5.zip

Machine group name is output as 1053 (standard comment processing). Toolpath group name is output as parameter 20018

Use parameter 20018

It is not that lturret$ should not be used in the post, it is used in most of our lathe posts and is an important variable for proper processing when more than one turret/spindle needs to be handled. The problem you ran into is that the value in the NCI was incorrect. Your machine has a single (right) turret and is limited to a single axis combination which defines the value that is supposed to be written into the NCI (and subsequently loaded into lturret$). What you ran into occured when you redefined the tool as being mounted in the left turret (which does not exist) after the operation had been created which then (and here is the bug) incorrectly wrote the turret info to the NCI. Regenning the operation after this re-implements the axis combination setting which in turn corrects the value in the NCI (which is why you get proper output in the end). Apparently the bug has been found and corrected for X6, I'll make sure to check on it to ensure it is addressed before release.