Community
Inventor Forum
Welcome to Autodesk’s Inventor Forums. Share your knowledge, ask questions, and explore popular Inventor topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

iParts losing constraints after update to parent

36 REPLIES 36
Reply
Message 1 of 37
karthur1
723 Views, 36 Replies

iParts losing constraints after update to parent

I stumbled upon a problem with iparts losing their constraints back in January, 2010.  The issue is that if the parent ipart is changedor update and the children are "regenerated", the assembly constraints will fail.  This defect crept in with R2010 and has basically crippled my fasteners library.  Smiley Mad  I cant add to or make any corrections to my ipart parent file. This defect is being tracked by Autodesk with numbers 1260490 and 1300828.

 

AD did release a hotfix for 2011, but this doesnt help with ipart files that already have the children created (DL15973874).

 

The only way to fix the issue is to re-generate the children to the current release and then fix the assembly constraints.  Only trouble with that is these are fasteners we are talking about.  This would take months to do and is not practical.

 

When we migrated from 2010 to 2011, there was a special person at AD that was able to migrate my files so I wouldnt lose the constraints.  He is no longer in the same department, so I'm not exactly sure how I'm going to handle the move to 2012 yet. Havent seen many posts about this.  Thats either because a. you dont use iparts, b. you dont know there is a very serious defect with your files, or c. You havent had the problem yet.

 

Guess what I am wanting is to know how others are handling this.  I could leave all the iparts alone, then rebuild them under totally new names for 2012.  Thats a lot of work and I really dont like the idea of having two libraries to maintain.

36 REPLIES 36
Message 21 of 37
Doug_DuPont
in reply to: karthur1

You are correct. We have set up a new drive on our network and can open their assemblies with no constrain problems. We are trying to not have to 2 different libraries of iparts. We also did not want to store them on different drives making it that much harder to find things. We don't use Vault and some people hear don't want to go that way. I know Vault will not fix the constrain problem and not sure if it would help with our network issues. But that's a different problem.

I think that we will need to bite the bullet hirer some kid to go thought all the assemblies and reconstrain. We are talking many thousands of constrains.

Can some one give me a fast procedure to do this?

Douglas DuPont
Inventor 2016 Pro, Vault 2016 Pro
Quadro M4000
Windows 10 64 Bit
Message 22 of 37
karthur1
in reply to: Doug_DuPont

Dont think there is a "fast" procedure. Regenerate all the members and go at it.  If you were using vault, you could at least see "where" the parts were used.  We use vault and I would not use Inventor without it.... but thats your decision.

 

If you do bite the bullet and correct all the assemblies, just make sure that you use the member generated with 2012.  I would do a small scale test first, before you jump in head first. Then, hopefully you want have this problem again.

 

I was po'd when I ran across this issue because of all the time and effort that we had placed in iparts. I could not tell you how much time this has costed my company.  I had four guys for a week just fixing constraints.

Message 23 of 37
Doug_DuPont
in reply to: karthur1

I have another question. We don't use the content center very much. What if we asked our overseas partner to use content center screws and not Iparts? It might be to late to go that way for them but it might help us here.

Douglas DuPont
Inventor 2016 Pro, Vault 2016 Pro
Quadro M4000
Windows 10 64 Bit
Message 24 of 37
karthur1
in reply to: Doug_DuPont

I have myself considered using the CC instead of iparts, especially for fasteners. I my case, I would still have to create a custom library (or convert my iparts).  Like you, I didnt want to have two things to manage, so I stuck with iparts. The reason that I would have to make a custom library was because of the information that I had to have in my parts list for the fasteners (p/n and description mainly). Not sure of what information you need.

 

If I was starting from scratch today, I would probably opt for custom CC parts for all fasteners.

 

If they send you an iam without the CC fasteners that they used, I think you would have Resolve Link errors when you opened the iam. If you already have the CC member on disk, I'm not sure if the constraint will hold or not.  Someone else might tell you that or maybe you could test this before you decide to go that route.

Message 25 of 37
Leo.Xie
in reply to: Doug_DuPont

You are right. You should encounter such issue since 2010.

 

 “Inventor R10” is the version that the iPart factory is created. For these old iParts, the generated members may have different internal identifies over multiple releases. This is the reason that the constraints lost. But this potential issue did not appear until Inventor 2010. It is triggered after added some new functions in Inventor 2010.  The iPart factory that created after R10 should not have such issue.

 

Best regards.



Leo Xie (Lichao.xie@autodesk.com)
Software Engineer, Inventor
Manufacturing Group
Autodesk, Inc.

Message 26 of 37
CNiemarkt
in reply to: Leo.Xie

I have been reading these post with great interest but only a couple of years to late. We are now having the exact same problem I found out last week. Incredible what a mess.

 

We are in the middle of migrating/converting our excisting files to get them into the Vault. Our reseller had tested our iParts upfront (because we had issues before which I now understand at last) and did not find anything wrong with using them in the Vault. But now that we finally have everything set up we just found out this juge problem. We are talking about thousands&thousands of constraints!

 

I know this is a longshot but has anything changed in the meanwhile?

 

Is fixing the constraints by the way enough to solve the problem? Do you not have problems with the attached 2D drawings also? I have seen in the past that leaders for BOM also have to be reconnected which is even a bigger nightmare because also the Partlist itself has te be reorganized (numbers are added for the unresolved parts).

 

Thanks,

Christian

Message 27 of 37
karthur1
in reply to: CNiemarkt

Christian,

