Inventor Engineer-to-Order

Reply
New Member
NTSULZER
Posts: 2
Registered: ‎09-27-2012
Message 1 of 4 (169 Views)

Faster Performance ?

169 Views, 3 Replies
09-27-2012 03:16 AM

 

1. What is the better performance / say better way of doing it ? 

--> If we define the "paramter" in the Child Code or if we only forward the parameter in the child rule of the parent without having the parameter espeacialy defined in the child itself ? ( LookUP funktionality )

 

Design Parameter_Test : Parameter_TESTRoot IvAssemblyDocument

'#############################################################
'#Rules
'#############################################################
	
	Parameter Rule Höhe As Number = 1.5
	
'#############################################################
'#Child
'#############################################################
	
Child Dreieck_1 As :Dreieck
 	Höhe =Me.Höhe
End Child

 This will work fine and we do not notice less performance even that we did comment out the parameter ! 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	'Parameter Rule Höhe as Number = 111
End Design

 This will also work but we do not really need this PARAMETER at this level ! Which brings us to the second Question

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	Parameter Rule Höhe As Number = 111
End Design

 

2. Why does following solution not work ? The value will not be given to the child nor it uses the look up funktionality . The value will stay 111 independent of what we do in root !

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	Rule Höhe As Number = 111
End Design

 

Thank you / Regards

NTSULZER

 

 

 

Board Manager
Jon.Balgley
Posts: 243
Registered: ‎08-23-2006
Message 2 of 4 (161 Views)

Re: Faster Performance ?

09-27-2012 09:29 AM in reply to: NTSULZER

NTSULZER wrote:

 

1. What is the better performance / say better way of doing it ? 

--> If we define the "paramter" in the Child Code or if we only forward the parameter in the child rule of the parent without having the parameter espeacialy defined in the child itself ? ( LookUP funktionality )

 

Design Parameter_Test : Parameter_TESTRoot IvAssemblyDocument

'#############################################################
'#Rules
'#############################################################
	
	Parameter Rule Höhe As Number = 1.5
	
'#############################################################
'#Child
'#############################################################
	
Child Dreieck_1 As :Dreieck
 	Höhe =Me.Höhe
End Child

 This will work fine and we do not notice less performance even that we did comment out the parameter ! 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	'Parameter Rule Höhe as Number = 111

rule foo as number = hohe * 2 End Design

 This will also work but we do not really need this PARAMETER at this level !

 

That works OK because references to a rule will automatically "look up" to the ancestors.   I added a rule which makes a reference to "hohe".

 

Which brings us to the second Question

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	Parameter Rule Höhe As Number = 111
End Design

 

2. Why does following solution not work ? The value will not be given to the child nor it uses the look up funktionality . The value will stay 111 independent of what we do in root !

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	Rule Höhe As Number = 111
rule foo as number = hohe * 2 End Design

 

Well, it may seem a bit odd when you show all the possible permutations here, but of course this is the simplest possible combination of a rule and a reference to it.  Of course the reference to "hohe" in "foo" should get 111, regardless of any ancestor's rule.

 

If you want the "look up" behavior, you can add the Lookup flag, like this:

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt
	Lookup Rule Höhe As Number = 111
rule foo as number = hohe * 2 End Design

That tells it to look to see if any ancestor defines "hohe", if so, use the ancestor's value, and if not, then use 111.

 

As to which is more performant, I don't really know.  Certainly in a small model you'll never notice any difference; it will only matter if you do it hundreds or thousands of times.  They all have slightly different behavior -- I would recommend using the one that makes the most sense to you.  Most people are happy with the use of Parameter when they want the parent to directly control the value, and "no rule" or "Lookup" when they want a distant ancestor to control the value.  Use of "Lookup" allows you to use the design in a hierarchy where no ancestor defines it (safer in one way).  Use of "no rule" allows you to get an error if you accidentally use it in a hierarchy that does not define it (safer in a different way).

 

 

Thank you / Regards

NTSULZER

 

 

 


 

          rule foo as number = hohe * 2

 



