Copy Object (Skeletal Modeling)

[bradeneuropeArthur]

Hi,

Why is  the "Copy Object" feature not included in the Description given in the Help file of Skeletal Modeling in Inventor?

Is there any good reason for that to avoid that?

Regards,

[johnsonshiue]

Hi Arthur,

I personally think the terms Top-Down, Bottom-Ip, and Mid-Out in modeling are confusing to me. In reality, any modeling approach is usually situational. It depends on what you are trying to do and there should be a more suitable workflow facilitating the process.

In theory, Copy Object isn't part of "Top-Down" approach. It is more like leveraging in-context geometry, very similar to Adaptive. "Top-Down" implies that something higher up drives changes downward. Adaptive or Copy Object basically pick up enough geometry within the assembly to create geometry within the assembly.

The so-called Top-Down is that you have a driver part. This part dictates the critical dimensions of other parts. They can all reside in one assembly or they can reside in different assemblies.

Many thanks!

[Frederick_Law]

Well the help did not include most features: extrude, sheet metal, revolve, sketch etc.

Does that mean you are not supposed to use them?

No!

This is an overall workflow, not a step by step procedure.

It can adapt to any way you want to design.

I usually design backward.  Start with the finish parts, go back to raw material and fixture.

[bradeneuropeArthur]

Hi @johnsonshiue @Frederick_Law 

Since we are using Vault Professional we have huge issues with skeletal modeling. Because we now know that we need to be careful and handle these files with care we are searching for a work-able workflow for our designs. Because I think the Autodesk team has left the "Copy Object" left out/behind may have a  major reason, I would like to know what that is. I can imagine that, because the Autodesk Team and resellers and experienced users always tell that assembly-part adaptivity should be avoided/minimized, I also can imagine that the "Copy Object" is left out/behind.

I am an advocate if we are talking about the features that can be used, and I am willing to do that. But if we are talking about Vault-pro with a release process in combination with Inventor I am very reserved of using them all because of issues.

Any further comments are very welcome.

[Frederick_Law]

What kind of problem do you have with Skeleton Modeling?

I used Vault once and did have any problem.

Of course, Master Skeleton require different file management then "normal" modeling.

Since every file is linked to Master, a change in Master will cause change to every linked file.

Copying a whole or partial MS project to make a new one is another challenge.

What do you want to do with "Copy Object"?

[bradeneuropeArthur]

@Frederick_Law 

Thank you for your reply.

This is exact our problem too. We need to update manually all related file to the Master Skeletal Design, with their related drawings. This happens day after day, because of manufacturing issues!

This a time-consuming job with Vault Pro and a Mono drawing system with released files.

How do you handle this basically?

All files related are set to Work In Progress again when the Master skeletal needs to be changed.

What basics are you using for Skeletal modeling?

Are you deriving from one and the same skeletal or are you splitting things up to avoid a bunch of updates?

Regards,

[Frederick_Law]

I don't use WIP.  Usually work in small company.

So I don't know how MS affect Vault.

I try to split into sketches in the MS for different section or sub-assembly or parts.

You could also split into different Masters.  This also help to split project up for different teams.

I the part, I only insert the sketch I need for the part, not the whole MS.

This could reduce the chance of everything getting "dirty".

You might need to make a simple assembly to test how Vault will react.

[bradeneuropeArthur]

Hi @Frederick_Law 

I don't understand your answer then!

"What kind of problem do you have with Skeleton Modeling?

I used Vault once and did have any problem.

Did you use Vault Professional with a release process or not. Otherwise we can not compare your and my story.

Of course, Master Skeleton require different file management then "normal" modeling.

Since every file is linked to Master, a change in Master will cause change to every linked file.

Copying a whole or partial MS project to make a new one is another challenge.

Since you don't use Vault there is no issue. We have also no issues if we have all files write-able and not released.

What do you want to do with "Copy Object"?

To avoid unwanted unnecessary updates because these references are not seen within Vault

[Frederick_Law]

No, I never used any released process.

So, I cannot give you a working solution.

I can only make suggestions.

Johnson should be able to help.

Another suggestion.

