Survey: 2.5D CAM features?

OK - so, one of the major sticking points with a Mac is that there is no good CAM software for it... a situation that I am not content with. But rather than just moan, whine, and complain about it, I, being fluent with Cocoa, can actually do something about it... which leads me to this:

I know what I'd like, but what would you like to see in a 2.5D CAM program? And, conversely, what wouldn't you like to see?

I'm specifically asking about 2.5D, not full 3D or multi-axis; as that would be based on a completely different engine.

I've already looked at other CAM programs, but just reading their feature set does not tell me what people actually like or dislike about them... and it doesn't tell me if it would be great if it only did "X"... ya know?


So, what do you folks think?

I tend to work from solid models most of the time. So the ability to import solids and then convert to geometry for machining. Or better yet machine the solid directly. Pick a horizontal face and choose to machine the perifery as a wall or pocket the whole thing.
Another thing that is very handy is the profiller tool in Gibbs. I have found that I use this tool frequently.

The ability to easily reposition the imported data.


I'm sure that most CAM users have a long list of likes and dislikes for all the popular packages.

ARB

Been a Mac user since I bought a Mac Plus in '87. Used to play with Virtual Gibbs (now GibbsCam). Always wished Bill Gibbs would have stayed with the Mac platform.

Anyway... ease of customizing the post-processer would be nice. And associativity between the part geometry and toolpaths is a must. A mask or filter for picking geometry, too. And a nice customizable tool library.

Glad to see someone taking an interest in the Mac market for CAM. I wish you the best of luck with it.

>> You might first define what you mean by 2.5D.

Ummm.... Good point.

Well, there's 3D based 2.5D - which is really a 3D program, but the CAM system is hobbled so that it can't do 3-axis simultaneous moves. This is not what I am doing - if I've already gone to the time and effort of making a true 3D engine, why not finish the job, and make a true 3D toolpath generator?

And then there's 2D-with-depth, which is what I am doing.

ARB - I'm afraid the solids thing requires a true 3D kernel, and would be a different app. But, for a 3D system, yeah - solids would be my preferred way to go...

>> And a nice customizable tool library.

E-Stop -

Umm... do you mean tools as in end mills, drills, etc, or tools as in click-the-icon, software tools?

