Is there a 5 axis post that is not encrypted?

[jlw™]

Just curious. I have some ideas I want to try but all of my posts are blocked. I don't care what machine I just want to be able to play and post and see the output.

[Guest]

Just curious. I have some ideas I want to try but all of my posts are blocked. I don't care what machine I just want to be able to play and post and see the output.

Not that I am aware of....

 

The 5 axis vector math is pretty intricate...

 

Thus it's locked.

 

You are of course free to write one  

[Colin Gilchrist]

I hear this request quite often, but it truly isn't necessary to have the whole post unencrypted. You just need to understand how the post processes data internally, and where/how to manipulate the output.

 

Every single character and line of data is output to the NC fiile through the PST file. All of the calculations are done inside the PSB, but the output is always through the PST. That being the case, it just requires knowledge of where and how to manipulate the output.

 

That said, gaining that knowledge can be difficult to come by. I realize that, and that's why I've taught "5X post classes" in the past. The courses teach you how to manipulate the post output, and the mechanisms that already exist inside the PST.

 

What specifically are you looking to get in terms of output? That makes all the difference in how you go about making the necessary edits to get the output you want.

[gcode]

The 5X generic post that ships with Mastercam is highly editable

 

"C:\Users\Public\Documents\shared mcam2017\mill\Posts\Generic Fanuc 5X Mill.pst"

 

The PSB file is encrypted but it is still possible to edit the pst file for different machines.

I've done dozens of Fanuc based machines with it over the year.

Mostly double rotary HBM's  and AB and AC head head vertical and horizontal mills.

 I just finished a RA Head post for a RA Head and a C axis rotary on an HBM

Its a little rough but it got the job done.

 

Once you get the axis described properly, the hardest part is getting the limit behavior

to post correctly.

On some machines this is not so important, on others it's critical

 

One thing to be careful of.

If you rename the .pst file, make sure to give the psb file EXACTLY the same name.

 

In the early days, failure to do this would lock up your computer hard enough to require a

cold (pull the power cord) reboot.

Now it just locks up the post process

[jlw™]

Not that I am aware of....

 

The 5 axis vector math is pretty intricate...

 

Thus it's locked.

 

You are of course free to write one

Vector math actually isn't that difficult. I appreciate the help with posts from you guys who always help but I'm a math kinda guy and just wanted to play with the calculations because I'm that weirdo that enjoys that kinda thing. I've noticed patterns in output regardles of tplane XY orientation as long as A(Ax, Ay, Az) and B(Bx, By, Bz) are the same for the created tplanes. It tweaks my curiosity because I was perusing an NCI output today and noticed it had what appeared to be matrix output in it but all 3 axes instead of just the Z axis vector. So, I'm thinking you could use that to orient the XY output for use with G68.2 or G68.4. I've noticed no matter where my XY are oriented output is the same so the X and Y vectors are wasted, imho.

 

I've also determined that trying to get this info from an unlocked 4 axis post is useless. You can easily track that back to pxyzcout0, pxyzcout1, etc and there is definitely no matrix math there as it comes from a simple c$.

 

I don't need to edit a post, I only want to play with one that I can get all the way under the hood on to satisfy my own curiosity.

 

Thanks guys.

 

If I write one, you'll be the first one I send it to for critiquing.

[crazy^millman]

Agreed and I have looked under the hood of some of the 3rd Party folks and Mastercam is by far the hardest one for any 3rd party to work with. What most 3rd party builder fail to realize is what the MP.dll does in the back ground. The .pst and .nci are only part of the equation the MP.dll is where a lot of the magic goes on with Mastercam NC Code output. Years ago many of the companies use to build their own MP.dll file for their machines. Then X came along to make it all better, but for the Generic post is has not. They are really still the original post written back in V9 days. The only real improvements for post are from 3rd part companies with regards to MP post. MP.net is the game changer, but seeing how it has been out for some years and still just only part of the MT not sure when it will migrate over to Milling side of things. I have heard so many different things over the years I will not say any more than that. Time will tell where things go and I will keep crossing each bridge as I come to them to see what is the best direction moving forward.

