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
Spring, rubber parts, such as, o-rings are solid but compress, stretch, squeeze, or extrude. Allow them to do that without assign new part numbers. They could be a subset or a choice or tabletized.
Yes, it's just that I hate adaptivity and it's slowness that it causes as assemblies get bigger.
Also, adaptivity doesn't allow me to define limits for the range of motion.
I would like it if for the part at the assembly level I could simply pick values for certain parameters and have it appear in that configuration in the assembly. A lot more robust than adaptivity, a lot smarter than adaptivity (design intent built into the part), no need for multiple components representing the same part numbers, no need to make extensive iPart tables.
Have you tried to use it with ilogic? This may be a good way to go for you then.. You could have a form pop up ask what setting you want then all spring would update. I have a spring with ilogic using a slider bar works real nice...
I really like those iLogic forms and its sliders with limits and increments, but have only played with it because in production I'm still on Inventor 2010. Moving to 2012 this year.
The concept of those forms would work very well for this, but what doesn't work is that it is still a normal part file that can not appear different in two separate assemblies. If the design is standalone, and you only need it in that one configuration, then that works.
But in my caes these parts need to be shared across teams, managed by PDM software, and linked to ERP systems, so I can't allow duplication of parts that are essentially the same material. iParts allow me to do this, but their structure of parent/child files can be a real headache with PDM (Vault), and making configurations through the table isn't very natural for situations like these.
I can understand that Inventor needs to generate and save each configuration of a part as it is used in an assembly, which is why the children for iparts exist I suppose, and this proposed flexible part would have to do the same in the end. Still, the method of making the variation would be much nicer is if it was as per iLogic forms and sliders.
I think you should able to create multi-value dimensions in your part and then save setsof mvd's like you save LOD's. Then you can select different mvd sets when you insert your part. Your part will come in with what-ever dimension sets you've chosen which gives different sizes of same part.
It would be fantastric to be able to have flexible materials, We use a lot of ropes and Strops, I'd like to be able to set up libraries of standard strops and then be able to bend them round fittings for each instance of use rarther than create a new model with the specific geometry each time, I woudl envisage somethign whereby certain dimensions can be defined as rigid and mateial properties would define the bending characteristics in the flexible dimensions.
Yes, in conjunction with "flexible" constraints, or the ability to establish constraint value limits for just such a purpose, like constraining a rigid buckle to a flexible strap. This would be very useful for fixing interferences more efficiently, for presentations (user manuals, etc) and to better communicate intent in design details. This functionality - especially for webbing straps - would be very useful in the (or a special type of) sheet metal environment
Hi @MMcGinnis, there are two ways to go about this currently:
Adaptivity. Advantages: You can constrain your flexible part and have it adapt to its context. Weaknesses: Every occurrence of the part will be the same size. You can't constrain multiple occurrences of the same Part File and expect them to conform to a different size (in fact, you can't make more than one occurrence of the same part file Adaptive at all. Only one occurrence can be Adaptive, and all other occurrences will have the same size as the Adaptive occurrence). You would need a different part file for each occurrence of a different size, which means keeping up with multiple files and manually keeping their iProperties in sync. Ideal usage: When your part will always be deformed to the same shape/size everywhere that it occurs.
iParts. Advantages: You can use a table to pre-define multiple deformed states of your part. Weaknesses: You can't constrain your part to adapt to its surroundings. Even though you can have multiple deformed states, those have to be pre-programmed into the iPart table and they can't be made Adaptive. You can, however, use linked Parameters to pull a desired measurement from another file and achieve a sort of "Adaptive" effect. Ideal usage: When your part will occur in multiple contexts and will have a different shape/size in those different contexts.
What would be amazing is if iParts could be made Adaptive. But that is currently a limitation of the software. Aside from iParts, though, there is currently no way for the same Part File to take on different forms in different contexts.
So you can either have your part Adapt to be flexible (but have the same shape everywhere it occurs), or you can pre-program in different shape/sizes for it to take on in various specific contexts.
But you can't do both (unless you use linked Parameters to drive some dimensions of your iPart like I mentioned above).
The ideal solution in the future would be to implement one or both of the following:
Allow iParts to be Adaptive. There's really no reason to not allow this. We would just need to be able to specify which members should be Adaptive for a given occurrence of an iPart. And those members would be marked as "Adaptivity used in Assembly" and should not be made Adaptive in any other context. This way, each member can be made Adaptive once and only once. This would ensure that a cyclic dependency relationship cannot be created.
Allow parts to be flexible (like Assemblies can be). There's really no reason not to allow this, either. Currently, an Assembly can be modeled with some unconstrained degrees of freedom, and by making that sub-assembly Flexible, and constraining to its components, Inventor can calculate a previously undefined configuration for that Assembly. The same could be done for Parts. A Part can be modeled such that its geometry has some underdefined "degrees of freedom". There's no reason we shouldn't be able to define an occurrence of that part as Flexible, constrain to it, and have Inventor calculate a previously undefined configuration for that Part.
The first method would be used when there is a finite number of configurations in which a part may occur, and drawings of these configurations may be necessary.
The second would be used for things like springs, O-rings, etc. which can occur in any number of situations, and their deformed geometry really isn't important except for visual's sake.
So probably the second of those two methods would be the proper way to implement this Idea--to allow Flexible parts (rather than Adaptive), just like we can have Flexible assemblies rather than Adaptive.
In the meantime, though, we have to use regular old Adaptivity or iParts and do our best to deal with their shortcomings.
Flexible parts could essentially function exactly like Adaptive parts, except the per-occurrence definitions would not be propagated to the original Part file (in the same way that per-occurrence definitions of flexible sub-Assemblies are not propagated to the original Assembly file).
Please see my comment on that thread regarding the difference between Flexible parts and Adaptive iParts, and why both would be useful in different situations.
I would like to have option to view instances (parts) in different shapes in assemblies. For examble coil springs, rubber dambers and other parts that have some flexible features in nature.
With Springs you usually need to have unloaded model for manufacturing drawing and in assembly this unloded position is rarely needed. Also you need different shapes according to assembly position.
Yes you can use (with some limits) adaptivity - but it doesn't solve unloaded situtation at all (and it's not wanted method by any way).
We want to create adaptive parts in Inventor Sheet Metal.
This has been possible in SolidWorks for many years.
Our products are delivered in one state, but many of them are flexible with adjusting by bending for hand onsite.
Our current method for expressing this in our model assemblies is time consuming and is based on making derived parts with different angles as shown in the table below.
We reuse them in many assemblies, in different angles. Each option becomes a new file which after some time, becomes thousands of files which is not a good or effective way of using disk space, nor making assemblies.
Delivery state.
Some of the different options.
We have a lot more already.
What we want is:
That it becomes possible to create the bends to be handled manually during assembly, and having custom configurations in one and the same file.
The actual bends act like "hinges" and bend automatically when we constrain the surfaces.
This must not affect original file, nor make a new file; just a presentation in an assembly.
1: Make the part configurable with bendinglines predefined at .ipt, and making the bend angle adjustable.
(example. 60° and 30°)
2: And also make it flexible with respect to constraining surfaces to each other, in the same way flexible assemblies are functioning today.
Adaptivity might not be the right expression or LOD eather.
What you need too is flexible part that shape is defined on assembly. Original part shape should not be changed (somebody has to manufacture the part too) and you should be able to use the SAME PART on many assemblies on "custom" shapes.
"Flexibility" is for situations where the alternate states of a Part do NOT need to be recorded or documented -- generally things like springs, o-rings, bendable parts, etc., which can deform to any number of shapes or sizes but which have no need to be documented or drawn in that sate -- only depicted that way in an assembly. It's ideal for when there's an "infinite" number of deformed states and you would never need or attempt to document them all manually, you just want them to look right in the Assemblies they show up in.
"Adaptivity" is for situations where the alternate states DO need to be recorded or documented. In relation to configurations (i.e. Part LOD), these alternate states could be: (A) Unique parts with different Part Numbers, or (B) The same Part with the same Part Number but in different deformed states. Adaptivity is needed in configurations when the differences between those configurations (whether unique Part Numbers or deformed states of the same Part Number) cannot be pre-determined at the Part level but instead depend on surrounding context at the Assembly level (in other words, the same circumstances which warrant using Adaptivity for normal Parts).
@Halvor.johnsen.kverneland's application, as he described it, is a perfect use for Flexibility, since he said the deformation "must not affect the original file", as it's only for "presentation in an assembly".
Halvor, I'm very glad you posted this, because it's a great example of combined configuration+adaptivity/flexibility workflows. In fact, I already shouted out your idea on the Beta forum and said as much. I would definitely second Curtis's suggestion for you to consider joining the discussion there.
Meanwhile, here a a couple of related links here in the Ideas forum:
Essentially this amounts to occurrence level parameters (a bit like Revit instance parameters ) which inventor doesn't do, but it would be awesome if it did!
Much appreciated for your feedback, I like the idea and the case. Second to Curtis's suggestion, if you haven't join Inventor beta before, please join the Beta program, and exchange your ideas with development team.
Much appreciated for your feedback, I like the idea and the case. Second to Curtis's suggestion, if you haven't join Inventor beta before, please join the Beta program, and exchange your ideas with development team.