exocad .constructionInfo file: what it contains and why

When exocad DentalCAD exports a finished restoration, it writes a small XML file with the extension .constructionInfo next to the STL files. Many technicians never open it and some forget to send it. For a milling center or a CAM program it is often the most useful file in the export folder, because it describes what the STL files contain. This post explains what the constructionInfo file stores, how production uses it and how to keep it intact.

What the constructionInfo file is for

An STL file contains only triangles. It has no information about which tooth it is, what kind of part it is or how it should be inserted. The .constructionInfo file adds that context. According to the exocad specification, it provides construction metadata that is typically used to optimize CAM processes, especially for implant-based work, and for accounting in milling centers.

What the file contains

The file has two main sections: one entry per tooth and one entry per exported file.

Tooth entries

Each tooth entry starts with the ToothNumber in FDI notation. If your orders use another system, the tooth numbering guide and the tooth notation converter help. ReconstructionType describes the restoration, for example anatomic crown, coping, pontic, bar, telescope, bite splint or custom abutment.

ParametersUsed lists every design parameter with the value used, plus the minimum and maximum offered during design. Minimum thickness and milling tool diameter are typical examples. ImplantType says whether the tooth is a normal preparation, a custom abutment or screw-retained without an abutment.

The Margin is stored as a list of 3D points, with separate lines for the emergence profile and the implant geometry. The Axes section holds the insertion axis (the recommended milling direction), the implant axis and the screw channel axis, which differ when the screw channel is angulated. For implant work the file also includes the screw hole center and diameter from the implant library, the type of angulated screw channel, a reference to the library entry used and a matrix that maps the library geometry into the design. The tooth color selected in the order or during design is stored as well.

Constructed file entries

Each exported file has its Filename and the ToothNumbers it contains. PartType is a short list of values such as merged tooth, merged bridge, bar, abutment, bite splint or denture base and exocad recommends that CAM decisions use this field instead of the longer ReconstructionType list.

The entry also gives the Material code and readable material name, the Height of the part (useful to preselect the blank) and SHA1 hashes of the STL file, of the reconstruction types and of the parameters. Optional data covers merged attachments, in-CAD nesting blank information, bridge split direction and whether the part was optimized for printing or SLM.

How CAM software and milling centers use it

With the insertion axis, the CAM can place the part in the blank in the recommended direction. With screw axis, screw diameter and implant geometry, it can apply the right strategy to the connection and the screw channel. Material and part height let the CAM or the milling center’s software propose a suitable disc or block. The hashes reveal a changed or wrong STL before milling and a milling center can count units, materials and part types without opening every file.

On a single crown the gain is small. In a lab or milling center running several machines and on screw-retained implant bridges, it removes many manual checks.

Why the file should never be edited

The file stores SHA1 hashes of each STL together with its reconstruction types and parameters. If someone edits the STL afterwards or changes values in the XML, the hashes no longer match and a CAM that checks them can flag the part.

The exocad specification states that this is error detection and not a security signature. It catches mistakes such as a wrong file version and it does not protect against deliberate changes. In daily work the conclusion is the same: never edit a .constructionInfo file by hand and never replace an STL while keeping the old metadata.

Keeping the file with the STL

Most problems come from the way files travel between CAD and production. Send the whole export folder, or a ZIP of it, instead of picking single files. Rename files inside exocad, because the XML references the exported file names and renaming them in File Explorer breaks those references. If the geometry passes through a mesh editor after export, the metadata no longer describes it. And do not assume that every CAM reads every field: ask your vendor which ones it uses.

Before a case goes to production, I check five things:

1. The export comes from the final design and not from an intermediate save.
2. The STL files and the .constructionInfo file travel together.
3. The original file names are unchanged.
4. The milling center knows the expected material and system, even though the file includes them.
5. For implant cases, the component brand matches the library used in the design.

For the other files in a case, see STL vs PLY vs OBJ.

Frequently asked questions

What is a .constructionInfo file?

An XML file that exocad DentalCAD saves next to the STL files of a finished design. It describes each tooth and each exported part: restoration type, margin line, insertion axis, implant data, material and file hashes.

Do I need to send the .constructionInfo file to a milling center?

Yes, whenever the milling center uses a CAM that reads it. The CAM can then orient parts, choose blanks and handle screw channels from the design data, which matters most for implant work.

Can I open a .constructionInfo file?

Any text editor opens it because it is plain XML. Do not edit it. The file contains SHA1 hashes of the STL files and any change breaks the link between the metadata and the geometry.

Which CAM software reads .constructionInfo files?

Many CAM systems with exocad integration support it. Check the CAM integration list on the exocad website or ask your CAM vendor, since support and the fields used vary between systems.