|
Welcome to the COE Discussion Forum!
|
|
|
|
To participate in the discussion forum, you must be logged in to the website. If you forget your login information, please contact COE Headquarters at coe@coe.org or (800) 263-2255.
If you are new to the COE Discussion Forum and would like to participate, please register.
|
|
| Forum Highlight: CATIA V6 |
|
|
 |
|
 |
| You are not authorized to post a reply.
|
|
| Author |
Messages |
|
THUNDERLASSE
 |
| 04 Jun 2006 01:08 AM |
|
Hi folks,
I have in my previous life impllemented a complex process that includes very advanced Knowledge based template products and a lot of knowledge based powercopies...
funny thing is that the actual tool that is meant to do that (PKT) was never used.... Acually when I evaluated PKT in R7-R10 level, I just couldn't see any mandatory need for it.
Basicly the fact is that you can quite well create knowledge based template products, if you just classify objects corectly and (Standard part versus template part versus Project specific part) and with Powercopy, you can do just almost all that you can do with UDF... . so why PKT?
So I just wonder what is the Real added value of using PKT? Is my knowledge on this outdated, is there something in PKT that makes it a killer application? Something thatis really mandatory for processes, not just 'nice to have'? Any opinions, KBE -experts?
Other question; how about PKT created templates in VPDM integrations? Any good experiences or even more interesting, any bad experiences?
BR,
Lasse
|
|
|
|
|
BPRASAD
|
| 05 Jun 2006 10:41 AM |
|
I believe the power of UDF and ( and thus PKT) come into play when you have a need to
(a) use UDFs as "code callable and reusable objects" inside a rule body
(b) define a "textual code" for capturing the logic of CATIA tree constructions and manipulations
(c) generatively define a CATIA V5 tree structure from simply few lines of GENScripts
(d) incrementaly instantiate new templates, new user-defined objects from GENScripts or from rule bodies as you go about adding new knowledge, templates, etc.
Needs for such generative capabilities (a)-(d) are not very obvious when you are only dealing with UDF or building "part templates" interactively.
But when you are dealing with large systems, and when you have a need to put all the pieces (UDFs, Templates, Powercopy, ) of the puzzle together, and would like to do it GENERATIVELY --in some logical fashion - governed by a set of conditional rules -- > Power of PKT comes handy.
Unfortunately such processes are not very much explained in PKT or well-documented while describing KW workbenches.
May be with your help, we could redefine what role UDF and a Generative Language (like GENScripts) could play in making KBE a "GENERATIVE SYSTEM of choice" for product development.
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
IPHILLIPS
|
| 06 Jun 2006 03:16 PM |
|
The UDF allows you to encapsulate many features into one.
This is important when you have a large complex structure. The result is a feature.
The result of a powercopy is not a powercopy!! Its just a bunch of stuff again.
Navigate with the historical graph/parent-children or Quick select, and you will find all of the unwanted contents of a powercopy and wonder what they are.
With a UDF you will navigate to the UDF only. You will know what it is. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
THUNDERLASSE
|
| 07 Jun 2006 03:56 PM |
|
Hi,
Ian, what would be your comment on following:
- Encapsulating data to closed package is "nice to have", but not mandatory, closely same can be reached with a good methodology when creating powercopies... UDF is good, but not yet maybe worth of $$$$$?
So anything else?
Brian; I see your point... well, kind of, but I want to get closer to practise. That is far too abstract for my simple little brains...
I see three main processes within knowledge based engineering, that I am interested of:
1) Creation and use of template Products with embedded knowledge, that work as starting point for Project design (for example a template car that can be parametrically changed to resemble a Sedan or stretched Limousine)
=> PKT adds some tools to this process; but in my mind this can be done quite well with just KWA mechanical design tools! and this process (especially the phase where you copy Template to starting point of new project) is so dependant of VPDM system that PKT is not giving all needed for this.
2) Creation and use of little Script-based tools that do some little tasks (like remove fillets when saving data to external format and FEA simulation) based on scanning the product structure or part structure. Typically these are best to be pretty independent of context, I don't see any help from PKT for this process.
3) Creation and use of "typical intelligent features"; so Powercopies and UDF:s . For this process I see a benefit from use of PKT and UDF, but I don't (maybe that will change) yet see the light why UDF is so much better than Powercopy... Sure, better but if you weight the value of that and put on other cup the price of PKT license... hmmm.
BR,
Lasse
|
|
|
|
|
NEVJOHNSON
|
| 07 Jun 2006 04:48 PM |
|
Lasse,
We use UDFs to control design standards. With UDFs all our standard parts or design knowledge is capture inside the UDFs.
Therefore all designers follow company design rules within the parameters allowable with the exposed parameters of the UDF.
Regards
Nev |
|
|
|
|
THUNDERLASSE
|
| 07 Jun 2006 05:46 PM |
|
Hi neville,
Exactly what I was hoping to get; a new point of view! Can you share your process a bit more? I don't get the full picture from these two lines...
Do you have a specific organisation that creates UDF:s (experts) or does every designer create UDF:s? How you capture All design knowledge to UDF's?
BR,
Lasse |
|
|
|
|
THUNDERLASSE
|
| 07 Jun 2006 08:00 PM |
|
Hi,
Just a comment; please don't see my comments so that I would think that use of PKT would be a bad Idea: I am just trying to find good arguments to support use of PKT for possible investment proposal.
...and on the other hand I want to bring up the fact that KBE should not be mainly (and especially not certain fixed tools) tools, but a process that collects the knowledge.
BR,
Lasse |
|
|
|
|
BPRASAD
|
| 08 Jun 2006 11:02 AM |
|
You seem to compare PKT as if it has only UDF tool. This, I am basing on the fact that you are comparing PKT licensing cost -- viz-a-viz UDF versus PowerCopy
I agree UDF is one of the tools inside PKT that has reached a high-level of popularity. Your question why license PKT, if you are just using UDF? I do also agree “usage of other tools in PKT” is not widespread either. Thus, the licensing cost looks very steep.
But, what about its (PKT) potentials in saving your future costs?
PKT workbench has many other KBE tools (such as GenScript) that have potential to provide even more benefits/savings.
I am alluding to the fact that GenScript is the only “Generative Modeling” tool currently inside DS KWare set of workbenches. The rumor is that may be changing soon.
If you didn't know, Generative modeling is an advanced KBE concept. It lets you capture “rules, which encapsulates “other rules”. Rules are sleeping and react to definition changes. New rules can be spawned at run time from its existing rules based on parameter/feature changes.
Most of the other capabilities in KWare suit of tools are “prescriptive” in nature. These concepts, in KBE/AI literatures are categorized as “Prescriptive Modeling”. Prescriptive meaning rules are prescribed (predefined) and react to a predefined set of inputs.
If DS adds “generative modeling” tools/capabilities to its fullest extend in PKT, I believe your savings could be many times more than the current licensing cost of PKT. This is also a good business case for DS to do something about PKT/GenScript.
But as of today, I agree with you it is hard to justify PKT licensing cost just based on UDF usage/savings.
Let us hope that DS adds those desired “Generative modeling” functionalities in future releases of PKT, so that we would have easy times justifying our PKT “use” costs.
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
NEVJOHNSON
|
| 08 Jun 2006 12:33 PM |
|
Lasse,
I suppose you could say that we use UDFs a little bit like Design Tables.
Design Tables are flawed in CATIA in that when you instantiate a part containing a design table,
if you change the configuration of an instance. It would change all instances.
Not always what you want.
Example with UDF for say a bolt.
I dont want everyone using there M6*10 bolt from their local hard drive say.
I (I usually create all the UDFs) create a UDF of the bolt which has exposed parameters (similar to normal parameters but encapsulated within the UDF only)
This could simply be the thread size
The UDF could take some inputs such as a centre point and a face/plane/surface which may represent the interface ot two plates plus another representing the starting mate face.
Using KBE rules/checks/reactions/vb macros etc..
The distance between planes would be calculated and an addition length added representing the screw in the second plate. The depth in second plate is calculated say via Screw Dia * 2.5 . Then a rule would ensure that the approriate size screw was picked from our internal standards.
All this would be blind to the user.
Lasse, this is just one simple example. In reality our templates are more complex that this and require many more rules. Many of the exposed UDF parameters are Boolean parameters allowing for simple interaction form the user.
If you want I could send a simple example for you to take a look at.
Regards
Neville
|
|
|
|
|
JSTRAWN
|
| 08 Jun 2006 02:19 PM |
|
Neville,
This example implies that you are using multiple bodies inside a single CATPart for your bolts. If so, I strongly object to this methodology. While it can make using V5 simpler by making it like V4, it can cause many problems later in the lifecycle of the design.
We use both UDFs and PowerCopies. As the others mention, the UDF prevents the user from changing the basic design of the standard features (bosses, lightening holes, sheetmetal Corner Reliefs, etc). Several other reasons for using them: File Size (UDFs can be significantly smaller), Performance (especially in a large model with lots of features), and organization (less wireframe elements in the geometric sets to look thru when you are looking for something).
They are defined by our Standards group. We don't forbid our users from creating them, but we don't tell them how, either. PKT is a sharable license, and we have KT1 as part of our configured seat. |
|
Jim Strawn
Cessna Aircraft Co. |
|
|
NEVJOHNSON
|
| 08 Jun 2006 02:56 PM |
|
Jim,
What gave you that impression?
Also I disagree that mutiple bodies in a single CATPart is bad design methodology.
Especially given that I am from a ProE background which meant that you only ever had a single body.
For one you will suffer huge performance issues if you do not use a mutiple body approach to design.
You have to consider the update cycle process in CATIA.
A multiple body approach significantly reduces the update cycle time.
I have done numerous test on this with drastically differing results.
Regards
Neville |
|
|
|
|
COE-FORUM-USER
|
| 08 Jun 2006 09:24 PM |
|
Hi Neville,
What about Mass budget?
How are you taking care of mass properties if you
Are using multiple part bodies ?
We have incorrect mass readings when multiple part bodies
Are used .
Reagrds,
 |
