The Gravity Defying Vomit Comet (image courtesy NASA JSC)
Voting is over and soon we’ll find out not only who is the lucky wearer of a Star Trek uniform, but also who the voters think should control simulation — bring simulation tools into the hands of the design engineers or bring analysts up front into the design process? As much as I love a lively debate between generalist and specialist, I vote “C – None of the above.”
The Black Box of Simplicity
I don’t mean to imply that I’m anti-simulation. Quite the contrary. But, I also know that there are plenty of design and manufacturing companies that don’t require simulation to build a safe, inexpensive, and functional product. But, those people still need to accurately model fits, interactions, and mechanisms within their product. I may be splitting hairs on semantics, but I was doing this type of engineering before it was considered simulation. I don’t need high fidelity models, I don’t need meshing, and I don’t need massive high-performance computing clusters to crunch through the stress and deflection of thousands of tiny elements. I need black-box, shrink-wrapped, envelope dimensions of rigid body sets that I can assemble and verify fit, form, and function. That’s it. That’s all I need. Let’s not over-think this. Let’s not make it more complex than what is needed to solve the problem at hand.
Best Practices are a Crutch
Assembly components should always be fully constrained. That has been the mantra of solids modeling since parametrics were invented. I fought this practice from the beginning. In the glory days of drafting boards and 2D CAD, the assemblies weren’t fully constrained. I could visualize the machine and all its working parts in my head.
Motors were whirring.
Shafts were turning.
Bearings were spinning.
Belts were indexing.
Servos were clicking.
Pneumatics were popping.
Hydraulics were leaking.
It was alive!
I wanted my assembly model to do the same thing. But, it didn’t take long until technology bit me in the arse and I soon complied with the best practice. My machine was dead, motionless, lifeless.
Today, I’m happy to say that technology has improved. Most MCAD software allows for some variety of “flexible assembly” where I can leave components under-constrained at lower levels and constrain them at a higher level assembly later in the design. Best practices remain, though, because of years of conditioning to believe that all components must be fully-constrained at every level, and also because not all flexible assemblies are robust. Technology is still biting users in their collective arses. Nevertheless, cultures are changing because someone managed to come up with a clever moniker — Kinetic Modeling. Yes, Kinetic Modeling, the solids modeling assembly technique where you only constrain to the level that the components would be constrained in actual hardware.
- If a rotary union would normally spin, let it spin. Don’t clock the halves together.
- If a plenum would normally slide, let it slide. Don’t constrain an offset distance.
- If a follower glides along a cam, let it glide. Don’t lock the follower to a fixed point.
The Cost-Benefit of Kinetic Modeling
One of the obvious benefits of kinetic modeling is the more accurate representation of your product at the design level. A not so obvious benefit is the translation to motion analysis/simulation software like MSC Adams. The 1:1 translation of assembly constraints to joints is more accurate, meaning less time to clean up the simulation model to allow for movement. Importing an assembly with fewer constraints into animation software also eases the translation process. These are some significant cost savings benefits of kinetic modeling, if you use any of these downstream tools.
I don’t own a seat of Adams. I rarely need to do motion analysis because I don’t care about reaction forces, for example. I also know, based on sound engineering judgement, that my deflections are minimal and treating the components as rigid bodies is accurate enough for a form, fit, and function check. I’m also not fluent in rendering or animation. That’s not my job. I have a shaded model on my screen, that’s good enough. Why can’t I just use that? I see in my “move” tool that there is a collision detection option. OK, I tell this component to move and my Kinetic Model with collision detection should do the rest. Right?
Technology still isn’t perfect. Under-constrained components sometimes produce unexpected results. But there is one boundary condition that can be added to a Kinetic Model that will still allow flexibility and improve the expected results. Gravity! That’s right, I want gravity to be included in my assembly file. (Oh, and because some software considers Y-direction to be UP and others consider Z-direction to be UP, the user needs to be able to define the direction of gravity.) There are many assembly conditions where one part is “resting” on another part. If gravity were an assembly relationship, constraint, or boundary condition, this “resting” degree of freedom would be solved and the model would be more robust. Granted, there are times where I’ll want to depict a component in something other than it’s rest state. I will have to be able to turn off or over-ride gravity. I don’t expect the implementation of gravity into an assembly modeler will be easy to code and collision detection will have to be always on, which may hurt performance. I still think it could be a valuable addition to assembly modeling to make Kinetic Modeling more realistic.
I know this won’t result in anyone dressing up in costume, but what do you think? Would gravity be enough for most MCAD users to get more value out of their kinetic assemblies?