[mkd]

you could get your hands on a post that will take the NCI output and translate it into APT.

Then from APT there would be a multitude of possibilities to crunch the numbers. NX, catia, etc use APT output along with third party post developers.

 If you want to maximize the utility of your skills and time, crunching from APT will translate better to a host of cam products.

2cents

 

P.S. there is a guy on CNCZone who is building his own five axis router with Mach3 and Autodesk360 (IIRC) for programming. 360 doesn't have 5axis ability so he made it happen, himself.

[Watcher]

you could get your hands on a post that will take the NCI output and translate it into APT.

Then from APT there would be a multitude of possibilities to crunch the numbers. NX, catia, etc use APT output along with third party post developers.

If you want to maximize the utility of your skills and time, crunching from APT will translate better to a host of cam products.

2cents

 

P.S. there is a guy on CNCZone who is building his own five axis router with Mach3 and Autodesk360 (IIRC) for programming. 360 doesn't have 5axis ability so he made it happen, himself.

Important to mention that a number of NCI unique tokens does not exist in the standard APT.

 

That means these commands would have to be converted to custom PP words so that APT based post processors could properly convert it.

 

Simple example: In APT the MULTAX/ON statement leads one to think your are going to start a simultaneous 4/5 axis motion. Wrong. It is used also for 3+2.

 

So how do you tell you're using 5axis simultaneously then? You need a PP word...

 

In Mastercam NCI there's a specific NCI code that triggers multiaxis mode... Same for polar milling, axis substitution, etc... Such things are not covered by standard APT... Or aren't covered in a standardized format... So you need a PP word... APT is a flavored language...

 

A translation tool from NCI to APT needs to convert the unique NCI codes to some custom PP words...

 

In fact this is just a remark, because all 3rd party PP tools working with Mastercam that are APT based already do that... Examples: ICAM, IMS, GPost...

[Tyler Robotson]

Vector math actually isn't that difficult. I appreciate the help with posts from you guys who always help but I'm a math kinda guy and just wanted to play with the calculations because I'm that weirdo that enjoys that kinda thing. I've noticed patterns in output regardles of tplane XY orientation as long as A(Ax, Ay, Az) and B(Bx, By, Bz) are the same for the created tplanes. It tweaks my curiosity because I was perusing an NCI output today and noticed it had what appeared to be matrix output in it but all 3 axes instead of just the Z axis vector. So, I'm thinking you could use that to orient the XY output for use with G68.2 or G68.4. I've noticed no matter where my XY are oriented output is the same so the X and Y vectors are wasted, imho.

 

I've also determined that trying to get this info from an unlocked 4 axis post is useless. You can easily track that back to pxyzcout0, pxyzcout1, etc and there is definitely no matrix math there as it comes from a simple c$.

 

I don't need to edit a post, I only want to play with one that I can get all the way under the hood on to satisfy my own curiosity.

 

Thanks guys.

 

If I write one, you'll be the first one I send it to for critiquing.

 

If you're comfortable with vector may and 3x3 matrix rotations, the hardest part of the vector math in 5axis posts is realizing how a matrix is represented and manipulated in MP. 

 

So I would +1 to what mkd & watcher said - I would only recommend spending time in MP if you're looking for some wham-bam output but if you're thinking long-haul development, in for a lot of headbanging in a proprietary language.

[Colin Gilchrist]

If you're comfortable with vector may and 3x3 matrix rotations, the hardest part of the vector math in 5axis posts is realizing how a matrix is represented and manipulated in MP. 

 

So I would +1 to what mkd & watcher said - I would only recommend spending time in MP if you're looking for some wham-bam output but if you're thinking long-haul development, in for a lot of headbanging in a proprietary language.

 

