CAM software, does all the code suck?

For the first time in my life, I've been playing with some CAM software. I have to say, I'm not impressed.

I'm just using Desk kam or whatever it's called, but the code it generates just plain blows.

100 lines of code for something that can be taken care of in five or six with a canned cycle.

Are they all this way, or is this just how a cheap "hobby" program works??

-Jacob

Jacob,
John Stevenson is the group's biggest fan of Desk products, so I think we should probably wait for him to weigh in with his opinion on this

I think there is likely a tradeoff to be made when using cam generated gcode versus hand written gcode. Some cam software is written specifically for a certain control (like Mazak perhaps?). But, a clever gcode programmer can certainly cut down on program length through the usage of subroutines nested 2 or 3 levels deep.

But, is his handwritten code safe? That is the question. Can it be simulated? This is One of the most basic functions of CNC software, is to generate gcode that can be simulated correctly.

Most of the functions within a general use cam software have to be independant of special canned cycles within the vast array of cncs out there. There are exceptions as some canned cycles are standard enough in usage that they can be "trusted" to behave in a certain way for the purposes of a safe simulation.

I wrote a lot of gcode by hand in my earlier years. That sucks, too. I'm glad I learned how to do it, and I can appreciate a good programmer, but the time to write a good short program and test it out, is usually many times longer than using cam software to write a longer "dumber" version that can be verified on a screen and then sent to the machine and run right away.

Heaven forbid that you want to change your strategy for machining the part if you hand coded the program. You just kissed that time invested goodby. Good cadcam software makes changing machining strategies easy and quick. You can come out ahead by improving your program once you have run it once on the machine and decided what it is that you don't like about it.

I hope no one noticed that subliminal message embedded in this reply

One other aspect to consider, is reviewing your own *.nc file after a few months, or worse, someone else trying to imagine what its all about. I've never had to work in that situation where someone else had to make sense of a clever program I wrote, but I can imagine a bit of hassle where several people are involved.

Overcoming the problem of "old nc files", regardless of how cleverly written they were, is one of the reasons I am gungho about OneCNC's software: the entire machining process can be reviewed in simulation or toolpath preview, at any time, by anyone, and give them a good idea of what train of thought was used in writing a given nc program. No need to single step through it to see how it worked.

To achieve this end, I am personally willing to endure a bit of extra code, for the convenience of having the whole model, and machining strategy available for replay at any time.

Not to leave the wrong impression, OneCNC does use some canned cycles. I have even got my post set up so I can do certain types of single level subroutine nests quite easily. Simulation only sees the subroutine as a single operation, though, so I still have to know a little bit

I've got no experience with any other cadcam software than Bobcad and OneCNC, so that explains my limited viewpoint. I'm sure that other guys have reasons why they like their cad cam systems, but once you find a good one, you might as well really embrace its usage, because the more you practice using your cadcam, the better you get.

We purchased a seat of Gibbscam a while back. One of the big disappointments I have with them is posts. We spent $2700 on nine "library" posts to match our machines. I carefully sent them code examples that they had assured me (before the sale) they could match to existing "library" posts for our machines. Well, they don't. None of them are even close to what I sent in for code examples. Some of them guarantee crashes at the machines, some of them guarantee alarms. They gladly offered to fix the problems, if I send them in another $200 per post. I have vanilla fanuc/haas/okuma controls on vanilla cnc mills/lathes, we aren't talking four or five axis or off brand controls. This and the complete lack of a comprehensive set of user manuals have been the two big disappointments with what is otherwise good software. So for $25K I get to use compost and make posts that generate extremely long(no canned cycle) generic g-code code or I get to use notepad to edit the corrections into their posted code, or I get to send them more money. If I were a paranoid suspicious conspiracy theory kind of guy I might start thinking they carefully mismatched my example code just to sponge a couple of thousand dollars more from me........nah

This is much of what I expected.

Last night I sent some code to the CNC router. I proofed it on the screen, but wanted to proof it on the machine too, prior to actually cutting.

Well, my version of the code would have been a few pocket milling cycles, so I could have just changed the final depth. Their version of the code was pocketmill, down z, pocketmill, down z....a whole bunch of times. So proofing the code would have taken the machine a few hours (it is a long program).

Finally said the heck with it and had the CAM program kick out another version that just didn't have the final depth as deep. Still worked, but a huge pain in the ass. Had to go back upstairs to laptop, generate code again, send to computer with floppy drive, copy to floppy drive, go back downstairs and load program...etc. I guess I always figured that CAM programs were a bit smarter (although I didn't expect a CAM program that costs a hundred bucks to be all that smart)

Glad it can be tried out in Demo mode

-Jacob

How much "off" were the depths, and why? Is this something that could not be handled by a change to the tool length offset, or, if applied to all tools, to a change in the work offset? Problem is, what your part really is, and what I am imagining it is, are likely completely different apples.

Jacob, there's probably a setting somewhere in the program that allows you to set the Z increment. Possibly its got some low value set as default, but thats something that should be changeable even in the lower end CAM programs. In fact, you should also be able to turn off incremental Z if you want to and have it generate code that would plunge and run the pocket in one pass to full depth. You might also look at the demo of Sheetcam. The site is http://www.sheetcam.com Les Newell, the developer, has written it specifically with sheet goods work in mind such as would be done with a router or plasma cutter. I've played around with it some and have generated the code for some 2.5D mill parts with it, and its intuitive, very easy to use, and generates good code. Les has made great efforts toward compatibility with the Mach control programs, so it might be just the ticket for your router setup. AFAIK, there is still a fully functional demo available, so you can try before you buy.