|
|
|
|
NEVJOHNSON
|
| 09 Jun 2006 08:12 AM |
|
Les,
I dont have an issue with that as all the mutiple bodies are assembled or removed from the main part body.
The representation of my PartBody is always an aggregation or summation of the minor bodies.
Regards
Nev |
|
|
|
|
THUNDERLASSE
|
| 12 Jun 2006 01:55 PM |
|
Hi all,
OK, now I have seen the light and found out all details about PKT
Here is my conclusion about PKT possibilities: (agree or not, but there is a lot of studying and experience behind these...)
1) If you use PKT, you'll need KT1 to everyone who'll use the result, in complex supplier network & extended enterprise that really really sucks. Big time.
2) PKT is expensive.
3) Use of PKT and PKT tools:
3.1) UDF
- UDF hides inside features, that's only difference to Powercopy (I thought that there would be something not so obious, but no, ther isn't.) Good result with powercopy can be achieved by using Geometrical sets + Groups. (allows to hide features!)
3.2) Genscript
- Historical, not useful. No proper UI. ;(
3.3) Part Template
- Allows to control External references when making New from. Very similar result can be achieved with Powercopy, if you include in Powercopy definition all features of part and external references as inputs. (resulting process: Create new part + instantiate powercopy)
3.4) Knowledge pattern
- Pretty cool! Allows to create very much like enhanced loop with ability to instantiate several powercopies. Better syntax than loop! A reason to go to PKT, if this functionality is needed.
3.5) Sub-assembly template
- PKT allows to create assembly template where Input external references can be nicely controlled in instantiation. Nice! Works great with "Skeleton" and "Template" approach (Tom-Tom, take a hint!) A good reason to go to PKT.
3.6) Main assembly - High level assembly template
- PKT allows to define which parts are copied, which are referneced, but that can be done also with proper naming or classification methodology; anyhow nice tools to start selectivly from existing template assembly. Anyhow, since this can be quite nicely (manuyally) done also without PKT, I don't think this is a good reason to go to PKT.
4) Based on these, I think anyone can take their own processes and think if PKT is necesserity; I will do my own conclusion, but I stand behind my words that KBE is mainly processes, secondarily tools.
With best regards,
Lasse
|
|
|
|
|
NEVJOHNSON
|
| 12 Jun 2006 03:06 PM |
|
<blockquote>Quote
<hr><i>Originally posted by: <b>Lasse Purma</b></i>
3.1) <u>UDF</u>
- UDF hides inside features, that's only difference to Powercopy (I thought that there would be something not so obious, but no, ther isn't.) Good result with powercopy can be achieved by using Geometrical sets + Groups. (allows to hide features!)
<hr></blockquote>
Lasse,
Note that the UDF is frozen. This can generate its own problems if you do not understand this fully.
Every change you make to the data that built the UDF has to be rebuilt for those changes to be seen.
This has been a real pain for creating UDFs. If I forget to add anything things can fail in my other templates that require the outputs of UDFs as inputs. I heard this is to be changed (GOD that would be nice)
Also if you are programming you cannot directly use the output of a UDF as an input for another. Yes it can be done interactively but not via code. What a real pain.
Regards
Nev
|
|
|
|
|
CLIFFJOHNSON
|
| 12 Jun 2006 04:58 PM |
|
Quote
Quote
<hr>3.2) Genscript
- Historical, not useful. No proper UI. ;(
Genscript has a bad rap because Dassault never completly implemented all the objects.
Thats too bad because it is still very useful.
Here are some things you can do in Genscript:
-Instantiate large assemblies from "thin air" much faster than VB.
-Build sets of parameters and formulas much easier and faster than VB.
-Create sets of expert rules
-Copy sketches into a part and then build formulas to control the sketch's parameters
-Instantiate UDF's
-Instantiate UDF's which are Assembled/Removed/etc (Can't do that with a power copy.)
-Create complex parts from a "recipe" with parameters, and formulas, and udf's all working together
Here is a GScript example for a specific configuration of a tooling block - a block of steel with holes for screws, dowels, and jackscrews - made from UDF's and sketches in GScript.
Something like this might be fired from an expert rule set (built using Gscripts) in the larger assembly which has taken notice of the need to create a block of this specific type and size.
GScript is not useful?
(Too bad the forum will totally mess up my nice indented formatting!)
import "C:\CATALOGS\SHAPES\BASIC SHAPE UDFS.CATPart";
import "C:\CATALOGS\SKETCHES\PATTERNS\USER PATTERN SKETCHES.CATPart";
import "C:\CATALOGS\HARDWARE\SCREWS\USSC_SHCS_Pattern_UDF.CATPart";
import "C:\CATALOGS\HARDWARE\SCREWS\USSC_TAP_HOLE_UDF.CATPart";
import "C:\CATALOGS\HARDWARE\SCREWS\USSC_SHCS_CLEARANCE_HOLE_PATTERN_UDF.CATPart";
import "C:\CATALOGS\HARDWARE\SCREWS\USSC_JACKSCREW_HOLE_PATTERN_UDF.CATPart";
import "C:\CATALOGS\HARDWARE\SCREWS\USSC_DOWEL_HOLE_PATTERN_UDF.CATPart";
`ZeroCenteredBlock` isa CATPart
{
`ZeroCenteredBlock` isa Part
{
SCREW_SPEC= "SHCS 1/2-13 X 3" ;
THREAD_SPEC="USSC 1/2-13";
DOWEL_SPEC=" 1/2 X 2 ";
BLOCK_HEIGHT=4in;
BLOCK_WIDTH=8in;
BLOCK_LENGTH =12in;
SCREW_OFFSET=1in;
GRIP=2.5in;
Sketches isa OpenBodyFeature
{
PS1 isa ZeroCenterRectPattern
{
PATTERN_WIDTH=?BLOCK_WIDTH-2*?SCREW_OFFSET;
PATTERN_LENGTH =?BLOCK_LENGTH-2*?SCREW_OFFSET;
}
JackscrewPatternSketch isa ZeroCenterDiagonalPattern
{
PATTERN_WIDTH=?BLOCK_WIDTH-2*?SCREW_OFFSET;
PATTERN_LENGTH =?BLOCK_LENGTH-6 *?SCREW_OFFSET;
}
DowelPatternSketch isa ZeroCenterDiagonalPattern
{
PATTERN_WIDTH=?BLOCK_WIDTH-2*?SCREW_OFFSET;
PATTERN_LENGTH =?BLOCK_LENGTH-4 *?SCREW_OFFSET;
}
}
SHCSScrewPatternBody isa BodyFeature
{
Screws isa SHCSPattern
{
`PATTERN SKETCH`= object: ..\..\Sketches\PS1;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?SCREW_SPEC;
`GRIP LENGTH`= ?GRIP;
`HAVE UPPER WASHERS` = false;
`HAVE LOWER WASHERS` = false;
`HAVE NUT` = false;
}
}
`DRILL BODY` isa BodyFeature
{
TapPattern isa TapHolePattern
{
`PATTERN SKETCH` = object: ..\..\Sketches\PS1;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?THREAD_SPEC;
}
ShoeDowelHolePattern isa USSCShoeDowelHolePattern
{
`PATTERN SKETCH` = object: ..\..\Sketches\DowelPatternSketch;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?DOWEL_SPEC;
}
}
PartBody isa BodyFeature
{
ZCtrBlock1 isa ZeroCenterBlock
{
`ANCHOR PLANE` = object: `xy-plane`;
`BLOCK LENGTH` = ?BLOCK_LENGTH;
`BLOCK WIDTH` = ?BLOCK_WIDTH;
`BLOCK HEIGHT` = ?BLOCK_HEIGHT;
}
ClearanceHolePattern isa SHCSClearanceHolePattern
{
`PATTERN SKETCH` = object: ..\..\Sketches\PS1;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?SCREW_SPEC;
`GRIP LENGTH` = ?GRIP;
}
JackscrewHolePattern isa USSCJackscrewHolePattern
{
`PATTERN SKETCH` = object: ..\..\Sketches\JackscrewPatternSketch;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?THREAD_SPEC;
}
DetailDowelHolePattern isa USSCDetailDowelHolePattern
{
`PATTERN SKETCH` = object: ..\..\Sketches\DowelPatternSketch;
`ANCHOR PLANE` = object: `xy-plane`;
SPECIFICATION = ?DOWEL_SPEC;
}
}
}
}
|
|
|
|
|
BPRASAD
|
| 12 Jun 2006 06:26 PM |
|
Bravo!! I knew someome out there must knew the power of "Generative Modeling", which a tool like PKT/GenScript "single-handed" provides.
I agree with you Cliff, "too bad", many of these PKT secrets are not well documented.
Cliff: thank you very much for pointing those good qualities of this PKT/GenScript tool to this Forum.
I am very surprised to see one could do all those, you pointed out -- with a handful lines of codes, (yours seems to be less than 100 lines) on a fly-- is quite promishing. The engineering design process knowledge is captured once in a "script form," I believe and reused multiple times.
No need to "store "thousands of configured designs" ; why not just store the seed file, (less than 1KB) and recreate the various 3D results based on your specific desired inputs & saved templates at run time.
That's very appealing. Thank you.
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
THUNDERLASSE
|
| 13 Jun 2006 01:37 AM |
|
Hi,
Great job Cliff; I knew it! If I just find a correct nerve to push, there is a lot of information to be found...
Nev! Take a look to UDF and Whitebox, BlackBox and Protected blackbox in R16. This should fix the thing! ...in my understanding... that can be limited sometimes...
BR,
Lasse
|
|
|
|
|
THUNDERLASSE
|
| 13 Jun 2006 03:17 AM |
|
Cliff,
About Genscript; I can see that you access to template parts from Genscript and create operations on top of them. (references to c:\... in beginning of your GENScript) Can you access to any VPDM (VPM/LCA/ST/??) from Genscript? That would be the only place to store any catalogs...
In R16 KWA we have "replace from URL" that can access some systems, but does that apply to GENScript?
Br,
Lasse |
|
|
|
|
COE-FORUM-USER
|
| 13 Jun 2006 04:27 AM |
|
Hello,
- udfs are no more frozen since R16 (you can edit their definition... but it won't modify existing instances except if you instantiated the udf with a knowledge pattern and that you reexecute the pattern in upgrade mode)
- there are strong differences between PCs and UDFs (in my opinion, they are really important from a KBE point of view) :
* There is no "instantiated PC", no instance notion. Once instantiated, a PC is exploded in the model. It can not be manipulated programmatically or interactively as a unique object
* Internals are really hidden for an udf, so it allows more "security" and complexity encapsulation for the final user
* Typing capability. This allows to manipulate udfs in Knowledge language very easily (and access ouputs programmatically).
* Knowledge Pattern integration : the ability to manipulate instances and references the same way enables the Knowledge Pattern udf integration. It is not possible to do so with PC (no instance notion)
Regards |
|
|
|
|
|
| You are not authorized to post a reply. |
|
|
|
ActiveForums 3.6
|
|
|
|