Unless you want to write your own DLL as the interpreter, you're kind of stuck doing Mastercam post development using the MP Language. Fortunately, it is very well documented, and very full featured. There is new MP Documentation available (I believe with 2017), but of course you'll have to request that from your Reseller.

 

The big limitation of MP in many ways is that you only have 1D arrays available, because MP uses simple ordered lists of variables for everything. I know Jeff has done some serious enhancements over the years, but I can't really talk about much of that. There are mechanisms that exist in the language now to allow you to use much more modern programming techniques. Things like passing variables to subroutines either by val, or by ref, and much, much more.

 

There is a whole new Tool Table mechanism, and parameter read options.

 

So if you want to develop Mastercam Post Processors, MP is a very useful language, and very powerful too. For what it does; which is processing NCI data in a "script" like method. This allows for quite complex output, and yet still performs quickly, which is always a concern. 

[Colin Gilchrist]

I really only see APT output being useful for interfacing with "external" products. For companies that have a system like ICAM or another "APT-based" solution, then it would make sense. There is already a data structure that exists in the form of the NCI data, and it gives you all of the parameters you need to figure out anything you could possibly want, at least in my experience. Mill-Turn being the exception, but the new MP.NET language, and the "Extensions" interface is designed to address that shortcoming.

 

The one limitation of MP that I see is really that it is only designed to work with Mastercam, and you really can't use it for developing anything that is "independent" of the system. It is also very much a "scripting" language, which is great for being a data translator (NCI > Machine Code), but not much else. I have seen some amazing things done with it to do advanced math calculations. An example that comes to mind is a program that John Summers wrote for creating profiles for cams. You could have a simple text file with angle and lift data, and run it through MP. This would produce a text file that is just XY point data. You import that data into Mastercam, and now you have the cam profile laid out as a series of points. It was really cool to see MP used for a different application, albeit one that is still designed to interface with Mastercam. 

[Watcher]

APT is that kind of rock solid format most systems that are in the business for a long time enjoy to crunch. They´re initially build to deal with it and only it.

 

VERICUT? An APT cruncher. Not a single G/M code it reverses goes unnoticed. Even a function set to be ignored is printed in the APT stream as PPRINT command or just ignored. VERICUT is an APT simulator since day one. What it does today is to reverse G-Code into APT and then process APT.

 

ICAM? G-Post? IMS? All them convert a native CAM output to APT and process APT. Then they post G-Code from APT.

 

There are many advantages in using proprietary neutral formats, and I think CNC got it right with the NCI. They can enhance their format, create special codes for specific functions without being tied to a legacy format like APT. 

 

APT is OK and as long as you have the PPWords to complement it, you can do whatever you want... But it is an old language created in the 50´s/60´s when things we see today in machine tools were not even science fiction. That´s why it is so flavored today, and the APT code from one company may have lots of differences compared with the code from another, due to the PPWords and flavors.

 

With proprietary neutral files like NCI, the software vendor has freedom to implement things the best way in their architecture. 

[mkd]

Not sure if jlw has lost interest but here is that other mathematics masochist. Hope you enjoy the build. Sorry if off topic.

http://www.cnczone.com/forums/showthread.php?t=286992

 

[jlw™]

Thanks for the link mkd, I am still interested. I'm just enjoying the show that is a public forum.

 

 

Thanks for all the input gentlemen!

[Newbeeee™]

Not sure if jlw has lost interest but here is that other mathematics masochist. Hope you enjoy the build. Sorry if off topic. http://www.cnczone.com/forums/showthread.php?t=286992

Just went through the thread on CNCZone.

Awesome!

[Tyler Robotson]

Unless you want to write your own DLL as the interpreter, you're kind of stuck doing Mastercam post development using the MP Language. Fortunately, it is very well documented, and very full featured. There is new MP Documentation available (I believe with 2017), but of course you'll have to request that from your Reseller.

 

