Pulling a child Part/Assembly from its parent file (factory)

[Anonymous]

Hello,

First off, this is regarding Inventor 2016 Professional.

Background on the issue:

My company has always had issues with factory files (ipart or iassembly).  They have never had the patience to learn why errors come about from them.  When 3D modeling first came into the picture, the engineers that worked here had made about half of all the companies files as factories.  Since then, none of those engineers still work here and the ones that now work here didn't know much at all about factories.  Because of this, if a factory file gives an error, the engineers have made the habit of pulling parts/assemblies from their respective parent factory files.

Example 1:

Open up parent factory file, save as factory file somewhere else, activate member in question, delete table to convert factory to non factory.

Usually the problem with this is that they do this with part components of an assembly.

Example 2:

Open up assembly file, notice one of it's parts (not sub assemblies for this scenario) has an error and that it is also a member of a factory.  So they open the factory file (otherwise referred to as the parent of this part) and follow the process in my first example to convert this member to its own file as a non factory file.  Then they go back to the assembly file where the factory member had an error and they replace that factory member with the non factory equivalent they just made.  Then every single constraint blows up and breaks.

This happens everyday and is incredibly time consuming.  I am fully aware that if you have 2 different files that are exactly alike in every way, replacing them with each other in an assembly will break all constraints every time unless one of those files was created by "save as" or "save copy as" from the other file.

Now here is something interesting that I noticed, in my Example 2... where i said "not sub assemblies for this scenario"... Well if you replay that scenario where the component in question on an assembly is a sub assembly file and convert it to a non factory file via the method in Example 1, then replace the sub assembly factory member with the sub assembly non factory file, NONE OF THE CONSTRAINTS BREAK!

I've made sample files to work through these examples so you can try and see for yourself what I'm talking about if you've never had this experience.  See attached.  This is the first time I've made a post while attaching files for reference.  I've attached the two sample assemblies, one that has a sub assembly factory component and one that uses a part factory component.  Will I need to attach their component files as well?

All in all, I'd like to figure out how to get all of the constraints to not break in Example 2 for part files... like how they don't break for sub assemblies.

[Sofia.Xanthopoulou]

Great post @Anonymous  Thank you!

But in order to be able to test your example you should "Pack and Go" the assembly,  so all the parts are included. Once this is done, we can talk about step 2 

Thank you

[Anonymous]

Oh thats pretty neat! I've heard of that before, but never actually used it myself 🙂

Here are the files.  Will a zip file work?

[mcgyvr]

---

@Anonymous wrote:

All in all, I'd like to figure out how to get all of the constraints to not break in Example 2 for part files... like how they don't break for sub assemblies.

---

Wouldn't it be better to learn to correct the errors/issues you are having with iparts/iassemblies? <--Thats the real problem here..

Learning to use them properly will be better in the long run and you won't have to spend time removing members/reconstraining,etc...

Just learn to use the program.. Don't try to fight it.. It has you in its grasps already.. 

There is really nothing you can do to change it breaking the constraints for many situations..

Its just how the process works.. The edge/face,etc.. names get "changed" and Inventor cannot find them to properly save the constraints..

They have made some progress in past releases to attempt to preserve constraints but they are still not there yet across the board for all situations..

[Anonymous]

Having recently gained some experience of iParts/iAssemblies, I DEFINITELY agree with the above. Just reading your description gives me the shivers... You've really got to know what you're doing with them or chaos ensues. If yours are being pulled apart and misused by multiple people, no wonder there are issues!

I haven't been able to interrogate your data but from my own experience, first guess would be constraints made to faces or features? If a constraint is placed on the face of a part which is present in one member, but which is suppressed (Included or Excluded) in the next, the constraints will lose their reference. I bang on about constraining to planes - and especially top level ones - all the time because they're constant in all members. 

Hope this helps. If I get time I'll try to have a look at your files tomorrow lunch. 

[Anonymous]

---

@mcgyvr wrote:

Wouldn't it be better to learn to correct the errors/issues you are having with iparts/iassemblies? <--Thats the real problem here..

Learning to use them properly will be better in the long run and you won't have to spend time removing members/reconstraining,etc...

Just learn to use the program.. Don't try to fight it.. It has you in its grasps already..  

---

