General renewal of mechanism (with focus on cam and 3d contact)

[AlessandroFerri]

It's a long time since we have something new into mechanism and now it is becoming obsolete (from my standpoint, obviously). One great area of improvement in my opinion is the one related to the interaction between bodies (cam or 3d contact). The way this type of interactions are managed is fiddly and heavy. 

It is frustrating for an old former PTC consultant like me watching other CAD doing now what is not possible in CREO while in the past the situation was converse

( see this example: https://www.youtube.com/watch?v=Phlij0roGs0 ).

[S_Edgenear]

I agree, Creo Mechanism needs an urgent update in the design philosphy to allow faster conceptual design phases. Using multibodies as skeleton elements inside a part to derive parts from later in an assembly, implies that bodies inside a part should be possible to be instatiated (like a part in an assembly to produce a component), and any body could be assigned to rigid groups inside a part. Like there is a default body, there should exist a default rigid group, but we should have the option to add new rigid groups, assign and reassign any body to any rigid group at will, and this assignements should be history based, and registered in the model tree. Each rigid group, which starts as "default" as a "ground", could later be assigned new constraints to reposition all the bodies at once that belong to that rigid group. All the rigid groups should be fully constrained, and do not allow movement during design stage in the model tree. There should not be possible to make features from one "ground" rigid group body to a "floating" rigid group body. All should be fully constrained, with no degrees of freedom. After all the design is made with the mechanism in some "extreme" positions (eg. Hidraulic cylinder fully extended, and latger, hydraulic cylinder, fully retracted, or intermediate stages), only after all the DESIGN STAGES, should the model tree have one or more SIMULATION STAGE, where the rigid groups are (re-)assigned initial stages, to allow the user to fully test the mechanism.

I also consider that a part could / should have more than a rigid group inside a "tree" structure (similar to an assembly), to allow easy mechanism simulation of strings, chains, ropes, electrical wires, pneumatic or hydraulic hoses, linear and angular springs, laminar springs, etc. In the case of a hose, for instance, one body designs one tip of the hose, beloning to a ground rigid group, but allow another body to be "FLOATING" in the simulation stage, to be moved freely or externally re-attached to an assembly or another part rigid group. This way the house, or electrical wire could be made flexible, by simulating only the centerline or the spline (converted to multiple linear line segments) of the "intermediate" "flexible" body of the hose or wire, that connects to "rigid" hose tips, or wire tips. The same could be applied to springs, since any "flexible" component that we draw in 3D, blocks the mechanism simulation in current implementation. But simulating moving springs, or moving hoses, or moving wires, tat connect components in different "assemblies" is a very useful feature in lots of industries. Namely, in the car components industry, mould tools mechanism simulation, etc.

I know it will take time and effort to implement it, but it's something that would put Creo again at the fore-front of the CAD industry, in the mechanism simulation area.

[AlessandroFerri]

Obviously I completely agree with your considerations. If I can add food for thought, it seems to me that Simulation modules such as Mechanism and Simulate, have been "put in the cellar" from the moment PTC set up a closer collaboration with Ansys. In my opinion Ansys software is historically targeted to Analysts rather than Designers (speaking in general obviously) and for this reason you can't replace mechanism DESIGN with something coming from Ansys. Of course Mechanism can be used to solve direct and reverse kinetic-dynamic problems, but it remains basically a DESIGN tool that must be used mainly by DESIGNERS and not Analysts.

You can find other my considerations/ideas regarding Mechanism and other PTC tools in the following posts:

https://community.ptc.com/t5/Creo-Parametric-Ideas/Flexible-component-in-a-Mechanism-dynamic-analysis/idi-p/494475

https://community.ptc.com/t5/Creo-Parametric-Ideas/Components-assembled-with-Mechanism-connections-identified-with/idi-p/465655

https://community.ptc.com/t5/Creo-Parametric-Ideas/General-renewal-of-the-cabling-interface/idc-p/643496#M12935

I always hope (but I'm not sure) that PTC take into account of all these suggestions and strive to improve one of the best CAD ever.

[S_Edgenear]

I fully agree with yout further comments.

One thing that I'm affraid tha Autodesk might surpass PTC even if they started with inferior CAD products, is that they do have an extensive portfolio of animation packages (3D Studio, Maya, they even bought Softimage), and all that experience in animation software will eventually translate into better machanism and rendering simulation in one of their CAD packages. I think it's up to PTC to try to not let that happen. For it, they have to improve the mechanism simulation workflow, and allow something that currently no other CAD packages allow, namely, simulate really flexible parts in REAL-TIME, like springs, hoses, wires, (heck, even cloth, why not?). To make this real-time simulations, these need to be calculated or simulated with the graphics card when possible, using CGI alghorithms tipically used in games animation packages, like morphing bodies, skeletal animation, using splines to control motion, using the splines to control connected small lines to simulate ropes or wires or hoses, or springs, that can be streteched, curved (for springs or cloth), or have its's segments move, but keep it's total length constant (for wires, hoses). Therefore, a Creo PART should allow to have bodies as "static geometry", but that could be moved (for hoses or wire tips, or helicoidal spring "tips" (the rigid parts)), and also have "intermediate bodies" defined as flexible (that could be represented eventually only as a triangle mesh, and allow the triangle mesh to have it's vertices manipulated by a OpenGL program inside the graphics card, to do the real-time animation, using morphing or skeletal animation techiques).

This was one of the suggestions that I indeded to present to PTC's Martin Mueller, which leads the multi-body working group.

I know it's not a short term project for PTC to engage on, but that should be started the sooner the better, if PTC should have any hope of keeping Creo relevant in terms of mechanism animation versus current or future Autodesk's products, or even Siemens's ones (Solid Edge looks way better tha Creo in terms of easy of use of designing mechanisms in a coceptual design phase). Using assembly motion "Skeletons" seems very outdated and cumbersome, and works mostly in 2D. With the multibody approach inside parts it's a better work environment for the future. Each body should be possibly to be assigned to a rigid group, and only after all the design phase, should the mechanism(s) be enabled in the model tree, as happens in Top Solid 7. Also, the mechanism constraints should be features in the model tree, and in the simulation, grounding or ungrounding a floating body should be a historical feature in the model tree, as happens in Fusion 360. Mechanism joints should also be easier to define, ie, if selecting to circles in separate rigid groups, should automatically assume a rotation joint with a coincident plane. There are indeed lots of room for improvement.

[S_Edgenear]

Speaking of Mechanisms AlessandroFerri, have you ever deciphered how nested interfaces work in Creo?

I work with PTC Creo since Pro/Engineer v18.0, and although I read almost all the documentation for each versions, I was not ever be able to figure how nested interfaces work. In theory, I know their funcions, to be able to design a mechanism of a sub-assembly, and preserve the mechanism in a higher level assembly. In practice, I was not ever able to decipher how to use them. PTC's lacking documentation and tutorial in certain areas do not contribute to the ease of use. So, there are lots of hidden functionality that does not get used due to a lack of documentation, or due to using complicated approaches to certain problems. Another example is contitional features. PTC probably was one of the first CAD packages to implement it with Pro/Program, but it's really outdated and difficult to work with. Other CAD packages opted for a much more "user friendly" approach, instead of a "programmers" approach, using a mouse click in a feature, and in the pop-up menu, selecting "Make Conditional feature" to associate it with a boolean parameter, to specify weather the features should be supressed or not, to make easier and simpler to understand and edit automation inside a part os assembly.

[AlessandroFerri]

I also started working with Pro/Engineer v18.0 in early 1998 (at that time I was a PTC consultant) and I still collaborate with PTC as a subcontractor (also if my main activity is as CTO in my own design firm). Unluckily I don't have so much time to spend to read all the docs from PTC. I always read the "what's New..." but nothing more. So my experience is mainly on the field together with my younger collaborators (some of them are certified PTC trainers too) and with my brother (that is also my business partner).

I never heard about nested interfaces  so I can't help you with that. Is that something implemented in version 8.0.0.0 ? I have installed it and I watched the demo videos but I didn't notice anything about that.

Regarding Pro/Program I fully agree with you and I don't want to add anything because you were absolutely clear. The same considerations you did for Pro/Program can be also applied to Layout (now re-branded as "Notebook"). Have a nice weekend. My wife now needs my help. 

Best Regards

Alessandro

[S_Edgenear]

Ciao Alessandro.

Nested interfaces have been part of mechanism for quite a while. I don't remember in which version they were introduced, but I think they exist even before the transition form Pro/Engineer Wildfire to Creo Parametric. I've never seen a video of how they work, and from the help files, even if their objective are relatively clear, how that objective is achieved is quite cryptic.

https://support.ptc.com/help/creo/creo_pma/r7.0/usascii/index.html#page/assembly%2Fasm%2Fasm_four_sub%2FAbout_Nested_Interfaces.html

"About Nested Interfaces

A nested interface uses previously defined interfaces as references. This allows the propagation of engineering intent and criteria to more than one level of the assembly. Use nested interfaces to:

• Customize placement options—A nested interface can contain connections. Each subinterface is a set that the user can enable or disable at will.

• Use interfaces designed in submodels—Nested interfaces at the assembly level can contain subinterfaces from different, lower levels in the assembly.

• Define criteria to propagate engineering sense—Criteria defined for an interface are propagated up in to the assembly hierarchy when the interface is included in a nested interface.

An interface cannot be selected twice as a reference for a nested interface, although it can be selected for more than one nested interface. Conflicting criteria from subinterfaces is ignored.

Assembly-level nested interfaces can include subinterfaces from any assembly level. Interface hierarchy is presented in the Model Tree when placement sets are displayed.

Related Topics

About Component Interfaces

To Define a Nested Interface

To Place a Component Using Interface Matching

About Placing a Component with a Nested Interface

About Setting Rules for a Component Interface "

Something that is useful but is not very well explained either, is the "pre-defined constraint sets", that allows a mechanism to have several different mechanichal conections between rigid groups, and that can be varied with a family table. But this part I was able to decipher and use, even though we tend to avoid family tables as much as possible. Family tables are very good for standard parts, or parts made from a bottom-up methology, but we do lots of parts using top-down design methods, with lots of in-context modeling, and for that, family tables tend to slow down a lot the regeneration times.

I think that there are also better approaches than to using multiple mechanisms connections between rigid group parts with those "pre-defined constraint sets". I would prefer an historically defined feature for activation or deactivation of connections in mechanisms to be able to do in-context design with sub-components located at different places, doing the in-context features, repositioning the components in another place, with other constraints, adding more features to do in-context modeling, and finally, specifying a final constraint set to allow the user to move and simulate the mechanism.

[AlessandroFerri]

I confirm you that I have never used that type of functionality.

I guess that it can be used together with Pro/program, relations and other tools for process automation (such as format changes in automatic machines).

Unfortunately I can't help you on this issue.

Have a nice day and keep the faith

Alessandro

[S_Edgenear]

I'm currently trying to implement a new methology of designing moulds to speed-up our develpment times, using the multibody funcionality to do the conceptual work and avoinding lots of circular references that my other work colleagues tend to make, slowing down exponentially the regeneration time. Multibodies really helps this new top down methology, but I know we will struggle when trying to implement the mechanisms. Currently only using assemblies can we simulate mechanisms, but I really think PTC should gradually try to bring to the part environment some of the tools that exist in Assembly mode, namely, the possibilities to simulate mechanism movements, but grab the opportunity to try to implement it in a more straightforward manner. Simplify some things, and give better tools to quickly make motion studies, and also, to bring a better approach to do design in context even between parts from different rigid groups. In assembly mode, any external reference features, such as extrudes, made in the context of an assembly, trigger a lot of regeneration between the parts. To avoid the assembly context references, we could copy the references as external geometry, but it's not easy to specify the external part coordsys when copying references to make a local feature in a part. One way we could more easily model an assembly in context, that could have some features in an "open" state, and some other features in a "closed" state (for example, an hydaulic cylinder pushing a whole sub-assembly in a "open" state, and pulling that same sub-assembly in the "closed" state, would be to make an even higher level assembly, and inside this new main assembly, assemble the previous top level assembly and constraint it to assume a "closed" state, and re-assemble the same geometry, but with another "pre-defined constraint set" to assemble it in a "open" state. Then, inside those twoo sub-assemblies, make the extruded cuts that are necessary in each of the two contexts using in assembly context references to reference other parts. In this case, to be more specific, we can think of the "closed" state the usual modeling of a closed mold tool, and the open state, the open mold tool. In those extreme positions, all the moving parts should be fully constrained referencing different geometry. Then in that top main assembly, besides this two "open" and "closed" mold subassemblies, we could add a third state, where the fixed and moving half of the mold, or the ejection plates, would be re-assembled with a new "predefined constraint set" to have one degree of freedom each, so that each conld be moved linearly to simulate the opening of the mold, ejecting the part, retracting the ejection plates, and closing back the mold. This is a lot of work, and very slow in terms of regeneration time, and we are only able to do it when the projects are almost already done, when for the motion studies, this kind of work should be done at the very start of the project, with very simplified geometry that's easier to define, and would give quicker regeneration times. This is the reason I think PTC should really try to improve mechanism, to do conceptual, or early design stage motion studies, and the best way to do it, and quicker too, is not with assembled components, but with moving bodies inside a single part. This implies that as Creo evolves in future versions, the concept of rigid bodies that exist in ASSEMBLY, should be gradually also exposed inside the PART code base. Allow the user to define a virtual tree of "rigid bodies", and allow the assignment and re-assignment of bodies to one of the created "virtual tree" of "rigid bodies." This would also allow Creo with a single click to "Extract Assembly" from "Rigid Groups", as it already allows to "Create Part from Body" in Creo 7, and where each rigid group would be "extracted" as a sub-assembly, and the bodies assigned to those rigid groups, would be the "Parts" to be created from those same bodies. This also implies that when patterning Bodies, which creates duplicates of the original body, it should also allow for a patterned body to be using only the original body re-assembled at the new location (preferably referencing a patterned Coordsys). This way, when "extracting" the patterned body as a new part, only a single part would be created, but in the tree, the part would be referenced once, and the same part would be pattern assembled at several locations as several components referincing the same part. Any "body" that after being patterned, was subject to any features, such cutting material or adding material, would be treated as a new body, to derive a new part, and the pattern automatically include a new part derived form this "derived" body, instead of referencing the original patterened body.

Sorrry for the rant,  Alessandro, have a nice day you too.

Anyway, we can keep dreaming of a better mechanism methology...

Sérgio