Introduction
The arrangement and processing order of geometry elements on each layer can make a huge difference on build time and build quality. For example:
Build time
It takes time to deactivate a laser, reposition it, and turn it back on again. These operations are called skips. Skips are needed to build unconnected geometry elements (imagine two circular elements on different areas of the layer). In the beginning, the laser is turned off and repositioned to the start point of the first circle. Then it has to be turned off and repositioned again to be on the starting point of the second circle. The longer the repositioning distance, the longer it takes to reorient the laser. Unorganized processing of layer geometry makes the laser skip more often than necessary and creates long skipping distances.
Build quality
Most machines have gas ventilation systems installed within the build room. Sometimes, melted material (chips) lifts up from the part and lands somewhere on the layer. Depending on the gas ventilation direction and the build order, these chips might land on parts of the layer that are processed afterwards and become part of the build result. An organized processing order might prevent this. There may be many more aspects of build quality optimization depending on the individual process and machine. Optimizing for quality often conflicts with optimizing for build time. In the end, a good trade-off needs to be found. As a result, there are good reasons to plan the toolpath processing of each layer.
Planning the processing of toolpaths with Advanced Toolpath Utility
Planning the processing of toolpaths is complicated because both toolpath generation and post-processing have an impact.
Toolpath generation
At this point the part and support contours are being processed and the toolpath is generated. Toolpath optimization strategies can already be applied while toolpaths are being generated and the source of all toolpaths (the related model, islands, or polylines) are still available to help inform organizational decisions.
Since toolpath generation is model specific, we only have information about one (the current) model and not about the whole build platform. This is a good place to group toolpath geometry to "packages" (bsHatchBlocks within a bsHatch instance), which won't get split up any further later in the post-processing step, and to add special processing flags and parameters (i.e. toolpath source information, which won't be available any more in the post-processing step).
Post-processing
The post-processing step gives access to geometry elements of all platform layers (remember, the toolpath generation only had access to one model of the platform). At this phase, it is complicated to generate new toolpaths, so it is mostly used to rearrange the processing order of existing toolpath element groups. This is also the place to make decisions about the processing order of parts, because all toolpaths of all models are accessible.
Refer to the Toolpath Organization programming example to learn more about the toolpath processing order.