The addressing functions divide up positions into addressing groups of positions that can share modules and that do not have different Pre-Assigned Rails.  The addressing functions then assign addresses to the addressing groups one after another.  Within an addressing group, positions can share modules.  Between addressing groups, positions cannot share modules unless their Pre-Assigned Rails overlap.

Typically positions do not share modules and thus typically addressing groups are indistinguishable from positions themselves, but if the addressing dialog or addressing blueprints do not include the constraint that restricts modules to a single position, then an addressing group may contain more than one position.

If positions do not share modules, then further details about addressing groups have no bearing on the assigned addresses.  If positions do share modules, the following sections explain the implications for sorting of addresses and sharing of modules.

Criteria for sharing modules

If the addressing dialog or addressing blueprints have the constraint that restricts modules to a single position, then positions cannot share modules.   Without that constraint, positions might be able to share modules but only if the positions also have the same:

• Firing System Controller
• Module Type
• Universe
• Addressing Blueprint
• Start Module
• Section

Positions with different Firing System Controller or Module Type or Universe properties can’t share modules because addresses can’t be part of two things at once.  Similarly, positions with different Addressing Blueprint or Start Module also can’t share modules because these fields affect the rules for assigning addresses, and a position couldn’t be subject to two different sets of addressing rules at the same time.  Section is a property that is specifically designated as needing to be the same among positions sharing modules.  If two positions differ in any of these six properties, or if they have different Pre-Assigned Rails, they cannot be in the same addressing group.

Addressing groups affecting the sort order of positions

The addressing dialog and the addressing blueprints enable you to specify the sort order in which addresses are assigned.   The most common sort criterion is sorting alphabetically by Position Name.   Although people generally think of sort criteria as applying globally across the whole show, the sort criteria actually apply within each addressing group.  If you think about it, it couldn’t be any other way, because different addressing groups can have different blueprints that specify different sort criteria.

Consider a set of six positions, A, B, C, D, E, F, addressed without the constraint restricting modules to a single position.  Positions A, C, and E are sharing modules in one addressing group (say they have Section = “rooftop”); the other three positions are sharing modules in a different addressing group (say they have Section = “road”, causing them to be a different group).  Because the sections are different, there is no sharing of modules between A, C, E and B, D, F.

If you address the whole show sorting by Position Name, you are probably surprised to see the addresses assigned to positions in the order A, C, E, B, D, F.  The reason is, the addressing function assigns addresses for the first group containing positions A, C, E in order; and then it assigns addresses for the second group containing positions B, D, F in order.

If the sort criteria apply within each addressing group, what sort criteria apply between addressing groups?  In the example above the addressing function assigns addresses for the A, C, E group as the first group, but how did it decide that was the first group?  More generally, how are the addressing groups sorted relative to each other?

Addressing groups are sorted relative to each other based on the “sort factor” of each group.  Depending on the sort criteria from the addressing dialog or applicable blueprint, each group’s sort factor is either the alphabetically first Position Name in the group, or the alphabetically first Custom Position Field in the group, with the Position Name as the tie breaker.  In the example above, the sort factor for group A, C, E is “A”; the sort factor for group B, D, F is “B”; so group A, C, E is first.

If the sort criteria from the addressing dialog or blueprint do not explicitly begin with Position Name or Custom Position Field, the sort factor is Position Name by default.  If different addressing groups have different sort factors based on different sort criteria (Position Name versus Custom Position Field), then the apples to oranges comparison between the groups is undefined but deterministic.  If multiple addressing groups have the same non-blank Start Module, then as a special case the addressing algorithm adjusts the sort order to make those specific addressing groups consecutive, as described in the Start Module paragraph below.

Section

Unless the Pre-Assigned Rails cause addressing groups to use the same modules, the firing system addresses assigned in one group will never be shared with positions in a different addressing group.  That’s what makes the Section field a useful feature.  By assigning different Sections to positions, you can force those positions or groups of positions to not share modules or pins that they otherwise would share (see Using the Section field in position properties).

Start Module

The addressing algorithm assigns addresses for the groups one after another, starting each group with the next module number after the largest module number assigned in the previous group (excluding Pre-Assigned Rails groups) and adjusting the “next available rail” by the Start Module and Pre-Assigned Rails for the group.  If you assign Start Module 50 to an addressing group in the middle of the sort order and if it uses one module, the subsequent addressing groups will continue allocating modules from 51 onward.

If you assign different Start Modules to positions, you need to ensure the gaps between the Start Modules are large enough to avoid overlapping ranges.  Consider a set of positions in two addressing groups X and Y.  For simplicity, you could just think of each addressing group as a single position, X and Y.  If addressing group X begins with Start Module 10 and requires five modules (10, 11, 12, 13, 14), and addressing group Y begins with Start Module 12 and requires one module (12), the two ranges are overlapping.  That would result in an addressing error — a collision!

What do you think will happen if you assign the same Start Module to positions in different addressing groups?  It seems like you would be setting up the addressing groups for a certain collision, but since it is often useful to specify a shared Start Module for a collection of addressing groups (or even all addressing groups to make module numbers count from an arbitrary starting point globally), the Start Module works as follows as a special case: if multiple addressing groups have the same non-blank Start Module, they will allocate modules back to back, beginning with the Start Module itself for the first addressing group and not sharing modules between addressing groups.  If the first addressing group with Start Module 10 uses modules 10, 11, and 12, then the second addressing group with the same Start Module 10 will begin with module 13.  To facilitate this special case, the addressing algorithm promotes addressing groups in the sort order if necessary to make addressing groups with the same non-blank Start Module (and the same Firing System Controller and Universe) consecutive.

Pre-Assigned Rails

Unlike Start Module, Pre-Assigned Rails does not affect the module numbers assigned to subsequent addressing groups.  If you assign Pre-Assigned Rails 50 to an addressing group in the middle of the sort order, the subsequent addressing groups will continue allocating modules from wherever the previous addressing group left off before the Pre-Assigned Rails 50 group.

If you assign the same non-blank Pre-Assigned Rails to multiple positions, you must ensure the positions are in the same addressing group, which means all the position properties in the above criteria list must be the same.  The addressing algorithm guarantees no collisions within an addressing group, but not across addressing groups that have the same Pre-Assigned Rails.

If you assign operlapping but not the same Pre-Assigned Rails to multiple positions, you must ensure the positions, which will necessarily be in different addressing groups, have pre-wired racks and pins that prevent the same firing system address from being assigned in the different positions, leaning on the use of pre-wired rails (Racks with pre-wired rails) and pre-wired pins (Pre-wired pin options) to ensure no firing system addresses are re-used across positions in different addressing groups.

Imagine two positions X and Y that share a module and also have an unshared module.  Imagine position X uses modules 10 and 11; position Y uses modules 11 and 12.  The Pre-Assigned Rails for the positions are 10, 11 and 11, 12, respectively.  Since the Pre-Assigned Rails are different, the positions are necessarily in different addressing groups.  The question is how to avoid the positions allocating the same pins of the shared module 11.

If position X has pre-wired racks for module 10 and 11, and if the rack pre-wired to module 11 has tubes pre-wired to pins 1-16 (in a 32 pin module), then position Y can avoid collisions by using racks pre-wired to module 11 and 12 with the module 11 rack pre-wired to pins 17-32.  To receive a firing system address, the events in position X or Y need rack tubes, and the only rack tubes available in X or Y require module and pin numbers that are not shared between the two positions.