I can send you an example of what I do, it might make sense, seeing it. Basically, lots of my work here is 2.5D jobs, and if any volume I will hand generate the toolpaths to tweak the run times. For exmple, we are running a 1200 part order this morning,and will start on a recurring order Monday that will be in the tens of thousands of parts.
Now, either part could esily and quickly be generated with most any CAM system. But, by hand generating the toolpaths, I can really improve on it, for a large run it is really impressive the gains possible.
Todays part, I estimated and quoted at 4 minutes run time. This coresponded with the shop that contracted it out, that is how they ran them too.
But by eliminating all rapids and retracts, and inserting operations into others... For example the part needs to be rough and finish faced, and the ends need to be rough and finished. So, in the middle of rough and finish on the top, it bobs down and nips off the ends while it is in the neighorhood, and keeps on cutting. I doesn't stop cutting from the time it touches down until it is done. Anytime I can cut with a smaller tool and avoid the toolchange, it is faster.
Any geometry segment I have I can define it's speed in the layer name. This is because of tweeking to the post processor. So I can optimize the cuts for every piece of geometry on the part, every fraction of a line segemnt or an arc can have almost any G code attatched to it, and this is hidden in the layer name for the geometry. The Post can process this on the fly.
Also, In the post, I can do multipe text substitution, to trick it into doing things it was not intended. I had an example of using a 2D geometry to generate Full 4 axes moves.
OK, for todays part, from a four minute estimate, we are getting 60 parts an hour, faster than the tumbler can keep up. For Mondays job, (In the 10,000s total) 20 minutes from the estimate, goes down to 3.5 minutes actual.
We push the tools till they break. And don't back off. I use the same tool for rough and finish, and don't take time for a tool change! Even though the tool life is short we get a lot of parts out the door, and focus on total job throughput, if we have to spend it on tools, you can see how we come out ahead on the job with the numbers I showed. Each feature on the part can have it's own CDC offset values, since any feature will cut differently.
If you cut really slow (for me) and consistent, you could get by with only one CDC value for each cutter. I estimate the cutter deflection, and program it into the each feature, and then we tweak it it at the control. We hold about .0005" this way, all month long.
All the feed rates for a tool are based on a base line for the tool, held in a variable. Thus:
N230 [#FEEDRATE] 120
N232 F [#FEEDRATE]
code....
N420 F [#FEEDRATE] * 1.5
code...
N502 F [#FEEDRATE] / 2
ETC..
This allows you to change the feedrate for an individual tool in one place, at the tool change, and all the speed ratios in the program will track. If the post set the feedrate at each point in the program, you couldn't change it at the machine and keep pushing it...

All of that is injected by the post based on layer names.

There are a lot of other things I do too. hopefully this gives you some ideas you might find interesting or usefull. There are a lot other things I am doing that might be interesting toyou I don't know. Fun numbers aren't they?

Understanding any comments I might have made yesterday, I want to really encourage you, and see you do something great with your knowledge and ability. Spend it wisely where you will get the best impact!
Keep up the great fight for excellence!


Pete

The points I was trying to make, were that just because it is a 2.5D system it is not limited to hobbiest activities. I have a higher end 3D system, very, very capable for 3D, but I can't tweak programs like I can with my cheap wireframe system.
Secondly, a little functionality goes a LONG way to achieving some great results.

Most everything I do is from two featuers:
The ability to insert text based on the layer name, and weather it is the first, middle, or last element in a chain of similar layername elements.
The example of inserting the Feedrate changing lines are examples of inserting text into the stream based on the first element of a new layer name. If the post encounters the first element of FAST-1.5 it inserts the text:
N658 F [#FEEDRATE] * 1.5
After the last element of that string of similar layer names, it inserts the text:
N784 F [#FEEDRATE]

Secondly, having a good text substitution is a real help for a lot of other tricks...
I can change axes names, or insert text to do a calculation, (variables for the control) then do the motion, all based on text substitution.

Hopefully this helps to clear it up a bit.
Pete

Been a Mac user since I bought a Mac Plus in '87. Used to play with Virtual Gibbs (now GibbsCam). Always wished Bill Gibbs would have stayed with the Mac platform.

Click to expand...

As Bill Gibbs has said, "I may wear PC clothes but I still wear MAC underwear" meaning he is big time MAC supporter and undertands how the power of the MAC platform lends itself very well to the CAD/CAM environment. BUT! ... being a good businessman he knew he could no longer afford to support the MAC with only an 8% installed Gibbs base. To bad. I am a big time MAC user... at home. I run Vellum Cobalt on a PC here at the shop but have it installed on my G4 at home. When the new MAC's come out next year with the new Intel processor I'm planning on getting one, they're supposed to cook.

Jim
www.pivotlok.com
Professional Bench Top Work Positioners

>> There are a lot other things I am doing that might be interesting to you I don't know.

Pete - we'll never know unless you spill the beans, now will we?

_______________________________________________________________

OK - this is what I've got as a data model so far...

http://www.rattlesnakehillsoftworks.com/stuff/model2.jpg

Lessseee now... a few comments and clarifications:

The top level class, SWItem, abstracts a data-storage extension facility for plug-ins (tags is a NSMutableDictionary, if that means anything to you...)

Both the Tool and the Operation classes have feed and speed fields. If left blank on any specific operation, the codegen will get the feed and speed from the tool, otherwise what you specified in the operation will apply.

All operations have names, and they don't have to be unique.

The project has a notes field, which can be printed out along with a list of tools required. The notes can be included in the program if you wish.

The project has a projectID field, which the G-Code codegen outputs as an O number, and the Mohave codegen uses as the resource name. This field is a string.

All operations have user-defined prologs and epilogs, which are inserted by the codegen just before and after the auto-generated code. This can be any text - it doesn't have to conform to any language expectations. Also, the entire project has prolog and epilog fields.

The tool ID is a string - so if you are using a tooling management system that takes non-numeric tool identifiers, you can put that in here. Also, you can have multiple tools with different parameters, but the same tool ID - enabling you to use any particular physical tool in multiple ways. The tool info is also output with the tool change command as a comment. And - not shown, as I just added it after uploading the jpeg of the data model - tools also have prolog and epilog fields.

Custom operations output the contents of the text field, and may be attached to a locus object. The x and y position of the locus object can be inserted into the code with a text substitution.

The codegen scans all inline text for certain variables, and substitutes the correct values for them. Codegen variables are prefixed with a ! symbol - something that I don't use in Mohave, and that I've never seen used in G-Code (now, if your machine does use it, please let me know, and I'll find something else to use as a prefix).

Also not shown (again - added after I uploaded the jpeg) is that the order of operations is user-specified, so you can have it do things any which-way-round you want.

_______________________________________________________________

What I was going to do for post-processing is just provide the ability to run any command-line program, with parameters generated in the same manner as the inline-text is handled (i.e., with variable values being substituted into the command-line string before it's executed). Thus, you can write the post-processor in just about anything - C, Objective-C (i.e., Cocoa), AppleScript, Perl, Python, Awk, or any of the shell languages (although, if you're gonna' use a shell script, you're probably gonna want to use other support tools written in other languages to help it out) - heck, even RealBASIC should work, if you've got it...


Pete - I'm still thinking about how best to implement the feed multipliers... I'd like to integrate operation and tool specific overrides for comp factors as well as feed and speed, so that you could tweak a variable on the control for it... (not all controls will support this properly, and it's exact format is control dependent, so it's going to involve post-processor intervention)...


P.s. - some of you might not be familiar with the text-file light-sabers lurking in your Mac...

http://www.vectorsite.net/tsawk.html
http://www.grymoire.com/Unix/Sed.html
http://www.uccs.edu/~ahitchco/grep/
http://gnosis.cx/publish/programming/regular_expressions.html

>> And a nice customizable tool library.

E-Stop -

Umm... do you mean tools as in end mills, drills, etc, or tools as in click-the-icon, software tools?

Click to expand...

Tools as in end mills, drills, ect. Nothing worse than having to redefine the tool parameters for every job. Sometimes it takes longer to define the tools than to program the job.

Not to deter from Hammer's question, BUT,
I have absolutely no friggen idea of what 3t3d just said in EITHER post!
Damn, I think I will go forage for berries, and nuts now.
Doug.

+1 on the tool library.
Also, the ability to machine tapered wallswith ease.
Able to pick start and end point of any path.
"Find text" in the post.
Easily modified posts.
Really definable ramp parameters.
Z axis ruffing. Ie. plunge cutting
Trochloid (sp?) milling for large areas.
Drag and drop on the geometry, and cam side.

That is all I can think of for now.
Doug.
(and I still don't know what 3t3d said )

I think I'm with Doug on this one.
3t3d, you have lost me somwhere between pressing the "Post Reply" button and actually starting to type the post.

If I'm guessing though, you are optimizing your toolpaths for running time before the POST processor.
I don't use any CAM programs, I use BobCrap instead.
In Autocad, I draw the complete path for the tool. starting from the point where the tool actually rapids to before the cutting pass. Redraw as many toolpaths as needed. This way I am still in full control of the tool and can make as few and as short of moves as possible. Send it to Bobby to automate the typing of G00-s and G01-s, add my feeds, speeds, G41 and everything else manually and then I'll run the part.
This way the cutting paths are pretty much optimised, but speeds and feeds are still tweaked on the machine during the first X # of parts.

So what you want is define all the parameters on the toolpath layer, and have the CAM package translate it without manually "monkey-ing" with the code?

I wouldn't mind having something like that, but until the birth of Lt. Commander Data, I just don't see it possible.

The thing I hate most about Gibbscam is not having the ability to pick the programmed point of the tool. Some tools just don't work well. Corner rounding endmills and chamfer cuts are a special peeve of mine. I ALWAYS have to edit them at the machine. Chamfer tools if you change the depth gibbs seems to change the XY on me...when I just want to go deeper or shallower its easier to edit. I generally program them CL and adjust depth now. Corner rounders you can program as a straight endmill, but then they don't render correctly. ever tried to program something so its" semi-automatic", I have a deep drilling rig for a VMC, and we write the positioning code by hand.... mdi a position, move, mdi drill cycle, mdi position move, mdi drill cycle... repeat up to 30 times in a block. by the time you have spent 3-4 hours doing this you are done. Ever tried to drive a cutter down a specific path at the programmed points? I did some rifle feed ramps once... easier to write it by hand than deal with gibbs. basically taking a 1/2 ball mill in a straight line at a compound angle ( true 3 axis move), but could not get it to come out right in Gibbs. Autocad to the rescue. Another one I have had to write by hand is a side relief cut that has to jump around a boss in the middle. simple paths, but hard to code from a computer.

Ok.
What I said, and what I did is too simple to beleive. I use the bumbest of dumb cad/Cam systems. THAT, IS what makes it so powerful. The POST is too dumb to know how to do anything, and so, it lets the user fill in the blank as to what it should do for any type of geometry.

What I tried to say...

1. For production runs I hand optimize the toolpaths. Yes, I have to do this in the Cad program, and the toolpaths are just lines and arcs.

1.5 The amount of speedup is really amazing, if you work hard enough at it. From 20 minutes down to 3.5 minutes on a 20,000 part order. from 4 minutes to 1 minute on a 1200 part order.

2. The toolpath lines and arcs are all on different layer names. Each layer name can specify a different feedrate, and/or compensation amount. In other words, each line segement can be named as a different type of line. I have FAST-1.5 lines, and SLOW-2 lines, Approach-15 lines, and Depart lines, etc. Each type or layer name of a line or arc will insert some text into the G code stream.

3. The CAM/POST (it's hard to know where the line is here) will insert text into the G code stream based on the layer names. So, if the POST sees a new layer name, say as the toolpath is being generated, it was looking at layer 0 geometry, and it suddenly sees FAST-1.5 lines, it will insert text that bumps up the feedrate. At the end of that string of geometry, it will insert text that bumps the feedrate back down.

4. This really simple trick will really allow you to get some awesome results, as I gave examples of.

5. I am not a good communicator, but basically, I hand draw the toolpaths when I want to optimize, and specify the feedrates for each line segment.It really is SO very much simpler than I can describe.

6. Having the ability of passing layer names or line types to the POST is so very powerful it is amazing what you can do. Any time you can spend 3-4 hours and shave 330,000 minutes off of a repeat job, it is worth figuring out how.

7. The POST has a window, where I can add text for the first element of a new line type, the middle elements, or the last element.

8. I use variables in the programs, and the POST inserts the code for the variables. Since the POST only knows that it is inserting text, based on the layer name, or line type, the text can be anything, and in my case I add text that makes use of variables. The POST is too dumb to use variables, and too dumb to know that I am inserting variables in the text, that I ask it to add.

9. Here is what it will insert if it sees the first line on the layer named FAST-1.5 (for example)
I use a variable for the "normal feedrate, anbd so I can bump it up or down, and set it back to normal afterwards. I use a variable named #FEEDRATE you Fanuc or HAAS guys might use a numeric variable.

N300 F [#FEEDRATE] * 1.5 ; Bump the feedrate by 1.5 times
G code.....

After the last element with the layer name FAST-1.5

N400 F [#FEEDRATE] ; Feedrate is restored from the variable.

See how slick and simple it is to use variables?


10. The reason to use variables for the feedrate is that the base feedrate is set once at the toolchange. Now it is really easy to push the feedrate up or down for any one single tool, if you use the feedrate over ride, al the tools are affected. Everything I'm doing with this crazy system is to optimize the production for this one volume part. Tweaking at the control is therefore encouraged.

Please let me know if this is still not too clear, if it seems complicated, you are over thinking it. All it is, is the POST lets me insert text based on the line type. How you use that feature, well that is what's slick.

I'll explain a lot more but only if this makes sense to someone.

Pete

Ok, it now makes sense.
It may be unconventional for milling and turning, but in EDM it is actually used quite often. There are a whole lot more machining parameters than speed and feed, and they do change depending on the geometry or part shape during the cut.

It certainly is a neat way of doing it.

>> I'll explain a lot more but only if this makes sense to someone.

I get it. Please go on...

OK - I just added prologs and epilogs to the layer, as well... when the codegen starts to generate code for an operation, it will check to see if the layer has changed, and if so, inject into the output code stream the epilog for the last layer, followed by the prolog for the new layer.

Mr H. orignally asked for what features are usefull for a 2.5D CAM system.
None of this is too sophistiacted, just one simple example of how a 2.5D CAM is used.
I might emphasize that the simpler it is, the more likely someone might make it do something useful. There are likely better ways to do this sort of thing, but this is some of how I did it with what I have.


There are four situations with layer transitions.
The first element of a new layer.
The middle elements of a layer.
The last element of a layer.

A single element of a layer.

Code (text) can be added in front and/or behind the element of a layer. In each case.

Here is an example for Peck drilling that I use.

First element (point)

@! :
; PECK DRILL TO Z
T|ask(' Drill T = ?','08')| M06
M03 F|ask(' F = ?','12')| S|ask(' S = ?','3500')| |ask(' M8 FLOOD M27 SPINDLE = ?','M08 ')
G83 @cx @cy R0 Z |ask('Depth = ?','-.1')| J13 |ask('Peck depth = ?','K .1 ')| |ask('End Plane = ?',' W1 ')|


Middle elements (points) :

G83 @cx @cy

Last element (point):

G83 @cx @cy
G80


.............

What is all that?

The @cx @cy outputs the specified coordinate value.
The ask function get user input, with default values.
Note that any element (first, middle, last) might have text inserted in front or behind it. Aslo, the text may be multiple lines.

Also note, that I output G83 on every line.
That is to make it human readable!
All of this is designned by me to be easy to tweak, and read. I like the output to be visually neat when done. Lined up in columns.
I've seen G code output by other POSTs and it is readable, but not quickly, visually, obvious to a human from ten feet away.

I do a lot of other non traditional things, all intended for more speed. Mr. H was curious how a 2.5D cam might be used... More later.

Pete

Hmmm, this thread is growing legs....

3t3d, In my case I rather not output the G83 on every line, and here is why.
As in another thread Mr Hammer said he partly does not like G-code because it is not easily readable. well, that is why I set up some rules.

1, Codes should be proper, as in G01, G00, G02 etc and not G1 G2 G3 ....

2, All moves, rapid or feed must have the G-code such

G01 X1. Z1.
G01 X2. Z1.

etc. So no skipping codes just because they are modal.

3, Exception to this rule: Only X and Y Z coordinates in drill canned cycles:

G00 X1. Y1. Z1.
G83 Z-5. R.03 Q.25 P.5 F2. <-- Order always the same
X1. Y2.
X1. Y3.
G80

4, N-numbers have meaning:
3 digit ex N100 means canned cycle start or end
4 digit ex N1000 means subprogram start or end
Otherwise no N numbers anywhere in the program!!!

....
I can go on for a while, but I think you've got the picture.