The addressing functions divide up positions into addressing groups of positions that are compatible with each other with respect to firing system related position properties, and assign addresses to the addressing groups one after another.   Every position is a member of exactly one addressing group.  By default, if you don’t change any firing system related position properties, then the entire show is one big addressing group, in which case you don’t need to concern yourself with addressing groups at all.  But if you start changing Start Module or Pre-Assigned Rails (see The Start Module, and Pre-Assigned Rails fields on positions) or other similar fields, then the show becomes multiple addressing groups, which affects the way addresses are assigned.

Positions with different “Firing System Controller” or “Module Type” or “Universe” properties obviously need to be in separate addressing groups because addresses can’t be part of two things at once.  Similarly, positions with different “Addressing Blueprint” or “Start Module” or “Pre-Assigned Rails” properties also need to be in separate addressing groups, 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 also a property that needs to be the same among positions in the same addressing group.  An addressing group is thus one or more positions that have identical values for the following position property fields:

• Universe
• Firing System Controller
• Section
• Start Module
• Addressing Blueprint
• Module Type
• Pre-Assigned Rails

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.  Positions A, C, and E are in one addressing group (say they have Section = “rooftop”); the other three positions are in a different addressing group (say they have Section = “road”, causing them to be a different group).  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.   A full explanation of this issue and of techniques to produce global sorts is described here: Sorting positions across multiple blueprints or sections.

Section

Unless the Start Modules or Pre-Assigned Rails cause addressing groups to have overlapping addresses, 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 Section numbers 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 and Pre-Assigned Rails

If the Start Module and Pre-Assigned Rails (see The Start Module, and Pre-Assigned Rails fields on positions) are different and non-overlapping for all positions, then all you need to know about addressing groups is that different Start Module and Pre-Assigned Rails split positions into different groups.

If the Start Module or Pre-Assigned Rails are the same or overlapping across multiple positions, extra care is required to avoid addressing collisions.   The addressing functions’ 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 and adjusting the “next available rail” by the Start Module and Pre-Assigned Rails for the group.  Within an addressing group, as the algorithm assigns rails and pins it marks them as used up to avoid re-assigning them later to a different event.   But between different addressing groups the algorithm has no recollection of what specific rails and pins were used up in previous groups.  Thus it is eminently possible for one addressing group to overwrite the the addresses assigned in a previous group.

Overlapping ranges with Start Module

The relationship between Start Module and Pre-Assigned Rails and the addressing groups has two limitations you need to watch out for.  The first limitation is that 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?  By the logic of the second limitation, it seems like you would be setting up the addressing groups for a certain collision, but since it is sometimes useful to specify a shared Start Module among a collection of addressing groups, the Start Module works as follows as a special case: if multiple addressing groups have the same 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.

Same or overlapping Pre-Assigned Rails

The second limitation is that if you assign the same or overlapping Pre-Assigned Rails to positions, you must ensure that either (a) the positions are in the same addressing group, which means all the position properties in the above list must be the same, or (b) the positions in different addressing groups have pre-wired racks and pins that prevent the same firing system address from being assigned in the different positions.

The assurance of (a) is only possible positions having the same Pre-Assigned Rails, since otherwise the positions would be in in different groups.  The addressing algorithm always avoids collisions within an addressing group, so the assurance of (a) avoids addressing conflicts by circumventing the problem.

The assurance of (b), for positions having the same or overlapping Pre-Assigned Rails, leans 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 in 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.