5 axis help using a trunnion

[Jeff2005]

We have a 1052VII millac milling machine with a tsudakoma trunnion using C as rotary and A as, what i call the cradle.

The "A" axis rotates about the "Y" axis, so it is sitting in our machine 90 degrees from normal.  The post swamps the axis.

 

We have been trying our best to run a full 5 axis program on our machine since day one, which was over a year ago.

We bought a simulator to be sure our programs don't crash unexpectedly.

we found out about 2 months ago the software that runs the trunnion is out of date.  which like it is, makes the trunnion run slower. This was causing a problem using inverse time.

We made the call to Okuma and they made a request to Okuma Japan for updated software, two months later and we now have updated our trunnion software.

The part i was trying to program, before the trunnion problem, I resumed trying to program after the update.

when we make a program and run the simulator, everything looks great.  When i post the program and take it to the machine in starts 180 degrees different than the simulator shows. the way the program is now in the machine it will crash into the part, it's doing moves it doesn't show on the simulator.

We have tested program after program from our reseller.  The programs they send us test fine, so I am thinking i am missing a setting or something so it will stop the crazy motion it's doing.  I would appreciate any help.  I can send a file if i need to.  it will have to be through dropbox.    My email is [email protected]

 

thanks for any help.

JEff

 

[Greg Williams]

Sounds like you have a post error do you and the reseller use the same post?

[Jeff2005]

Yes.  we have been trying to prove it out to send it to the developer for final adjustments.

[Greg Williams]

Jeff,

From what I can understand the simulator is different to the machine? the machine will always be the master, the simulator should replicate what the machine does not the other way around, send me a zip2go if you want and I will take a look. Sounds like the post has the wrong zero point for one of the rotaries.

[Jeff2005]

Our 3+2 programming works fine. If the zero point was wrong would the 3+2 be correct?

[Jeff2005]

https://www.dropbox.com/s/1d74llr98k4zzux/%23401 FORM X9.Z2G?dl=0

here is the ZIPTOGO via dropbox

[huskermcdoogle]

Are you using TCPC?

[huskermcdoogle]

Looking at your code, I guess you aren't.  Do you have the TCPC option?  If you do its usually a better idea to run it than inverse time and posted rotary offsets.  Makes your programs more portable and you shouldn't need to repost in the future.

[Jeff2005]

Well, I have been around the world with this trying to figure out why this won't run .  From the beginning all involve said inverse timing is a better option.  I could care less which option we run I just want it to run.  Below is a link explaining what the typical go-to type program is preferred.  Now you are telling me, TCPC is better, you must explain in further detail why it's better than inverse timing , please.  

 

I did check with our machine reseller, and they confirmed, we do not have the TCPC option on our machine.

 

https://www.okuma.com/essential-multi-axis-control-options

[mkd]

10 hours ago, Jeff2005 said:

Our 3+2 programming works fine. If the zero point was wrong would the 3+2 be correct?

are you using CALL OO88  for 3+2?

[huskermcdoogle]

TCPC is generally always better for a multitude of reasons, and Ron explains that pretty well in that article.  His mention of inverse time, is the old go-to that lots of people still use.  The four paragraphs after that are the newer and more capable portable methods that will help the industry become more accurate, agile, and efficient.  Ron does a good job explaining why those options are useful and worthwhile.  But it mainly comes down to not having to adjust the post and repost code if you have a machine crash or thermal drift.  It also makes the programs generally portable between machines, say from one table/table machine to another.  The kinematic offsets are in the parameters and therefore the program will run accurately on both machines.

With an Okuma, correct me if I am wrong, you can't or wouldn't typically use inverse time in TCPC mode.

But... given that you don't have TCPC, you are most certainly better off using inverse time, and having all of your kinematic offsets built into your post, and therefore posted code will be specific to that machine and only that machine.  It's the only way you will make a good part.  Given that you have a table/table setup, I don't think tool length really comes into play code wise, and you can use regular height offsets in the program to manage that.

Good luck.  It sounds like an axis direction or zero was flipped from the original software to now.  This could be as simple as a parameter change.  Talk to your dealer or apps guy about that.  You don't have an example of how you are doing 3+2 working in your sample file, so I can't really speculate there.  Therefore your post and your simulator, or the machine will need to be adjusted to correct the problem.  I see its a postabliity post.  Dave should be able to help you get it sorted out if its a post issue.

