cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Allow Mechanism Application in part mode (multi-body)

Allow Mechanism Application in part mode (multi-body)

Currently a structure of kinematic skeletons can be obtained only through the use of a "Motion Skeleton" (ASM) with a standard skeleton inside that generates several body Skeletons. It would be interesting that all these files could be condensed into a single PRT file (multibody) that performs the same functions as the Motion Skeleton.

From the theoretical point of view this is possible, but obviously it presupposes a fairly radical reorganization of the  creation of the Bodies within the part: it would be necessary to be able to manage them through connections (which is not possible at the moment).

In this way the structure of the assembly would be considerably simplified: instead of a system of many files (1 Motion Skel + n Body Skel) consisting of very few entities, there would be a single file containing all the necessary kinematics. This also simplifies its management on the PDM side.

8 Comments
S_Edgenear
14-Alexandrite

And allow feature level regeneration states, meaning, features to reposition a body or groups of bodies, assigning them to the same rigid body, or changing rigid body assignments. For instance, we could model an closed hydraulic cylinder, re-assign constraints for the extended positioning, and finally leaving a final constraint assignments that would allow free manipulation with the hand tool.

 

Body within parts is specially useful to be able to do conceptual work without circular references. Conceptual work, is basically skeleton geometry for start parts.

 

In Creo 8 we can already almost do what is proposed, to have all the mostion geometry in a single file (in this case, an assembly file with embedded components). We could theoretically do it this way, but embedded components inside a virtual asselby could still lead to circular references, even if we can have a single file defining the whole mechanism. Another problem with embedded components, is that we cannot have family tables components, nor can we use any automation with pro/program, which invalidates the use of a "smart" assembly generric meachanism that could be quickly adapted in a quick conceptual design. We would have to manually edit all the dimensions and parameters in all the mechanism components.

 

I would prefer the motion multibodies capabilities, but as an alternative, PTC should as soon as possible remove the no Pro/Program limitation in Embedded components in inseparable assemblies.

AlessandroFerri
6-Contributor

You're right.  The use of inseparable components within an assembly could be a way to "shrink" all the mechanism infos within a single file (starting from Creo 8 obviously). 

Of course the topic of Circular references still exist and must be carefully considered if you decide to implement such a methodology, as well as the use of top-down design techniques vs. carry over parts.

Unfortunately these topics (external references, circular references...) are in general not so clear for most of the cad users.

Thank you very much indeed for your relevant comment, I really appreciate it.

S_Edgenear
14-Alexandrite

Even us experienced users (in my case, using Pro/Engineer since V18) sometimes assemble parts that lead to circular references, so it's next to impossible to explain things to less technical users, even if they are very experienced. They assume that if parts and assemblies can be added in any order, and if it allows in-context modeliing (creating external references) that the software should not have any problems recreating what they assembled. The problem is that iince Creo is parametric, it needs a specific sequence of feature and comopnents regeneration. The model tree is like a computer program that the software must follow to recreate geometry. There are lots of situation when we need to create in-context modelling with an assembly mechanism in different states (open and closed, for example). Currently to be able to do this, we would need to create a family table of a whole assembly, and create those mechanism states (open and closed) as twoo instance in the family table, to be able then to do external references (cuts, or holes, for example). This is way too complex and very slow to regenerate. It's better to not allow any external references in mechanism assemblies, which have components with certain degrees of freedom. If we need to make external references, we should do it in a skeleton (motion skeleton), but even in this case, we woud need to assemble two different states (open and closed) to be able to referencee in different positions. So, because of that, I agree with you, that the "skeleton" should be different bodies in a single part, and in the model trre of that single part, we could assign two (or more) different motion states, and alter any body using normal features (extrudes, revolves, holes), then reposition those bodies (with not degrees of freedom), and add additional features in the new motion state (open or closed), and in this case, the bodies are allways constrained with no degrees of freedom. After sequentially making all "external references" in the contexdt of a single part, with no circular references possible, we could remove constraints in some of the bodies, to leave degrees of freedom, allowing then, and only then, to use the drag hand to simulate any motion in the not tottlly constrained bodies. These "free" bodies would not ever be allowed to be externally referenced, we could only internal or external reference bodies, in one of the "static" or "fixed" position of those bodies.

S_Edgenear
14-Alexandrite

