.psb post files

[Bob W.]

I am aware that most 5-axis posts have a .psb file that is locked up for proprietary reasons because that is where the magic happens.  I am curious what the contents of this section is.  In my 5-axis post I have access to every function that my machine would need (tool change, header, peof, drill cycles, etc...) so I am am interested to know what is locked up.  I'm pretty sure it is the code related to motion but that doesn't seem all that complex.  From what I understand, in full 5-axis machining Mastercam creates a WCS for each individual axis change, then executes that move as though it is done in 3-axis.  Kind of like machining in 3+2 only fully automatic.  This is all done in nci so the magic in the psb is the equivalent of linear algebra with a few matricies (3x3, 5x5?) crunching the transforms.  I'm not sure what the syntax would be for emulating a matrix in a post.  Anyone have any comments on the subject?  I'm just wanting to expand my knowledge base on the subject so I can better understand how TCP code might be posted differently than standard 5-axis code.

[crazy^millman]

Bob, we have had some really in depth discussion about this very topic over the years. Watcher shared some stuff. MTB did along with some folks from CNC over the years. You have about summed it up and I think with the complexity come into the generic post as the fact they are just that. They are generic so they are built to support switches and controls for many different types of machines. If the post was build for one specific kinematic and control I think it would be a much smaller post to work with. That would make it much easier. I was told the nuts and bolts of the software are written into the .psb and that is not something they want to open up and I understand and respect that.

[Mick]

Ron is right. I had to tweak a 5 axis post recently, as there was some gaping flaws in the 5 axis output (I was writing in TCP). While I got it to work, I had to use a workaround. It would have been far easier to access the code with the psb, but that was too much of a mission to get it done.

[Watcher]

...From what I understand, in full 5-axis machining Mastercam creates a WCS for each individual axis change, then executes that move as though it is done in 3-axis.  Kind of like machining in 3+2 only fully automatic.  This is all done in nci so the magic in the psb is the equivalent of linear algebra with a few matricies (3x3, 5x5?) crunching the transforms...

 

Not trying to make it seem more complex than it really is nor simpler. In full 5 axis, there´s no such thing like one WCS for each tool vector. All the output is based on a specific WCS and the tool vectors IJK are related to this WCS (Cartesian coordinates and angles). But what makes the angular motions is not a WCS but the XYZIJK coordinates/vectors in each position. In 3+2 you are correct, each WCS represent a orientation.

 

Yes, it uses matrices, but that´s just part of the job. There´s a lot of logic depending on the kinematic model, and the post has to do a lot of magic to deal with feedrate calculations, rounding and division by 0 scenarios, axis rewinds, repositioning... the list is long... transformation is only a portion of the post... you can have a useless post for a 5 axis machine even with perfect XYZABC coordinates...

 

A good 5 axis post solves a lot of kinematic issues and acc/de-acc stuff... For example: Trunnion tables have some particularities when dealing with acc/de-acc, just like nutator heads... each kinematic model has its quirks... That´s why it´s important to get a good post and sometimes only purchased posts will do that extra magic for your machine... Generic posts are... generic...

 

Like I said, not trying to make it more complex than it really is nor simpler... but it takes a lot of science and knowledge of physics to make a decent 5 axis post, specially a Mastercam post where almost everything is coded in MP language. When you have a post builder like ICAM or GPOST the kernel of these systems do the hard work for you, you can do a lot through their graphical builders. (The nasty stuff needs to be coded anyway...) - In MP, everything needs to be constructed by the post builder.

[crazy^millman]

Not trying to make it seem more complex than it really is nor simpler. In full 5 axis, there´s no such thing like one WCS for each tool vector. All the output is based on a specific WCS and the tool vectors IJK are related to this WCS (Cartesian coordinates and angles). But what makes the angular motions is not a WCS but the XYZIJK coordinates/vectors in each position. In 3+2 you are correct, each WCS represent a orientation.

 

Yes, it uses matrices, but that´s just part of the job. There´s a lot of logic depending on the kinematic model, and the post has to do a lot of magic to deal with feedrate calculations, rounding and division by 0 scenarios, axis rewinds, repositioning... the list is long... transformation is only a portion of the post... you can have a useless post for a 5 axis machine even with perfect XYZABC coordinates...

 

A good 5 axis post solves a lot of kinematic issues and acc/de-acc stuff... For example: Trunnion tables have some particularities when dealing with acc/de-acc, just like nutator heads... each kinematic model has its quirks... That´s why it´s important to get a good post and sometimes only purchased posts will do that extra magic for your machine... Generic posts are... generic...

 