Jon Balgley
Autodesk Configurator 360 / Inventor ETO team
Autodesk, Inc.

New Member
NTSULZER
Posts: 2
Registered: ‎09-27-2012
Message 3 of 4 (148 Views)

Re: Faster Performance ?

09-28-2012 01:48 AM in reply to: Jon.Balgley

Jon.Balgley wrote:


 Most people are happy with the use of Parameter when they want the parent to directly control the value, and "no rule" or "Lookup" when they want a distant ancestor to control the value.  Use of "Lookup" allows you to use the design in a hierarchy where no ancestor defines it (safer in one way).  Use of "no rule" allows you to get an error if you accidentally use it in a hierarchy that does not define it (safer in a different way).


Thank you Jon for your answer !  However as  our experiance with ETO is not proceeded far enough we would like you to clarify some things. As we are starting with a quite big project we need to define our phylosophy.  

1. Most happy people:  So you say to place a parameter rule in a child even if you want to control the value by the parent makes sence for many people ? "No rule" and "Lookup" for more distant ancestors ? What about the following several solutions which did all work:

 

1.

Here we use the Lookup even if the parent is clearly the one which can deliver the value. The rule Breite is equal to your "FOO" example! However we did also use "Me" ! it will also work without "Me" ( Somehow strange !!! )

 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Lookup Rule Höhe As Number = 111

    Rule Breite = Me.Höhe*2

End Design

 

2.

Here we use the in HELP described parent function to forward 2 time Höhe to Breite.  What is somehow strange is that the model will not need to be told about Höhe itself but updated both values by just one line.

 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Rule Breite = Parent.Höhe*2

End Design

 

3.

As you can imagine there are ( aggree bit ODD !!! ) many permutations.  We like the one with Lookup and either Me or Parent .  Parent seems strange though if I already use Lookup.  Our tutor tells us to use Paremeter and Me.

A.   

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Lookup Rule Höhe As Number = 111

    Rule Breite = Parent.Höhe*2

            End Design

 

B.        

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Parameter Rule Höhe = 111

      Rule Breite = Me.Höhe*2

            End Design

 

Can you please let us know what phylosophie makes the most sense to you ?

 

Thank you / Regards

NTSULZER & THSULZER

Board Manager
Jon.Balgley
Posts: 243
Registered: ‎08-23-2006
Message 4 of 4 (136 Views)

Re: Faster Performance ?

09-28-2012 10:36 AM in reply to: NTSULZER
Comments below.
NTSULZER wrote:

Jon.Balgley wrote:


 Most people are happy with the use of Parameter when they want the parent to directly control the value, and "no rule" or "Lookup" when they want a distant ancestor to control the value.  Use of "Lookup" allows you to use the design in a hierarchy where no ancestor defines it (safer in one way).  Use of "no rule" allows you to get an error if you accidentally use it in a hierarchy that does not define it (safer in a different way).


Thank you Jon for your answer !  However as  our experiance with ETO is not proceeded far enough we would like you to clarify some things. As we are starting with a quite big project we need to define our phylosophy.  

1. Most happy people:  So you say to place a parameter rule in a child even if you want to control the value by the parent makes sence for many people ? "No rule" and "Lookup" for more distant ancestors ? What about the following several solutions which did all work:

 

1.

Here we use the Lookup even if the parent is clearly the one which can deliver the value. The rule Breite is equal to your "FOO" example! However we did also use "Me" ! it will also work without "Me" ( Somehow strange !!! )

 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Lookup Rule Höhe As Number = 111

    Rule Breite = Me.Höhe*2

End Design

 

Using "Me.Something" is the same as using "Something".

 

Using "Lookup" without "Parameter" is rare, but OK.  What that means is: "Dreieck expects that some ancestor will define a Hohe rule, but just in case no ancestor does that, here's a value to use."

 

2.

Here we use the in HELP described parent function to forward 2 time Höhe to Breite.  What is somehow strange is that the model will not need to be told about Höhe itself but updated both values by just one line.

 

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Rule Breite = Parent.Höhe*2