The big limitation of MP in many ways is that you only have 1D arrays available, because MP uses simple ordered lists of variables for everything. I know Jeff has done some serious enhancements over the years, but I can't really talk about much of that. There are mechanisms that exist in the language now to allow you to use much more modern programming techniques. Things like passing variables to subroutines either by val, or by ref, and much, much more.

 

There is a whole new Tool Table mechanism, and parameter read options.

 

So if you want to develop Mastercam Post Processors, MP is a very useful language, and very powerful too. For what it does; which is processing NCI data in a "script" like method. This allows for quite complex output, and yet still performs quickly, which is always a concern. 

 

yeah that's what I meant - I think for almost anyone it would be more effective to pay someone else to develop in MP than to learn more advanced functions unless you plan to be with Mastercam for a long time and forsee needing to change the post quite a bit. 

 

The big limitations to MP like you mentioned being 1D arrays so matrix math is a pain.  I think the biggest limitation is it forces someone who may already be comfortable  OOP in modern languages to fight against programming instincts. The buffer filestream is a nightmare to explain to someone and so there's a huge barrier to entry which I can only imagine holds back post development at CNC as much as it would at any other company. I'm sure there's far more to it than that

 

As far as quick script-like programming, Python is lightning quick as an alternative. 

[Lee1]

     i have "Generic Fanuc 5X Mill.pst" all source code.

[jlw™]

yeah that's what I meant - I think for almost anyone it would be more effective to pay someone else to develop in MP than to learn more advanced functions unless you plan to be with Mastercam for a long time and forsee needing to change the post quite a bit.

 

The big limitations to MP like you mentioned being 1D arrays so matrix math is a pain. I think the biggest limitation is it forces someone who may already be comfortable OOP in modern languages to fight against programming instincts. The buffer filestream is a nightmare to explain to someone and so there's a huge barrier to entry which I can only imagine holds back post development at CNC as much as it would at any other company. I'm sure there's far more to it than that

 

As far as quick script-like programming, Python is lightning quick as an alternative.

I would love to see it go to python.

[Mick]

     i have "Generic Fanuc 5X Mill.pst" all source code.

 

Seriously? I doubt it.

 

Part of that post is encrypted by CNC Software, as mentioned previously.

[jlw™]

if you have pst you also have psb... encrypted.

 

my reseller does not even have a psm file for it.

[Lee1]

Seriously? I doubt it.

 

Part of that post is encrypted by CNC Software, as mentioned previously.

of course,i'm have full unencrypted post processor

[Colin Gilchrist]

of course,i'm have full unencrypted post processor

Got any proof? Why don't you post up some of the 'encrypted' code then? Or are you just bragging?

 

Let me know if you want to sell a copy...

[Lee1]

see below source code

 

# --------------------------------------------------------------------------
# Common User-defined Variable Initializations (not switches!)
# --------------------------------------------------------------------------
#Format assignment for absolute/incremental variables
fmt  "X" 2  xabs        #X position absolute
fmt  "Y" 2  yabs        #Y position absolute
fmt  "Z" 2  zabs        #Z position absolute
fmt  "X" 3  xinc        #X position incremental
fmt  "Y" 3  yinc        #Y position incremental
fmt  "Z" 3  zinc        #Z position incremental
fmt  "A" 20 p_abs       #Primary absolute axis position
fmt  "B" 20 s_abs       #Secondary absolute axis position
fmt  "C" 20 d_abs       #Dummy absolute axis position
fmt  "A" 21 p_inc       #Primary incremental axis position
fmt  "B" 21 s_inc       #Secondary incremental axis position
fmt  "C" 21 d_inc       #Dummy incremental axis position

#Global assignment for output variables
xout = xabs
yout = yabs
zout = zabs
prv_xout = prv_xabs
prv_yout = prv_yabs
prv_zout = prv_zabs
p_out = p_abs
s_out = s_abs
d_out = d_abs
prv_p_out = prv_p_abs
prv_s_out = prv_s_abs
prv_d_out = prv_d_abs

