What's new
What's new

How hard to write a custom post for Mastercam?

motion guru

Diamond
Joined
Dec 8, 2003
Location
Yacolt, WA
I have a customer that owns a slew of older machines that all have proprietary CNC systems that are getting difficult to support and maintain. The machines have an odd linkage arrangement that allow the workpiece being machined to be rotated and translated using a parallel axis arrangement and a spherical joint with a rotating A-axis to boot.

All that is to say that while I can control this machine and have even figured out the forward and inverse kinematic equations to be able to simplify programming the machine - how difficult is it to get MasterCam to generate G-Code for this odd machine mechanical arrangement?

I'd like to retrofit the machines to standard CNC controllers (the easy part) and then help them simplify programming by getting their preferred CAM system to generate code that will run these machines.
 
For oddball axis movement I would look at TopSolidcam before messing with Mastercam. I use MC and have a couple very modified posts, but I wouldn't want to deal with MC and weird axis configurations.

While you likely can modify your MC post to work, you will never get correct simulation inside MC, and that is going to suck in getting everything working.
 
It is the customer who has asked if his MasterCam post can generate G-Code for these machines - having never worked with MasterCam, I have no idea what kind of third party post capabilities it has. It seems that most of the machines we do are somehow non-standard enough that a special post is required. The last one we worked on was with Catia and coordinating 15 axes of motion all interpolating at the same time was not something any of us thought would be easy, but the engineer tasked with the work was able to get it working in a few short weeks. Those were all nice Cartesian axes though and these machines are not at all friendly in that way. I'll check out TopSolidcam. Thanks!
 
Get in tough with Colin Gilchrist at Eapprentice. Pretty much your go to guy for anything post related with MasterCam.
 
"The machines have an odd linkage arrangement that allow the workpiece being machined to be rotated and translated using a parallel axis arrangement and a spherical joint with a rotating A-axis to boot."
perhaps if we had a little more of a clue what precisely you are asking about, we could give you a yes or no or a maybe.
a spherical joint seems to denote at least two rotaions, not just an "A to boot".
are you asking about posting after your retrofit or before?
 
Interesting. Doesn't odd motion usually get handled in the machine control, not the program? I mean, shouldn't the machine control "do the math" to get all the motion to work to get thing A in the right position relative to thing B?

All that said, the MasterCAM post is just a C type language. It's pretty simple. That hard part is learning all the internal variables. Get in touch with the local MasterCAM reseller. Writing posts is a huge part of selling the software. Everyone wants their code to be just so. Almost every machine is different.
 
"The machines have an odd linkage arrangement that allow the workpiece being machined to be rotated and translated using a parallel axis arrangement and a spherical joint with a rotating A-axis to boot."
perhaps if we had a little more of a clue what precisely you are asking about, we could give you a yes or no or a maybe.
a spherical joint seems to denote at least two rotaions, not just an "A to boot".
are you asking about posting after your retrofit or before?

"Spherical" probably wasn't the best choice of mechanical descriptions. There are two axes of rotation:

The first rotating axis is created by displacing two parallel ballscrews relative to one another - and this rotation is combined with a translation if both ballscrews extend or retract together.

The other rotation is created by a true rotary axis and rotates orthogonal to the first rotation.

They have two machines down now looking for parts to get them running again. I have enough test / demo equipment to breadboard together a 5-Axis CNC control on a backpan and do some testing. If I can deploy a test CNC on the machine with a couple days of work and have a reasonable post to try - that would give the customer enough confidence to move forward with a plan to retrofit this series of machines.

I have the retrofit of the CNC covered, but the CAM system post with selection of typical tools is what is missing.

This kinematic arrangement is not like anything I have seen in a machine tool. And to program it into the CNC controller would require both a ridiculously priced license as well as a significant engineering cost / investment to get it done. I need to balance the cost of doing it this way versus having this all done in MasterCam and figure out which way is most cost effective.
 
I am not sure about the 'custom' post. The editing I have done with Mastercam posts is pretty simple really, changing the output from C (rotation axis) to A, clockwise to output + angle instead of negative angle, etc. Not sure I would want to tackle what you are doing. For the record, the Haas UMC-750 post (with machine simulation) runs over 4k, at least what we were quoted....
 
I'm still confused why is a CAM issue. Are there duplicate (parallel) axes of motion that must be selected by the program code?
 
Rotation of axis C is accomplished by two ballscrews.
Translation of axis X is accomplished by the same two ballscrews.

Extend Ballscrew1 and Ballscrew2 together the same distance and you get a pure X-Axis move in the positive direction with no change in the C-Axis

Retract Ballscrew 1 and Extend Ballscrew2 the same distance each and you get a pure C-Axis move with no change in the X-Axis.

In machines where I have had to deal with this kind of kinematic arrangement before - if it is non-CNC machine, I just coded it in the controller. I have never encountered this kind of mechanism in a machine tool and I am not sure if this is something that should be in the controller or in the CAM system post.

If in the controller - the license is about $10k plus engineering to code it - if I have to repeat the license cost for 8 machines - I think it would be easier / cheaper to do in the CAM system
 
