Parametric Programming Versus CAD and CAM Toolpath Creation

A request for help in defining a shape mathematically for machine code leads into a discussion of situations where hand-coding and math are better than working in higher-level drawing and toolpath programs. February 19, 2013

Question
I'm trying to calculate the XY locations for two tangent arcs. Any help would be appreciated.


Click here for higher quality, full size image

Forum Responses
(CNC Forum)
From contributor B:
Is this a quiz or do you just need to know those coordinates?



From the original questioner:
I need them for a parametric program for a CNC router. I have it figured out on one of our other CNC routers (a Weeke Venture 5L via WoodWOP) but on our Busellato routers I can't program it the same way parametrically with a fillet. I've actually contacted the machine manufacturer and they said I'd need to trig it out to achieve this. And I've been racking my head for a while.

I'm pretty good at writing code. I'm achieving the same thing in AutoLISP in an automatic print creation program. Now just need to parametrically program the machines for this basic shape. The width, length and radii vary.



From contributor B:

I remain baffled by the need to program these things for CNC cutting. It would take about 5 minutes to draw this in AutoCAD and toolpath it with CAM software. I do understand there are situations where working with code can be more efficient in the long run. But for individual parts like this drawing, using a CAM package is just so easy. Can you tell me why you don't just do this?


From contributor J:
This brings back days of doing MacroB programming on a Fanuc controller. I believe I have come up with a formula that will work for you.

If your x(width) is 48" and your y(height) is 60".
The formula you can use is for determining the x1 value is: =r2-(r2/2.9612)
For your y1 value:
=(r2x1.0586)-(r2/8.5225)
These two numbers are the end coordinates of the r2 arc relative to their start point. This should achieve what you are looking for.



From contributor M:
I guess the easiest way is to use the contributor's example. Let's assume he is offering these to custom fit to the customer's requirements and every customer has different requirements, but proportionately, they all want the same geometry.

Let's say his volume of these is 500 a year. A competent cad/cam programmer can draw this up, tool path it in 5 minutes. That in itself is 2500 minutes which isn't bad (about 42 hours of programming time a year), but then you have to transfer the code to the machine. Depending on your method, let's go with 1 minute. 500 minutes (8.3 hours a year).

Even though all of us would like to think we would never make as many mistakes as we do, things happen. So in every shop I have been in there is some degree of proving of new programs. Hands on the override, watch the approach and distance to go screens, etc. Our first new program rarely runs as efficient as the subsequent times we run it after our confidence in the process is stable. This is very true if you have a very conscientious operator running a program generated by someone else! Throw a few minutes (and that is being kind) in there.

And don't forget, those 500 programs have to be maintained, retrieved, recalled to the control, etc., if you ever want to run it a second time 6 months later. That is going to take some amount of time. I know everyone has nice directory structures and filing methods, but it still takes time. We just don't see it when we look at it on a daily basis because it is only a few minutes. This is also one of the foundation concepts of Lean, focusing on the seemingly insignificant, but that is for another post.

This is probably the questioner's intent (correct me if I am wrong).
1.) He understands the volume, frequency and demand for this product and doesn't want to program it every time it comes through. After all, it is relatively simple geometry, so why waste a lot of the time above?

2.) Once he constructs a solid parametric program, it is proven. It can actually be written in a manner to prevent errant variables from even being entered and it is not run as a new program every time as opposed to the rapid CAM posted program. It is one program to be maintained, usually resides in the control and all personnel involved understand its intent and efficiency.

3.) The boss comes up to him tonight at 10:00 PM and says I need 30 of those parts tomorrow by 9:30 am and the width and height is different on all off them. He gets a raise because simply going from one part to the next, even though they are different sizes, only requires seconds to edit the program variables by the operator. From a throughput and lead time standpoint this can be pretty big. The program is always ready to go. There are no external supporting processes (additional PC, transfer protocol, programmer) that need to be scheduled (come in at 4 AM and have those programs ready to go by 7), all of which have the potential to have something happen to slow down the money making process of cutting those 30 parts.

Parametrics and variable programming is a little more than just playing with the code. You can control the way the program flows, what it does and doesn't do, create your own custom canned cycles. In fact, the math behind a lot of CAM packages is the same math parametric programmers use. It is another level of programming and isn't for everyone. But if you have applications for it and don't use it, you're literally throwing away time and money.



From contributor M:
I wouldn't purchase a new Fanuc without custom Macro B.


From contributor J:
I do agree on the Macro B should always be purchased. Back in the 90s, not a lot of people bought that option. But it came in handy to write one program for different sizes. Now that is standard on all PTP, but not on the flat table machines.

Most people do not rely on the software to do all the parametric and push out finished code for the machine. So not a lot of machines come with that option. It is good to have in case you don't do nesting.

Of course, my math is one way of figuring out the questioner's calculations. There is always another way of doing the math using sin/cos. I chose not to do it that way. This calculation will only work on this style particular door pattern.



From contributor J:
If you wanted to do the math using Sin/Cos, this would be the formula to use.
hyp(hypotenuse) = r2/.8688631269
y1=sin(55)*hyp
x1=cos(55)*hyp

That would do the math for the x and y start point. You could shorten the .8688631269. But the longer, the more accurate the formula. If you shorten it to 4 digits, then the start and end points are off by about .030 in x and y. Just trying to give you options. I would personally use the first formula. It is more accurate at 4 decimal places. This is the standard accuracy for most machines.



From contributor B:
Contributor M, thanks. I can see that comes from a conviction to the system. I do understand though. There is definitely an advantage to being able to enter size variables right at the CNC to repeatedly create the same basic shape in different sizes. If I had stopped to think about it just a bit more I'd have realized we actually do the same thing for true radius arches. I have several DOS wizards right on the control PC that we use to create the code without having to do the drawings. They are simple math by comparison but the concept is exactly the same. Thanks for taking the time to elaborate the theory.


From the original questioner:
Contributor B, yes, this is a very simple thing to do. And I've actually written an AutoLISP routine to automatically draw the these tops. But like contributor M was saying, we have such a large volume of these and making it parametric for the machine is the way to go.

One of our other machines has a fillet/chamfer option which is what we're doing parametrically. The other machines we have I'm not even going to attempt this. One runs a Fanuc controller and yes, it has macro programming option on it, but there is too much going on with that and it's also primarily used for other products. The last machine runs a very old NUM controller and we'd program this via AlphaCAM anyway.

Contributor J, I'm gonna give your idea a try. This is probably quick and easier than what I was thinking and trying. I'll provide the CNC file for the Busellato and MPR files for the Weeke if anyone would like to see the whole scope of what I'm talking about.



From contributor C:
I had a similar problem also. We have 13 CNC routers, a couple of them running WoodWop. It is easy to create a parametric program in WoodWop. We have CadCode, which has a MPR reader. I create the program in WoodWop, feed into CadCode, and make code for any machine I want or all at the same time. I worked with Ned until he had it reading almost anything from WoodWop.