We’re often asked what’s the difference between Xenon™ and Cobalt™. When we say that Xenon has associative parametric modeling but Cobalt also includes geometric and equation-driven parametric constraints, most people’s eyes glaze over and they do one of two things, usually for the wrong reasons. Either they buy Xenon because they’re sure they’ll never use whatever it is we just said, or they buy Cobalt because they’re scared they might be missing something for the slight difference in price. Neither response makes a good business decision, and since our customers are some of the best informed designers and engineers in the business, it’s important to understand the distinction and what makes the most sense for your needs. Let’s talk about the differences and where the real value lies in each product.
Associative Parametric Modeling
Associativity is found in both Xenon and Cobalt. This is the technology that allows you to use a curve to build a part, then, several steps later, jump back to that base curve, update it, and watch the change ripple through the entire model. Associative parametric modeling uses geometry and feature parameters to drive the dimensions of a model.
Both Xenon and Cobalt have associative parametric modeling,
which uses geometry and feature parameters to drive dimensions.
Constraint-driven Parametric Modeling
Only Cobalt can be driven by parametric constraints and equations. Like Xenon, Cobalt uses geometry and feature parameters to drive model dimension, but Cobalt has the additional power to use dimensions to drive geometry and the parameters of a feature. In other words, things can be designed both ways.
Only Cobalt features constraint-driven parametrics,
which use dimensions to drive geometry and feature parameters.
The Joy and Headaches of Constraints
Parametric constraints are sophisticated mathematical equations that allow you to solve for variables automatically, as shown in the example on the right.
While dimensional constraints are incredibly powerful for automatically calculating appropriate design variations, you can see from this example how they can also be very difficult to set up. Constraints can be especially cumbersome when simply exploring the initial concept of a design. So when should they be used? We’ll discuss that next.
The key slot on the shaft above is currently 120mm, within Section B which is 180mm.
If I adjust Section B, say to some length between 25-300mm, I want Cobalt
to automatically adjust the key slot so that it is approximately 2/3 of the section length
but only in 10mm increments, unless by using 10mm increments, the offset
from the edge would be less than 10mm. If so, then use 2mm increments.
At all times, however, the slot must be centered as near to the center
of the section as possible, but on an even 2mm increment.
When to use Constraints
Constraints are extremely valuable when used for the right purposes. But because they can be time consuming to set up, they are only worth the investment when designing something that will have a high number of non-random variations. In other words, it’s not worth the effort to set up the parametric equation and constraints if:
- There are only two minor variations of the same thing.
- The variable cannot easily be solved with an equation, such as a random curve whose shape is determined more by what looks right than by what is mathematically calculated.
Cobalt is the only software that allows you to use dimensional constraints on demand, only when you need them. Competitive programs, such as SolidWorks or ProEngineer, demand that all design be done with parametric constraints. This means that every feature is driven by an equation. This is fine if you’re able to think four or five moves ahead, planning for all possible design contingencies, like a master chess player. But it is an incredible handicap to free flow conceptualization, where the basic shapes are determined by “what if” thinking. On the other hand, typical history-free modeling programs such as Rhino, Space Claim or CAD Key offer some of the conceptualization flow, but none of the parametric control. This is just one more way that Ashlar-Vellum’s paradigm of Organic Workflow delivers exactly what you need right when you need it.
A random curve determined mostly by what looks right is not usually
a good candidate for parametric constraints.