X5 has been officially released and is available for download here Mastercam X5 Download Page You should also consider downloading the installation documentation and reading it prior to installing X5. Also make sure to review the Update Folder feature in the file menu as this is the function you should use to migrate your files from a previous version and update them. Update Folder has been improved to automatically call updatepost to update your post when Machines or posts are selected for updating. Enjoy!

Just a little forward warning prior to everyone rushing out to install and run X5. We have completed RTM. RTM for us is Release to Manufacture which means everything is being readied for the official release - DVDs, servers, websites, packaging, ordering, etc. But just as we have an RTM check point, the users have their own RTM check point and that stands for Read The Manual, specifically the installation and getting started guide. There are some basic changes to the install program, the installation folders and file structure as well as file extension changes and you should make yourself aware of them by using your RTM checkpoint. There is NO migration in the X5 installation so read up on the Update Folder function under the file menu. This feature will allow you to process your previous version files into the new X5 formats and file structure. The installation guide, admin guide and Transition guide will all be available on the X5 downloads page when it goes live - which will occur sometime during the morning of Tuesday Nov 9 2010.

no harm no foul Evil. Everyone wants to be the hero and be the first to delivery the news and we appreciate the the help, but it is just a little safer if you let us do it. We are performing some last minutes tests and updates on our download servers and service which is hosted by a 3rd party so please be patient and wait for the official notification that it is released. Everything is looking good, and we should be official Tuesday morning. Better get me some rest tonight.

Manual entry has an option for "Use text file" which would allow you to specify a text file out on your system that it would read and use for the manual entry text. Another option is to use canned text and just configure a specific post call for this code that gets called anytime the canned text option is added. Using the canned text method requires post mods while the manual entry does not. hope this helps.

When you edit a machine definition Mastercam needs to load it into the current database so it asks if you want to save the current MCX data off first. The machine definition allows for geometry to be part of the machine def and when editing a MD it would need to load the geometry as well which is why the MCX needs to be saved first. Currently the machine being edited isn't opened so it doesn't know if there is actual geometry to load or not when the machine is loaded for edit. I don't remember being able to turns this off Randy, but I will check into it for you.

You can NOT force out a postblock with a *. pxout, pyout, pzout and prdrlout are all postblocks and adding a * to them (pxout) will NOT work. You need to go into the postblocks themseleves and find the appropriate output variables and add the * to them. In our Mastercam posts there are also specific postblocks used to force XYZ which are pfxout, pfyout and pfzout so replacing pxout with pfxout would work for them but no such postblock exists for prdrlout. John's suggestion would also work for the refht but you have to be careful to make sure NO other variables are formatted with the nonmodal format statement or they too will be forced out.

Do you have any other Mastercam versions installed on the 64bit system? We've been fighting this problem for a long time now and still not convinced we have it nailed down completely but we have had some success with HASP drivers causing this. Here are some steps you can try to see if this helps. Use will need to use the command promtp for these steps. [*]For each install of Mastercam, go into the Mastercamcommon directory with a command prompt. [*]Run the following two commands: a. hinstall –r –alldrv b. haspdinst –fr [*]After doing this in each install of Mastercam, go to the control panel and remove any HASP Driver entries. Be sure to check under ‘SafeNet’ as well as ‘Hasp’ and ‘Aladdin’. [*]Reboot the machine. [*]In the Mastercamcommon directory, run ‘HASPUserSetup.exe’ to re-install the latest HASP drivers. You can run this from explorer, you do not need to run this from the command line Please post back to this thread to let us know if this worked for you or not.

