Creo 7.0 Multibody Home: Start Here!
I'm creating this blog to be the central home page for anyone interested in trying out the new capabilities in Creo 7.0 that support multibody design.
Below will be links to other blog posts on specific detailed topics under the general heading of multibody. I'm interested in getting your feedback on all the new stuff, but I also want to try to do this in a somewhat organized fashion. So, you can think of this blog as the top node of a tree that will have a number of branches below it for the various multibody related topics.
In parallel to the list of blog posts below, I also plan to maintain a Multibody Infos post that provides you with links to further information, documentation, presentations, and any other information bits and pieces around multibody design in Creo.
To get going effectively, I encourage you to first go through the What’s new material and tutorials that you find there, so that you have an overview and high level background on the use cases and capabilities. That will allow me then to go one level deeper and include some tips, tricks etc. in the blog posted here.
I hope to be able to post new information regularly and hope you tune in, find it beneficial and give feedback in return. If you want to send me private messages, that’s fine, too. In particular if you have any suggestion on future blog post topics or questions, feel free to contact me at email@example.com .
And more to come…
Do the present implementation of the multibodies functionality in Creo 7 permit for the transfer of surface colours from the trimming body into the trimmed body?
currently color transfer is possible, but not (yet) automatically.
If you watch the second of the above listed posts (Multibody- Seven 90sec-Tipps & Tricks around Booleans & Split), you will see how you can do this color transfer as of Creo 7.0 by leveraging intent-references.
Thank you for your reply.
We don't have yet Creo 7 installed, but I've been watching all the public videos on youtube about multi-bodies on Creo 7.
As far as I remember, the colors of the "tool" (timmer body) were not transferred, but it would be very nice and speed up our workflow if the color transfer was automatic. (or with an option to transfer it or not, since there are many use cases).
I think it makes more sense to transfer the surface colors of the trimming body, and not the color of the triimmer body. (Since we can have surface or quilt colors, and they are both independent, with surfaces colors having pririty over quilt' colors, I assume that the same goes for the body colors).
I noticed that if we do merge of bodies, the colors are indeed automatically transfered. But if instead of merge, we do a boolean subtraction, the colors are nor transfered.
I think the algorithm of the color transfer is using a color for each side of each surface (since a surface has a normal and two directions, and each side of each surface may have a color atrribute?). In the case of a subtraction of a second body, the algorithm will have to copy the surface color of the "flip" side of the surface normal?
Anyway, tank you for your kind reply.
I saw the video on the blog post you recomended (although without sound, so I might have missed something), and I guess this is the part of the video where you said that we could leverage intent surfaces to repaint the modified body (trimmed by another one).
I recognize that solution can solve some some users' problems, but in our case (mold industry, where we have to paint with some color codes the surfaces that are to be machined according to diverse tolerances, or color code which holes are to be threaded, etc) this solution makes us having to repaint each "cut" that we might make with a construction body. Our need is for the construction bodies around a part to be already color coded in our library, indicating the tolerances of the surfaces, tp be machined, and then when we use the part with it's construction body to open an insertion cut (boolean subtraction) in another part, the pre-defined colors would automatically be applied.
With the intent surfaces, we can quickly select the surfaces of the boolean subtraction to be painted with the ONE SAME color. But we need for the surfaces of the trimmed body to have SEVERAL colors pre-applied on the surfaces of the construction body (of the trimmer body)., so that we can avoid having to manually paint the affected geometry after each boolean operation.
I hope this simple but very needed feature is quickly implemented on an update of Creo 7.
Thank you very much for the detailed feedback.
I do understand the use case and the usefulness of this and we will be capturing it as enhancement idea into our enhancement backlog list.
How do you currently deal with it?
Best regards ….
Are there also plans to split a geometry surface in part or assembly mode so you can indicate different surface treatments on a surface in part and/or assembly mode by giving them different colors (similar to the Ansys imprint command).
yes, please vote for surface region related ideas on the Creo Parametric ideas side. They on the list of enhancement candidates for future releases.
I thought this capability already existed, at least in part mode, with Pro/MESH. We no longer own a Pro/MESH license, so I cannot test it. PTC or anyone with a Pro/Mesh license, can you confirm/deny?
From a very old license file:
#9 1 Pro/MESH Wildfire 3.0 Flt Opt perm
I don't know if this is the right place to post about this.
I've found a bug or quirck in using the edge and face collectors in multibody operations.
If two bodies have overlapped edges or faces, it's not easy to individually select both of them.
I've noticed it using chamfers or rounds. It's not easy to specify if the edge we select belongs to
one or the other body, if the edges visually overlap. Not even using Quey Select.
I've tried the obvious solution, of temporarily hiding one body, to avoid overlapped edges on-screen.
But the problem lies that those edge and face collectors presently do not take into account body
visibility. They are shown and are selectable as if the bodies were not hidden.
I think this is a fix that should be included in an update to Creo 7.
please report this to Tech Support. That is the best way to ensure it gets tracked, reproduced and fixed.
I tried to reproduce it and couldn't, so a call to Tech Support would be best to explain the issue.
Thank you very much in advance
To be frank, I was uncertain to classify it a sa bug, since I was able after several tries to achieve what I intended to.
If we press Ctrl + right mouse button, to use query select, sometimes we are able to chose the overlapped edge or surface that we want. But it's not easy nor fast way to do it. The issue I have, is that if we hide bodies, we should not be able to select it's edges or surfaces by picking on the screen. I admit that those already selected adges of the previous unhiden body may be still previewed when trying to finish the command (in this case, a chamfer), but we should not be able to unselect edges or surfaces of a body that is not visible on the screen. The previews edges or surfaces of the hidden body should preferebly be previewd as "read-only" selection, and no be able to unselect them, unless we unhide again the body where they belong.
agreed, you shouldn't be able to select edges of invisible bodies. (and that's the way it works for me).
If you reach out to Tech support they will figure out whether this is a special setup related behavior on your system or whether it is reproducible.
Thank you very much.
I confirm that I was not able to select new edges from the invisible body. That behabiour is correct as you stated.
What I was able, was to unselect edges from the invisible body, by clicking on previewd edges of the hidden body. If the body is hidden, its edges or surfaces should not be pickable, even though they were selected when the body was shown.
In this situation, we could make individual chamfer features, making the edge selection easier. But sometimes we might want to do it in a single feature, adding rounds or chamfers using the same feature, but beloniging to different bodies. This way we can guarantee that the chamfer or round value is the same on all the bodies. We could guarantee that if we made relations to copy the chamfer or round value from the first feature to the second one, but it adds unecessary complexity for such a simple task.
About multi body parts: extend the multi body usage to assembly level, so multi body assemblies.
Right clicking on a body of a multibody part to put it in the assembly model tree directly, insteadof reassembling of again. External references to the main part should be able to be removed. By extending the current capabilities of flexible modeling you are able to featurize this component again, see NX. For instance by replacing holes in this death body by thread holes/countersunk holes etc. from the holes tool.
On the other hand internalize an assembly component in the assembly so that you are able to change that component for that assembly only and can check the assembly with the internal component in into pdm. In concept phase you don't want to generate a lot of files. Also for purchase assemblies this is a good use case. In creo 5.0 there was already a hidden config option to do such things. A little enhancement on this functionaly should be great. Btw Ansys Spaceclaim has this functionality of internal and external components already.
Creating a new part from a body is a beautiful thing.
This new part contains an external copy geom.
I expected to be able to display the generated dimensions of the original body in the new part. But I have not managed it until now. It says "No annotation can be shown for the selected objects"
Is this really not possible - or have I just not found the way yet?
A geometric copy does not copy the feature information over to the new part.
As such there is no way to show feature dimensions in the extracted part.
If you create an annotation feature in the source part that holds the dimension that you want to show in the extracted part, then you can re-define the external copy geometry (if you have the AAX license) and tell it to bring those annotations over.