[Jeff2005]

22 minutes ago, mkd said:

are you using CALL OO88  for 3+2?

I am not sure.  Given the fact that the 3+2 was working form the get-go.  I picked up trying to figure out the 5 axis stuff, only because our other programmer got mad midstream. I don't think we are using the CALL OO88.  

20 minutes ago, huskermcdoogle said:

With an Okuma, correct me if I am wrong, you can't or wouldn't typically use inverse time in TCPC mode.

 

Not sure about this.  We only have ONE okuma using a trunnion, so you are correct our best bet is inverse timing. 

As you can tell from our conversation, I still have a lot to learn about all the ins and outs of 5 axis programming. I am not sure I will ever get it, but my reseller thinks I will eventually.  I do appreciate the inputs.  thanks.

[mkd]

search this forum for g169 and you'll see some refrence to 0088

[huskermcdoogle]

Once you get your head wrapped around it, you are going to feel like you were over complicating things.  It's just vector math based on rotational center offsets and whatnot that allow the post or machine control do its magic, while that may be above most peoples heads math wise, the concept behind it is very simple.  It's just rotating points around other points in space.  The logic built into the post's thankfully can usually be easily manipulated to accommodate different c/l offsets which makes the changes attainable by us normal folks once in a while.

[Greg Williams]

I don't think you can have TCP with a dual rotary add on table. I am not sure the machine will have the CALL OO88 option either.

You will need to have all of the operations from the same WCS for this to work. There is no datum tracking OO88 in the code and maybe not even in the machine, so hence there is no mechanism for the control to track the moving datum as you change the WCS values.

As I see it you have 3 choice

1 - Have your local apps guy extract the CALL OO88 sub from the msb file on another 5 axis and load it in your machine, he will need to check the internal variables are there as some are linked to specific machines. The apps guy could then set it up as a custom gcode say G120 or even a just a sub *.ssb and call that from the NC code.

2 - Use the same WCS for all operation which will mean setting up the part on the machine then  adjusting the part in mastercam before posting

3 - have Dave add the pivot points to the post if you have a fixed table or chuck.

 

Any questions feel free to drop me a line.

[Jeff2005]

8 hours ago, Greg Williams said:

3 - have Dave add the pivot points to the post if you have a fixed table or chuck.

 

Any questions feel free to drop me a line.

Who is Dave?  If he is the person from Postibility, then I don't know him.  We are dealing with our reseller from QTE manufacturing.  Should I be dealing directly with "DAVE"?

 

[crazy^millman]

2 hours ago, Jeff2005 said:

Who is Dave?  If he is the person from Postibility, then I don't know him.  We are dealing with our reseller from QTE manufacturing.  Should I be dealing directly with "DAVE"?

 

Dave(Postability) along with In-House are used by many of the dealers for Posts, but at QTE you have a world class organization who does what I consider a great job. I think they are newer to your area, but Reece and Mark along with many others I know personally there are good people. Stay put and they will guide you to help you get where you need.

[Jeff2005]

Should the NCI code match the NC code?  The NCI code is what I am seeing from the simulator.

thanks,

[Guest]

6 minutes ago, Jeff2005 said:

Should the NCI code match the NC code?  The NCI code is what I am seeing from the simulator.

thanks,

In a perfect yes.....but the post manipulates the nci data to output the actual gcode....so they may not match

[mkd]

Is there still a way to choose the 2nd 5 axis solution in MC simulation?

[Jeff2005]

26 minutes ago, JParis said:

In a perfect world yes.....but the post manipulates the nci data to output the actual gcode....so they may not match

How am I going to know when the program is correct?  At this point all I am getting from our reseller is small programs that seem to prove out correctly. When I try and do our part, then it does something stupid, that will crash.

My world has not been anywhere close to perfect.   I have pulled my hair out, had it replaced, then pulled it out again , trying to figure out why this won't run the way it should. i would love for someone that knows something about our setup to help get this fixed.   

thanks,

[crazy^millman]

21 minutes ago, Jeff2005 said:

How am I going to know when the program is correct?  At this point all I am getting from our reseller is small programs that seem to prove out correctly. When I try and do our part, then it does something stupid, that will crash.

