Codeblocks for Industrialized Construction
A visual language to define rules for parametric prefab customization
Autodesk Informed Design defines a common framework for Industrialized Construction processes. One of it's key features is the application of CodeBlocks, a visual programming language first introduced by Tinkercad, to allow product engineers to specify the boundaries of parametric customization through algorithmic rules. In this article we will describe the Informed Design workflow and how CodeBlocks provide an accessible yet sophisticated solution for rules-based parametric productization, while meeting requirements of flexibility, security and platform independence. We will also break down the main components of our CodeBlocks implementation for Informed Design, and demonstrate how Codeblocks provides a versatile platform for real-time rules validation.
The Informed Design workflow
Autodesk Informed Design implements a three-step workflow that covers manufacturing, construction and prefabrication (Figure 1), each performed by a distinctive persona: the Product Engineer, the Designer, and the Production Engineer.
Step 1: A Product Engineer takes an Inventor assembly with all the manufacturing details, and specifies the parameters and restrictions necessary to productize this assembly. For an Inventor Model to derive a Product Model it needs to be parametrized and rules for the calculation of different parametric configurations need to be specified (e. g. in iLogic). Once all details of the Product Model are specified (parameters, rules, drawing templates, available outputs) the Product Engineer can finally publish the Product to the ACC platform.
Step 2: A Designer working within Revit will have access to the catalog of products that have been published by the Product Engineer. After selecting a product, the Designer can set the product configuration details by adjusting the parameters values to meet the needs for the particular application of that construction element. Informed Design will ensure that the selected values are valid according to the product rules defined by the Product Engineer. Once the product configuration details are set, Informed Design will generate a Revit Family of that product configured precisely to reflect the selected values.
Step 3: Once the Building Model is ready for fabrication, a Production Engineer logged into the Informed Design Web Portal, can generate outputs with the fabrication details for each product instance. These outputs can be BOM (bill of materials), shop drawings, 3D native assembly models, etc.
The distinctive value of Informed Design is to automate the processes of validating rules, configuring the Product Model for use in a specific Building Model and then automatically generating outputs with fabrication details.
Figure 1 – The Autodesk Informed Design Workflow
Codeblocks as a language to define fabrication/manufacturing rules
Codeblocks refers to the Tinkercad visual programming language, based on Google Blocky, and designed as a accessible language for learning algorithms by automating simple CAD operations. The Blockly-based language implemented in Informed Design is distinct from Tinkercad’s Blockly-based language. While the goal in Tinkercad is to manipulate 3D elements, the Informed Design language targets the definition and application of rules for prefabricated construction. However, we chose to use the same nomenclature (i.e. Codeblocks) as both tools have more similarities than differences.
Informed Design CodeBlocks solution for prefabrication rules is made up of three main modules.
The Enhanced Codeblocks Editor is an instance of the Blockly editor customized to allow the manipulation of the parameters made available to customize the Product Model. It includes most of the basic algorithmic statements (logic operations, loops, math operations, etc) and a couple of custom block statements that we will describe in more detail in the next section.
The Customization Form allows the Designer (Architect) to set the values that are needed for each configured instance of the product. At each change event in the customization form, the code runner is triggered to adjust the values according to the rules expressed by the Codeblocks. For example, If the Width value is set to 12 while the max width is 10, the value is adjusted as soon as the user leaves the Width field.
The Code Runner is the rules engine. It receives as input the rules (as a Blockly structure) and a set of parameter values, and then outputs another set of parameter values corrected to satisfy the specified rules. For example, consider that the Product Model contains a Width parameter along with a rule that specifies that this Width parameter has a max value allowed of 10 ft. If the value enters for the Width Input is 12, the output value is corrected to the nearest valid value, which In this case would be10 ft. The codeRunner also returns error messages and can be halted when the rules cannot be satisfied.
On Figure 2 we can see the Codeblocks implementation for the Inventor Add-in. On the left side there is the Enhanced Codeblocks Editor and on the right side, the Customization Form. In the Revit Add-In the Designer will only have access to the Customization Form, as this Inventor implementation is targeted to the Product Engineer. The Code Runner is the engine that enforces the rules in the Customization Form.
Figure 2 – The Enhanced Codeblocks Editor (left) and the Customization Form (right).
Custom Blocks introduced by the Informed Design Codeblocks implementation
In order to enable manipulating Product Model parameters in Blockly, we adopted an approach based on object manipulation. This is achieved by introducing a getter statement for read and a setter statement for write (Figure 3.a). Each of these blocks allow the selection of the targeted parameter (Figure 3.b) and the property that will be read or written (Figure 4.c). Each parameter has its own set of properties depending on its type. For example, numeric parameters have range properties (min, max, increment), while boolean parameters (true/false) will have labels for each selection in case the Product Engineer would rather display the labels “Yes” and “No” instead of the default labels “True” and “False”.
Next we present some of the logic that can be implemented with these getter and setter statements.
Figure 3 – Custom getter and setter blocks to manipulate Product Model parameters
Example 1: Pre built rules
One specific validator that is pre-implemented by the Code Runner is the range. On Figure 4, we observe that minimum and maximum values, and also the increment (step) are adjusted by declaration. After each value change, the Code Runner is triggered, and based on these settings, it will act to validate the numbers or to adjust to the closest valid value.
Figure 4 – Range delimiters are pre-built into the Code Runner
Example 2: Custom rules
In Figure 5, the rule specifies that the product can have a maximum area of 150 square feet. This rule is validated by checking if the multiplication of Width and Height is smaller than the threshold of 150 square feet. If so, the Width value is automatically set to the maximum valid value calculated with a simple rule of three. The engineer can also use the message property to provide an explanation to the user of the reason for the adjustment.
Figure 5 – Rule: Max area is equal to 150 square feet.
Notice that pre-built rules and custom rules can be combined for a more fine grained rule specification. In Figure 6, the combined usage of pre-built and custom rules ensures that the product area is no bigger than 150 square feet as well as preventing disproportional values, like a product with a 1:150 ratio.
View full article