Top Solid 7 is very good in this respect, in the mechanism approach. The assembly regeneration works by stages. There is a "modelling stage", where every component is static, imovable, which allows external references, there is a "moving stage", which allows mechanism to be added as features, even in imported parts that were assembled by default in the prrevious "modelling stage". This allows easy simulation sequences to be added, even for statically designed parts and subassemblies. After the "moving stage" of regeneration, there is the "annotation stage" or "detail stage", which allows MBD to be added, or weight to be calculated, etc. Creo allows mixing of all these ddifferent stages when regenerating, wich leads to lots of problems when to referencing moveable components. (which should not be done), but sometimes there is no other easy way to do it).

S_Edgenear
14-Alexandrite

One of the added benefits of considering bodies as virtual components inside parts, besides allowing them to move, and avoiding circular referencing, is that it would also allow faster regeneration of body patterns, since each body could have it's geometry calculated once, and the graphics card would only need to shade another instance at a new coordinate system. Only when bodies needed to intersect each other, would we need to "collapse" the patterned body to have the same coordsys as the default part coordsys. Having patterned bodies as insance at new coordsys, withought re-calculating each vody geometry would also facilitate the extraction of bodies to create new parts from a conceptual stage to an assembly stage. Each patterened body, would create an instance of a single part, and be assembled several taimes (several components), one for each patterened body. Currently, when we Create a part from a body, all is placed on the same default coordsys, and there is no easy way to generate patterened components from paterrned bodies.

S_Edgenear
14-Alexandrite

Besides allowing better mechanism inside a part, having the possibility to assign coordinate systems (or rigid groups) to bodies, it could allow to (parametrically) extract a whole assembly (with sub-assemblies) from a single multibody part skeleton. We could create "rigid groups" similar to the new Creo 8 custom groups. We could specify that a custom group is a rigid group. Inside the Design items we should have the possibility to add rigid groups, whhich ould be a new coordsys for all the bodies that are assigned to that rigid group. if we move one body from that rigid group, all bodies would be moved.

AlessandroFerri
6-Contributor

Also this time I agree with you. Since 1996 to 2005 when I was a PTC consultant and from 2005 until today that I have my own engineering structure, I have always advised those who asked me, to limit external references and assembly features only if it is strictly necessary, as they significantly slow down the assembly regeneration time (for the reasons you explained in your post) as well as making the duplication of the assembly itself considerably more complex.

Another important thing for me is to limit the number of levels that these external references must cross and, consequently, try to have (if possible) a single data repository from which to take the geometric information (i.e. the skeleton).

In the case of kinematics I have always advised to create in the design skeleton several coordinate systems used as positioning reference to transfer geometry to body skeletons and also to mount, later in the design process, the moving components.

In this way you decrease the number of mounting references to 1 and at the same time create a solid basis for geometric transfer using features such as external copy geometry that will be created using the same coordinate system  as positioning reference  in order to reduce the risk of circular references. 

Of course, as I said before, if your component need to be reused in other projects (carry over part), it must not contain external references to a peculiar assembly. In this case you can assemble these components using the body skeleton coordinate systems to to make these components part of the motion simulation.

Have a nice day 

S_Edgenear
14-Alexandrite

I think I pointed this out in another thread, but one of the other main advantages of having moving bodies inside a single part, would be to be able to animate hoses or wires. Currently, even if we use flexible parts to model hoses, the generated part is static, and must regenerate to assume a moving assembly new positioning. And if we have flexible compeonents (like springs or hoses) inside a mechanism assembly, those flexible parts are frozen when perfoming the kinematic simulation of the assembly.

 

What I think moving bodies inside a part would allow, is to model the tip of a spring, hose, or wire, as a rigid body. One of the ends, would be using the default CSYS, or assembled by default (as inside an assembly), and the other rigid geometry (rigid body), would be the other tip of the spring, hose, or wire, and this floating or moving body inside the part, could be attached to an assembly moving part (where the spring, hose, or wire connects to). Then, we could have parts with two rigid geometry, with one of the rigid bodies floating, the other, fixed, and Creo could use a single spline animation to perform a sweetp to connect those two rigid bodies. This spline animation can be easily animated inside a vertex program inside the graphics card, with no need for Creo to regenerate geometry to update the triangulated geometry sent to the graphics card. It just would need to animate a spline point interpolation, and from there, use "skeletal" animation (with the spline being the skeletal), to real-time animate a moving hose, wire, or spring. This would allow us to real-time simulate this kind of common components (wires, hoses, springs) in our assemblies. Currrently we can only kind of see the realtime animation of a very specifc kind of helicoidal spring in mechanism, which we cannot control much of its geometry, besides its diameter. With moving bodies inside a part, and interpolated splines, we could simulate and design custom springs and other flexible components in realtime.