Curing Data Migration Insanity

If you’re really concerned about interoperability between CAD packages, this is an article you should probably read all the way through. I don’t say that too frequently, although I do usually hope that people read as much as is relevant. Otherwise I wouldn’t write it.

Data migration has been a long-standing thorn in the side for CAD users. You’ve got one package and your machine shop has another. And it seems that CAD vendors don’t really want you to share files, or they do as long as the data is coming into their system.

The real problem, it turns out, is when a CAD system puts the intelligence in the same file as the geometry. Because each system handles that intelligence differently, you can’t share the data. Your data is held captive. Because the control of the model is done through abstractions such as features and sketches that you can’t really see in the model itself, and can’t (or just won’t) be shared between CAD vendors, your ability to control an imported model in a history-based system is pretty much lost.

Most of you already know this, but for the folks who don’t, SolidWorks stores data in a lot of different ways. Primarily, they store the body data as Parasolid information. Body data is stored for multiple roll-back states and multiple configurations, in addition to multiple bodies within a given part file. Plus, there’s preview data, and lightweight information, and stuff that assemblies store. Beyond the geometry, SolidWorks also stores feature information, inserted bodies, metadata like properties, comments, in-context info, design binder stuff, sketches, sketch pictures, configurations, design tables, as well as info for add-ins like rendering, FEA, motion, electrical, eDrawings, etc, etc. This is why SolidWorks files get so bloated, and why a SolidWorks file is so huge compared to a Parasolid file.There is a lot of information in addition to just the geometry inside the CAD file. It would be impossible to get Creo and SW to read all of the same data. Competitors just don’t cooperate in that way.

The fact that vendors put so much intelligence into the CAD file has given rise to the odd concept of imported data being “dumb”: It doesn’t really contain information about design intent, or relationships, or dimensions, or driving sketches, or patterns or features of any kind. So imported information got labeled as “dumb”. Hold on to that thought, we’ll come back to it.

One way this info within the native CAD file can be simplified is to read just the body data. This is the straight Parasolid (or whatever core modeler is being used) definition of the finished solid or surface body(ies). Its easy enough to reach into an NX file and pull out Parasolid geometry. That’s nice, that seems to be what the newish 3D Interconnect functionality in SW is doing. It pulls body data out of native files for several different file types. Imported files can be edited in their native program and essentially changed, then re-imported or update the import so the SW “dumb” data appears to be associative.

I know from a sales point of view this is exciting stuff. But from a technical point of view, we’ve been able to “edit feature” (edit definition for the old school folks) even on an imported body for some time, so you have been able to update imports manually. Yes, the 3D Interconnect automates that somewhat, so it is an advantage, but it’s not the groundbreaking enhancement they want you to believe it is. Plus, it’s not really an associative link, even though the feature shows the “->” in-context marker, it doesn’t work in the classic sense like a “real” in-context link would work, it’s more like a locked in-context reference that can be unlocked, updated, and then re-locked. Plus, there’s the killer that it requires a seat of the competitor’s software to make it work, and it only works for certain versions. So yes, 3D Interconnect is a cool idea, and yes, it’s better than nothing, and yes, it’s an attractive plus for a sales demo, but no, it’s not a practical solution for 80% of users.

Direct edit tools are a great way to work with imported data, but we’ve already established that SW’s direct edit capabilities are primarily superficial. They are first of all not truly full-powered direct edit tools (like say Solid Edge), and they store the direct edits as history-based features, which defeats half of the benefit of using direct edit tools in the first place. So if you’re thinking about SW direct edit tools as a solution, you are half way right, at least.

To really work with what you are accustomed to thinking of as “dumb” data, you need a “dumb” editor – a CAD package that doesn’t have to put information back into the model.

Think about it this way: What if the design intent is not something artificial that you make up and impose on the geometry. What if design intent is really something that is actually inherent in the model. For example, lets say two faces are parallel. Why do you have to have a sketch that forces these conditions on the model, when the model itself already shows these faces as parallel? And why do you need a sketch to tell the model that “this edge and that edge are separated by 5 inches”? You don’t. That information is already in the Parasolid data because those two faces are already 5 inches apart.

You’re used to thinking of design intent as being something abstract that you impose on the model, but that has never really been true. The truth is that the information has always existed in the geometry itself, without the need for any abstraction or metadata (sketches, relations, dimensions, features,…).

In the way of an example, let’s say you have a 1″ cube. What does the history-based file of this model include?

• some sort of sketch
• with dimensions
• and relationship information
• a metadata feature that defines how to do what to the sketch to make the solid body
• solid body of the dimensions and relations specified.

Ok, now what does a history-free (direct edit) model look like?

• solid body of the dimensions and relations specified

So, the history-free part has all of the same information as the history-based model, it just doesn’t store it in multiple ways, and doesn’t have to recalculate it based on that stored extra metadata every time a change is made. So it turns out that what SolidWorks thinks is a “dumb” model is what some other package would think of a full of design intent, and actually very smart. This is insanely simple. To me, once I understood all of this, using history-based software (for most types of work) became insane. Why not use a simpler definition of the model that enables you to work without the extra instructions?

You can get the relationships directly from the model. Two faces are parallel, so the design intent must be “parallel”. If that’s not really what you intend, or if the intent changes, you can turn off the part of the design intent that you want to change. This intent applies to the 3D model, not just to 2D sketches.

What I’m saying here is that even an imported model, by virtue of the fact that it has geometry, comes in to a package like Solid Edge with design intent inherent in the geometry. Import that cube into Works, and you can add to it, but you really can’t work with it. Import the cube into Edge or Fusion 360  or I assume NX, and you can stretch it, angle faces, move holes, and so on.

You can think of the intelligence of a direct edit program as being in the program itself, rather than in the data. Solid Edge can infer the intelligence from the parallel, perpendicular, distance, size type information available from the geometry itself, and that information isn’t lost if it travels from Edge to Works to NX to Creo to Fusion360, and then back again to Edge.

So, what I’m really trying to do is to solidify my case against history-based methods in general. Interoperability, or data migration is one of the best ways to illustrate the benefits of a “dumb” model (because the intelligence is in the software, which infers the design intent from geometry in the model). Working with imported data in a direct editor is infinitely easier than working with imported data in any history-based methods.

PS:  I’m using several terms interchangeably that don’t necessarily mean the same thing.

History-based

• ordered
• feature based
• sketch based

Direct Edit

• history-free
• synchronous technology
• “dumb” geometry

There are a lot of details that we can nit-pick about, but we can leave that for later. I’m primarily trying to educate the history-based public that the technology they are using has only a limited use in modern CAD. History-based modeling may never really die, but it needs to take a back seat in importance when compared against other methods and other types of data. People who are exclusively using history-based systems may be blind to alternatives and benefits they are missing out on.

P.P.S:

Editing dumb models as if they are native solves another problem you may not have thought of, and I had forgotten until after publishing this article. Remember how ripped off you get at a CAD company when you want to edit a 2018 version file, but you only have 2017? Suddenly this becomes less of a problem, because you can send out a neutral format without losing all of your design intent.

This is becoming a better idea each time you hear about it, isn’t it? Do you see now why I’ve been hammering on the fact that history-based methods are out dated?