Type any phrase to search documentation

Software Documentation


BasicLast updated: October 16, 2019

15 Using the Section field in position properties

The Sectionfield in position properties is an implicit constraint that prevents modules from being shared across positions in different sections. Just like the other module constraint options on the addressing dialogs of the form “Module restricted to single X”, you could imagine the meaning of Section is “Module restricted to single Section, except it isn’t shown on the dialog because it always applies.

Sections are commonly used in large shows with firing systems that have slats. Imagine a show with 100 positions, and five modules to be shared across those positions with slats at the individual positions. You may want to organize your positions into five sections for the five modules, to arrange for each module to serve 20 positions that are nearby each other. To create this organization, select a group of 20 positions that are nearby each other, then right click one of them and do “Edit position properties” from the context menu. Then section the section to 1 (or “A” or “banana” or any word you want). Do the same for the second group of 20 positions, assigning them a different section name. Repeat for all five groups. After assigning the section numbers, when you address the show, modules will never be shared across section boundaries.

Adding section numbers wouldn’t make any difference if you already were using the constraint “Module restricted to single Position, because if modules are restricted to single positions, then that means they are also restricted to single sections, since sections are just groups of positions. Most commonly, section numbers are useful when either 1) you are using slats, or 2) your groups of positions are so close together that you allow e-matches from a single module to serve all positions in the section, or 3) you are handling a special circumstance, like using scab wire to connect a position with a lone large caliber shot to the nearest other position with a module.

In the slat circumstance (1), the addressing constraints are typically,


Table 1 – “Normal Slats” blueprint for sharing modules with non-piggy back slats

Modules constrained to same(no constraint)
Slats constrained to samePosition


And since there is no Position constraint on the modules, the section number is what prevents the modules from being shared across the boundaries of the groups of positions.

In the scenario (2) in which modules serve all the positions and slats aren’t even involved, the constraint options are simply,


Table 2 – “Sharing Modules” blueprint for sharing modules

Modules constrained to same(no constraint)
Slats constrained to same(no constraint)


Scenario (3) usually uses the constraints of Table 2 for the specific positions involved in the special circumstance, but uses a different set of constraints from a different blueprint for the other positions in the show. As discussed in addressing constraints, the assignment of a different blueprint to the positions involved in the special circumstance would create an implicit section boundary around those positions, so it is not strictly necessary to further distinguish them with a unique section number, but it is good practice, because you might use that blueprint in other sections of the show also, without intending to group those other sections with the special circumstance positions.