Re-using (true/false) parameters in different parts/assemblies is something that I do a lot. I repeat the same process over and over, and since [this idea] isn't a thing yet (support is appreciated), I'm looking for a smarter/faster way to do this.
What I'm doing currently is this:
If has_feature_x Then has_feature_x_num = 1 Else has_feature_x_num = 0 End If
If has_feature_x_num = 1 Then has_feature_x = True Else has_feature_x = False End If
If has_feature_x Then Feature.IsActive("feature_x") = True Else Feature.IsActive("feature_x") = False End If
What would be sensible steps to automate this process?
I was thinking about making something that I could use like this:
exportParameter(has_feature_x)
It would have to:
- makes numerical counterpart if it doesn't exist
- marks numerical counterpart for exporting if it isn't yet.
- gives the numerical counterpart the right value.
Similar Idea for importing, but I'm sure I'll figure that out once I have the exporting going.
I've never made a sub though, and I'm not sure how to go about this. So an example would be hugely appreciated.
And of course, if you have a better Idea how to go about this please share.
Thanks!
Solved! Go to Solution.
Solved by PaulMunford. Go to Solution.
Solved by MechMachineMan. Go to Solution.
Solved by PaulMunford. Go to Solution.
I'm confused, do you want to Export and then Import Parameters?
Do you want to link parameters?
Parameter("Frame Skeleton Example:1", "Part_TF") = Assy_TF
Perhaps you could explain the gola and then we couls suggest an alternative method?
My goal is to manipulate my assemblies and parts from one location with less of a hassle. The way I do this now is using an ipt file (that's not in the assembly) as a master file. (If I use the assembly to modify a part and then put it in the assembly Inventor claims it can't do that because of a (possible) circular reference.) Perhaps exporting/importing aren't the right words to use, it is about linking parameters. I just called it exporting/importing since I wasn't able to link them the way I'm able to link numerical parameters.
Your (linking) suggestion sounds promising, I will try that. Thank you.
Another alternative:
Step1: Drive your sub-models using named parameters.
Step 2: Write code that pulls all named parameters into top level as user params
Step 3: Write iLogic code that pushes all of the user parameters from the top level to all sub-levels over the params of the same names.
@PaulMunfordI've tried linking the parameters on the top assembly and it works like a charm, thank you!
@MechMachineManThank you for the suggestion. This definitely sounds like where I would eventually like to end up! I'm not sure how to go about this yet though. Will do some research on this. Pointers to useful building blocks for this would be greatly appreciated.
This class at Autodesk University online might give you a few ideas 😉
Paul
@PaulMunfordGreat talk! Very informative/inspiring. (And good to see I'm not the only one who thinks giving features and parameters a proper name is good practice)
The 'Dims' rule seems to be exactly what I need right now. I've cut all the parameter-interface links to my master part, and intend to drive everything from the top assembly. (the broken links leave convenient handles in the respective parts/ sub-assemblies) I can't get it to work though, and since I can only see the top half of the code in the video (and I can't find it in the handout) I'm afraid I've missed something. Would you be willing to share? Thanks.
Sure,
We've worked on the routine a little since then.
This iLogic Code will create a list of all parameters that exist in the Assembly, that start with 'A_' (This allows you to make parameters 'Local' or 'Global).
It will then iterate through all parts in the assembly. In each part it will make a list of all part parameters that start with 'A_'.
If it can find a parameter in the assembly, that has a matching parameter in the part, it will 'push' the value of the assembly parameter down into the part.
The 'Trigger Generator' rule is just a helping rule. This just creates a list of all assembly parameters inside a rule called 'Trigger'. As long as parameters are listed inside an iLogic rule, updates to the parameter values will happen instantly.
You need to run the Trigger Generator rule whenever you add a new parameter to the Assembly parameters table.
Is that helpful?
Dim oAsmDoc As Inventor.AssemblyDocument = ThisDoc.Document Dim oPars As Inventor.Parameters = oAsmDoc.ComponentDefinition.Parameters Dim oList As Collection = New Collection For Each oPar As Inventor.Parameter In oPars If (Left(oPar.Name, 2) = "A_") Then oList.Add(oPar.Name) End If Next If oList.Count = 0 Then MsgBox("Empty list :(") Else 'print oList content for debug purposes 'Dim sTotal As String = "Found: " & oList.Count 'For Each st As String In oList ' sTotal += vbNewLine & st 'Next 'MsgBox(sTotal) 'now we can do something useful with names in the oList For Each oOcc as ComponentOccurrence In oAsmDoc.ComponentDefinition.occurrences For Each ParName As String In oList Try Parameter(oOcc.Name, ParName) = Parameter(ParName) Catch End Try Next Next End If 'Update the document to see the changes iLogicVb.UpdateWhenDone = True
Dear @PaulMunford If there was a "give bucket full of kudo's" button I'd hit it. Thank you!
The code I got from the presentation seems to work now (it didn't work upon 'run rule', but it did when I changed the parameter in question). I will test your new routine, and adapt it as soon as I get it to work.
And again, it works like a charm.
Here is a slight modification that perhaps you might find useful:
'[ DEBUG If debug Then 'Print oList content For debug purposes Dim sTotal As String = "Found: " & oList.Count For Each st As String In oList sTotal += vbNewLine & st Next MsgBox(sTotal) End If']
the '[ and '] make the code collapsable, and the If statement enables you to turn on/off all debug code by setting the parameter "debug" to True or False
@PaulMunfordI took the code for a little spin, and I understand what happens now. It doesn't work for parameters in subassemblies. So I thought I'd fix that, by having the same rules in the subassemblies and firing them in a similar way (determine which parts are assemblies and firing running the rules from the top assembly. (At one point I was even thinking about having the assemblies passing their own code down to the subassemblies so that I'd only have to put the code into a top assembly.)
Although I still like the idea, things were starting to slow down. It started to take up to 20 seconds to change the parameters directly. Probably because of all the loops it was going through. So changed my form to change them upon hitting Done or Apply. That wasn't in line anymore with the whole idea of directly seeing what you're doing though. So for performance reasons I'm now setting all the parameters using the Parameter()function directly.
So I've learned a lot, said goodbye to the hassle of managing all the links the way I used to with a master part, and I'll probably pick this up again later.
Can't find what you're looking for? Ask the community or share your knowledge.