Haha oh I definitely agree.  I guess there was one main thing I left out though.  The other reason they have been pulling the parts from their factories is because they are using them as something to start from for making custom parts.  Most of the time "custom" is just different from standard by one dimension (length, width, depth).  They do custom jobs everyday and if they were to continue adding custom members to the factories, those files will just keep getting larger.

Now that I think about it more, the errors/issues with the ipart/iassembly files is sort of a separate issue.  Even if we fixed all our factory files, the constraints will still break for replacing ipart components with regular part components in an assembly.  A long term solution would be to fix all of the standard assembly files because those are the files they use as something to start from for custom orders and it's those standards that have the ipart files as components... but even that would be a 3+ month project for one person. Our boss sees this as a low priority relative to other projects, so that probably won't happen for awhile.

I'm just frustrated that this is not a problem for iassemblies, yet it is a problem for iparts.  I don't see why it would be a problem for one but not the other? I don't think its a factory problem because iparts and iassemblies are both considered factories.  If it was an issue for one... shouldn't it be an issue for the other as well?  You would think iassemblies would have more issues because assemblies are more complex than parts.  Why would the more complex file type have less issues?

[Anonymous]

---

@Anonymous wrote:

Having recently gained some experience of iParts/iAssemblies, I DEFINITELY agree with the above. Just reading your description gives me the shivers... You've really got to know what you're doing with them or chaos ensues. If yours are being pulled apart and misused by multiple people, no wonder there are issues!

I haven't been able to interrogate your data but from my own experience, first guess would be constraints made to faces or features? If a constraint is placed on the face of a part which is present in one member, but which is suppressed (Included or Excluded) in the next, the constraints will lose their reference. I bang on about constraining to planes - and especially top level ones - all the time because they're constant in all members. 

---

This is exactly the case.  A lot of the previous engineers did not know the proper way to use and modify the factory files.  The biggest thing was that nobody knew about the "Edit Factory Scope" and "Edit Member Scope" settings.  Inventor defaults to "Edit Factory Scope" and most of the time the engineers thought they were editing only the active member...  

I've been writing button macros in VBA to help make some processes easier and recently I've been writing add-ins.  The first add-in I wrote was to switch the setting to "Edit Member Scope" upon opening a factory file.  Which is at least a start to preventing errors in the future.

As for constraining to planes... that is a perfect solution.  The other engineers now know this, but the previous engineers had really bad and inconsistent constraining habits and thus the constraints seem pretty random in our standard assembly files 😞

[Anonymous]

Out of interest, how many parts/assemblies does this affect? 

You make an interesting point about using iParts/assemblies as a starting point, as that's what we plan to do. The task I'm currently working on involves a set of 33 assemblies that are all variations of the same thing; motor mounts that fasten to a machine. There's a back plate, a cover and a tensioner plus fasteners. Each can be made in mild/paint, mild/galv. or stainless. We use these all the time. Currently they're modelled as individual assemblies and there are some issues re. control of material/finish I won't go into here. 

I've set up a top level iAssembly which produces all the combinations as members. Now this is done, users place the top level iAssembly in their assembly and are given options as to which member they want to use. Material: correct, finish: correct, part numbers: correct... Our intention is that unless a change is requested that will affect ALL variants, these will now be left untouched. Standard parts. 

If someone needs a 'special', they do a Save As on the factory and break the link as you described earlier, which is a perfectly acceptable thing to do. Crucially, this new assembly is now it's own entity - A NEW AND DIFFERENT ASSEMBLY with a new and different part number. It's not used to fix something and doesn't get slotted back into where it came from. 

I think you're right: you have two problems. I think you need to a. slowly start tackling the issue of fixing the iStuff and b. reprimand users for substituting as a fix and encourage better practices. Hopefully everyone working on achieving a. will make b. easier! 

[Anonymous]

I know it's been awhile since I've posted in this thread, but I think I'm on to a new solution for this.  My old solution was a macro that did the following:

1) The user selects a factory component in an assembly and runs the macro

2) The macro then checks all the constraints related to that factory component and remembers that information to recreate later on (information being the selected faces/edges/points etc)

3) The macro then opens up that component's factory parent file and breaks the component from the table (thus creating a nonfactory identical part file)