Colin, I'm not sure the work offset functionality in Mastercam is covered in our posts docs but I will check. i was going to tell you to use the Mastercam help until I opened it and read where it says quote: entering -1 in the offset field will result in no offset code being generated , which is NOT true. The key to remember here is -1 ALWAYS tells mastercam to determine what value - offset to use. And by offset I don't mean based on your machine. It gets a little tricky but here are some things to help. [*]-1 allows Mastercam to determine when and what offset value to use [*]Offset numbering in Mastercam always starts from ZERO and increments by 1 ie 0,1,2,3,etc [*]Mastercam offset values are controlled by change in plane (view) and/or tool origin [*]When -1 is active, Mastercam uses the other other planes and operations already created to determine to use an exiting offset (matching plane) or create a new one [*]When using -1 and a new offset is warranted (change in plane/origin) Mastercam will always start with the lowest available number. IE. IF you are entering a 55, 56, 57 for your offset values in the toolpath and you create another toolpath with a -1 and Mastercam determined it met requirements for new offset it would enter the next available value starting from ZERO and NOT from the highest number entered already. [*]The actual value written to the NCI is just the an integer value (0,1,2,3,......100,101,102...etc) [*]There is no way to control the Start numbering and increment in toolpaths - the only exception is using transform toolpaths [*]When using transform toolpaths you must understand that when a copy of the operation is created the settings (off, maintain, start, increment) for work offset in the transform operation will be used, but off doesn't really mean off. The default work offset value for ALL operations is -1 and -1 is automatic numbering so it may still be possible for Mastercam to create a new offset. [*]Transforms Maintain can cause new offsets if the source operatrions are set to -1, but if set to an actual value say 2 then maintain would make the trasnform copies 2 as well. [*]Because there is no real off switch for offsets our posts use the Miscellaneous Integer #1 to determine if the user wants offset output or not. [*]The post can be used and configured according to how you the user want to use the work offsets. For example entering in a value that more closely resemble the gcode on your machine... IE.54, 55... for G54 G55, 1, 2 for E1, E2, etc [*]If you choose to enter values that resemble your actually G code numbering DO NOT try and mix it with the auto numbering. [*]The offset numbering scheme is designed to allow the flexibility of going from machine to machine without having to edit your toolpaths. For example if you stick with the numbering scheme of 0,1,2,3,4. You can configured multiple posts for multiuple machines based on this generic scheme and get the correct output for your machine. for exmaple one post coudl output G54, G55, G56 and that same MCX file with no changes can outoput E1, E2, E3 if you use the standard offset numbering. [*]A vlaue of 0 = first offset, 1=second offset, 2=3rd offset and so on. I hope this helps and it looks like I need to follow-up with documentation to clear up all this confusion.

Tim, the -1 is what is throwing your whole scheme off. -1 will never, ever occour. The -1 you see in the toolplane page will NEVER be written to the NCI. The -1 tells mastercam to figure out what value to put in. So if you have one op with a 55 in it and one with a -1 then Mastercam will take the -1 and if the plane & origin is different than that plane used in the 55 toolpath then you would get a ZERO value written to the offset field causing a G55 based on your logic. If the toolplane and tool origin where the same then you would get the same 55 written out to the NCI as the first operation. only in the case of 2 toolpaths. Now if there were 3 toolpaths and lets say the first op had a 55 in the workofset field and the other 2 were -1 and all 3 were different tool planes then the workoffset value written to the NCI would be 55, 0, 1 respectively for the 3 toolpaths and in all cases based on your logic they would all be G55 in the NCI file. For you to get a G56 output the workoffset value in the toolpath would have to be a 2 and that would actually be the 3rd offset used. Mixing the use of automatic offsets (-1) and specific like specifying a 55 is not the way to go. Pick one or the other and role with it. All mastercam's automatic numbering will start with 0 and increment by 1. in transform toolpaths you have some additional controls for starting number and increment but not in NON transform toolpaths. I strongly urge you to contact your reseller for some training on Mastercam and offsets otherwise you will be chasing your post logic from here to kingdom come especially if you keep using the -1 in the toolpath. The good news is there are no errors in your post according to the ERR file. I've cleaned up the indenting on the postblock to make it more readable. code: pwcs #G54+ coordinate setting at toolchange sav_frc_wcs = force_wcs if sub_level$, force_wcs = zero if workofs$ <> prv_workofs$ | (force_wcs & toolchng), [ [ if workofs$ < 6, [ if workofs$ < 1, g_wcs = 55 else, g_wcs = workofs$ + 54 ] if workofs$ > 6 & workofs$ < 26, g_wcs = workofs$ + 103 if workofs$ > 54, g_wcs = workofs$ ] [ *g_wcs ] ] force_wcs = sav_frc_wcs !workofs$

Do not use Transform ROTATE for Axis substituion!!! The instructions in the post explains that Axis Substitution must be programmed from the flat. That doesn't mean program the first one from the flat and then rotate it using transform Rotary programs of rotary substitution is really messy. Toolplanes and rotary sub logic start to interfere. There is no way to know what you are intending to do, or which angle calculation should win out. It's much better to do a translational transformation of the "unwrapped" geometry. The right way to do this is a translational transformation (trasnlate in the flat and then the post will wrap the entire transformed toolpath) of the "unwrapped" geometry, using a toolplane sift.