Like I said, not trying to make it more complex than it really is nor simpler... but it takes a lot of science and knowledge of physics to make a decent 5 axis post, specially a Mastercam post where almost everything is coded in MP language. When you have a post builder like ICAM or GPOST the kernel of these systems do the hard work for you, you can do a lot through their graphical builders. (The nasty stuff needs to be coded anyway...) - In MP, everything needs to be constructed by the post builder.

 

 

Good to see you around. Stop in an say hey more often.

[Colin Gilchrist]

The PSB section does have the matrix math and logic calculations encrypted, and for good reason. There are sections that you don't want pirates getting their hands on.

 

That said, all of the output from the post comes from the PST part. Even the "post generated" moves.

 

The Generic Fanuc 5X Mill Post has switches at the top of the post that control the kinematic configuration of the internal logic. This includes setting the orientation of the Linear Axes (set with the Machine Base Matrix), and the orientation and rotation directions of the rotary axes.

 

Since this post is setup to handle basically any configuration of kinematic machine, all those values get stored in matrices that are defined inside the PSB file.

 

But the post does much more than just setting up the basic configuration of the output. The post also has the ability to generate moves if it detects that the distance from the end of one toolpath to the start of the next is beyond a user-defined threshold. This behavior can be turned off/on, like most of the other options available to you in the post. You can also define a "clearance box" around your part, and have the post processor automatically insert retract/approach moves to get your cutter from one side of the part to the other.

 

The other thing the post controls and keeps track of are the rotary limits. So for example, on a gantry style machine when you hit the primary axis limit, the post will output an "unwind" move. This retracts the tool along the tool axis vector (away from the part), unwinds the head 360 degrees, (or less/more depending on if it has to change the secondary), plunges back into the cut, and continues cutting.

 

So there is a ton of stuff that is binned in the PSB file, but that doesn't mean you can't overcome that, you just have to know where to look.

 

For TCP output on a Table/Table setup, you basically have to switch the "machine type" and associated rotary variables to tell the post that the machine is a "Head/Head" style machine. There is quite a bit of work involved to do that, but it can be done with the Generic Fanuc 5X Mill Post.

 

The alternative is to write your own 5X Post completely from scratch, which know you, would be totally doable. If you are interested to learn more, I teach a 5X Post class where we explore the Generic Fanuc 5X Mill Post, and I go through how to configure the post for different machine types, and understand how to use the Misc Values to control post output. We also talk about how and where to modify the post blocks to do things like enable G68(or G68.2) plane rotation, or enable/disable TCP and DWO. (Tool Center Point Control and Dynamic Work Offset. DWO is also referred to as WESC I think). We also explore the definition of Vectors and Matrices, and use functions like 'atan2' to calculate rotary angles based on the tails of the tool axis vectors.

 

Hope that helps,

 

Colin

[Bob W.]

This is fantastic information, thanks for all of the replies.  I was unaware that so much information was pulled from the psb during posting.  I thought it was pretty much limited to the 5-axis position calculations which are pretty straightforward.  I was able to calculate the .nc code positions from the .nci code data (x,y,z,u,v,w) in an Excel spreadsheet so I didn't really understand what the big deal was.  These posts have been enlightening.  I don't really have the time to write a post myself but I would like to be able to have an intelligent conversation with a post writer to get exactly what I am looking for.  I modified the generic 5-axis post to get my current post but I do plan to incorporate TCP in the near future and I don't really have the time to try and tackle that.  There are some huge accuracy gains to be made by running TCP and WSEC simultaneously and this was confirmed the last time Jeremy was out.  The result of running both is better than just running one or the other, at least on the Makino.  

[Guest]

DWO (RTDFO - Rotary Table Dynamic Fixture Offset) cannot handle simultaneous 5-Axis motion accurately. WSEC (work setting error correction) picks up where RTDFO leaves off. You can substitute WSEC for RTDFO in 3+2 but you cannot substitute RTDFO for WSEC in 5-Axis simultaneous.

 

HTH

[Bob W.]

The B and C axis on my machine are off by .0004" from intersecting.  The only way we could get the machine to compensate for that was by running both TCP and WSEC at the same time.  WSEC alone, without TCP would not account for the stagger.  TCP would do it alone but without WSEC one has to program to the COR.  We confirmed this through extensive testing and varying of the 19xxx and 26xxx parameters.  This is a major reason I want to incorporate TCP into my 5-axis machining.