Announcements
Attention for Customers without Multi-Factor Authentication or Single Sign-On - OTP Verification rolls out April 2025. Read all about it here.
AlexFielder
in reply to: Anonymous

Hi @Anonymous,

Thanks for the detailed explanation and code sample.

 

I can see now why you want to remove unresolved components. I agree that if it's going to cause the exported BOM process to fail then you'd be correct to remove them.

 

BUT (And it's a big but!), it would seem to me to be a better question/solution if you were able to address why you are seeing unresolved components.

 

Typical reasons for this are (and I'm sure someone else will add to this list if I miss anything):

  1. Assemblies not saved in consistent network paths i.e. some users have Z:\path\to\assembly whereas others may have \\servername\zdriveroot\path\to\assembly or a mixture of both.
  2. Users creating assemblies locally on C: and not sharing all files.
  3. Users creating assemblies locally and not using/being aware of "Pack & Go" to grab all referenced files.
  4. (and by no means least) users working on assemblies locally and not setting the correct project file.
  5. Inconsistent naming of part files (user A creates a new part called "widget", user then creates another part called "widget" using a different project file and (after sharing the assembly) when a different user opens the assembly they get prompted as to which they want to use and choose neither.

So really this boils down to:

 

a) Do you use Vault? All versions provide unique naming checks which can prevent users checking in multiple parts called "widget" or whatever. Vault also allows enforcement of a common project file for all users.

b) Are your team trained sufficiently that they're aware of the company's unique naming/path conventions?

c) Is any of ^ documented (for new/existing users)?

 

Since you're here and asking for help on this, there are steps you can take whilst you get a thru c above sorted out.

 

The first of which would be put together (or update) a document showing what is stored where on your network as well as the reason for it's importance in getting paths correct (point them to this post if necessary).

 

Second, I would think about changing your iLogic rule above such that when it finds an unresolved file to flag to the user the points I noted above, such that they can set the correct project file, check they received a complete pack & go and/or are using the correct file paths etc. etc.

 

Third, if you have users (even especially those who are self-taught!) who haven't been trained (or trained recently) I would heartily recommend you seek out the services of your local Autodesk reseller who will be more than happy to help.

 

Full disclosure: I work for a reseller here in the UK, so have trained Inventor users on both the main product, as well as iLogic in the past and the unresolved file problem typically stems from the issues I touched on above.

 

Apologies for the wall of text, but I hope it gives you food for thought.

 

Cheers,

 

Alex.