I think your confusion comes from leaving the workofset value in Mastercam to -1. -1 in Mastercam tells mastercam that AUTOMATIC offset generation is on and it will use the toolplanes (views) to determine what value to write to the NCI. -1 will never ever be written to the NCI file, never...did I say never... Mastercam uses the toolplane and tool orin to determine if a change in offset is needed, IE. create an operation in say the top toolplane and one in the side leaving both set to -1. When the NCI is written the workofset values will be 0 and 1 respectively. Now if you had two operations both in the top and set to -1, then because they both use the same view and no change in tool origin the NCI would have 0 & 0 for both operations. Another problem with the first PWCS post block shown above is it looks like you have way to many [] as well as lines that will overwrite everything you are trying to do. My suggestion is to repost the postblocks to a new forum post but make sure you are using the full reply and "CODE" ubb code so the formatting (idententation) of the postblock remains in tact like the one shown below Another suggestion is to see if there is a .err file created when posting as you very well could have errors but not being told about it based on your settings in your Control Definition. code: pwcs #G54+ coordinate setting at toolchange if mi1$ > one, [ sav_frc_wcs = force_wcs if sub_level$ > 0, force_wcs = zero if workofs$ <> prv_workofs$ | (force_wcs & toolchng), [ if workofs$ < 6, [ g_wcs = workofs$ + 54 *g_wcs ] else, [ p_wcs = workofs$ - five "G54.1", *p_wcs ] ] force_wcs = sav_frc_wcs !workofs$ ]

Steve, Look at your code closely. See the # in front of the else??? By commenting out the else and leaving the nwadrss line below (the Action associated with the else statement) you are causing the variable thrdlt variable to always have the address K and never I. Note: nwaddrs is a function used to change the string address that gets output with the value. Not sure what the original goal of the edit (commenting out the Else) was but you can't comment out the else without commenting out the action which was part of the else. Also the variable thrdlt is only forced out if threadpass - one in the code shown so.. Do you always get a K? If so then your problem is related to commenting out the else and not the action. If you get nothing out (I or K) then the conditions are never being met (true) to output the thrdlt variable. Hope this helps and goes back to a basic understanding of the Syntax rules of MP. Call Steve Kidd and check on a post class or atleast see if he can get you a copy of the V9 post reference CD.

I misunderstood the horizontal transform as a planar transform. If you are usign rotate you still need to use the Tool plane option and then check your work offset settings int eh transform dialog. If you set the workofset value in the source operations then this will affect your transform output depending on the work offset settings int he transform dialog. IE. Maintain - if you set source ops to say zero and have maintain set then all have a zero offset. You may need to send your part and post in for a look. If you still are having problems please contact your reseller for some help.

If you are using the automatic work offset numbering and trasnforming in the same plane then you need to turn on the "Tool plane origin Only" option under the translate otpion. Also make sure that Toolplane is selected. Mastercam's automatic offset generation works off of views or changes in views (tool plane origin). If you are working a pattern in the flat then the view is always the same. Workoffsets are NOT available in coordinate mode, only tool plane mode even for flat work.

Has to be a parameter on your machine seeing there is NO F output on those lines.

The above code is what is called a string selector and they basically let you use a single output variable (target variable) for different output based on an input (variable with a value). Think of this as many IF statements or even a CASE statement if you are familiar with those programming concepts. I bet if you do a search on string selectors you might find some helpful information. In simple terms the value of ipr_actv$ is what is causing the G94 or G95 to be output. If you never, ever want G94 then don't use the string selector and just force out the G95 using a literal sting "G95" in your output line. String selectors are another BASIC concept in MP and our Posts.

Steve, understanding WHY you had to force it out is just as important as finding out you can force it out. Way to much to type on this subject but I may ave done so int he past. It's a basic understanding of variables and output - Things that play into this are the formatting, the defining/declaring of the variable, how the variable gets it's value and what that value is. Getting the post to output the right code is only half the battle, understanding why it does it is imperative to moving forward.

