The main ODB2GBR conversion engine often has to perform a Boolean operation on ODB++ "surfaces1" and "macros" to produce the same "image" in Gerber as one obtains using ODB++ constructs. The downside associated with the Boolean operation is that arcs and circles that originated from surfaces and macros — of which there are many in a typical PCB layout — are lost and replaced with a large number of small line segments.
This, of course, can greatly increase the file size -- in some cases to the point where the subsequent machine will slow down or even crash on the Gerber files.
Our solution to the problem is to use another module we developed for conditioning Gerber data called Split274x. This module normally acts as a Gerber pre-processor for tools such as GBRVU, GBRUnion and GBR_RIP. However the same capabilities that make it useful as a pre-processor for those programs, make it useful as a postprocessor for Gerber files generated by the ODB2GBR converter.
Split274x is responsible for the following post-processing operations on the Gerber data coming from the ODB2GBR engine:
Circularization
The recovery of arcs from multi-segment paths.
Max Points
Splitting polygons with a large number of vertices into a number of polygons with less vertices.
Data Sizing
Surfaces (i.e. G36/G37 area fill) can be sized up or down if needed for edge compensation.
Transformations
Scaling, Rotation, Mirroring and Offset are all handled here.
The postprocessor is controlled from the ODB2GBR command line by sandwiching the directives between:
-bgn_split_args [directives] -end_split_args
for example
-bgn_split_args -maxpts:4096 -dpi:0 -circularize:1um -chord_error:0.5um -end_split_args
-maxpts:4096 directs the processor to break any polygons with more
than 4096 vertices into ones with less than this value.
-dpi:0 used to compensate polygon data (G36/G37) by 1/2 of
the pixel diameter.
-circularize:1um directs the processor to convert a series of line segments
into an arc using a tolerance of 1 um.
-chord_error:0.5 um not sure how this interacts with the 1 um circularize parameter.
Post processing will add to the time required to convert from ODB to Gerber. However these routines have been optimized and the circularization and max points computations are multi-threaded to take advantage of today's multiple core computers.
Let's compare the multi-threaded version to the previous version of split274x
Here are three command lines
|
No Postprocessing does not trigger split274x |
Postprocessing triggers split274x |
Postprocessing triggers split274x |
|---|---|---|
odb2gbr_cmdline.exe -job:example.tgz -unit:mm -arcres:15 -arcsag:0.0003 -non_std -butting -step_repeat -nosropt -step:panel,l4m |
odb2gbr_cmdline.exe -job:example.tgz -unit:mm -arcres:15 -arcsag:0.0003 -circularize -maxpts:4096 -non_std -butting -step_repeat -nosropt -step:panel,l4m |
odb2gbr_cmdline.exe -job:example.tgz -unit:mm -arcres:45 -arcsag:0.0003 -circularize -maxpts:4096 -non_std -butting -step_repeat -nosropt -step:panel,l4m |
First let's run odb2gbr64 v2.33 and the newer v2.34 (multi-threaded post processing) on the same input file to see the effects of multi-threading.
| Version | Elapsed Time | Output File | Parameters | ||
|---|---|---|---|---|---|
| (mm:ss) | Size (MB) | Circularize (um) | ArcRes (deg) | Chord Error | |
| v2.33 | 2:39 | 2480 | No | 15 | 0.3 |
| v2.34 | 2.31 | 2480 | No | 15 | 0.3 |
There is little difference in speed when the postprocessor is not used between these two versions of odb2gbr. The extracted Gerber file is very large: 2.48 GBytes. We found that a Gerber file of this size crashed a number of rasterizers and viewers.
Now let's turn the circularize function ON, and see what the new timing and output file size are:
| Version | Elapsed Time | Output File | Parameters | ||
|---|---|---|---|---|---|
| (mm:ss) | Size (MB) | Circularize (um) | ArcRes (deg) | Chord Error | |
| v2.33 | 6:31 | 524 | 0.6 | 15 | 0.3 |
| v2.34 | 4.59 | 524 | 0.6 | 15 | 0.3 |
One can now see the benefit of multi-threading during the circularization computation. The v2.34 is significantly faster than v2.33. The output file size is greatly reduced: from 2.480 GBytes down to 524 MBytes. The output Gerber file can now be read and processed by viewers and rasterizers that could not handle the 2.5 GB file.