Did you set 'rd_mch_ent_no$'? That variable controls "what parameters" are available to 'pmachineinfo$'. By default, it gets set to read "only the active axis stream" for a given operation, at a "tool change event". You will see this in the MPMaster Post: if sof = 1, [ maxfeedpm = 999999 #Uncomment these variables to force use of machine def values as initial lowest max feedrate value maxfeedpm_m = 9999999 #Otherwise the default (post) initialization setting is used as initial value #minfeedpm = 999999 #minfeedpm_m = 999999 !maxfeedpm, !maxfeedpm_m #, !minfeedpm, !minfeedpm_m rd_mch_ent_no$ = 0 rd_md$ #Read machine definition parameters - calls pmachineinfo$ ] rd_mch_ent_no$ = syncaxis$ #Retrieve machine parameters based on current axis combination - read from .nci G950 line rd_md$ #Read machine definition parameters - calls pmachineinfo$ rd_tlpathgrp$ # Read toolpath group parameters - calls pmachineinfo$ In that piece of code, we first test the value of 'sof = 1'. If that is true (presumably at the start of processing), then all the code below it is read. Notice that 'rd_mch_ent_no$' is set to '0'. Then there is a call to 'rd_md$', which calls 'pmachineinfo$ for each of the Parameters. You probably need some code like the following: rd_mch_ent_no$ = -1 #GET ALL MD PARAMETERS rd_md$ #Read machine definition parameters - calls pmachineinfo$ Then, inside pmachineinfo$, get the value of '17435'. I also like to add a "trap", to test for values, because MD Parameter Numbers can be overwritten. In other words; some MD Parameter values can be shared between multiple 'components'. As we process the "axis combination", we do this component-by-component. At some point, we should get 'the value you want'. You should initialize a 2nd variable, to save the value as a backup. (A "test" if you will...) Add: fmt "" 2 main_stk_pos "" #Main spindle stock position fmt "" 2 sav_main_stk_pos "" #Main spindle stock position saved during pmachineinfo$ loop Try this inside pmachineinfo$: if prmcode$ = 17435, [ main_stk_pos = rpar(sparameter$,1) if main_stk_pos <> zero & main_stk_pos <> -9999, sav_main_stk_pos = main_stk_pos result = mprint("The next value shown is current value of main_stk_pos") result = mprint(main_stk_pos) result = mprint("The next value shown is current value of sav_main_stk_pos") result = mprint(sav_main_stk_pos) ]

Do you possibly have TWP (G68.2) active? Just check to see if you might need a G69 before the G28? I have never been a fan of G28 and G91. It's just too easy to get errors with the combination of Machine Parameters that can be configured to cause a crash or over travel situation. I always choose to output G53 moves for any safe retract or machine positioning move. The main reason I love G53 is that it won't cancel your active work offset, and when G53 is read, the machine temporarily disables look ahead. The final reason is that I can make all the safe moves using Absolute Coordinates (G90), so I never have to worry about where I reset the machine in the NC Program, because my code never puts the machine in Incremental Mode for a repositioning or safe retract move.

Well yes, MP.DLL is the Post Engine, that does all the heavy lifting. I did not bother going into data structures, buffers, stacks, enumerors, or the Parameter Memory Map. Mainly because those are more recent additions to the language. Some mechanisms, such as the 'Comment Buffer' mechanism (internal buffering of Comment Strings) have been available in MP for a very long time. However, a great deal of enhancements have been made to both MP.DLL and the language functions over time. Jeff Hill is the wizard who has been making many of the functional enhancements that have really brought MP into the modern era. One of the greatest recent developments has been Post Block variable passing. You can now define a Post Block to accept 'arguments', and you can pass the arguements "by reference", or "by value". Sounds fancy. But what does that jargon actually mean? It means you can pass data to a Post Block routine, and have the routine return a result. By Reference means the function updates the original variable that was passed into the Post Block. By Value means the Post Block makes a copy of the value to a separate internal variable.

You're on the right track, but there are some significant differences. The MP Language was written by John Summers, and he loosely based the language on Standard C. However, the language was designed as a 'scripting language', so although there are similarities between Standard C and the MP Language, there are differences. The asterisk character is used to 'Force variable output regardless of modality'. When MP was invented, there was simply an ordered list of 'predefined variables'. These variable names were reserved for use, and you would get a 'duplicate initialization' error, if you happened to create a variable name that was already a predefined variable. The situation was like this for many years (maybe 15?), from at least Version 6, through V9.2. When Mastercam X was released, the MP Language went through a significant overhaul. In addition, the Code Expert Editor was released. Coinciding with the release of the editor, predefined variables were updated to include a dollar sign at the end of the variable. This is true for all predefined variables, regardless of if they are a String or a Numeric Variable. In addition, you will get an error if you try and include a $ with a User Defined Variable. So predefined variables all end in the dollar sign character, while user defined variables do not. I think of MP as cross between Standard C and VBScript. It is a homegrown programming language, built to take NCI Input, and convert it to NC Code Output. It opens the NCI file, and every pair of NCI Lines calls one, and only one, Entry Post Block. This is the 'entry point' into the instruction list. All the instructions in the Entry Post Block get read, line by line, from the start of the Post Block, to the end of the block. (Note that you can always call another Post Block from within the Entry block (like a Subroutine). These 'post block calls' can actually be nested up to 25 levels deep. Once the instructions in the 'called block' have been processed, MP returns back to where the call originated, and MP keeps processing the Post Lines, until it reaches the end of the entry block. MP is a 'column dependent' language. The 'first column' holds special significance. Any variable, formula, or Post Block Name that starts in the 1st column, indicates that is the 'definition' of that thing. For a Post Block, all the Post Lines underneath must have at least one space character in front of the line (6 space characters is the standard 'indent' for all Post Lines). This indicates that the line is a continuation of the active block. The next '1st column character' that is detected, is what actually 'ends' the block above.

Hi Bob, With Mastercam's new Mill-Turn Product, there is a new workflow to be aware of. Code Expert now acts as a "Simulation Layer" between Mastercam and the output of NC Code. Everything you used to control at the "Operation Level" in Mastercam (through custom "input" to the Post Processor), is now done in the Simulation Layer (Code Expert). Moving these "inputs" to the Code Expert Simulation Layer is simply a new method of working, and for Mill-Turn, this is the new tool that you've got to familiarize yourself with. Rather than using "Misc Values" as input, Mastercam Code Expert uses "Tokens". You can think of a Token as a "Variable with Properties". Many of the Tokens in the Simulation Layer are now "bi-directional", meaning they get saved, and 'persist', even if you need to 'Re-Post' the Operation Level Code, and send new Ops to Code Expert. There are "User Level Tokens", which you should be able to set. (They may have to be "Exposed" so you can use them.) These Tokens will handle things like "controlling Tool Breakage Detection", but can also represent things like Sync Code and Wait Code Controls. Again, you'll need to set these Tokens at the Simulation Layer (inside Code Expert), rather than at the Operation Level. Although Misc. Values (reals and integers) provided a fairly easy mechanism for the average user to understand (and use), it took a lot of work on the Post Processor Side, to be able to "guess your intent", for how your code and workflow. Moreover, activating, deactivating, and tracking, "what machine mode" you are in, and "what machine mode" do you want to activate, gets squirrelly, real quick. You asked in a different thread about "how do I just position the C-Axis, instead of XY cutting, for a drill path?". Sometimes that is handled by specific "operation type and/or order", but most of the time a Token would be used to determine the Machine Mode, and cutting options (What M-Codes to activate, Accel/Decel Mode, and things like Tool Breakage Detection).

Arrrr, me hearties!

Yep. Hi, I'm a red flag...

Where are you located? Have you reached out to your Mastercam Reseller for support with this issue? Generally, your Mastercam Reseller should be your first point of contact when you experience issues with your Post Processor.

Who is your Reseller? Your Mastercam Reseller would be your first point of contact. They have dedicated Tech Support staff who help their customers overcome these issues. Your location says "United States". Where are you physically located?

Yes, there is a checkbox for 'Endpoints' in the View ribbon bar. There is also a similar option to toggle the display of Arc Endpoints.

There are two options now for importing a STL File. The default is 'Mesh Entity'. This is a "blob" of data, that won't let you select points from the mesh. If you change the import option to "Lines", it will then let you analyze discrete points at every triangle vertex. I will usually import all of my STL models twice. Once as a Mesh Entity, and again as Lines, so I can measure distances when positioning the mesh model. When you open the 'STL Import' dialog box, there will be an 'import' button, once you have changed the File Handler to 'STL'.

It really depends on what is the "authority" for making the part. Is the "model" the standard to which the part should be made, or is it a drawing with tolerances? The export issue doesn't just effect the "closure of the face edges", but the actual position in 3D space as well. I've seen walls that were "off" by 0.002-0.004", when simply opening up the stitching tolerances. This isn't to say that the "create a solid from surfaces" function is causing the issue. That isn't the problem at all. It is the "quality of the import geometry" that is really going to effect the outcome. My preference was for the Moldplus Catia Translator, but the translator that is available from Mastercam directly has also been improved recently, so take that with a grain of salt. I'm not aware of any comparisons between the two translators, to tell us definitively which is the better translator option, so my preference is purely anecdotal.

Then your best bet, would be for your company to invest in a Catia Design license. That's going to be the easiest route to take. (Although also potentially very expensive.) Otherwise, rebuilding the model might be your best option, or using a 3rd Party tool like SpaceClaim.

This is really a case of GIGO Buffers effecting the model inside Mastercam. . . . . . . . . . . . . . . . . . . . . . . . . Now, what is GIGO? Just a bit of humor as there are, of course, no such thing as GIGO Buffers in Mastercam. GIGO is simply an apt acronym for this situation. Garbage In = Garbage Out In your case, you could open up the "Import Tolerances" to 0.020", and Mastercam could likely cobble together a "water-tight solid", but the model that Mastercam generates would not match the same "face and edge locations" as the original model. Again, garbage in equals garbage out. In your case, you'll obtain the best results by manipulating the upstream data, to give you a quality model to work with.

I think the default "Export Tolerance" for Catia is 0.1mm. This means your model faces/edges can "float" by up to 0.00394", and often results in models that are not watertight. That "loose" of a tolerance really helps if you are working on designing something large, like a ship(boat) or plane. It is a terrible default value for exporting models, but you'd have to communicate this issue back to your customer's engineering department. If you can get them to change the value, I'd suggest 0.002mm Export Tolerance. That would get you under 0.0001" for face/edge gaps. I worked for a company years ago that bought a full Catia Design License, for the sole purpose of being able to open the native ".CatPart" files, which allowed us to then set our own export tolerances. Moreover, we could check for "poor design practices" in the native model itself, and fix the issues before performing the export function. This saved me easily several "weeks of effort" over the year, from problems that I would have had to re-model or fix myself inside Mastercam.