End Design

 

Using "Parent" means that you start the search for the rule at the next level up.  

This usage is unusual/rare, because just using "Hohe" will find the parent's value.

 

Note that you can use "parent" to "skip over" a rule in the current design.  See the next example.

 

 

3.

As you can imagine there are ( aggree bit ODD !!! ) many permutations.  We like the one with Lookup and either Me or Parent .  Parent seems strange though if I already use Lookup.  Our tutor tells us to use Paremeter and Me.

A.   

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Lookup Rule Höhe As Number = 111

    Rule Breite = Parent.Höhe*2

            End Design

 

I agree, there are many permutations.  What this one says, is: the "hohe" rule in Dreieck will look for a value in its ancestors, and if none are found, it will use 111.  The "Breite" rule will ignore the hohe rule in Dreieck, and will start the search in the parent.  So, if no ancestor defined a Hohe rule, then Dreieck's hohe rule will succeed with 111, but Dreieck's Breite rule will fail.  This is slightly different from case 1, above.

 

B.        

Design Dreieck : Parameter_TESTAdoptedComponents DreieckAdopt

            Parameter Rule Höhe = 111

      Rule Breite = Me.Höhe*2

            End Design

 

 

The use of "Parameter" means that only the parent can control the value of Hohe (or it can choose to not control it, and let the value default to 111).  The parent controls the value of Hohe by supplying it as a parameter in a Child rule.  Of course, the parent can have multiple children, each of which has a different value for Hohe.  (This is a key differentiation between "Lookup-no-Parameter" and "Lookup Parameter".)

 

As above, the use of Me is unnecessary.  There is a rule for "Hohe" in the current design, of course, so no looking-up is necessary.

 

Because there are only these two possibilities (comes from parent or comes from default value), this is the most common technique for controlling "variable" rule values.  Using Lookup or "no rule" ... it is harder to determine where a value comes from.

 

Can you please let us know what phylosophie makes the most sense to you ?

 

 

Here is my philosopy:

 

1. All the following is "in general" ... there are rare cases where it makes sense to use most permutations.

2. For most controllable/variable rules, use Parameter.  "Parameter Rule Hohe as Number = 111"  Refer to the rule  with just the rule name, "hohe", not "me.hohe" nor "parent.hohe".  

  2A. Sometimes I will use :Required if there is no reasonable default value.  

  2B. Exception: sometimes I like to use me.hohe inside a child rule, like this:

              child d as :dreieck

                  hohe = me.hohe

                  ...

3. Occasionally I have a rule that needs to affect an entire subtree.  In that case, I will typically include that rule as a Lookup Parameter rule in a mixin, and use that mixin in every relevant design ... and "relevant" means any design that makes a reference to that rule.  By using the mixin, it ensures that the rule is available, even if no ancestor defined it.  But since this is relatively rare, it is also common to carefully ensure that the root's design has definitions for these few rules, and so every design underneath can refer to them freely. 

4. "Never" use Lookup without Parameter.  By using Parameter, that allows the parent to have two or more subtrees with different values for "the" rule.

    child a as :smileyvery-happy:reieck

       hohe = 1

    end child

    child b as :smileyvery-happy:reieck

       hohe = 2

    end child

 

Finally, I agree that this is all confusing.  In a simple model, such as Dreiecken, it is hard to see the point. 

But all of these features have their purpose in a complex model. That's the difference between a "toy" and an industrial-strength product.

 

--Jon

 

Thank you / Regards

NTSULZER & THSULZER


 



Jon Balgley
Autodesk Configurator 360 / Inventor ETO team
Autodesk, Inc.

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Manufacturing Community
The Manufacturing Community provides additional access to tips, tutorials, blogs and networking with peers.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community


Inventor Exchange Apps

Created by the community for the community, Autodesk Exchange Apps for Autodesk Inventor helps you achieve greater speed, accuracy, and automation from concept to manufacturing.

Connect with Inventor

Twitter

Facebook

Blogs

Pinterest

Youtube