Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

Pimp_your_post

Verified Members
  • Posts

    9
  • Joined

  • Last visited

Recent Profile Visitors

860 profile views

Pimp_your_post's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. The three predefined variables for the top of stock are : drl_tos_x$ drl_tos_y$ drl_tos_z$ If for example, your top of stock is at 1" (or mm) on the top plane, you will see drl_tos_z$ = 1. However, if the top of stock is at 1" on the right plane, you will see drl_tos_x$ = 1.
  2. Since you updated from version 8.1 to X2, you now have to deal with machine definition files and control definition files. More specifically, the control definition file has options in there that WILL modify the output of your post. For example, there are settings for your arcs, your feed and there is even a setting that will add spaces in between all your words. When updating to X2, Mastercam should've created these two files with default settings. Problem is, these settings may not be right for you. I would therefore suggest that you take the time to look at all the options available in the control def, play with them and you should be able to regain your proper output. Also, open up your post and search for lines that start with "#CNC". These are lines that have failed to update properly. You will most likely have to fix a few of those from the look of things.
  3. Oops, I made a mistake. mill5$ = 2 is for multi-axis drilling, not milling. We do allow lock codes for multi-axis drilling.
  4. There is "mill5$". It is a variable that is set to "1" when doing 5 axis (or 4 axis) milling and is set to "2" for multi-axis. We check this on our post to check if we are going to do a 4 or 5 axis tool path. If so, we keep the rotaries unlocked for the whole tool path. I assume that is what you are trying to do?
  5. Here's a quick explanation, consider the two following lines of code where we display our variable "MyVar" pbld, n$, MyVar, e$ (MyVar is displayed) pbld, n$, MyVar, e$ (MyVar is not displayed) MyVar = MyVar + 2 (MyVar changes) pbld, n$, MyVar, e$ (MyVar is displayed) In the first line, MyVar will be displayed in the NC file since this is the first time we have called it since the last time it has changed. In the second line, MyVar will not display since it has not changed. pbld, n$, !MyVar, e$ (MyVar is not displayed) pbld, n$, MyVar, e$ (MyVar is not displayed) MyVar = MyVar + 2 (MyVar changes) pbld, n$, MyVar, e$ (MyVar is displayed) Using the "!" symbol tricks the post into thinking that MyVar was already displayed and because of this, MyVar will not be displayed in the lines afterwards until its value changes. pbld, n$, `MyVar, x, y, z, e$ In this line, MyVar will only be displayed if it is not alone. In other words, if either "x", "y" or "z" is displayed on that line, MyVar will display also. Please note that pbld and n$ already behave like this, that is why we don't get empty lines with sequence numbers all over the post. pbld, n$, ~MyVar, e$ (displayed) pbld, n$, MyVar, e$ (displayed) pbld, n$, MyVar, e$ (MyVar is not displayed) MyVar = MyVar + 2 (MyVar changes) pbld, n$, MyVar, e$ (MyVar is displayed) In this case, the "~" symbol forces the output of MyVar but it does not affect the output of the next line. This is useful for debugging. The is also a "@" symbol that you can use to get the rounded value of MyVar but I don't really use that one personally. I hope it helps.
  6. If you take mplmaster as an example you will see that most rapid move go through one post block : prapidout. In this postblock, you need to setup your output lines like this : pbld, n$, psgplane, psgcode, pxout, pcout, pyout, pscool, strcantext, e$ pbld, n$, pzout, e$ In this case you will get an X move (and Y if applicable) first, then you will get a Z move. Will this fix everything? Most likely not because you still need to check and see if there are other places in your code where rapid moves are ordered. The most likely places are ptlchg$ and ptlch0$ but you should also check your retract routines. Somebody mentioned that it can all be done in the control definition but that only works for mills (or mill tool paths on lathes). For your lathe tool paths you have to set that up manually.
  7. 1) In the pmachineinfo$ post block, you can capture the name of the post like so: pmachineinfo$ if prmcode$ = 17008, sstring_for_the_name_of_the_post = ucase(sparameter$) And then you can display the post name where you want. 2) You can always ask a question like so: #define a question and capture it in a variable fq 8 sstring_for_user_name "Hey man, who's the user?" Then, make the post ask the question during the posting process. You can ask the question somewhere in the beginning of pheader$ pheader$ q8 # ask question number 8 Now you will be able to display the username in the header.
  8. The problem with the arcs may be resolved easily by making sure that the settings for these are setup properly in the machine definition. If this is a post that has been newly updated to X5, these settings may have been changed by the updater (It is a bug and it has been reported).
  9. Near the beginning of the post, in the General Output Settings, look for the variable "one_rev" and set that to "1". This will keep the B-axis between 0 and 360.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...