Trunnion on 4axis machine, rotational limits for continuous 4axis motion

[Carbonwerkes]

Hey guys

 

Sorry for what may be a stupid question. Im running 2017, and I just acquired a 4th axis trunnion for my rotary table. In the past, I had no trouble with the standard MPMASTER post. But, with the trunnion, there is the issue with rotation limits. I have been able to implement base limits in the machine def, and that works as regards the post (it simply will not post any operation that MC has generated an excessive rotational angle to achieve). But that doesn’t help much- ops are omitted, and I cannot simulate natively since the omitted ops are only in the .nc code output…

 

My understanding is that the logic for this is typically found in a 5axis post, but from a MC perspective, I would have thought defining limits in the machine def would tell it how to position the table (what angles to generate as NCI before the post even looks at it). That way, I can simulate motion/travel natively. And that would seem to be more a function of a 5axis toolpath parameter set than the post…

 

So, do I stick with my 4axis MPMASTER post, and tweak the rotational limits in the operations themselves, or is there some interplay between MC and the post where MC will use logic in the post for figuring out how to position the table (as with native simulation etc)?

 

Sorry- just a bit confused, and any clarification would be much appreciated. I did do some searching here, and found some references, but mostly they were in regards to physical limits of the trunnion (trunnion table crash with the column, etc), and not about preventing an undesired rotation of the table for what is a 4-axis toolpath. There is a forum entry  just below which is similar, but again, that is more about hard limits and less about having MC figure out how to deal with complex 4axis surfaces within a single op (i.e. not taking shortest path, but not simply cropping code either).

 

Best

CW

[nickbe10]

Stick with the MPMASTER. It is written to do 4 axis continuous/multiaxis, and I have used it to do those toolpaths on both VMCs and HMCs. There are a number of switches at the top of the post too that might help you out.

It could also be how you are setting up your toolpaths. Make sure you are locking the Y axis in your parameters, assuming you are rotating on the x axis.

I wasn't involved in the detailed set-up of the MD/CD for the above but there are plenty of people here who I am sure will chime in with advise, there is probably more than one way to skin the cat.........a sample file with the problem will greatly help troubleshooting. 

[crazy^millman]

Did you read this thread just posted yesterday?

A Limits using MPMASTER

Mastercam is not a Kineamatically aware software. It is a Vector based anywhere in space will work software and let the post do all the heavy lifting after you have made the toolpaths process. I mentioned how you can get the post to tell you there are errors on the other thread, but far as I know out of the box MPMASTER or even any of the Generic Mastercam posts don't do what you are asking. There are ways to do what you are needing, but you will have to read what I posted in the other thread to narrow it down.

[Carbonwerkes]

Yes, I did read your comments in the other thread- I appreciate that post and your response here.

 As I mentioned above, the issue I face is not (conventionally-speaking) a function of order of different operations. It is that for a given continuous-motion toolpath on an organic surface, I don’t really have option to break down motion without a huge amount of effort.  Even that would be less a burden relatively if we were running 10K parts, but we do prototyping, and 10-20 parts of a given type is a lot for us.

Putting limits in the MPMASTER does seem to work in catching moves that violate the output, but that isn’t helpful except for a notification. It throws a warning, and seems to cull the offending (remaining) maneuver(s) from the output even though they are machinable if the trunnion simply moved the other direction for repositioning. The basic sim wont catch it regardless, and the advanced sim strangely will show ‘proper’ motion if you set it for manual limits (as with the video Giang posted on Youtube for a 5-axis problem which is similar- which seems strange- the logic for repositioning properly exists in a bolt-on sim but not in the toolpath generator?).

Hence my question- where Giang opted for the generic Haas 5-axis post. Was just hoping MC has enough smarts to realize that a violation on a rotation limit in one direction on an A rotation in only one of two possible rotational solutions doesn’t mean you abort that operation, but that you cut what you can, and then continue on for an extension of that cut once it becomes kinematically possible by rotating the table within the constraints defined. Just really hard to understand how that is not native to MC, since that move might involve entry-exit paths which the post is not going to manage well absent significant effort, and where this concept exists for even basic 3D 4-axis machining with concepts like containment boundaries and check surfaces- which can require significant modification of the toolpath in 4-axes by the MC engine.

Best

CW

[nickbe10]

1 hour ago, Carbonwerkes said:

As I mentioned above, the issue I face is not (conventionally-speaking) a function of order of different operations.

So you have to remember that you are driving mutiaxis toolpaths which have the built in ability to move 5 axis simultaneously. But you are one rotation axis short of a full loaf. The key to this is how you set up the part on your machine. You have to compensate for the lack of the extra rotational axis by placing/tooling your part such that you pre compensate for this. If your machine is unable to rotate in the axis you desire no post is going to get you out of your corner.

To give you an example from aerospace which is where my experience comes from. Many parts have only one or two 5 axis surfaces, so we would line up the part so that the (usually) swarfed surface was parallel to the Y axis. Now the Y axis rotation alone is required to generate the motion.

If there was an additional multiaxis  surface this would require a second set-up with the part repositioned to give the rotation along the axis you require, unless by happy chance the two surfaces are near enough parallel. Usually if everything is set up correctly and you try and rotate around an unavailable axis MC will tell you.

How you set up your rotations and planes is also important. If you are running rotation macros (WCS,Cplane and Tplane all the same) instead of WCS on COR and rotated planes. you might not get a warning, I've never tried to run multiaxis with rotation macros so I don't know.

Also use Mastercam Origin, constructed origins in space can give unpredictable results with multiaxis, and you lose some functionality, at least the last time I was doing this you did, no lead and lag available (might be fixed now, I last did this in X5).

How you set up and call your work offsets for your rotated planes is important, use only one (e.g.G54) and make sure the origins are all the same in your different views (this is how you control your entries) 0,0,0 if you are on MC Origin.

If you construct any vectors to drive your path you must make sure they lie in a plane at right angles (perpendicular) to the Y axis, otherwise the system sees this as an additional rotation axis, which you don't have. There are ways to ensure this is so.

You might have to "cheat" a little and use some of your tolerance.

Remember it's a 4 axis machine and nothing is going to change that, no matter what post you use.

Hope that helps

[crazy^millman]

Read the topic over there again seems there is a solution that was offered and one that seems to work so I might be eating my words which is no problem for me I like learning new and different things.

[nickbe10]

Note my description above is for an HMC, for a 4 axis VMC your part would have to be arranged relative to the X axis not the Y.

Sorry about the confusion, a few posts about this at the moment and I lost my way.....early onset....

Also lock the axis you don't have a rotation ability on in the parameters.