|
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.
|
|
|
The COE 2008 Fall Industry Workshops
|
| Experience two days of industry-focused education and hands-on training on the Dassault PLM solutions suite of products. All education featured at the workshop is developed by and for users of CATIA®, ENOVIA®, DELMIA® and SIMULIA®. |
| |
|
|
Automotive
Oct. 15-16
Troy, Michigan
|
Aerospace & Defense
Oct. 27-28
Wichita, Kansas
|
 |
|
Register by October 10 and Save $100
|
|
| Forum Highlight: CATIA V6 |
|
|
 |
|
 |
| You are not authorized to post a reply.
|
|
| Author |
Messages |
|
COE-FORUM-USER
 |
| 10 May 2006 01:01 PM |
|
HI Guys-
I've worked myself into a corner here...
I have:
1) A KWA Loop instantiating multipile UDFs.
2) A List pointing to the UDF context Open Body.
3) A reaction fired by a change in the value of the List.
So, here's what is happening:
I activate/re run the loop.
The Context is repopulated with a new number of UDFs.
The List does NOT update!
Therefore, The Reaction never fires....
However, if I 3MB "Local Update" the list, the reaction fires.
I understand loops are somewhat exempt from the space-time laws that govern our universe, so I created a Let L= List....->...Apply (List Update) Rule to force the List update.
However, this has no visable effect!
Why won't my List recognize the change of the context Open Body?!
Please help/enlighten/scold...
Dave
|
|
|
|
|
IPHILLIPS
|
| 11 May 2006 08:39 AM |
|
Loops were originally developed by Klingons before Dassault bought them up.
Ian
Hab SoSlI' Quch! |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
COE-FORUM-USER
|
| 12 May 2006 07:34 AM |
|
Mmmhh....
I don't see any reason why List should send a modification event. It is not modified during your scenario, if I understand it well (if I have understood, the list contains only a reference to the openbody). The only thing that happens for this list is that one of its linked object becomes not uptodate and then uptodate...
|
|
|
|
|
COE-FORUM-USER
|
| 15 May 2006 05:59 AM |
|
Well,
The UDF Loop Targets an Open Body to store the "new" set of instantiated UDFs. These UDFs are then gathered by a list to feed a "Single-assemble" result, per the R16 shortcut method we've been discussing in the associative Join thread:
'Curve.1' = assemble (List.1) \*Explicit result of single curve*\
This result is then used for a split. \*ex. dynamic number of multipile cutouts from a single master shape*\
In order for the assemble to accuratly capture all the UDFs, the list needs to first update.
I tried pointing the assemble directly to the UDF Open Body, but the result would not always update after the loop was run. By making the assemble a reaction to the List value, it ensures an update, if the list is updated first.
Is there a way to put a "Stop Update" attribute on an element or action? I used to do this with GSMV4, to help manage the build-up steps. Perhaps this would be an application for it here..
Thanks for all the help guys.. |
|
|
|
|
IPHILLIPS
|
| 15 May 2006 09:56 AM |
|
| "Stop Update" is only available on geometric features and not knowledge features as far as I've seen. Access it through "Properties of the feature. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
COE-FORUM-USER
|
| 17 May 2006 07:37 AM |
|
Actually, I think I misunderstood...
I'm not sure if the list contains all udfs generated or if it contains only the open body?
In the first case, the list should be not up to date. But the update of objects inside Parameters node is not automatic (like in the relations node) for various reasons (performance, bigger risks of update loops, ...)
To ensure that the list is recomputed during part update, there are several ways :
- compute it through a relation whose update is integrated with part update (the famous and not liked question "do you want to integrate etc."). This can be modified through relation properties.
- ensure that the list is reused as an input of a feature that is updated. In the case of lists, it has to be another relation which is itself updated because it valuates a parameter which is updated, for example a parameter of a geometrical feature (I know this is complex, but there is a kind of logic behind!)
- move the list in another feature set (for example an open body because all objects aggregated on an open body are updated if they are not uptodate when the open body is updated).
Hopes it will help, and maybe clarify a little why parameters and relations are sometimes not updated |
|
|
|
|
|
| You are not authorized to post a reply. |
|
|
|
ActiveForums 3.6
|
|
|
|