GRIP Programs & UFUNC/Execute 1

[Xwheelguy]

I'm fairly ignorant to the differences in GRIP & UFUNC/Execute other than one allows for writing of the program & the other allows only execution. Throw Knowledge Fusion in there & we're talking complete dunce. Can anyone give me a brief but well rounded overview of these items?

Can any GRIP or KF program be compiled to run with UFUNC/Execute only? How about the old O-text program?

If so, would anyone be willing to share any of their custom programs & compile them to work with UFUNC/Execute? Should anyone be willing, a list with the names & what they accomplish would be greatly appreciated.

I apologize for leeching like this, but I'm looking for ways to improve productivity or make retrieving any information from UG data easier.

Thanks very much in advance.

Tim Flater
Senior Designer
Enkei America, Inc.

http://www.enkei.com

 

[looslib]

All three allow you to automate portions of UG. through in Macros (Journeling in NX3) and you have a fourth method.

GRIP is a basic-like programming language that in todays UG is very limited in use. It has not been enhanced since V10 with the exception of some new NX3 plotting functionality. It is best used for text types of inquires or attribute assignments. I wrote one program that would extract all attributes from a part file and put them in a text file. I also do our drawing formats in a GRIP program. Our designers don't see a normal File-Open dialog, it is a custom GRIP program, as are File-Save and File-SaveAs.

UG/Open API (Ufunc) requires C or C++ programming skills. It can corrupt a UG part file if executed with an improper command.

KF is its own language and is built on the Heide Intent programming. It can do things like calculate the least material needed to contain a quart of liguid. (The answer to that is the old round oil cans.)

Macros and journeling record the keystrokes to perform a function. If you find you are always doing the samething in multiple part files, record a macro to make the repetitive task shorter. Macros are version dependent, so I very rarely use them. There are also limitations like a toggle/button type of dialog switch. Playback the macro 1 time and it will turn the function on. Play it back again and the function is turned off.

Each programming method is independent and they cannot be cross compiled.

I have seen very few people willing to share UG/Open API programs. There are GRIP programs available in the PLMworld website. Actually a link to the GRIP Librarian at Patriot Machine.

What function are you trying to automate? I have written some quick programs in GRIP for others and I know some who do custom UG/Open API programs.


"Wildfires are dangerous, hard to control, and economically catastrophic."

Ben Loosli
CAD/CAM System Analyst
Ingersoll-Rand

 

[Xwheelguy]

Ben,

I was just curious what types of automation other users were implementing. I was aware of drawing formats (like what is done in GM's toolkit), working with attributes, XYZ dimensioning for points, expanded analysis information, and some that work with UG's text.

I kind of figured I was treading on a touchy area by asking for any programs, as through the years I have seen very few made available in any of the forums.

I guess I have reached a point where I'm quite comfortable with my knowledge of UG's 'out of the box' capabilities but am seeking to expand my knowledge or my own capabilities through the UG/Open API, GRIP, KF routes. Also, I haven't ran across too many areas that offer up an explanation (in terms that are easy to understand) as to what these programs can do.

I'm curious if anyone has an associative body array, as modeling wheels can be done in "pie" sections at times & mirroring can be out of the question due to design or model size. Also, I only have a UFUNC/Execute license, so that limits what I'm able to work with...basically someone else is going to have to do all the work for me.

I appreciate your time & explanations. Thanks buddy.

Tim Flater
Senior Designer
Enkei America, Inc.

http://www.enkei.com

 

[chekald]

Here is my view of the GRIP, UFUNC/API, Knowledge Fusion tools

GRIP:
Ben said BASIC-like, I would say more FORTRAN-like, but that is just semantics. GRIP is good for automating simple, strait forward tasks. A rule of thumb would be if you can draw a flow chart on a single piece of paper without the lines crossing, GRIP will most likely be a good candidate. Example, If your process is to input a Series of XYZ points, connect the points with lines, fillet the intersections, then extrude a profile along the lines and fillets to model bent bar or wire. This would be a good GRIP program candidate.

UFUNC:
C or C++ based, much more powerful language requiring more programming. If that flow chart starts growing to three or four pages, it might be time to think about UFUNC. If your task has large, unwieldy calculations or wants to exchange data with outside programs, UFUNC will be a good candidate. Example, if your process is to size a shaft given torque requirements and selection of coupling options while optimizing the mass.

Knowledge Fusion (KF):
Based on Heide Intent!, like Ben said. Its LISP based and uses a different programming paradigm. If any attempt creating a flow chart ends up looking more a plate of spaghetti then an organized process, then Knowledge Fusion might help your process. GRIP and UFUNC run in a sequential way (step 1, then step 2) with controlled branching. KF does necessary resolve things in the same order every time. Yes, you can force it to resolve in a given order, but if process requires a given order you would most likely be better off with either GRIP or UFUNC.

KF is best used for embedding knowledge or design intent in to a part, rather than automating a process like is done with GRIP or UFUNC. When a GRIP or UFUNC program ends, any geometry create only as the parameter used build it (i.e. a block will have a length, width, height values) but not the reason for those values. By contrast, KF is not a program but more of a base part with relationships build in.


David Chekal