The link to Master can be suppressed in part.  This might avoid change in part.

It also create problem when you do want to change the part.

[johnsonshiue]

Hi Arthur,

Let me chime in here. This is a big topic. I don't have all the answers but I try my best. "Skeletal modeling", the way I understood it, is that you use an assembly or a part to lay down the critical dimensions, parameters, and geometry (sketch, surface, or solid). This skeletal component drives changes in other components. The change can be geometric or positional. In Inventor, this paradigm is mostly achieved by using Derive (assembly or part). Derive is one directional. Part A drives Part B. The other way around is not allowed. When the source component (skeletal) is changed, the change will be propagated and all derived components need to be updated. The skeletal component should be managed by a supervisor or a technical lead. It should not be changed arbitrarily.

One may ask why Copy Object is needed? It also drives geometric change from one part to another. What is the difference? From behavior's perspective, they look the same. They (Copy Object and Derive) both drive changes. However, conceptually, they are different. Derive is not context sensitive. This means the derive relationship can exist between any two components regardless of where they exist or how they are created. As long as the rule of Part A driving Part B is adhered, Derive is allowed. Copy Object on the other hand is context sensitive. This means the relationship can only be established within certain context (assembly). Part B is adaptive to Part A because they both exists in Assembly C. Such relationship does not exist outside of Assembly C. To certain degree, Part B is aware of Part A and Assembly C.

Allow me to use a somewhat comical but real analogy here. To me, such driving workflows (Derive vs Adaptive) are like borrowing money. Derive is more like borrowing money from a bank or a stranger. You don't know where the money was made and where it came from. There is certainly a purpose of having the money. In theory, you can borrow from anybody as long as your credit rating is good enough.

Adaptive (Copy Objects) is like borrowing money from your family or friends. You are bounded within a pre-existing relationship before the money was borrowed. Such borrowing is usually situational and at the moment. It is also possible they may borrow money from you.

Regardless of how you borrow money, you need to control the debt level. Too much debt is always bad. Derive and Adaptive likewise, should be used prudently. Striking the balance is the key. You don't want to go overboard at any moment. So, when I see a part deriving all objects from another component, something is not planned right. It is because, if Part A needs to inherit Part B totally, then Part A should be Part B. The same holds true for Adaptive. When all parts are adaptive within an assembly, it is a misuse of Adaptive. An assembly should not be fluid like that.

Derive and Copy Object are both tools to drive geometric change from one part to another. As a designer, you want to make sure you clearly understand the relationship and the implication comes with it. Just like the debt example, you need to manage your finance properly. Is this particular item worth borrowing money for? Are there other means to achieve the same goal? Use Derive and Copy Object when it makes sense. It is an art, not a science.

Many thanks!

[bradeneuropeArthur]

Hi @Frederick_Law 

Thanks I knew that already, but with Vault the suppress link etc and the workflow is more or less different. Because vault shows you more then you see with inventor standalone.

Thanks anyway

[bradeneuropeArthur]

Hi @johnsonshiue ,

But what if vault comes around.

What is best practice here.

All related files in WIP if the skeletal model is set to WIP. 

I still have no real answer why Copy Object is not in the story of the help file.

Derive and Copy object are handled differently within vault, are you aware of that?

Thanks for the clear explanation of the skeletal basics, but I knew that already.

The problem is skeletal design and using Copy Object. And best practice skeletal design within a vault environment. Because this is to be threaded differently.

[johnsonshiue]

Hi Arthur,

For Vault workflows, I would assume that derive source component file should be sort of locked up. One tip I would like to share is to make sure all Derivable objects are exported (Manage -> Author -> Export Objects). For example, if a parameter is not exported in the source part file, the user will be asked to check out the source part when the parameter is derived into another part. This is for performance purpose so that non-exported objects are not tracked.

Other than that, I am not aware of anything you need to do differently in terms of leveraging Derive or Copy Object or Adaptive workflows. Inventor manages what files need to be computed and tells Vault what files need to be checked out and saved.

In terms of file management, I am not aware of any difference between Derive and Copy Object (except the tip I mentioned above). Please share an example that I can take a look. Regarding documentation, I will follow up with the project team. I don't know why Copy Object was not mentioned in the related workflows. It was probably omission.

