Our unofficial Professor of Model-Based Design, Ryan Gelotte, sat down recently to chat about digital consumption of MBD data.
To digitally consume MBD data, you first need to understand the four parts of MBD:
- Presentation states
- Metadata (Or properties, attributes, whatever you want to call it)
Digital consumption of MBD data involves consuming one or more of the three components that can be machine-readable, which is geometry, annotations, and metadata.
CNC machines have been able to use 3D model geometry for a long time, 20 or 30 years. It’s the annotations that those programmers have either had to manually program or recreate in whatever software they’re using. Since CNC machining has been using the 3D CAD geometry for so long and it’s already a model-based process, we should give ourselves more credit for it, as an industry. Its use of the annotations is a newer subject, however. For instance, if the 3D CAD geometry is modeled at one end of the tolerance zone, so the tolerance zone is asymmetric, it’s like a plus 0.1 minus 0. In those cases, the desire of the programmer of the CNC machine would be to put the machine in the center of the tolerance zone. But the CAD geometry is not modeled at the center of the tolerance zone. So what the CNC programmers have needed to do is either create a new model or manipulate the 3D geometry in the software they’re using to create the CNC programs. But then they have another model they have to maintain and that is typically done in an uncontrolled environment, breaking the digital thread.
MBD provides the capability for CNC programming software to use those 3D annotations and eliminate the need for the programmer to create any geometry. There’s intelligence there. We know where the tolerance is asymmetric, and that the geometry is at the low end of its nominal state at that zero level. If the CNC software can recognize the annotations and recognize the tolerance, it could then include capabilities that generate CNC programs to the center of the tolerance zone as opposed to the nominal state of the geometry. That’s the punchline there.
Inspection programming and CMM programming is the machine readability that we probably talk about the most. CMM programming software can use MBD data to program the CMM’s probe path very much like a CNC machining center would program a cutting path to move a milling machine cutter. For example, if the geometry says ‘this surface needs to be flat’ the probe can be programmed so that it touches multiple surfaces on the part and then reports the results against the annotation, which is the flatness requirement. Basically, it is using semantic GD&T, with machine-readable geometric dimensions and tolerances.
Digital inspection also includes CT scanning or any other form of point-cloud analysis inspection, where you have a physical part and there is a piece of equipment that captures a finite number of 3-D points, all with X,Y, Z coordinates. It could even be a person using traditional tool shop equipment to measure those points. It’s a very manual effort to collect the points, but once you have the point cloud data, you can compare that to the 3D CAD model and run inspection reports against the MBD model geometry and annotations.
The overall philosophy is ‘I have the points, I have some software that allows me to overlay the points on top of a 3D MBD model and now I can perform measurement analysis that compares the two and then creates reports.’ This 3D model-based inspection is the most prevalent type of machine readability. It’s also making the most progress, technically, though there is still a long way to go.
Metadata is another benefit to MBD. There is ambiguity between terms metadata, attributes, and properties depending on the CAD software. I like the term metadata because it’s data that persists across different systems. In Solidworks it’s called properties, in Creo it’s called parameters, in Siemens NX, it’s called attributes, in Autodesk Inventor it’s called parameters. We’re talking about data that can persist from one application to another. A lot of the definition captured in an MBD model that is ‘machine-readable’ is just metadata. For example, part number is a piece of metadata in your CAD file. The CAD file may be the start of the digital thread for that piece of metadata, meaning that when the CAD user creates a new part and assigns it a part number, they check it into the PLM or PDM system. Then that part number can be reused by other systems like SAP to create parts in whatever enterprise system they’re using.
So metadata is machine-readable by nature because it is persisted to other files. I think the sticking point for a lot of people because there are many examples of data in MBD that fall into that category of metadata, but people think it’s something bigger than that. They hear ‘machine-readable’ and they think there is some piece of manufacturing equipment that is going to read the model and magically build and inspect it. They think there is a mythological beast called the MBD model that Is going to automate everything.
In fact, metadata could just be used to feed other systems and machines. Maybe you have ‘paint thickness’ that could be used by some robotic painter that says “Ok the thickness is 0.015 and we can only put on .005 per coat, so we need three coats. That metadata in itself is machine-readable, but that is only a very small piece of the metadata picture. Overall, you have to understand how MBD information is consumed by whatever system or process is using it. You can’t just say “I made this a piece of metadata in my 3D CAD model, it’s now machine-readable. Go build it.’
As an engineer, you have to have a very keen understanding of how your 3D models will be used downstream. I think people get hung up because they want to know exactly what they need to put into the model because they’re engineers. Even if they’re focused on machine readability, they still have to know why it’s being used in order for them to put the information there in a successful way. It’s even more relevant to understand the downstream use for machine-readable data. People can think and make sense out of incomplete data, but machines can’t.
Ryan Gelotte is the Chief Technology Officer of Action Engineering. He is certified as an ASME Geometric Dimensioning and Tolerancing Professional (GDTP) at the 2009 Senior Level. He holds degrees in Plastics Engineering Technology and Mechanical Engineering Technology from Penn State Erie, The Behrend College. His career over the years has included a focus on all aspects of plastic part design and manufacturing, including mold design, as well as expertise of PTC’s various CAD and PLM systems. In fact, Ryan started his career as an Applications Engineer for PTC from 1998-1999 and, over the years, has provided training, support, and consulting services with PTC’s products for several companies. His experience in engineering systems, product design, and manufacturing have been instrumental in preparing him for the many challenges that come with implementing a Model-Based Enterprise. He enjoys the many challenges inherent to the engineering discipline and thrives off of finding new and better ways to accomplish superior results both in engineering and manufacturing operations by defining Model-Based processes.