CAD/CAM/CNC "Associativity" Benefit or Futility

[Scott_bob]

Weimedog,

A bit hard to follow your ramble... Your story is an example of what I am afraid will happen here. I'll call it; "having trouble seeing the forest for the trees". I am sure that there are more people with "tried and failed attempts" at this level of sophistication, because it is not that easy...
Some engineering methods don't even attempt the associativity thing and just focus on automation of the process steps instead. Easier to start over than to figure out parametrics. This is a real consideration, because it can be easier to just modify the feature that has changed and create a re-work program for this alone, which is needed anyway most of the time, instead of re-generating an entire program start to finish.

This method can be better than an associative / parametric system if:

(What are your thoughts, any Delcam users...)?

[weimedog]

Actually that "modify the feature" approach is something we did accomplish with our system..as far as "failure"...As I'm beginning to poke around the industry..I'm no longer certain it did.

From what I'm seeing there are several products on the market place that have their roots with that very system either directly or having used it as a proof of concept. I haven't seen a product with ALL the concepts implemented as we envisioned but there are products that take the same approach to either the process modeling interfaced with their GUI or actual machining algorythms. Especially relative to machining solid models.

I guess the peice of the puzzle I left out is we built the system as a proof of concept and/or for companies to use as an accellerator to get their system design done faster. Some are still out there and some died...I had visability of many systems back then including Darpa funded projects, in house designed proprietary systems, and some products that were/are actual systems sold on the market. I'm not certain a list of current products effected by those who worked with my group or had visabilty of the product I was charged with is appropriate as I think you said, transparency isn't for the net.

But the question here is the "associativity" concept a viable one for the average CAM user...and I think there are many situations where the answer is absolutely yes. Some where the answer is "no". Done right there shouldn't be any need for super hero tech wienies to manage a system built to allow editing and regeneration of process models....and my approach was a super set of the true "associativity "concept based totaly on models. (A concept tried out by some systems.Too limiting) (My concept was really an evolution of another very smart persons idea blended to my way of approaching the NC programming process)

The places where this process modeling worked best were things like changing tool sizes, changing hole locations and/or specifications, moving clamps, changing the order of events (ie. doing pockets in a different order to help stress releive a large part), Changing part dimensions and re-evaluating an entire process (ie changing a wall thickness and having to re-evaluate an entire process to get the updated toolpath.) Stuff like that...

The ability to edit an object could be as simple as deleting a piece of geometry & replacing with another then re-evaluate the process from that point on; or edit the geomerty and re-evaluate from that point on. (Or just that specific Toolpath) & output a entirely new set of clfiles or subset of clfiles....If parts of the process model were no longer relevent..delete them and/or replace with a operation or toolpath object that is. Building a new toolpath object within an operation would look like running a conventional CAM system with the commands used stored within that toolpath object...when evaluated it would create a toolpath entity..and set a flag saying that object was successfully evaluated..then move on to the next part of the process model. I personally used to like building all Operations without evaluating them first and then try to eval everything...and our demo package would open up the toolpath generation part if it didn't evaluate successfully....then I could fix that and let it run. Kinda fun for a nerd.

How would that type of thing look? Imagin a user interface to the process where it looked sort of like a windows interface to a file system...pick a file and open "properties" & "edit properties" is anologous to picking a operation object opening and editing things like the part model it points to, tool definitions, or parameters for the machining algorythm..etc. "Apply" is anologous to you choosing to re-evaluate the entire process model, that specific operation, or from that operation to the end of the process model. OR choose NOT to evaluate and move on. The "menus" and "object" displayed in a typical place for a CAD system while the main display shows the graphics of the model(s) and toolpaths that have been evaluated. Very flexible but the product developer had to define how much was accessible to their user interface. The Software hooks were there...we had both a command structure available as well as API interfaces to allow a developer to develop their own.

Actually the anology of a file hierachy and the process model is perfect....could delete operations, add operations, etc. as you could move files around. "Setup" objects were anologous to directories, Operation objects were anologous to sub-directories, and Toolpath objects the files...difference when they were "evaluated" actual "toolpath entities" were generated....like execution of an executable.

Another neat feature was the ability to use the attribute mechanism on our solid modeler to pass information from the design of the part or parts thru the rest of the design and manufacturing process. An attribute could be as simple as a material definition which could be used to determine feeds, speeds, or other machining parameter or as complex as complete specification to pass to an FEM or CAM type who had to set up a model for evaluation. Since the some of the machining and process modeling code was parametric in nature, evaluation of attribute information on the model was actually used to define variables. The modeler used was capable of attaching attibutes to either the entire model or to elements such as faces and edges of the model. For example "stock" and "part" attribute classifictions were placed on faces and used to determine if the tool was to pass through or to machine to a defined thickness a given face.

Another piece we added to the package was smart "picking" (from the graphics display)...but thats another days rambling cause I hate some of scheme's I see now.

As for following my rambling, its hard as hell for an old man to remember ALL this stuff! The terminology is forgotten first. I have to remember this without any of the documentation or code from that part of my life..just memories some good and some not.

Back to the subject.

Implemented on a subset of geometry & machining problems with a windows type interface it would do well even now from what I see. Again as a layer of interface above the actual NC Toolpath generation...I have a hunch you might be familier with a system or two with that very concept. And if thats true I guess it wasn't a failure. But rather than confuse or start an argument I think its best I leave this discussion to the current experts.

As for seeing the forest....its crystal clear the group who worked with me and who I worked for made way more impact than I thought. Maybe there are some on the other side of that forest looking back....interesting concept isn't it..

I think I will go back to farming bliss and let those who are risking their hard earned dollars and ego's take this one on.

[Scott_bob]

I sure would like someone to comment on the other side of the issue...
By the "other side" I mean: using a system that is not associative or one that updates toolpath automatically. After all, if a system does not do associativity, but is so much faster than one that is, that system may indeed be better. Better by virtue if it's speed. Time is money, and the claims of the associative CAD/CAM system are designed to meet this need. As the above discussion summarizes, some of these high end systems are quite difficult to use. Capability and complexity go hand in hand sometimes, especially if the design intent is to include parametric associativity. Defined as: "change a design element, and the associative tool path is automatically updated".

What do you think?

[REVCAM_Bob]

o.k. this is for Scott Bob from Revcam Bob. check out www.revcam.net for all the details on how our system works. Basically it is a feature recognition system. It knows what to do and where to do it, and there is no need for "updating" toolpaths.
I really don't get the need for associative tool paths. Maybe for big 3d models with lots of contouring where the toolpath might take a long time to generate. But with the type of work we do (tool & die) simply squaring up blocks and drilling holes, machine pockets etc. there is no advantage to updating the toolpath as you go. There is no advantage when the whole programing process is the time it takes to measure the raw block size and punch in the length, width, thickness of the steel. The rest of the process is only a couple seconds for a complete program..... Does that help any?