Many thanks!

[bradeneuropeArthur]

Hi @johnsonshiue 

For Vault workflows, I would assume that derive source component file should be sort of locked up.

What do you mean with that? Do you mean that only a kind of administrator can do that with special permissions?

One tip I would like to share is to make sure all Derivable objects are exported (Manage -> Author -> Export Objects). For example, if a parameter is not exported in the source part file, the user will be asked to check out the source part when the parameter is derived into another part.

We have seen this as a dirty-maker for files if forgotten. Question is why vault and inventor are allowed to change the released file in these specific situations?

This is for performance purpose so that non-exported objects are not tracked.

You mean that features that are not exported are never seen as an updater for files related?

Other than that, I am not aware of anything you need to do differently in terms of leveraging Derive or Copy Object or Adaptive workflows. Inventor manages what files need to be computed and tells Vault what files need to be checked out and saved.

In principle you are correct. The only thing is that files become often dirty and they are released. What workflow is needed here. Best option is to take all related files (where used) into WIP if the Master Skeletal is set to WIP, are you agree. This will help us update, but will also take a lot of manually updates and further often the files have not changed really and did not need a revision as you may understand. This confused our workshop and creates them a lot of additional work to check if the files have really changed or not. This means the workshop preparations need to be done over and over again. Sometimes the production is delayed/paused for 2 or 3 days.

In terms of file management, I am not aware of any difference between Derive and Copy Object (except the tip I mentioned above).

Vault does not see this reference at the moment and that could be a benefit!

Please share an example that I can take a look.

I think we still use basic skeletal modeling as you explained clearly, thanks for that. I think you should take a look at this theory if you are using Vault with a release process. Then you will be surprised an exactly know what I mean. That would be the best option for you and me. Our models are not very different as what you told us. Furthermore I have shared files with you already regarding this e few years ago and you did not see strange things 

Regarding documentation, I will follow up with the project team. I don't know why Copy Object was not mentioned in the related workflows. It was probably omission.

Many thanks!

No You thank you for helping to understand the issue.

[johnsonshiue]

---

@bradeneuropeArthur wrote:

Hi @johnsonshiue 

For Vault workflows, I would assume that derive source component file should be sort of locked up.

What do you mean with that? Do you mean that only a kind of administrator can do that with special permissions?

[JS] I am just saying that the skeletal model source file should not be actively edited. Any edit can propagate to all dependent files. If you need to edit it frequently, it may be a process issue on your end.

One tip I would like to share is to make sure all Derivable objects are exported (Manage -> Author -> Export Objects). For example, if a parameter is not exported in the source part file, the user will be asked to check out the source part when the parameter is derived into another part.

We have seen this as a dirty-maker for files if forgotten. Question is why vault and inventor are allowed to change the released file in these specific situations?

[JS]: This behavior has nothing to do with Vault. To allow an object (sketch, parameter, solid body, and surface body) to be derived, it has to be "Exported." The need to have this process is to limit the scope of design tracking to enhance performance. When you attempt to derive an "unexported" object, the source file will be dirtied and it needs to checked out and saved. When you try to derive a unexported object in a released component, you will encounter the behavior. I believe you will probably need to use Copy Design workflow to make a copy of the released component and unrelease it for the purpose of Derive.

This is for performance purpose so that non-exported objects are not tracked.

You mean that features that are not exported are never seen as an updater for files related?

[JS]: Yes. The unexported objects are not tracked for change.

Other than that, I am not aware of anything you need to do differently in terms of leveraging Derive or Copy Object or Adaptive workflows. Inventor manages what files need to be computed and tells Vault what files need to be checked out and saved.

In principle you are correct. The only thing is that files become often dirty and they are released. What workflow is needed here. Best option is to take all related files (where used) into WIP if the Master Skeletal is set to WIP, are you agree. This will help us update, but will also take a lot of manually updates and further often the files have not changed really and did not need a revision as you may understand. This confused our workshop and creates them a lot of additional work to check if the files have really changed or not. This means the workshop preparations need to be done over and over again. Sometimes the production is delayed/paused for 2 or 3 days.

