NX has numerous tools available to the designer for creating a product model effectively. One tool that is commonly NOT leveraged by the designer is Knowledge Fusion. KF is often thought of as “For Programmers Only.” While KF has the ability to become very complex and intimidating, it can be used by the non-programmer to assist in the design process.
Many of you out there have heard of Knowledge Fusion and are interested in learning how to get started. The KF SIG can help. The KF SIG has the following objectives:
- Collaborate with Siemens-UGS to define the Enhancement Requests on the yearly Customer Involvement Process (CIP) ballots
- Collaborate on future functional projects with the UGS Product Managers
- Assist in developing the KF community through knowledge sharing and assistance
To communicate with the group you can use the web board at PLM World’s website (Link). If you have technical questions they may be posted on the board, in addition the UGS support site contains a helpdesk style board (group name = nx.kbe) that is another resource that you can leverage (Link). To use the UGS site, however, you will need a webkey – available with your sold-to address at support.ugs.com.
Our meeting schedule is the second Wednesday of the month at 12.00 PM EST. Please check the PLM Web board for more information. Our meetings are open to ALL levels of users please plan to attend and ask some questions.
Now on to a tip or two….
Knowledge Fusion 101
For the people that are new to KF, I am going to review some introductory thoughts about KF. Actually, I am going to use many of the thoughts that I conveyed during my 2006 presentation entitled “Bringing KF to the Designer.”
Knowledge Fusion is an outgrowth of a concept called Knowledge Based Engineering (KBE). KBE can be defined as taking advantage of any experience, expertise and other information relevant to each phase of the engineering life cycle of an end user product. Design engineers typically use this concept on a daily basis and do not recognize it; they draw information from knowledge bases and use that information to create their design. Knowledge bases can exist in many forms, some are:
- Spreadsheets – an Engineer’s favorite!
- Handbooks - documented guidelines (design data or process manuals)
- Engineering formulas - Roark's Stress and Strain
- Proprietary software - custom design tools
- Human judgment, such as rules of thumb - the person that has been with the company since they invented the concept
- Etc.
Knowledge Fusion provides a mechanism to channel this knowledge directly into your design tool – namely Unigraphics. Knowledge Fusion allows the user to create rules that govern the geometry of the final design. For example, a user needs to insert an edge feature in his/her design - let us use a cube in this example. The rules governing this feature state the following:
- If length < 1.0 then 0.0625 chamfer
- If length >= 1.0 then 0.125 blend
A user can create his/her rules via the KF Navigator or in a text editor, similar to how a C or JAVA programmer would. The unique thing about KF is that it is an interpretive language, meaning you do not need to compile the code, once it is written it is ready for use. For this example I will talk in terms of writing the code in an editor. My hope is to provide the user with some comfort when dealing with code – an often foreign environment. The code for this example is as follows:
#! NX/KF 4.0
DefClass: edgeDemo (ug_base_part);
#FYI - "#" designates comment
#INPUTS – these are user inputted values
(Number Modifiable Parameter [in]) height: 1;
(Number Modifiable Parameter [in]) Length: 2;
(Number Modifiable Parameter [in]) width: 3;
#CREATE BASE GEOMETRY
(Child) cube:
{
Class, ug_block;
Length, Length:;
Width, Width:;
Height, Height:;
};
#GET EDGE
(Point) point: Point(Length:/2,0.0,height:); #point on edge - kept simple for this example
(List) edge: ug_feature_askEdgeClosestToPoint( cube:, point:);
#APPLY EDGE OPTIONS – note nulldesign turns a rule off
(Child) blend:
{
Class, if (Length: >= 1) then ug_edge_blend else nulldesign;
Edge_Blend_References, edge:;
Radius, 0.125;
demandOrder, {cube:};
};
(Child) chamfer:
{
Class, if (Length: <1) then ug_single_offset_chamfer else nulldesign;
References, edge:;
Offset1, 0.0625;
};
This program starts with user modifiable inputs. Is the user does not modify them when the rule is applied they will retain their default values as written in the code. A user may return and change them late as necessary. The inputs are then used as the basis for a simple block which creates our base geometry. Since we know that we are applying an edge condition I have some simple code to choose an edge. KF allows a user to manually select (click) on geometry or to select it programmatically. I have chosen the later to illustrate some of KF’s other capabilities. Once the edge is determined it can be passed into the edge option section of code. Each edge option contains an if/then statement to control its application.
The results of this simple example are a cube with either a chamfer or blend on edge as seen in the following images.
Figure 1 - Length = 0.9
Figure 2 - Length = 1.0
This simple example illustrates the power of knowledge fusion when applying rules to a design. It is able to integrate the rules that a user prescribed and apply them based on a simple if/then statement. One thing that a new user should note is that the KF classes operate in the same manner that they do in the modeling environment. A block requires inputs for height, width, length and position (position left out of this example). In modeling you type these into a dialog box, in KF you type them in via the KF navigator or via a dialog box that can be connected to the program. The dialog box connection is a simple feature of KF, however, I will save that for another time.
My intent is to get you thinking about what rules you have that govern your designs and how/where you can integrate them into the Unigraphics environment. In the future I will give more detailed tutorials and examples. I want to get your creative juices flowing and get you asking questions about where to start and what to do. For a more comprehensive example, I will close with the coupling demo that I gave in 2006 and 2007. The types of coupling are listed and the rules that govern the design. Based on user inputted shaft size, rpm and horsepower the coupling type will be determined and the correct geometry created.
Drive coupling
Types
- keyless compression coupling for low torque applications
- eyed clamp coupling to support higher torque
- flanged-face coupling that allows the input and output shafts to have different diameters
Engineering rules
- Torque
- (33000*horsepower) / (2p*rpm) - from design rules
- Coupling type
- If (input_radius != output_radius) Then Flanged Face Coupling
Else If (torque < 100.0) Then Keyless Compression Coupling
Else Keyed Clamp Coupling
Results
Figure 3 – Coupling Options
Please feel free to contact me with any questions.
