NEVJOHNSON
 |
| 24 Jan 2006 10:08 AM |
|
I have built a part solely from wireframe data.
I have then built a UDF and specified which features I want as outputs.
I also have a rule which deactivates one of the features which is an output in the UDF.
Catia seems unable to cope with this scenario.
Has anyone a method of applying this. |
|
|
|
|
BPRASAD
|
| 24 Jan 2006 04:12 PM |
|
If you are using KWE rule, you should be able to deactivate a ruleset by Name via KWE. I do not understand the scope of your questions though. Could you be more specific about the issue that you would like to get addressed?
Perhaps that way we could answer your questions, more closely,
Brian |
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
NEVJOHNSON
|
| 25 Jan 2006 07:45 AM |
|
I have a circle feature that is activated and deactivated by a rule(KWA),
dependant on whether a parameter is true or false.
This circle is an output in my UDF.
On creating the UDF the circle is deactivated.
When I instantiate the UDF the parameter that drives the circles activity is false
and the UDF returns an error. |
|
|
|
|
NEVJOHNSON
|
| 30 Jan 2006 11:29 AM |
|
Brian,
Have I clarified sufficiently? |
|
|
|
|
BPRASAD
|
| 30 Jan 2006 01:42 PM |
|
You are right. I am getting the same error.
Looks like whenever an UDF is instantiated from a document, there is a default parameter added -->"Activity =true" with it.
It works fine with Activity=true condition.
If I set that Activity to "false", the system gives an "Invalid userfeature input. /" error message. With the short time, I put in, I could not figure out why?
Looks like this is a bug... May be DS would clarify this for us?
Thanks. |
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
COE-FORUM-USER
|
| 01 Feb 2006 10:47 AM |
|
Hello,
I don't think it is really a bug : it is not allowed to deactivate udf main's output (if you do it, the udf is activated but has no geometrical result, which is an error).
To do that kind of scenario you have to deactivate the udf itself.
|
|
|
|
|
NEVJOHNSON
|
| 01 Feb 2006 11:23 AM |
|
Quote
Quote
<hr><i>Originally posted by: <b>nevjohnson</b></i>
I have built a part solely from wireframe data.
I have then built a UDF and specified which features I want as outputs.
I also have a rule which deactivates one of the features which is an output in the UDF.
Catia seems unable to cope with this scenario.
Has anyone a method of applying this.<hr></blockquote><hr></blockquote>
If it is not a bug then what would be a workaround?
Also the main output result is still validate. The difference is that I have many outputs.
The fact is that it functions differently for wireframe data as opposed to solid data.
Even if I put the wireframe body in an assemble within the PartBody I cannot overcome this scenario.
|
|
|
|
|
BPRASAD
|
| 01 Feb 2006 12:03 PM |
|
Hi ds_developer2:
Thanks for your update. It is important for us to know what's the desired behaviors were?
However, I am very confused with this the reason for this "desired behavior" itself.
I am sure you have heard about the concept of a "nullpart" used in KTI/ICAD system?
In the same token, why can't we have a UDF here, which morphs into (a) geometrical entity of some form or to (b) a "null_udf", based on some rule.
Why can't we accomplish the above behavior (in an udf) via a KWA rule, which reside inside of a “udf part” itself?
|
|
Brian Prasad
COE-DPC/KBE Chairperson |
|
|
IPHILLIPS
|
| 03 Feb 2006 08:58 AM |
|
The UDF is an important building block in vehicle body design. It allows us to solve many problems and simplifies complex GSD structures.
2 main things we miss are UDFs (or any alternative) that have a variable number of INPUTS. And UDFs that have a variable number of OUTPUTs. It is this 2nd one that Nev is having problems with. For example, I would like a part that has a variable number of holes in it depending on its length.
At the moment we use Loops(KWA). It is also not so straight forward handling the variable number of outputs from a loop. But there are ways. |
|
Ian Phillips. FORCEFIVE AG, Munich, Germany |
|
|
COE-FORUM-USER
|
| 06 Feb 2006 04:34 AM |
|
Nev,
Sorry, I thought you wanted to deactivate main output without deactivating the udf.
Actually, it should not be allowed to publish activity of features put in output : their deactivation is currently not supported.
There is a bypass, but I'm not sure you'll like it : you can deactivate the circle if it is not an udf output... So you have to remove explicitely the circle from udf outputs in user feature definition.
I think you can send an incident report for this problem :
- activity defined on udf outputs is not taken into account (after instantiation)
- internal feature activity should not be publishable if the feature is an udf output
Ian I would be interested in more precisions about what you mean about user features... I don't see how we could do that (variable number of inputs). So if you have ideas... |
|
|
|
|
NEVJOHNSON
|
| 07 Feb 2006 10:58 AM |
|
ds_developer2
Your statement
"Actually, it should not be allowed to publish activity of features put in output : their deactivation is currently not supported"
Here are you speaking of the activity for each publishes output?
And
"There is a bypass, but I'm not sure you'll like it : you can deactivate the circle if it is not an udf output... So you have to remove explicitely the circle from udf outputs in user feature definition."
This is not a workaround as the circle is a udf output.
I shall raise a PMR in this case
|
|
|
|
|
COE-FORUM-USER
|
| 09 Feb 2006 02:32 AM |
|
I'm speaking of the activity of the internal feature that is seen as a secondary output. With the udf creation panel, you can choose to remove secondary outputs. Then deactivating these features is supported. As soon as these features are published as outputs, they can not be deactivated
I understand it is a problem (and it is worth to raise a PMR): if you want to build other features on this circle, it has to be an output. But if you don't, the bypass works fine.
|
|
|
|
|
JOBY
|
| 22 Feb 2006 03:51 PM |
|
I have a UDF for adding a one-dimensional rectangular pattern of pockets to a model.
One of the published parameters of the UDF is the Number of instances in the rectangular pattern.
If the user sets this number to one however, the rectangular pattern errors.
So, I included a rule that controls the activity of the rectangular pattern, and the rule is included in the UDF.
The "Output" of the UDF is the rectangular pattern, and I control it's activity based on one of the user parameters... isn't this what you are trying to do?
For me, if the number of instances is one, and the rectangular pattern is deactivated, then I suppose the Output of the UDF is my original Pocket, not patterned. However, the pocket is not listed as an output of the UDF. Perhaps you can use this to your advantage? Your UDF could have a dummy output, so it would never have no output at all.
The attached pictures should show what I mean...
If this isn't the problem, and I've misunderstood, then I wish you the best of luck figuring it out! 
~Joe |
|
 |
