Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Show only
|
Search instead for
Did you mean:
This page has been translated for your convenience with an automatic translation service. This is not an official translation and may contain errors and inaccurate translations. Autodesk does not warrant, either expressly or implied, the accuracy, reliability or completeness of the information translated by the machine translation service and will not be liable for damages or losses caused by the trust placed in the translation service.Translate
Support the assignment of all iProperty fields in Multi-Body part solids... and their population into the subsequent parts/assemblies created during the "Make Part/Component" workflows.
AddiPropertiesforevery singlebodyinmodelingmultibodycan afford toextractthe part list withoutthe need tobuild an assembly.This can beextremelyuseful in simple weldments.
I use solid bodies within parts very often. Lately I've been trying to figure out how to extract properties (Mass, Volume, etc.) from a solid body in a multibody part for use in iLogic rule programming. After searching the internet, it appears that Inventor doesn't natively support calling out and using these parameters in iLogic.
According to the forums, it CAN currently be done by using some pretty advanced programming, however, I am not a highly trained programmer (as I assume is the case for most users).
Please add native support for calling out and using the properties of solid bodies with iLogic. Preferrably, add a snippet category in the iLogic rule dialog box for solids.
Why is this needed (why not just fill in the iProps in the subsequent parts/assemblies ) ?
If there iproperties in the derived part that comes from the Multi-Body part how do we know which direction to push/pull, in order to keep these in sync?
If I have 87 solid bodies, how would we want those iProperty fields to get filled out, updated, etc.
Are we needing an authoring table (something like iPart editor table) for solid body parts?
I'm not suggesting this is not a good idea (I actually kind of like it), but just looking for more details.
Why is this needed (why not just fill in the iProps in the subsequent parts/assemblies ) ?
Because I plan/assign the info while designing in the MBS environment & want to capture/assign that info up-front
If there iproperties in the derived part that comes from the Multi-Body part how do we know which direction to push/pull, in order to keep these in sync
IMHO, I would think the MBS part is the master of the design info and would expect it to also be the master source of the iProps (refresh the subsequent part & assy files) That said, a "sync-to source" might be useful in workflows others might have).
If I have 87 solid bodies, how would we want those iProperty fields to get filled out, updated, etc.
Either a right-click on each solid... Or much more efficient would be via a "MBS BOM" dialog (much like the BOM dialog in assemblies) would seem to be appropriate and efficient.
Are we needing an authoring table (something like iPart editor table) for solid body parts?
One way to accomplish this would be to isolate each solid body as its own iPart member. Then you could control the iProperties for each member (i.e. solid) using the iPart table. And rather than using "Make Components" or "Derive" tools to push out each of your solids, you would generate them as iPart members.
Problem is, there isn't currently a way to suppress a solid body as a whole. So for each row you'd have to actually suppress every individual feature for the other solids, which is unrealistic. (Maybe there's an iLogic solution to this?)
If you could suppress a solid as a whole, or, even better, isolate a specific solid in a given iPart row, then using iParts would be a much more viable solution.
I just checked to verify, and the functionality is that if the iProperty (Description for example) is specifically added to the iPart table, then each member uses the value specified in its own row (this holds true even if it is blank--that iProperty's value will be blank for that member).
If an iProperty isn't in the iPart table, then they all do indeed use the factory's iProperty value.
Possibly so... actually I think the material can be driven by the iPart table as well, which would be a very handy solution to the "different solid bodies can't be given a different material" problem that Inventor's had for so long. If iParts played more friendly with multiple bodies, then they would be a great tool for managing the iProperties AND material of individual solid bodies.
Also, I strongly agree that LOD for parts would be amazing. In reality (I've said this before) all that's really necessary is for iParts to function like LOD parts--where the iPart table controls suppression, parameters, iProperties, and material like it does now, but you simply place the master file in assemblies and choose the "LOD"/member, rather than pushing out every single member into a new derived part where it loses feature patterns and work features and makes you keep up with a bunch of extra files. I think you're right that LOD parts are the solution, but I say keep the additional control of the iPart table with that, and do away with creating all of the "spawn" files of the iPart factory.
So basically... I think the ideal way to enhance multi-body and configuration functionality would be:
@Curtis_Waguespack, would you agree that "localized" iParts would accomplish the same advantages as LOD parts? Or do you see an advantage to having pure LOD part functionality?
My workflow doesn't utilize iParts because dimensional information doesn't follow a set, nor predictable/quantifiable, list. As such, the geometry in each MBS part file is unique in each combination/case, and because of this, potentially infinite.
@ DRoam localized iParts sound interesting. Maybe an option to have a localized option in iParts is all that's needed.
Also "actually I think the material can be driven by the iPart table ", I was speaking of mass properties no materials. If I recall correctly, the members only report the factory mass props? Maybe I'm not recalling that correctly either though?
@ bverboort, just FYI you can set up custom columns in an iPart to accommodate infinite sizes, then you specify the value for the custom column(s) when you place the iPart member.
The MBS is really no more than a template in our design scenario. It gets modified (similarly to the way iCopy works), then the required product geometry and structure is produced via Create Part/Component.
I have also made a related "Idea" request (linked below) that would enhance the use of iFeatures in MBS parts, which in combination with what I'm requesting here would provide a tenable workflow/solution for our design needs.
@Curtis_Waguespack, yeah possibly so. It's possible there are some users that for some reason like the "spawn files" for iParts. But allowing them to be localized, essentially functioning like LOD parts, would be ideal in my opinion. It would eliminate nearly all of the biggest weaknesses of iParts.
Also, "I was speaking of mass properties not materials." Oh ok, I guess I'm confused on this one because I thought mass properties were "tied" to the material and were essentially the same thing. Is that wrong?
@bverboort, fortunately, I think this iPart workflow would still work for you. If you used iParts to achieve iProperty control for your solids, that would not in any way mean that you would also have to use them to create and manage your configurations. If you were able to use iParts to control and manage the iProperties of your MBS's downstream parts, you could still use your current workflow of creating a copy of the master MBS part (which is now an iPart), making your changes as necessary, and then pushing your solids out into a new set of parts. You possibly could use the iPart functionality to create an manage the various possible configurations of your MBS, but you wouldn't have to.
The only problem is, as we mentioned, it's currently very difficult to manage solids using iPart functionality, because you can't suppress or isolate a solid directly. But if that were possible, I think iParts would be a perfectly viable and ideal solution for your needs.
That's close, but really the iProperty/material and parameter control already exists via iParts. It all comes down to iParts. Essentially what is needed is the following:
Needed part configuration (iPart)/Multi-body functionality:
1) iPart control of solid bodies (i.e. ability to suppress/isolate specific solids for an iPart member)
- This would enable iProperty and Material management for solid bodies
2) Localized iPart members (i.e. LOD parts)
- This would enable suppression states in parts and localized part configurations (which eliminates extra files and the issue of lost feature patterns, work features, parameters, etc. in iPart members)
3) "New Solid" option for iFeature placement
This idea is essentially Number 1 (iProperty management for solid bodies, which could be accomplished via iPart control of solid bodies).
I came across another idea requesting the same thing as "Number 1" in my post above. Please consider giving it a vote to help get these suggestions recognized.