p_absinc_chng   #Set global assignment to the output variable
      if prv_absinc$ <> absinc$,
        [
        if absinc$,
          [
          #Incremental linear output
          result = newfs(three, xout)
          result = updgbl(xout, "xinc")
          result = updgbl(prv_xout, "prv_xinc")
          result = newfs(three, yout)
          result = updgbl(yout, "yinc")
          result = updgbl(prv_yout, "prv_yinc")
          result = newfs(three, zout)
          result = updgbl(zout, "zinc")
          result = updgbl(prv_zout, "prv_zinc")
          #Incremental rotary output, always absolute for signed
          if not(pang_output),
            [
            result = newfs(21, p_out)
            result = updgbl(p_out, "p_inc")
            result = updgbl(prv_p_out, "prv_p_inc")
            ]
          if not(sang_output),
            [
            result = newfs(21, s_out)
            result = updgbl(s_out, "s_inc")
            result = updgbl(prv_s_out, "prv_s_inc")
            ]
          ]
        else,
          [
          #Absolute linear output
          result = newfs(two, xout)
          result = updgbl(xout, "xabs")
          result = updgbl(prv_xout, "prv_xabs")
          result = newfs(two, yout)
          result = updgbl(yout, "yabs")
          result = updgbl(prv_yout, "prv_yabs")
          result = newfs(two, zout)
          result = updgbl(zout, "zabs")
          result = updgbl(prv_zout, "prv_zabs")
          #Absolute rotary output
          result = newfs(20, p_out)
          result = updgbl(p_out, "p_abs")
          result = updgbl(prv_p_out, "prv_p_abs")
          result = newfs(20, s_out)
          result = updgbl(s_out, "s_abs")
          result = updgbl(prv_s_out, "prv_s_abs")
          ]
        ]

 

 

 

 

 

 

 

 

 

 

 

 

# --------------------------------------------------------------------------
# Position calculations, generally these do not need to be modified
# --------------------------------------------------------------------------
#Incremental calculations
ps_inc_calc     #Incremental calculations and output assignment, start             
      xabs = fmtrnd(xa)
      yabs = fmtrnd(ya)
      zabs = fmtrnd(za)
      xinc = vsub (xabs, prv_xabs)
      if drilltype = two,
        [
        if gcode$ = 81, pdrillcalc81
        if absinc$,
          [
          refhtoutx = vsub(drl_rxa, xabs)
          drlx = vsub(drl_dxa, xabs)
          ]
        else,
          [
          refhtoutx = vequ(drl_rxa)
          drlx = vequ(drl_dxa)
          ]
        ]
      ps_cinc_calc
      p_absinc_chng

ps_cinc_calc    #Incremental calculations, start rotary             
      @p_abs, @s_abs
      p_inc = vsub (p_abs, prv_p_abs)

pe_inc_calc     #Incremental calculations, end             
      if cuttype = one, x$ = xnci$, y$ = ynci$, z$ = znci$
      !x$, !y$, !z$, !xabs, !xinc, !yabs, !yinc, !zabs, !zinc
      !p_abs, !p_inc, !s_abs, !s_inc, !fr_pos$
      !cc_pos$, !cutpos2$    # 01/26/04