How hard can it be to put another piece of software in between to handle the transform?
I'm a rookie at M-cam posts but I think this is fancy dancing inside here.
You know how to handle the kinematics.
Can't be that hard to run it though from standard M-cam to real world, you've got very good people there who would love something along this line.
I'd kill to have a job doing this type stuff.
Bob
 
What you are describing sounds similar to a Hexapod. I know Okuma and Fanuc can control that type of machine. That seems like a control issue and nothing to do with a CAM system.

 
well a post just takes CL data from the GUI (cam sys) and crunches the numbers via formulea in the post.
this setup would need some pretty heavy mods inside the binary file part of the MC post so no shade tree post hacker (like me) is going to cut it. If you already have some code/ math that might help the Mathematician/ gods to tweak.

in addition to the above referenced vendor you could also talk to Postability or In house solutions. i would guess it could get done at or below the single seat machine controller you mentioned.
but at the end of the day you are still going to have an odd proprietary setup that is going to scare 99% of the operators outta the shop and only have one CAM system to do it. tough call.

not sure what the advantage of this intriguing kinematic solution is but i'm sure you have already considered simplifying the whole thing by deleting one of the parallel x axis' and replacing it with a commercially available ROTARY. lol:D
 
FWIW tritech has a similarly odd setup for their rotary-train.

to get one rotary axis movement, you need to command two.

they offer posts for multiple Cam systems, so it can be done. but i would never buy into such an odd config.
 
Thanks for the comments - these are specialty machines that are highly sought after in a specific industry - not at all for typical machining operations and I hesitate to get to detailed for competitive reasons with the OEM.

The best opportunities I have had in my business have been with machines that the OEM has failed to support long term.
 
I made a quick animation of the machine actuators and operation - I have crunched through the kinematic calculations but haven't yet gotten much information on how to get a CAM package to generate G-Code for this configuration. To clear up confusion from my posts above . . .

X-Axis is the first move in the video
Z-Axis is the second set of moves in the video
C-Axis rotation using the ballscrews (Z1 and Z2) - third move in the video
A-Axis rotation where the blade is fixtured in the video

That should be easier to follow.

https://picasaweb.google.com/kinemation/BladeTransportHandlingSystem#6130744912463474130

The ballscrew motor mounts pivot and the ballscrew nuts pivot. Each ballscrew (Z1 and Z2) / motor mount assembly pivots +/- ~ 6 degrees when the rotation of the fixture rotates +/- 20 degrees. . . why would anyone build a machine like this?

My question is -

Do I embed the translation parallel to the spinning axis of the Grinder (Z-Axis) and the rotation about the (C-Axis) into the controller and then get the CAM system to spit out G-Code for X, Z, A and C?

OR

Can I do this all in the CAM package and get it to spit out G-Code that commands X, Z1, Z2 and A?
 
In machines where I have had to deal with this kind of kinematic arrangement before - if it is non-CNC machine, I just coded it in the controller. I have never encountered this kind of mechanism in a machine tool and I am not sure if this is something that should be in the controller or in the CAM system post.

I know that at least EMC2 handles kinematic motion control side, and runs cartesian gcode. I'd kind of assume that was the norm with kinematic motion machines, as all the ones I've seen appear to use standard controllers - Okuma, Scharmann use Siemens etc. Don't think I've ever seen a Fanuc on a kinematic machine though.

I'm pretty sure that doing it all in post would be a mistake and require many workarounds as any cam system is going to be heavily focused on cartesian code generation.

Edit, after reading your last post.

My question is -

Do I embed the translation parallel to the spinning axis of the Grinder (Z-Axis) and the rotation about the (C-Axis) into the controller and then get the CAM system to spit out G-Code for X, Z, A and C?

OR

Can I do this all in the CAM package and get it to spit out G-Code that commands X, Z1, Z2 and A?

All post processor languages that I have ever worked with (only a handful admittedly) don't make any particular distinction between parallel axis. They provide three axis of linear and three axis of rotation. Any parallel motion is entirely done in the post as the cam system will not have any built in support for it. Because of the very basic nature of most post languages, and on the fly interpretation, doing this in post is going to require some lengthy code that will be horribly slow to execute, and difficult to trace/debug. Some do provide some hardcoded coordinate manipulation functions, but still this really isn't the job of the post.

If possible, you should do it in the control, IMHO.
 
Ok, I think I can manage programming the transformation within the controller to run the stage from X, Z, C and A axis commands. Now the question is do I reference those axis movements from the perspective of the CS defined by the machine or from the CS defined by the Workpiece? I guess that as I think about it, generally 95% of the machines I have worked with are straight up Cartesian CS systems where G54..5x and tool data is used to allow the program to always run in workpiece coordinates.

And then there is the CAM post processor to deal with as well. I am beginning to see why the OEM had a funky on-machine method of programming with lots of tedious offsets and guess and check methods to get it dialed in.
 
I think it'd be worth it to look into Vericut or other verification packages. It's never fun finding out the program was wrong at the machine
 








 
Back
Top