[JS]: I believe when the files are released, you should not try to operate on them. The only thing logical is to open or print. Any attempt to derive it is considered further change is allowed. Like I mentioned earlier, I suggest you use Vault Copy Design (iLogic Design Copy) to make a copy of those released components. Then unrelease the copies accordingly.

In terms of file management, I am not aware of any difference between Derive and Copy Object (except the tip I mentioned above).

Vault does not see this reference at the moment and that could be a benefit!

Please share an example that I can take a look.

I think we still use basic skeletal modeling as you explained clearly, thanks for that. I think you should take a look at this theory if you are using Vault with a release process. Then you will be surprised an exactly know what I mean. That would be the best option for you and me. Our models are not very different as what you told us. Furthermore I have shared files with you already regarding this e few years ago and you did not see strange things 

[JS]: Indeed, the behaviors can be confusing. But, from Inventor's and Vault's perspective, I believe my explanation holds true. You do need to implement proper design process to ensure the changes are well understood. Vault can help you manage who owns the files at when. But, it cannot help you manage design process.

Regarding documentation, I will follow up with the project team. I don't know why Copy Object was not mentioned in the related workflows. It was probably omission.

Many thanks!

No You thank you for helping to understand the issue.

[JS]: You are more than welcome. The issues being discussed here are not unique. I have heard about it before. I just want to clarify a bit to avoid further confusion. Inventor is a design tool. It is helping facilitate the design process. It needs to track changes and make sure the changes are updated at the right place at the right time. Vault is a data management tool. It cannot interfere with the design process. Nor can it perform design functions. More often than not, the need to save or dirty a file is triggered by Inventor. Not the other way around.

---

Please see my embedded reply above.

Many thanks!

[bradeneuropeArthur]

Hi @johnsonshiue ,

Thanks for your clarification here!

Still I am waiting/expect a mechanism in Vault that prevent is from changing files (Skeletal Mater) that are used in any released files (Derived Parts).

At least I expect that a warning will be shown that the files related need also to be changed in general.

Also we know that there are still features that are dirtying files without warning.

• Not fully constraint assemblies. All degrees of freedom must be eliminated.
• Flexibility in assemblies without a positional representation.
• Not used fully constraint adaptive parts or assemblies.
• Dimensional sketches.
• Projected geometry from assemblies into parts.
• Projected loops from assemblies and parts into Parts.
• Mass property
• Use of the task scheduler.  Task scheduler uses another project file then the BeVault.ipj.
• Linked excel sheets in the parameter box.
• Use of Quick change  without Quick changing the parents (Where used)
• Overwritten text in the drawing part list. This is shown as blue text.
• Linked assemblies needed for positioning components.
• Substituted Level of details in assemblies.
• Mixing substituted Level of Details. If Custom Level of details is used, only use substituted LOD or normal LOD in all custom LOD.
• Editing Substitute parts manually. When The Substitute LOD is used in an higher parent assembly.
• Measure tools
• Express Mode settings in the application options

And there are  even more of these.

Regards,

[johnsonshiue]

Hi Arthur,

Many thanks for sharing the list! It sounds like these file-dirty events are not properly monitored by Vault. Let me follow up with the project team to see what we can do.

Thanks again!

[swalton]

@johnsonshiue

I'd like to understand something about Vault and Inventor.  Should a Vault-Released file be editable/dirtied by Inventor? 

My expectation was that any file that is Released in Vault is locked from any edits by Inventor.  I.E. Vault controls how Inventor behaves and all the "dirtying' code paths in Inventor are prevented from running on a Vault-Released file.

From my limited testing, a Vault-Released file is editable when opened by Inventor.  The file can be dirtied by all the various code paths in Inventor.  I can even save the dirty file to disk.  I can't check it into Vault, so that part seems to work.

What am I missing?

Back to @bradeneuropeArthur main point in this thread:  Given that a State Change/Revision bump is a significant time/cost expense on the production floor, what is the proper workflow with a top-down design to minimize the number of files that need a State Change in Vault because Inventor has ignored the Vault-Released status?  

