Blocks

What to keep in mind

• Blocks are reusable authored systems, not just geometry containers.
• A block reference is an instance of one definition in a specific context.
• Parameters are the main authored inputs for a block.
• Variables derive secondary values that geometry, text, and outputs can consume.
• States let one block hold alternate behaviors without splitting into separate definitions.

Blocks are the authored system

A block definition is a reusable component. It contains states, parameters, variables, selection logic, optional lookup tables, and the primitives that belong to each state. A block can represent a part, an assembly, or a larger system fragment.

Block definitions define behavior. They are not just geometry containers. They are the core unit of LogiDraft and the place where logic, parameters, and behavior are defined.

Everything else in LogiDraft exists inside or is evaluated through blocks. Blocks are the system.

Definitions And References

The definition is the authored source. It describes what the block can do, what inputs it accepts, what values it computes, and what geometry or nested content it can realize.

Block references execute behavior. A block reference is an instance of a block definition placed on a sheet or nested inside another block. It points back to one definition but can carry its own parameter values, insertion point, scale, rotation, and chosen state.

Multiple references can use the same definition while producing different results because each instance can resolve different inputs. The definition stays stable. The instance behavior varies with context.

Why blocks matter in practice

• Blocks are the unit of reuse in LogiDraft.
• They let one authored system produce many instance variations without duplicating logic.
• They become essential when a design contains repeated parts, assemblies, or product families.
• They reduce drift because changes happen at the definition level rather than across many copied variants.

Use blocks when behavior should be reusable, parameter-driven, or nested into larger systems. Do not create a new block merely because one isolated piece of geometry exists once and carries no reusable logic. Blocks are most valuable when they capture behavior, not when they simply wrap a one-off shape.

Blocks connect authored behavior to execution

• Grounded by System Model: blocks exist inside the broader inputs-to-logic-to-outputs architecture.
• Defined here: block definitions define behavior, parameters, states, and reusable structure.
• Related by Logic: logic defines relationships inside each block.
• Executed in Evaluation: block references execute behavior in runtime context.
• Scaled by Composition: blocks combine into assemblies and larger systems.
• Reflected in Outputs: outputs are derived from evaluated instances, not from definitions alone.

Parameter precedence is a key bridge between authoring and execution: explicit values on a reference win first, inherited values win next, and defaults on the definition fill the remaining gaps.

Parameters, variables, and states inside blocks

Parameters are the primary authored inputs on a block definition. They define the values a user or parent system can supply for each instance. Parameters can be free values or option-constrained values, and they are typed as number, string, or boolean.

At the block-reference level, parameter values can be literal values, inherited values, direct references, or formula expressions. They are resolved before block logic is fully applied.

Variables are derived values defined by formulas. They compute secondary values from parameters and other variables and are used to drive geometry, state selection, text, directives, and outputs.

States let one block definition hold alternate geometry and behaviors without splitting that logic into separate definitions. Each reference resolves to one active state at evaluation time, which is how the same block can behave like different variants while still sharing one authored system.

A block is a reusable program definition

The cleanest way to understand a block is as a reusable program definition. The definition holds the logic. The reference is the runtime instance that supplies actual input values and context.

That framing helps separate authoring from execution. You do not copy behavior when you need variation. You instantiate the same definition again with different inputs.

Overrides and variation happen at the instance level

A definition does not become different just because one reference uses different parameter values. Variation happens at evaluation time inside each reference context.

This is why parameter overrides matter. Two references can share one definition yet produce different geometry, different state selection, and different output fields because explicit values, inherited values, and defaults resolve differently in each instance.

The subtle behavior is that references can vary without fragmenting the library. When variation belongs to input data, it should live in reference-level resolution rather than in duplicated block definitions.

Reusable forms blocks often take

• Use a block as a part definition when one item has stable behavior but many dimensional variations.
• Use a block as an assembly when it composes several nested definitions into one reusable subsystem.
• Use a block as a product family when states and logic choose among related variants.

A motor starter is a concrete example. One block definition can describe the starter behavior, while separate references resolve different horsepower, voltage, and protection choices without forking the definition.

For the rules that govern relationships inside blocks, continue to Logic System. For exact parameter and reference syntax, use Reference. To see reusable blocks assembled into a working system, use Help or open the MCP example.

Keep exploring