My world has not been anywhere close to perfect.   I have pulled my hair out, had it replaced, then pulled it out again , trying to figure out why this won't run the way it should. i would love for someone that knows something about our setup to help get this fixed.   

thanks,

This is where a external Verification program is the key. Mastercam simulator is not real world as much as they keep trying to make it so it is not NC Code. The other thing is MP.DLL does so much stuff to the outputted code from the NCI how will the Mastercam Simulator ever really match? I have some projects I trust it as much as I trust and externally CAV program. This is the missing piece of the puzzle I have told every 3rd party post builder they must do and so far everyone has ignored me on this one thing. You must get data from Mastercam NCI and Mastercam outputted code. From there you can generate perfect NC code from Mastercam. ICAM goes a step further they take Kinematics into account when posting code. Really wish they were a better relationships company, but it is what it is. Vericut has a great product, but I can't seem to get them to stop looking down their noses at a Mastercam user and they don't offer Posting ability. NCSIMUL as far as I know doesn't take Mastercam NCI and make Posted NC code. They do have Posting abilities for all the majors, but not Mastercam. NCSIMUL hands down is the best product in the industry for Verification. I have a part right now that has been through Rev Changes and I have need to make changes to the program. In NCSIMUL I can take the update section and paste into already proven code and go from there. Vericut you must start over every time or save IP files for each progression through the file to keep moving forward. Time is money and I have well over a 100 hours of Vericut time on one of my current projects. With NCSIMUL I think it could be as little as 40 hours. I will put out this disclaimer I have never been formally trained in Vericut. (I have never been formally trained in Mastercam either.)

You have 2 choices you either become the verification process for your posted code sweating bullets every time you hit the green button or you spend the money and get a CAV program to save you that stress and worry. Time is money and how much money is it really costing your company? Once crash is you tore up a spindle $30-40K. $10 to $20k in down time? Even if you never crash how much time is being lost not trusting your code until you have run about the 3rd or 4th part? I ma tired of showing people how much money they are losing and not a personal comment to you, but amazes me still how much money companies throw away day after day.

Are you done yet?

[Colin Gilchrist]

What if I made you a special offer? Sign up for my 5 Axis Post Class (starting next week, running on Tue/Thurs evenings), and we'll use your Post as the sample post we build for a Trunnion machine.

I created this 5 Axis Post Processing Class to de-mystify the Generic Fanuc 5X Mill Post. In this class we take the Gen Fan 5X Mill Post and configure it for two different Machine Types: a Gantry (Head/Head), and a Trunnion (Table/Table) machine. I show you the variables that are used to configure the Post output, and show you how to control the post output using the Miscellaneous Integers and Real Numbers.

I'm not trying to step on your Reseller's or Post Developer's toes here, but I drop an incredible amount of 5X Post knowledge on you for $500 bucks...

That way you won't be beholden to your Reseller for 5 Axis Post Work, since you'll have the knowledge to do it yourself. (Or at least have enough knowledge to be able to intelligently direct your Post Developer on how to properly configure the output for your Post...)

https://eapprentice.net/product/live-course-mastercam-5-axis-post-processing/

Not only do we talk about TCPC vs. Inverse Time, but I show you how to setup those functions inside the Gen Fan 5X Post.

[Newbeeee™]

^^^snap Colins hand off.

[Guest]

FWIW why I believe TCPC is superior to Inverse feed is simple; Inverse Feed says "...I want my CAD/CAM software to calculate WHEN the tool gets to a given position..", TCPC says "... I want my MACHINE TOOL with all of it's kinematic awareness to do all the calculating.

Ever want to change a feed rate on an inverse program? Yeah, good luck with that. It's a repost at it's easiest because F is a function of time not feed. With TCPC, F is actually a function of feed (the time calcs are done in the control - where it should be done). I do a LOT of 5-Axis programming and sometimes there's a few spots (especially on a tight inside corner) where I need to make a feed rate adjustment on the fly for a short segment, in TCPC it's easy. In inverse, not so much. 

Bottom line; Inverse Feed = Old School and if you gotta use it it will get you good parts, TCPC = New School, smoother motion, easier to manage feeds on the fly, faster, etc, etc, etc.