General iLogic Practices question

[Anonymous]

Not sure if this is the place to post this question or not.

I've been writing iLogic code for the last month or so and I'm wondering if I'm doing it the best way. For example, we manufacture truck bodies, trailer bodies and trailer chassis. What I've been working on to date is the trailer bodies, made up of a floor assy., left and right sides, bulkhead and tailgate. Depending on the model and material there may  be other options as well. I'll use the sides as an example for my question. I  use one iLogic rule to drive length (in 2' increments), height (in 6" increments) and style (posted or smooth panel). I also include options for the sides that turn on or off features depending on what type of tailgate it gets. And I do all this with one rule and one form.

   Is this best practice? Or would I be better using one rule for length, one rule for height, one rule for the features for tailgate options? I haven't had any major problems trouble shooting my code to get things working properly although some of my rules end up being 400 + lines long. Seems large compared to the examples I've seen in the tutorials. But they work and my daddy always told me "if it ain't broke, don't fix it" . 😉 So is there an advantage to breaking rules into smaller size and sticking to one function per rule? If so, what would that be?

   I'm a newbie at all this iLogic stuff and I'd rather develop good habits early on, than try to break them later. Looking forward to hearing opinions on this topic. Have a great weekend.

Frank

Inventor 2016

[MechMachineMan]

One of the methods I have used in the past is to put a param that I want to control in each of the parts that it applies to, and use the same name. Then base the dimensions I want to change based off of that parameter. I then change that value in the parameter window in the top level run the rule below to push it.

It may not be the best method and I haven't gotten a lot of testing with it done, but it's definitely one possible method.

Option Compare Text

Sub Main()

Dim oDoc As Document
ODoc = ThisApplication.ActiveDocument

PushParams(oDoc, "DRUM_ID")

End Sub()


Sub PushParams(oDoc As Document, oStr As String)
	
	oParamExp = oDoc.ComponentDefinition.Parameters.Item(oStr).Expression
	
	For Each oSubDoc As Document in oDoc.AllReferencedDocuments
		For Each oParam As Parameter in oSubDoc.ComponentDefinition.Parameters
			If Not oParam.Name Like oStr
				Continue For
			Else
				oParam.Expression = oParamExp
			End If
		Next ' Param
	Next 'Sub Doc
					
End Sub

[MechMachineMan]

One of the methods I have used in the past is to put a param that I want to control in each of the parts that it applies to, and use the same name. Then base the dimensions I want to change based off of that parameter. I then change that value in the parameter window in the top level run the rule below to push it.

It may not be the best method and I haven't gotten a lot of testing with it done, but it's definitely one possible method.

Option Compare Text

Sub Main()

Dim oDoc As Document
ODoc = ThisApplication.ActiveDocument

PushParams(oDoc, "DRUM_ID")

End Sub()


Sub PushParams(oDoc As Document, oStr As String)
	
	oParamExp = oDoc.ComponentDefinition.Parameters.Item(oStr).Expression
	
	For Each oSubDoc As Document in oDoc.AllReferencedDocuments
		For Each oParam As Parameter in oSubDoc.ComponentDefinition.Parameters
			If Not oParam.Name Like oStr
				Continue For
			Else
				oParam.Expression = oParamExp
			End If
		Next ' Param
	Next 'Sub Doc
					
End Sub

[Anonymous]

Thanks Justin,

   I am grateful for all the suggestions I get here on this forum. I haven't attempted the VB style coding in iLogic yet. I am sticking with the snippets and what little code I've had to create custom within iLogic. The piece you are showing here, is it for a part file or assembly file?

  I have a "standard" format I try to use when naming parameters as it helps when creating my rules with iLogic. Any of the parameters that will be driven with iLogic use a "multi value list" to store the information I will be using in my rules to drive the assembly model. I've also learned to carefully plan how I will constrain my assembly models. This helps to achieve predictable results when using the rules to control your models. Especially when one rule controls multiple parts at the same time in an assembly model.

  I was really hoping someone would address my question concerning using the built in snippets vs using VB in iLogic.

Again, thanks for your input.

Frank

[Curtis_Waguespack]

---

@Anonymous wrote:

 And I do all this with one rule and one form.

   Is this best practice? Or would I be better using one rule for length, one rule for height, one rule for the features for tailgate options?  

---

Hi frank,

I would break it up into several smaller rules and then:

• have one main rule that call the others
• or have the form controls run the individual rules
• or have some combination of a main rule, and the form controls triggering the rules.

You main rule would use the RunRule and or RunExternalRule, something such as this:

'Main Rule
iLogicVb.RunRule("SetLength")
iLogicVb.RunRule("Set_Tailgate")
iLogicVb.RunExternalRule("Update_BOM")

---

@Anonymous wrote:

So is there an advantage to breaking rules into smaller size and sticking to one function per rule? If so, what would that be?

---

I think breaking it up helps us avoid building a "house of cards" in one giant rule that falls apart when we need to update it 6 months from now, or if someone else needs to modify your code at some point down the line.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com

[Anonymous]

Thanks Curtis,

I appreciate the input.

I really could use some 1 on 1 time with someone that knows more about this than I do.  I was looking into calling more than 1 rule from a form and I don't see how that works. I found the rules ok, but placing them into a form in a way that allows me to use the individual rules escapes me.

   I modified the rule that controls my floor assembly model today. It is now up to almost 1200 lines of code. As far as someone else working on my code, that isn't going to happen. We have one seat of Inventor here, one workstation and one operator. (me) I get what you're saying about working on the code down the line. Good point. I have plenty to add to my code yet, it's nowhere near doing what I want it to do. I still need it to save files into a different folder with new numbers. I would like it to generate all the required shop drawings (per customer) also into a different folder. It will also need to create that folder. My goal is to take the order form from our sales person, enter the information from the customer order form (which is also our shop work order) and have that information generate the model and all related drawings required for production. All the while, placing those files into a customer folder for that particular order. Then all I have to do from that point on is to open and print the files to send with the shop order. And yes I know iLogic will also generate the prints.

   I know I'm trying to create the mythical "Done" button. But I also know it's possible so why not do it.

Frank

[Curtis_Waguespack]

Hi frank,

One of the keys to the Forms and running rules is the way we call parameters.

This first block does not run the rule it is in automatically if the that parameter value is changed in the form:

If Parameter("Length") > Parameter("Diameter") Then
    MessageBox.Show("Length rule...", "iLogic")
End If

This one where Length is in blue is "listening" to Length and will run when that parameter value is changed in the form:

If Length > Parameter("Diameter") Then
    MessageBox.Show("Length rule...", "iLogic")
End If

This assumes 2 things:

1. We're working with Internal rules
2. The option to run the rule automatically is turned on (that option is can be set for each rule )..

Attached is little example file (Inventor 2015) that you can mess around with to see how some rules get fired automatically because of the blue parameter, and some are called from buttons in the form, or are called from other rules.

Note that if I had all of this in one rule, and that rule had a lot of blue parameters, updating anything in the form would update everything at once., every time, but by splitting it up and firing only when one specific value changes, we a great deal more control.

This example file is of course an example of some very simple code, I'm not saying that in real life you can't use one rule to control more than one thing, but it serves as an example.

I hope this helps.
Best of luck to you in all of your Inventor pursuits,
Curtis
http://inventortrenches.blogspot.com