The “Start Module” and “Pre-Assigned Rails” fields of position properties are two ways of specifying the firing system equipment for the position. For any position, you can use one field or the other, but not both at the same time since they would conflict with each other. The two fields have slightly different purposes.
- The Start Module field specifies what module number the addressing functions should start counting from when assigning modules to an addressing group of positions.
- The Pre-Assigned Rails field is a comma separated list of rail addresses that specify a specific set of firing system rails that an addressing group of positions can use.
The words “module” and “rail” are synonymous for firing systems whose addresses do not have slats. So for FireOne, for example, the word module means the same thing as rail. For fireTEK, however, the “module” refers to the piece of hardware that has four twelve-pin “slats” connected to it. The “rail address” is the module number for firing systems without slats, and is the module-and-slat number for firing systems with slats. Whereas a FireOne rail address might just be the number 10, a fireTEK a rail address might be 10-1, or 10-2, or 10-3, or 10-4, identifying a specific slat of module 10.
Figure 1 – The Start Module and Pre-Assigned Rails fields are two ways of specifying the firing system equipment for the position.
One other difference between Start Module and Pre-Assigned Rails is that Pre-Assigned Rails will show up in the rack layout window for a position even before addresses have been assigned. Compare the Pre-Assigned Rails field of Figure 1 with the graphical depiction of the slats in the lower left of Figure 2. There aren’t any assigned addresses yet (no pin numbers in the slats), but the slats are still there. If the position used the Start Module field (specifying 10, say), instead of using the Pre-Assigned Rails field, then there would be no slats drawn in the lower left of Figure 2 until addresses were assigned. At that point, whatever slats were used by the addresses would show up.
It is easy to guess why Start Module doesn’t cause modules or slats to appear in the image before addresses are assigned — the software wouldn’t know how many are required!
Figure 2 – The Start Module and Pre-Assigned Rails fields are two ways of specifying the firing system equipment for the position.
The addressing functions divide 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. 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. But if you start changing Start Module or Pre-Assigned Rails 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 different 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. “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:
- Firing System Controller
- Start Module
- Addressing Blueprint
- Module Type
- Pre-Assigned Rails
So why bring up addressing groups when discussing Start Module and Pre-Assigned Rails? To use Start Module and Pre-Assigned Rails correctly, you need to appreciate that the addressing functions assign addresses to addressing groups separately. It is as if the show were divided up into pieces (the addressing groups) and each piece was assigned addresses one after another, using a different range of addresses.
When you think about it that way it is obvious that different addressing groups cannot share modules or pins (because they must use different ranges of addresses). That’s actually 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 if they otherwise would (see Using the Section field in position properties).
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 or Pre-Assigned Rails to positions, you will in so doing be splitting those positions into different addressing groups that require non-overlapping ranges of addresses. That’s probably what you would expect, because different Start Modules would lead to different ranges of addresses, but there is still a possibility of overlap that you need to watch out for. 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!
The second limitation is that if you assign the same Pre-Assigned Rails to positions, you must ensure the positions are in the same addressing group, which means all the position properties in the above list must be the same. Why is that? Because if you assign the same Pre-Assigned Rails to positions that are in different addressing groups, then you are setting up a certain 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: 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.
In short, the two rules for assigning Start Modules or Pre-Assigned Rails to positions are,
- If the Pre-Assigned Rails are the same for multiple positions, the positions must be in the same addressing group (i.e., have identical position properties for the above list).
- If the Start Module is different for multiple positions, the gaps between the Start Module numbers must be wide enough to prevent the ranges of assigned modules from overlapping.