|
|
NEVJOHNSON
|
| 23 Feb 2006 09:00 AM |
|
The problem is that there is more than one output. Yours only has one.
In addition the outputs are not solid geometry but wireframe elements.
Take a look at the attached jpeg.
I have also created a simpled version of the problem FYI.
I have solved the problem another way but this would have been the simplest approach.
Thanks for your feedback
Rename UDF_part.zip.txt to UDF_part.zip and decompress
Nev |
|
|
|
|
JOBY
|
| 23 Feb 2006 10:04 AM |
|
is that an R15 or R16 part you attached?
I only have 14 right now...
But, you don't really need any more help, so we can let this go.
~Joe |
|
|
|
|
NEVJOHNSON
|
| 23 Feb 2006 10:49 AM |
|
| Sorry its R15 |
|
|
|
|
NEVJOHNSON
|
| 07 Mar 2006 10:20 AM |
|
Just for the record this is the response I got back from DS upon raising the PMR
This PMR was sent to Dassault and the responded with the following comments:
"After analyzing the scenario with the data it
is found that the current behavior is working as designed.
The User Feature properties are independent from its internal
components properties because the User Feature is a feature with its
own properties. As soon as the User Feature is created, the properties
of the User Feature are "frozen" and thus independent from the
properties of its components. In the current scenario the
"Activate/Deactivate" is available for Point.1, which is controlled by
Rule outside UDF. However when the User Feature is created the
Activate/Deactivate properties of the point.1 are frozen and are not available. "
|
|
|
|
|