I feel you.... The only way to fix this is to generate all your ipart children on either pre or post 2010.  When they are mixed up is when you have constraint errors. Once they are all the same version, you can then migrate them forward.  If you don't fix this now, then whenever you "change component" and replace an "old" one with a "new" one, the constraint will fail.

 

Their workaround is this (from Leo's post):

"...., a workaround for your reported issue is to delete the generated member file from disc before you generate the new members, then generate the members by “Change Component “command. This needs the hot fix for Inventor 2011. And Inventor 2012 has included this fix too."

 

Not sure about the other things you brought up about the idws.  That might be an issue as well.

 

BTW, the problem has nothing to do with Vault.  It is because they (AD) made a change to something internal to the parts.

 

Kirk

 

Message 28 of 37
CNiemarkt
in reply to: karthur1

Thanks Kirk,

You are right it is an Inventor problem, but it's the way how Vault is handling files that is giving us the issue.

 

In the past before IV2010 we had generated already all our members (because of the problems described in this post I now finally understand what the problem was at that time). These members and belonging factories are now in the Vault.

 

But if the members are not available on the local harddrive and for example we make a new assembly, add an iPart by selecting the factory, then Vault does not recognize that the member is excisting on the Vault server. After that Inventor generates a new local meber wich is then not exactly the same as the original on the server.

If the members are existing on the local harddrive, then the above does not happen. Vault recognizes the local member perfectly.

 

I have understood that Vault first searches for a file by looking at the filename on the local harddrive, if this fails then Vault starts to search on the server but then not by "filename" but by "Member Name". Because of the issue with the old iParts this "Member Name" is not found and therefore a new member is generated locally (with the correct member name). The difference in Member Name is then causing that 2 members are not exactly the same and that's the reason that constraints are failing I have understood.

 

Regards,

Christian

Message 29 of 37
karthur1
in reply to: CNiemarkt


@CNiemarkt wrote:

...

But if the members are not available on the local harddrive and for example we make a new assembly, add an iPart by selecting the factory, then Vault does not recognize that the member is excisting on the Vault server. After that Inventor generates a new local meber wich is then not exactly the same as the original on the server.

If the members are existing on the local harddrive, then the above does not happen. Vault recognizes the local member perfectly.

...

 


Thats NOT how it works. When you place a ipart child, Vault will check to see if it already exists. If it does exist in Vault, then it downloads the file and places it in your workspace.  If it is not in Vault (or you aer not logged into Vault), then it will generate a new member.

You can check to see if its creating a new member or using whats already generated by looking at the modified date from Windows Explorer.  If its creating the file new, WE will show the date/time when you placed it.  If its d/l it from Vault, then it will have an earlier date.  Also, if its recreating a member that already exists in Vault, then from Vault Explorer, you should see a Green dot on the file status (means its been edited out of turn).

 

Kirk

Message 30 of 37
CNiemarkt
in reply to: karthur1

Kirk,
Not sure if we are talking about exact the same thing (could be my misunderstanding).
But we absolutely see a difference in behavior if the member is available on the local harddrive or not. The way that Vault searches for files have been explained by our reseller (this is not something I dreamed up myself).
Like I described if the member is available locally there is no problem (please remember that ALL members have been generated in the past).
If the member is not available locally then Vault fails to recognize that the member is existing in the Vault. As a result a new member is generated -> Like you explained: We also see in WE that this has a new date/time. You also see in the Vault the message "edited out of turn" (or something like that). This new member is not interchangeable with the old member.

For your info I have added a screenshot from an old and new iPart (most likely you already are aware about these internal differences)

Christian

Message 31 of 37
karthur1
in reply to: CNiemarkt

What I described is how it works in Vault Basic 2014.  What Vault version are you using?

Message 32 of 37
CNiemarkt
in reply to: karthur1

Vault Pro 2013. Is there a difference in approach then?

Message 33 of 37
karthur1
in reply to: CNiemarkt

We only use the Basic version here.  I have one machine with Vault Explorer 2012 still on it.  I just tested it and it functions exactly like I described for 2014.

 

There might be a difference in this between Pro and Basic... Since I dont use Pro, I could not answer that.

 

It has GOT to know that the child already exists even if it is not local. 

 

You might want to start a new thread in the Vault forum and ask about this. Let me know if you do, I would like to follow that thread.

Message 34 of 37
CNiemarkt
in reply to: karthur1

Yes, that is what is causing the issue. Vault is not able to recognize that the Member is available on the Vault server.

 

Out of curiousity: Does the basic version also works with a local workspace (stored on the computer of the user) like with Pro? Or do you directly work on a server location?

 

If I will post a new thread I will let you know.

Thanks for the help.

 

Christian

Message 35 of 37
karthur1
in reply to: CNiemarkt

Yes, Vault Basic works with a local workspace like Pro.

 

http://www.autodesk.com/products/autodesk-vault-family/compare

 

I think you have your workspace mapped correctly, but check this.  from Vault explorer, go to one of your iPart children.  Right click and select "Go to Workspace".  Does that take you to where you expect this file to be on your HD?

Message 36 of 37
CNiemarkt
in reply to: karthur1

Yes it does go to the expected location.

Christian

Message 37 of 37
CNiemarkt
in reply to: karthur1

Problem solved!

Not sure if there are more people with the same problem as we were facing, but our reseller/Autodesk have found out that our problem is fixed with Vault SP1, update 2. When I have more details about what fixed the problem I will post it here.

 

Christian

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report