Bennett EarleJanuary 25th, 2024
With the NFL playoffs in full swing, I figured this would be a super time for us to discuss a successful gameplan for creating custom subassemblies. There are endless considerations to take when tackling a new subassembly, but keeping these tips in mind can help as you scope and develop your new custom content!
Bend-Don't-Break
One of the most important – and nebulous – topics regarding custom subassemblies is maintaining a high level of flexibility in their construction and usage. Each design team or organization will define flexibility in their own way; however, it will typically relate to the reusability of a particular subassembly in perpetuity and allowing for customizations by the user for each and every design alternative. This is a lofty goal for each design, and attaining that goal has many different paths to success, however two I find to be the most beneficial are defining Geometric variables and Coding variables.
Allowing our subassemblies to be dynamic in their geometrics can add a lot of functionality for our users. This could mean providing our users and teammates additional control of dimensions and toggles based on input parameters or various targets. Or having systems embedded within the subassembly flowchart that can react to different program variables or user enumerations. Using variables to drive the definition of geometry within a subassembly can help with the templatization of design standards or construction documents, and can make almost any PKT a Swiss-army knife.
Although the geometry that our subassemblies create is important for the generation of linework and content in Civil 3D, the intelligence that the intrinsic subassembly coding can provide dwarfs the geometric model content! Creating a flexible coding scheme through variables can accommodate an endless number of possibilities enabled by simply changing coding on the fly and applying it to geometric content where needed later in the flowchart process. Remember, coding has an impact on every aspect of the corridor outputs.
Follow the Passing Progressions
The programming interface in Subassembly Composer utilizes a visual flowchart that creates an overall ‘program’ flow in just one downstream direction of travel. As such, the sequence in which actions are performed in the Subassembly flowchart matter immensely! A general rule of thumb for complex subassemblies is to define any geometric variables first. Second generate a working 'skeleton' geometry through the use of auxiliary geometry. Third define any coding variables or additional geometry checks. And once these preliminary steps and checks are performed the actual subassembly geometry can be created and output parameters can be defined at the end of the flowchart. Inserting sequence or embedded flowchart elements can aid in organizing related geometry or complex calculations throughout your 'program' layout.
Auxiliary Geometry is an invaluable tool to assist in formulating, solving, and pre-calculating problems earlier in the flowchart than would be possible with just regular Geometry elements. Gaining an understanding of the methods to pre-calculate geometry variables, frame out geometric problems (think finding intersections on slopes or curves), or even preload reusable geometries to take advantage of pathing in the flowchart will serve you will in your subassembly development journey.
Creating an effective and reproducible processing flow can take your subassemblies to the next level. Do not forget to spend time during the development phase to plan out and scope out an effective subassembly flow in detail that can be relied on in perpetuity for custom subassembly development across your organization.
Follow the Coding Playbook
Subassembly coding is one of the most important aspects to subassembly and corridor generation and occasionally takes a backseat to the flashy and dynamic geometries Subassembly Composer can create. However, these geometries are meaningless without a strong coding system. The coding that we implement for our subassembly – points, links, and shapes – opens an endless world of intelligent CIM/BIM representation as a corridor output. During subassembly development appreciate your organization's standards and explore what is important or valuable during corridor construction. Is it Linework? Proposed Terrain? Quantity Takeoffs? Visualization or 3D Solids? Dynamic Annotations?
Recall that Point Codes can drive distinct linework generation, surface definition, unique linear quantities, and annotations at markers. Link Coding contributes surface definition, rendered materials / area fills for display of corridor treatments, 2D area quantities, linework in cross sections, and annotations along link linework. And finally Shape Codes are able to highlight shape area fills in cross sections and produce individual 3D cross-sections.
PKT Awareness
Pocket / Packet awareness, bad football puns almost over... Developing an accurate subassembly will always be the result of diligent testing throughout the subassembly development process. The subassembly preview window – both Roadway and Layout views – is great for initial testing during subassembly creation, however it rarely tells the full story. It is highly encouraged that the subassembly is constantly tested in Civil 3D to verify its full functionality. It is important to test out all input / output parameters, targets, report messages and coding to ensure that the subassembly is functioning as expected and absolutely do not forget to test edge cases. Testing the outlier and edge case scenarios ensure that we can accommodate various design parameters, and also identify parameters where we might limit user interaction or include geometry checks and report messages.
When testing your subassembly approach it from both the angle of an average Civil 3D designer/drafter as well as from the position of a CAD manager. This means that parameters, documentation, and workflow are all easily understood in the Civil 3D environment for a typical drafter or engineering designer. Additionally, features such as subassembly versioning, PKT organization, and Tool Palette populating are all considered so that the custom content can easily be integrated and used by anyone in the organization.