Make file references bi-directional (allow Parts to know about their Parents)

[DRoam]

Have you ever wanted to…

• Put the Item # and Quantity of a Part on its own Detail drawing?
• Make Item #'s be consistent throughout drawings where the same parts appear in more than one assembly?
• Find out quickly where a Part is used (which Drawings and Assemblies contain it)?
• Rename or move a Part without its parent Drawings/Assemblies losing reference?

The reason none of these are possible is that “child” files (such as Parts) do not know ALL of the relevant information about themselves. While most information about a Part is stored in the Part itself (geometry, material, Part Number, Description, etc.), some crucial information is only known at the assembly level, such as:

• Its Parent assemblies (and their location)
• Its Item # in its parent assemblies
• Its Quantity in its parent assemblies

We need a way for Parts to be able to check “upstream” in order to find out assembly-level information about themselves.

The solution: File references should be bi-directional, such that both the parent AND the child are aware of the relationship.

This would allow the child to:

1. “Find” the parent
2. “Ask” the parent for upstream information about itself (such as Item # and quantity)
3. “Inform” the parent about changes to itself (such as location or filename).

Basically, with a new upstream-reference capability, we could do all of the things I listed at the top, and more.

[DRoam]

In a little more detail, adding upstream-references would empower these capabilities:

File management capabilities:

• Quickly find out where a Part (or other Child file) is used, without having to use the Design Assistant.
• Rename or move Parts directly from the Part itself, without having to use Design Assistant
• Replace all references of a Part in all Assemblies with another Part file, without having to use Design Assistant

Administrative capabilities:

• Quickly determine the quantity of a Part (in each assembly or total) right from the Part itself

Drawing-side capabilities:

• Display the “Item #” and “Quantity” for a Part (pulled from a selected Parent assembly and selected BOM structure) on its Detail drawing
• In a given assembly’s BOM, tell it to pull the Item # for applicable parts from a specific higher-level or other sub-assembly which also contains those parts. This way the “Item #” property can be consistent across drawings where the same part appears in more than one assembly.

I talked mostly about Parts when describing this Idea, but this new “upstream references” functionality would work in all file types, and would essentially turn Inventor datasets into a “web” of interconnected files rather than a long, one-way street where only upstream components know about downstream components but not vice versa. Resolving file link references would dynamically work on both sides of the link and not just one.

One side-note: The Drawing-side functionality described above (accessing a Part’s Item # and Quantity from a specific Parent assembly) could be achieved without this “upstream reference” functionality by simply adding the ability for the user to manually choose a parent file to pull that information from, whether in a text box or a Parts List. However, there are several very beneficial, very powerful file-management capabilities gained by implementing the upstream reference functionality, and doing so would make the Drawing-side functionalities much more streamlined and stable at the same time.

[machiel.veldkamp]

So..... Like the Where-used in Autodesk Vault?

[DRoam]

Exactly like that  except it's a very functional solution for those who don't use Vault.

It mimics the fact that Vault keeps an "index" of all file references. Except rather than keeping a centralized index of file relationships, every file just "knows" each of its immediate references (upstream and downstream), and those links can be traced in either direction to quickly find and manage file relationships (and, as an added bonus, make assembly-level information available to Parts and sub-assemblies).

[swalton]

Droam,

It seems this requested functionality will dirty a file every time it is used in a new parent.  What happens with hardware/library parts?  If I have a 1/2-13 x 4" hhcs used in 3000 different assemblies, does that part file have 3000 "where used" entries?  How about Content Center parts that are read-only?  Vault files that are not checked out to the user?

What happens when corporate IT decides to change all the paths from my workstation to the central CAD data directories? 

If I use Windows Explorer to move or rename files, what will correct the where-used list?  What about a stand-alone application that understands the Inventor file structure and can correct any issues...

[dba78]

Hi, 

I guess that's what is Vault for. I personally think, you should not Work with Inventor w/o Vault (at least not in a team). Vault gives you much more than reference handling even in the Basic version... 

As @swalton sais, parts can get more "reference data" as model data over time.... and if you put this ipt/iam in another environment (copy and paste in another project....) it gets chaos only...

[Curtis_Waguespack]

Vault does this using the SQL database to keep track of all of this.

What Inventor users want is a database tied to Inventor that does not require all of the check in and check out, etc.

If there was a simple non-vault database tied to Inventor, then I think "Where Used" and "Copy Design" and "Rename" would be doable. Where used would not smudge the Inventor files, but instead the database.

All  of those utilities would just run through the database to find referenced or referencing files, and in the case of renaming or copy design the files would be "cracked open" and updated.

So imagine a new "Design Assistant" that ran off a database, rather that using Windows search, I think this is really what is being discussed here. This database could likely be cloud based and use the A360 platform as well.

[dba78]

So you are actually talking about a Vault with no check in, Check out, right?
And you want to dismiss the server-client relationship for the Files too.
The Files shall remain online while working on them and you want to rely on the Filesystem security for exclusive write permission....
That does not seem reasonable for me...
I think,  there is a good reason for the Vault being as it is....
Anyhow,  it's just my personal opinion.
BR,  Daniel


⁣Gesendet mit TypeApp ​

[dba78]

So you are actually talking about a Vault with no check in, Check out, right?
And you want to dismiss the server-client relationship for the Files too.
The Files shall remain online while working on them and you want to rely on the Filesystem security for exclusive write permission....
That does not seem reasonable for me...
I think,  there is a good reason for the Vault being as it is....
Anyhow,  it's just my personal opinion.
BR,  Daniel


⁣Gesendet mit TypeApp ​

[Curtis_Waguespack]

>> So you are actually talking about a Vault with no check in, Check out, right?

No, not at all. I'm talking about Inventor being tied to a database to manage where used, copy design, and renaming. That is all.

Then non-vault users would be able to have those functions. The subject idea was "Make file references bi-directional (allow Parts to know about their Parents)", a database is how Vault does this. And a database would be the best way to do for users who do not use Vault.

If vault is being used, then this idea could be accomplished by using the Vault database to read parent info, etc. Although I don't think Inventor's Vault add-in allows this or does this currently.

[dba78]

Okay, then you are talking about a Vault w/o a filestore?

If I get this right, you mean, there should be a DB maintaining File references and all those copy/rename functions shall use this DB, while keeping the files on the filesystem...

The problem with this approach is, it's just too easy to break the references, since the user is able to move, rename, delete files directly over Filesystem. Or shall be a FS-Watcher implemented too? You cannot rely on a DB, which has no control over file manipulation.

On the other side, a DB, which keeps track by free string search(filenames) and then needs to look at the FS, whether the files are there, or not, can be very inefficient.... In fact, I believe this solution could not be better, then the actual Project-based Design assistant, since you still needed to search the FS for existence of the reference, and then check the assemblies/drawings of their content (again, you could manipulate files outside of Inventor/DB as storing them on the "public" filestore)...

What about renaming a server, or moving data (partially) to a new server? You would have to restore all file references in the DB...

And there are so many pitfalls, I don't even think about....

That's why Vault has an own filestore with it's own storing logic (at least this is one aspect) and the user communicates over the DB only... Sure, since the Vault DB and files can be accessed by users simultaneously (this is also one the core desires of Vault), there is a need to ensure exclusive write permission (you don't want users to overwrite each others work, right?) -> Check in/check out... ALL EDM/PDM-s use this mechanism in some way (AFAIK), and I don't think there was a better approach.

My personal opinion: use the Vault and you are safe by having all the desired functionality for maintaining references (and additionally versioning, backup, permission management, etc...) I suggest all our clients to use the Vault with Inventor (or more general: use some EDM/PDM System when working with 3D-Modeling...  Else you get a mess sooner or later, for sure)

And... if a Vault is being used, then this topic is not relevant.... you have all in your hand. If you don't want to use the Vault Explorer, you can use an own Addin... Did not too much in the field yet, but I believe the Vault API gives you access to copy/rename functionality by maintaining references...

BR,

Daniel

[Curtis_Waguespack]

>> The problem with this approach is, it's just too easy to break the references...

I would imagine the database would just check the file names & paths as alert the user that an update is needed, and the user would then run the update from within Inventor.

>> What about renaming a server, or moving data (partially) to a new server?...

Same as above, then the database addin would detect the out of date status and prompt the user to run an update?

>> ...you don't want users to overwrite each others work, right?

There are many users who work in environments as single users, or as part of team that does not work concurrently. In these cases the extra overhead of all of this is intrusive. Of course uses who work collaborate concurrently should be using the check-in/out protections of Vault.

>> And... if a Vault is being used, then this topic is not relevant.... 

Vault is aware of parent child relationships, but Inventor is still not. And therefore the BOM & parts list functionality that DRoam is requesting is currently not available even in a vaulted setup.

>> My personal opinion: use the Vault...

Yep, you've made that clear.

I don't see this idea as a Vault vs No Vault issue, but I think it would require something that would work from within Inventor. That could be some update to Inventor's Vault add in to work with the Vault database, but I think it would be the outstanding if it worked for non-vault situations as well.

[dba78]

Hello,

I don't see this as a pro/contra Vault topic too. And I'm not propagating the Vault here - why would I...?

My point is:

to realize this idea in a feasible way, you actually recreate the Vault w/o Filestore... And exactly this point would make the database vulnerable, not to say impossible to work clean.

- you'd have to monitor all files maintained by this DB realtime for renaming/moving (even through a network infrastructure), whatever outside the inventor environment. Just because it's possible!

- you'd have to search DB by freetext-strings with any length

That's it.... I just refer to the Vault, because this is the solution ADSK provides for such tasks (and the Design Assistant of course for offline users)

About the parent-aware BOM... A part can be used in many Assemblies, how to decide, from which the information should come....?

This info can't exist in the part, since he part itself is not determined to be in any Assembly by nature....

However, a simple Addin for Manipulating iProps on inserting the part in the Assy,  can store the required info in the part. But this seems to be a too specific requirement for me to be a general idea for inventor.

BTW, you surely can obtain these informations via the Vault API 

BR, 

Daniel

[DRoam]

Thanks for all of the dissection and critique of this idea. Hopefully it will help the Inventor team come up with a great solution that, whether or not it looks exactly like what I or anyone else proposed, proves to be a solution to the basic needs discussed.

Just came here to point out a related idea: Indicate Drawing Available. This is something else that a bi-directional link, or database manager, or some other file-link-management solution would enable: determining which components in your Assembly or Project already have a drawing, and which still need one.

[Anonymous]

This is a great Idea that's been a long time coming.

I've had to search the forums for possible iLogic codes that will update each assembly/sub-assembly/part with a "total quantity required". I've only found one to work, but it still has errors with sub-assemblies and some part files. So I have to manually update/multiply individual sub-assembly/part quantities to display correctly on drawings.

I typically work for myself, or by myself at different companies. I work in the construction field at the shop fabrication level. My drawing sets sometimes have to be sent off for approval and I like to make my drawings easy to see where assemblies/parts not only live, but also what assembly/sub-assembly is referring to a assembly/sub-assembly/part at the bottom level. I typically work from the Top-Down approach where I start with an "Erection Assembly" drawing (if applicable) for a particular are of a project. Inside this assembly, all of the subsequent assemblies/sub-assemblies/parts will live. Each assembly/sub-assembly/part has a dedicated drawing with a "Total Quantity Required" note. Sometimes there are more than one quantity required for this main "Erection Assembly" and as such, each assembly/sub-assembly/part quantity required is updated to reflect the total required on each drawing.

Having something inside Inventor that will not only update total quantities required for each assembly/sub-assembly/part inside a particular project, but will also keep track of what higher-level assembly/sub-assembly any particular assembly/sub-assembly/part lives in will benefit myself and others to no end. Not only will it add to my productivity by not having to manually update things, but it will also help when there are changes. And as an added benefit, I can make notes on drawings that specify which assembly(ies)/sub-assembly(ies) each assembly/sub-assembly/part exists in, and also their respective quantities. This helps then end users in the shop who only get to see the drawings and anyone else who is responsible for double-checking your work.

I'd like to add that it would also be beneficial to have the ability to show in the "Parts List" (on a drawing) either the per-assembly part/sub-assembly quantity, or the total part/sub-assembly quantity, or both. e.g. Assembly A1001 (1 quantity required) has two parts; part P1001 and P1002 with a per-assembly quantity of "1 REQ" and "2 REQ", respectively. Changing A1001 quantity to "5 REQ", would result in the per-assembly part quantity still remaining as "1 REQ" and "2 REQ", but the total part quantity required would change to "5 REQ" and "10 REQ".

As far as the issues Daniel Balogh pointed to, I think it would work similar to the current way of updating referenced/derived parts/assemblies per project. That is to say, when you open up an assembly/part that references another file that no longer exists, it gives you the option of replacing the file.

I hope this gets implemented soon.

Thanks,

Eddie

[nicolaken.barozzi]

See CoolOrange Clever, seems to do what you intend.