FIRST OFF!!!

I was exactly like you about 3 months ago...
I HAD NO CLUE how to use CAM!!!

NOW its all different...
You need to specify that you want a CANNED cycle... Not LONGHAND!!!

Also i have no idea about your software... But i use MasterCAM and its GREAT!!!

and learn to use your CAM software correctly, OR!!! get a different package!!!

Yup. This is one of the reasons I wrote (well, am writing) DiamondBack/Mohave - G-Code sucks. Sorry, but it does.

On this particular subject:

Mohave: Standardized execution environment. Code will run correctly on any machine, and can be correctly simulated on a PC.
G-Code: Kinda-sorta similar execution environment, but with critical differences that prevent code portability. Lack of standardization impedes simulation.

Mohave: Subroutine libraries that can be provided by the CAM system and bound to the part programs (but, are not part of them, so you don't have to wade through the entire library when looking at the part program code). Subroutine calls look just like in-built operations, resulting in elegant code (in fact, hooks are provided for the boot code to take over built-in opcodes with subroutines, and still be able to call the built-in opcode from the overriding procedure). An individual library can be comparatively huge - PC ram is used (was about $20 for 128MB of DDR266 down at Fry's last week), and you can have an unlimited amount of them on your network.
G-Code: You get the canned cycles that your machine has. Adding cycles (as subroutines) requires setup (you must get all the files loaded onto the control yourself - no smart resource binding), eats memory (often in short supply) and is awkward, at best. Subroutine ID number conflicts can occur. Overriding an existing operation is essentially impossible. Reading code written like this is impossible without a setup sheet (the code is not self-documenting).

Mohave: Powerful x/z-buffer, space-transform-stack, and user-code-curve operations generate tool-paths on the control; while still maintaining the flexibility of an execution-oriented environment.
G-Code: Nothing comparable.

Mohave: Local and global variables (of real, integer, vector, and string aspects) with human-readable names are standard. Having names reduces the possibility of conflict and error dramatically.
G-Code: Variables are often only available with macros, are often global, and use numbers to identify them, not names. If they are used at all, they are prone to conflicts and errors.


I am getting close to a (private) Preview Edition 1 release of DiamondBack - there's a couple of bugs that I still need to fix, and a few modules I want to add first; but some of you will actually be able to get your hands on it soon.

Whaddhee say, whaddhee say?

pi,
Is this a personal download hub or a public download repository? I don't have anything like this (1000 posts) from Gibbs, and am not finding it on the Gibbs site, The posts I paid for are good enought that I know they have to have basically perfect posts for my machines. I am dealing with a rep, Gtade Eng. not Gibbscam themselves.

100 lines of code for something that can be taken care of in five or six with a canned cycle.

Click to expand...

-WAY BACK WHEN-

I used to be like you. I liked programs that were lean and mean. I used to write programs that if you took even one digit out of it it would not work properly.

-NOW-

I could give a rats ass. Yes my Gibbs generates a lot of extra code but you know what? WHO CARES! As long as it gets the job done. I do all my editing in Gibbs CAM so my CAM file is always up to date, revisions are a piece of cake when you do it this way. When I'm finished with the job I just delete the program in the machine because I know the CAM file is there.

I generate programs in Gibbs that look like, if you saw the machine run, that they were hand written. No wasted moves at all.

Don't worry about the extra code. BTW, how does it effect you or the job? I doesn't I'll bet. You just have to change your way of thinking.

Jim

www.pivotlok.com

i'll second that for milling. on lathes i prefer handwriting. i haven't saved a mill program in years. it makes no sense if you have the cam file. this insures your program always has the most recent processor.

I'm with Wild West (Jim)...Who cares how long the program is. I had a stop block the other day. Mill to length two holes with counter bores. I programed it on CAM. I'm not sure I remember how to hand program anymore. My CAM work station is out on the floor, it's so easy I can't imagine going back to hand programing.

And if you get good with your CAM software, it may write longer programs with more code, but in the end you'll have finished parts faster....which is the goal anyway.

dan k

My boss insisted the mastercam guru write a program for me.

It was an "o" ring groove about 36" dia. for the Devlieg Jig Mill.

His program had over 19,000 lines in it.
He thought he was really cute.

Had to dump every other program in the machine to get it to load. Lost a couple of programs that caused me an arse chewing later.

I could have gotten by with a hundred or less lines I guess.

Told the boss that I was doing my own programing, or going up the road.

Still here!

Ha! Ha!

Guru's gone!

Falsified his timecard and got cought.

kap

19000 lines for an o-ring?
sounds like he had a spline that should have been converted to arcs

19000 lines for an o-ring?
sounds like he had a spline that should have been converted to arcs

Click to expand...

I agree... and curious....

or it was one serious o-ring.

I read through this topic and found that one thing not mentioned here is that long strings of dumb code generally run faster than short programs using a lot of canned cycles. This is very apparent on my lathe. It has a 21ti control and I usually write my programs using the conversational programming function in the control. These programs are easy to write and edit but when run, there is noticable time delays during the cycle while the machine compiles the movements to do based on the canned cycles. Once I have proven the program, I use the "convert CNC" function to change the program into a long string of dumb code. It is no longer easy to edit but it runs a lot faster. Glenn.