quote: I do have alot of time to waste, im just trying to learn as much as I can on my own about the posts. Steve, that's fantastic for sure. See if Cimtech offers up a generic post class as it will be helpful. Learning the basics of the language (rules, syntax, Etc) along with the default post layout and the reasons behind it goes a long way to being comfortable with editing posts. Just learning what Mastercam provides for data in the NCI and doesn't provide is enough to keep you going for years. Also after doing this for 14 years now there are very few post issues that can be fixed without viewing the code itself along with the part file as I'm sure you gathered from my comments. I can take some stabs at the issues for sure but with the part and post life is much easier. Not everything is available through the standard mastercam toolpaths so the post uses tools to allow the user to pass along more information and many times this is custom type programming in the post - yes we even have to do this on our default posts. As an example with your workoffset questions, by using a Misc Integer the post writer is trying to offer the user some options for configuring their output that are NOT built into mastercam and if you are NOT setting things up correctly in MAstercam then you are chasing output issues so understanding what was intended is important and usually impossible without seeing the code. Hope this helps and good luck in your Journey of post writing.

Steve, The home_type variable is probably controlled from the Miscellaneous integers - most likely number 1. So in your Toolpaths make sure you set the Misc int #1 correctly. Also, the PWCS postblock controls the output of G54, G55 ,etc but you still need to make sure it is called in the start of file (psof) and toolchange (ptlchg) postblocks. Bascially somewhere in the those postblocks a call to pwcs must be made. If it is then refer back to the first paragraph. Most posts are written to use 0, 1, 2, etc for controlling the work offsets 0 =first, 1=second, and so on. again, Is strongly suggest contacting your reseller unless you have time to waste. If you want to keep posting sections of your post switch to the full reply form and use the Code option to and put your post code in between the ubb code brackets as it makes it easier to read - see below. code: psof$ #Start of file for non-zero tool number if ra_error = 1, [if mprint(sra_error, 2) = 2, exitpost$] toolchng = one if ntools$ = one, [ #skip single tool outputs, stagetool must be on stagetool = m_one !next_tool$ ] pbld, n$, *smetric, e$ pbld, n$, *sgcode, *sgplane, scc0, sg49, sg80, *sgabsinc, e$ sav_absinc = absinc$ if mi1$ <= one, #Work coordinate system [ absinc$ = one pfbld, n$, sgabsinc, *sg28ref, "Z0.", e$ pfbld, n$, *sg28ref, "X0.", "Y0.", e$ pfbld, n$, sg92, *xh$, *yh$, *zh$, e$ absinc$ = sav_absinc ] pcom_moveb pcheckaxis c_mmlt$ #Multiple tool subprogram call ptoolcomment comment$ pcan pbld, n$, *t$, sm06, e$ if mi1$ > one, absinc$ = zero pcan1, pbld, n$, *sgcode, *sgabsinc, pwcs, pfxout, pfyout, [if nextdc$ <> 7, *speed, *spindle], pgear, strcantext, e$ pbld, n$, sg43, *tlngno$, pfzout, scoolant, pstagetool, e$ absinc$ = sav_absinc pcom_movea toolchng = zero c_msng$ #Single tool subprogram call

You will beat yourself bloody without someone taking a look at the post and the MCX file. It could be anything, especially if you have edited the post in anyway. I strongly suggest you contact your reseller for some help so it can be debugged. But if you insist on trouble shooting it yourself and on the forum you should at least post the psof postblock so we can see the code.

Currently Mastercam for SolidWorks is only available for the 32bit version of SolidWorks. a 64bit version is in development and test for the X5 release of Mastercam for SolidWorks. For information on the functionality currently available in the Mastercam for SolidWorks product check out the www.mastercamforsolidworks.com website.

Do you mean something like this To see all the benefits and value that have been added since Mastercam X, please click here. I'm not sure if there is anything else available but the list in the link above but I can ask around.

Brian is talking about the CLEARANCE and RETRACT options on the driling page. It looks like your post is setup to do additional moves based on the drillref setting (equal to zero) which in our default posts is set based on the initial heights and reference heights for the toolpath. If they are NOT equal (meaning you have a clearance and retract height set) set drillref = 0 which is causing the extra moves. There is probably additional code in pcanceldc postblock as well for the cancel portion of the operation. ofcourse the NCI could be telling it to do this as well depending on your toolpath. Post up your pcanceldc$ and ppeck_2$ postblocks. Now if you want to have a clearance and retract height set and NOT get the extra output then you may need a post edit.

If it is NOT a typo as Andre has caught, then check your format statement for fs2 2 - and see if this is set to delta. Delta will suppress output if the value is zero and this is common for arc IJK output.

From a quick test in X5 this looks to be fixed, but I will dig into our bug database to make sure and ask the QC group to run through our tests to make sure. Not sure on the coolant issue yet, but I'll work on that one now.