4) Then the factory component gets replaced by the identical nonfactory component that the macro created.  All the constraints get broken.

5) All the broken constraints get deleted.

6) The macro recreates all the constraints by referencing the remembered information from step 2)

This has worked out quite nicely.  But I've stumbled upon something very interesting lately.  We have one part in our system that has 2 different part files (8432-0247 is the shared part number).  One is a factory part, the other is a nonfactory part.  The models have the exact same geometry.  My original goal was to get rid of the factory part by replacing it with the nonfactory version in all assemblies it shows up on.  When I replaced the factory part with the nonfactory version in assembly 8434-0705, I had expected all constraints to break... but instead they were all fine and none were broken!  My problem is that I cannot figure out how this is working.  I've tried to recreate the nonfactory identical part multiple different ways, but no matter how I create it... replacing the factory with my newly made nonfactory part keeps breaking the constraints.

The attached zip file contains the assembly 8434-0705 and all of its components.  It is assembled with the factory part 8432-0247.  The separate folder inside this zip file contains the 8432-0247 nonfactory part.  Maybe someone else can figure out how replacing factory 8432-0247 inside assembly 8434-0705 with nonfactory 8432-0247 does not break the constraints.

One last note:  The nonfactory file seems to have been derived from the factory file and then the link was broken.  I tried making a nonfactory part this way, but replacing the factory ended up breaking the constraints.

All I want to do is make a nonfactory part file with the exact same geometry as a factory file and use that nonfactory part in all my assemblies instead of the factory part.  And then not have to fix all the constraints.  I know it's possible because I have proof now.  It's attached.  Check it out.

[johnsonshiue]

Hi! If the constraints are iMates, replacing components will not lead to loss of geometric reference. As long as the replacing component has the same iMates as the replaced component, the constraints will survive.

Many thanks!

[Anonymous]

That's good to know.  I'd like to set up more parts/assemblies with imates, but as it stands now... only about 5% of our parts/assemblies use imates because no engineers at my company before myself knew how to utilize them.  So sadly, it would probably take longer to set those up rather than just fixing the broken constraints right now.

[Anonymous]

Wait, are you saying that if my factory component and non factory component have the same imates... I can replace them with each other in assemblies without losing constraints?

[Anonymous]

Nevermind that didn't work.  I opened my factory component, put 3 imates on 3 specific faces.  Then opened my nonfactory component and put 3 imates on the same 3 faces.  Replacing them with each other still broke all constraints.

[johnsonshiue]

Hi! It should work. I don't understand why it fails. It is probably a bug or the iMates were not set up properly. Please share an example here. I can take a look and see where the problem is.

Many thanks!

[Anonymous]

Do the imates on the components have to link up to some other imates on the assembly?  Because I literally just had imates on the one part in the assembly.  I've attached the files. 9515-0646 is the assembly. 9512-1169 is the factory component.  DPLT is the nonfactory component.

[johnsonshiue]

Hi! I took a look at the assembly. Indeed, 9512-1169.ipt has iMates and DPLT also has iMates. But, the iMates are not matched to any iMate in other components. As a result, the constraints still fall on replacing component.

You need to match iMates so that the constraints are established by iMate matches. When the component A with matched iMates can be replaced with component B with the same iMates.

Many thanks!

[Anonymous]

Gotcha that's what I thought.  We don't have many imates setup yet.  So for each assembly that these factory components are on, we would have to setup imates on the factory component and then somewhere in the assembly (or on another one of its components) to match.  Choosing to just fix the constraints is usually faster.  

I was just hoping someone might have some insight on my post a few days ago where I was able to replace a factory component with a nonfactory component while retaining all the constraints without the use of imates.  I do know that each face/edge/point gets an ID assigned to them by inventor and those IDs are referenced by constraints.  When you do a save as or save copy as on a part, those IDs are maintained and that's why the constraints won't break when replacing them with each other in an assembly.  But usually when converting a factory to a nonfactory by deleting the factory table, all the IDs get reassigned to different values and that's why constraints usually break when replacing a factory with a nonfactory in an assembly even though their geometries are identical in every way.  

BUT somehow, I found a factory and nonfactory with identical geometry AND face/edge/point ID numbers (proven by constraints not breaking).  I just wanted to figure out how to reproduce that result.