p_absinc_chng   #Set global assignment to the output variable
      if prv_absinc$ <> absinc$,
        [
        if absinc$,
          [
          #Incremental linear output
          result = newfs(three, xout)
          result = updgbl(xout, "xinc")
          result = updgbl(prv_xout, "prv_xinc")
          result = newfs(three, yout)
          result = updgbl(yout, "yinc")
          result = updgbl(prv_yout, "prv_yinc")
          result = newfs(three, zout)
          result = updgbl(zout, "zinc")
          result = updgbl(prv_zout, "prv_zinc")
          #Incremental rotary output, always absolute for signed
          if not(pang_output),
            [
            result = newfs(21, p_out)
            result = updgbl(p_out, "p_inc")
            result = updgbl(prv_p_out, "prv_p_inc")
            ]
          if not(sang_output),
            [
            result = newfs(21, s_out)
            result = updgbl(s_out, "s_inc")
            result = updgbl(prv_s_out, "prv_s_inc")
            ]
          ]
        else,
          [
          #Absolute linear output
          result = newfs(two, xout)
          result = updgbl(xout, "xabs")
          result = updgbl(prv_xout, "prv_xabs")
          result = newfs(two, yout)
          result = updgbl(yout, "yabs")
          result = updgbl(prv_yout, "prv_yabs")
          result = newfs(two, zout)
          result = updgbl(zout, "zabs")
          result = updgbl(prv_zout, "prv_zabs")
          #Absolute rotary output
          result = newfs(20, p_out)
          result = updgbl(p_out, "p_abs")
          result = updgbl(prv_p_out, "prv_p_abs")
          result = newfs(20, s_out)
          result = updgbl(s_out, "s_abs")
          result = updgbl(prv_s_out, "prv_s_abs")
          ]
        ]

 

 

pupd_brk        #Update the current position/angle to store in prv_ for last pos
      !brk_gcode
      prv_brk_xa = vequ(brk_xa)
      prv_brk_ua = vequ(brk_ua)
      prv_brk_vecx = vequ(brk_vecx)
      prv_brk_iout = vequ(brk_iout)
      prv_brk_drl_rxa = vequ(brk_drl_rxa)
      prv_brk_drl_dxa = vequ(brk_drl_dxa)
      prv_brk_drl_zxa = vequ(brk_drl_zxa)
      prv_brk_drl_txa = vequ(brk_drl_txa)
      prv_brk_p_abs = vequ(brk_p_abs)

      #These are separate from the break routine
      prv_brk_p_wnd_ang = vequ(brk_p_wnd_ang)
      !p_wnd_ang
      !s_wnd_ang
      !p_lim_flg
      !s_lim_flg
      !drilltype
      !pln_match

 

 

#Rotate vecx, the machine base vector for angle calculations
pp_rot_vecx     #Rotate vecx to primary angle
      if axis_rot1 = one | axis_rot1 = three, axisx$ = vequ(caxisx)
      else,
        [
        if axis_rot1 = two | axis_rot1 = six, axisx$ = vequ(baxisx)
        else, axisx$ = vequ(aaxisx)
        ]
      if mtype > two, #Nutator, undo the rotation, p_abs is output angle
        [
        if p_sign_ang > zero,
          p_vec_rot = -p_sign_ang*p_abs+p_shft_ang
        else,
          p_vec_rot = -p_sign_ang*p_abs-p_shft_ang
        ]
      else, p_vec_rot = p_sign_ang*p_abs+p_shft_ang

      if (pri_vert), p_vec_rot = p_sign_ang*p_abs
      vecx = rotv(p_vec_rot, vecx)

ps_rot_vecx     #Rotate vecx to secondary angle
      if mtype < three, #Non nutator
        [
        if axis_rot2 = one | axis_rot2 = three, axisx$ = vequ(caxisx)
        else,
          [
          if axis_rot2 = two | axis_rot2 = six, axisx$ = vequ(baxisx)
          else, axisx$ = vequ(aaxisx)
          ]
        ]
      else, axisx$ = vequ(nut_vecx)

      s_vec_rot = s_sign_ang*s_abs+s_shft_ang

      if mtype > two & nut_ang_pri$ < zero, s_vec_rot = -s_vec_rot

      vecx = rotv(s_vec_rot, vecx)

[crazy^millman]

Lee don't look for that to be allowed to stay too long if it is intellectual property you have got access to.

[Watcher]

Lee don't look for that to be allowed to stay too long if it is intellectual property you have got access to.

Good point.

 

But I don´t think what he pasted above is an encrypted portion of the generic 5 axis post shipped with MC...

 

My eyes are not bleeding with that code...  And Paul Decelles said once they would the day we looked into that...