For example, say I have an assembly driven by a multi-body master part.  The master part has 4 bodies that generate 4 different parts in the assembly. 

MasterPart.ipt

• Body Alice-> Alice.ipt
• Body Bob  -> Bob.ipt
• Body Charlie -> Charlie.ipt
• Body Dave -> Dave.ipt

Dave.ipt needs a State Change from Released to WIP and a revision bump from Rev A to Rev B.  To make the geometry change to Dave, I will need to check out and edit MasterPart.ipt.  What will happen to Alice.ipt, Bob.ipt and Charlie.ipt?  Do they need to be checked out because MasterPart.ipt has been modified?  Even if my changes in MasterPart.ipt don't alter Bodies Alice, Bob, or Charlie?

Is the best way to minimize the Design/CAD/Documentation cost to my company of an ECO to not use any top-down design?

[bradeneuropeArthur]

Hi @swalton 

Swalton thanks for understanding the issue clearly.

This is exactly what happens.

I'd like to understand something about Vault and Inventor.  Should a Vault-Released file be editable/dirtied by Inventor? 

Yes that is possible that the files are dirtied in a release state too!

Furthermore you see that files can/will be based on different revision if not completely updated and exchanged in the design, this leads into confusion and also dirty files. You may understand what I mean! Otherwise I have explained it below....

My expectation was that any file that is Released in Vault is locked from any edits by Inventor.  I.E. Vault controls how Inventor behaves and all the "dirtying' code paths in Inventor are prevented from running on a Vault-Released file.

No this is not blocked and also released files become dirty.
Not the released state is used to block changes etc.

I would also not know how this should be done easily since Inventor is working different then Vaults wants/would like it.

From my limited testing, a Vault-Released file is editable when opened by Inventor. 

Yes, that is correct! 

The file can be dirtied by all the various code paths in Inventor. 

Yes, that is correct!

I can even save the dirty file to disk. 

Yes, that is correct!

I can't check it into Vault, so that part seems to work.
Yes, that is correct IT SEEMS! but not really!

What am I missing?

You are missing nothing in your story you are highlighting here.

You are fully correct, in what you found out and explained.

I would like to see it different for many many years/releases now, of course, but that is not the case yet.

Back to @bradeneuropeArthur main point in this thread:  Given that a State Change/Revision bump is a significant time/cost expense on the production floor, what is the proper workflow with a top-down design to minimize the number of files that need a State Change in Vault because Inventor has ignored the Vault-Released status?

Thank you for asking it too! And it is very very time consuming...

For example, say I have an assembly driven by a multi-body master part.  The master part has 4 bodies that generate 4 different parts in the assembly. 

MasterPart.ipt

• Body Alice-> Alice.ipt
• Body Bob  -> Bob.ipt
• Body Charlie -> Charlie.ipt
• Body Dave -> Dave.ipt

Dave.ipt needs a State Change from Released to WIP and a revision bump from Rev A to Rev B.  To make the geometry change to Dave, I will need to check out and edit MasterPart.ipt.  What will happen to Alice.ipt, Bob.ipt and Charlie.ipt? 

In worst case all files related to MasterPart.ipt become dirty, and it does not matter what (Release; For Review) state it is in!

Do they need to be checked out because MasterPart.ipt has been modified? 

In worst case all files related to MasterPart.ipt become need to be changed and revised to.

Even if my changes in MasterPart.ipt don't alter Bodies Alice, Bob, or Charlie?

Yes, you are correct. because otherwise you would have different file Revisions with a different link to the MasterPart.ipt.

For example:

Alice Rev_B used MasterPart Rev_B

Bob Rev_B used MasterPart Rev_A

if you put it together in an assembly you have a revision (Mixed) problem, causing issues!

Is the best way to minimize the Design/CAD/Documentation cost to my company of an ECO to not use any top-down design?

I would have hoped not.

many features within Inventor are based on this like: Frame generator is also based on this!

Many thanks for your support on this

[bradeneuropeArthur]

Hi @johnsonshiue 

That sounds great, how can we follow the progress or the findings of the team?

Thanks for supporting on this!

Regards,