A newly invented protocol just might replace GCODE for certain types of 3D printing.
OVF, or “Open Vector Format” is an open source protocol that is designed to control a laser with galvanometric scanner. This just happens to be the base design for many LPBF metal and polymer 3D printers. It is also used by some laser engraving equipment.
But what’s the problem with GCODE? It’s served us very well so far, hasn’t it?
Not really. While GCODE is certainly functional, it is showing gaps when increasingly exposed to production operations, where the best possible results are required.
In order to produce metal parts that meet specific quality standards, it has been the best practice to monitor the progress of the print job in great detail. This is because minute deviations from intended parameters can generate flaws in the solid structure of the metal part.
Significant quality control systems have been built around this concept by some 3D printer manufacturers, able to verify parts were produced correctly — or stopping the print if things fall out of line.
But how about this? OVF allows the file to carry detailed information about processing steps, as well as meta data. Thus, you can imagine a 3D printer’s quality control system using the OVF instructions as the comparative in real time as the print job proceeds.
The OVF project explains:
“Thus, we are confident that the OpenVectorFormat will not be “just another format” alongside other, similarly well suited formats. It is the first truly open, feature rich format for the growing range of scanner based laser applications.”
OVF was built on a base of Google’s Protobuf, which the authors believe this many of the file format requirements, including space efficiency, high serialization performance in a variety of programming environments, easy streaming, seamless transfer between multiple applications, extensible and backward compatibility.
OVF is able to do this by means of a properly designed structure, shown here. Basically, they divide the job into “workplanes” representing the slices of the job. These are then subdivided into “VectorBlocks”, which can each have a specific set of print parameters. By linking this all together, you can represent a very complex LPBF print job with many different laser configurations as the job proceeds.
OVF is quite new, as you might guess, and at this point is not used by any major company that I am aware of. However, it does seem to address concerns I’ve seen resulting from the use of old-time GCODE.
For that reason I would not at all be surprised if we start to see the LPBF players begin to experiment with, and perhaps eventually release OVF-compatible products and services.
Via GitHub (Hat tip to Benjamin)
