Software Documentation

AddressingDocumentation

Basic Last updated: March 26, 2019

13 Slats, virtual slats, and splitter boxes

Slats, virtual slats, and splitter boxes all refer to the same type of firing system hardware — a box or rail with electrical terminals on it. They only differ with respect to the representation of addresses in the exported firing system script files, which varies from firing system to firing system. Thus depending on what firing system that you use, you will probably use only one of the three terms — slats, virtual slats, or splitter boxes — whichever term makes sense for your firing system.

The basic idea of slats, virtual slats, and splitter boxes is to partition the modules’ electrical terminals (pins) onto multiple boxes or rails that can be located at different physical launch positions, rack clusters, or racks. A single cable or wireless connection connects the controller to the module; multiple cables extend from the module to its boxes or rails of terminals located at different physical locations; e-matches extend from the terminals to the effects being ignited. Thus by way of using the boxes or rails of terminals, a single module can serve multiple physical locations without requiring e-matches or scab wiring to bridge between them.

Some firing systems, such as Pyrosure or FireTek, incorporate the idea of using boxes or rails of terminals integrally in the design of the firing system itself, and represent the group of terminals in the script file explicitly as a two-part rail address, such as “1-B” for module 1, slat B. We call these groups of terminals “Slats“.

Other firing systems support external hardware that partitions the terminals into rails or boxes arbitrarily but do not explicitly represent the partitioning in the script file format itself. We call these groups of terminals “Virtual Slats.” Addresses of virtual slats are represented with two-part rail addresses in Finale 3D, just like non-virtual slats, but the two-part rail addresses and their pin addresses are converted back into the corresponding sub-range of pins of the parent module in the exported firing system script file. For example, you can partition the 32 pins of a FireOne module with module number 1 into four 8-pin groups that would be represented in Finale 3D as 1-A, 1-B, 1-C, and 1-D, each with pins numbered 1-8. In the Finale 3D script table you would see two-part rail addresses and pin addresses in the range 1-8, but in the exported FIR script file those addresses get converted to one-part module numbers, and pins in the range 1-32 (pins 1-8 of group 1-C would be translated to pins 25-32 of module 1 in the FIR script file).

The third term, “Splitter Box“, simply refers to slats that partition the terminals into pre-defined sub-ranges of pin addresses that are not explicitly represented in the script file format itself.  Explo and Galaxis splitter boxes are examples of this third category of hardware.  As you can see from these definitions, there’s not much difference between virtual slats and splitter boxes.  The different terms simply reflect the fact that you can create any kind of partitioning you want for a firing system using virtual slats, whereas splitter boxes refer to pre-defined hardware listed as options in Finale 3D’s user interface that you can choose from.

Given these definitions, you can understand why Finale 3D uses the term “Rail Address” in the script table and in other places in the user interface instead of “Module Number“.  The rail address specifies both the module and slat (two-part addresses) if the firing uses slats or if you are using virtual slats, whereas module number just specifies the module.   If your firing system doesn’t have slats and you aren’t using virtual slats, then rail address and module number are the same thing.

 

Table 1 – Definitions

Term Definition
Slat A distribution box or rail for a module’s electrical terminals, which is explicitly represented in the firing system’s script file in a two-part rail address
Virtual slat A user-defined distribution box or rail for a module’s electrical terminals, which is not explicitly represented in the firing system’s script file
Splitter box A pre-defined distribution box or rail for a module’s electrical terminals, which is not explicitly represented in the firing system’s script file
Rail address A two-part or one-part address like “1-B” or “1” that specifies both the module and slat (a two-part address) if slats or virtual slats are required, or just the module number otherwise (one-part address)
Module number The one-part address identifying a specific module

 

The most common need for slats, virtual slats, and splitter boxes is to partition a module’s pins into boxes or rails that can be located at different launch positions, but you might also want to locate the slats at different rack clusters or at different racks themselves within a launch position.  The addressing system of Finale 3D supports all these use cases  with the same mechanism: addressing constraints.

Slats at different launch positions

Suppose you have one Explo module with 70 pins that are distributed to three different launch positions using three splitter boxes with twenty pins each (10 pins being left over, unused). It would be important when addressing the show to apply the constraint that each splitter box is restricted to serving a single launch position, for otherwise you might have e-match wires running from position to position. But it would be too restrictive to constrain each module to serving a single launch position, because that would defeat the whole idea of using splitter boxes to distribute the module’s pins among multiple positions.

In this scenario, you would use the addressing constraints section of the “Addressing > Address show…” dialog to specify that slats are restricted to a single position, but modules are not restricted to a single position.  You would address the show with the firing system = “Explo”, and module type = “Explo 3 x 20K” to indicate you want to use the Explo 20-pin splitter boxes.  Based on these parameters, the addressing function will assign as many splitter boxes as necessary to your three launch positions and will ensure that no e-matches are required to bridge from one position to another.

In practice, large shows that use splitter boxes typically don’t use splitter boxes everywhere.  They use splitter boxes for certain positions that are close together and use non-splitter modules for the other positions.  To address a show like this, you need to create two separate sets of addressing constraints for the two kinds of positions — those that use splitter boxes, and those that do not.  The Finale 3D menu item “Create addressing blueprint…” presents a dialog very similar to the “Address show…” dialog, enabling you to create sets of addressing constraints called “Addressing Blueprints.”  Create two blueprints, one with slats restricted to a single position and modules unrestricted (for the positions using splitter boxes); the other with modules restricted to a single position and slats unrestricted (for the positions not using splitter boxes).  Right-click on the positions and edit their position properties to assign the appropriate addressing blueprint to them, and set their module type to “Explo 3 x 20K” for the splitters or “Explo 70K” for the non-splitter modules.  Do the menu item “Addressing > Address show using blueprints assigned to position…” to address the show.

 

Table 2 – Blueprint for slats at different positions connected to the same module

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

 

One more consideration remains.  A large show may have multiple groups of positions that are in proximity with each other, but the groups themselves may be far apart.  If you use splitter boxes for all these positions, the slat constraints and choice of module type will correctly indicate splitter boxes and ensure no e-matches bridge between positions, but there’s no guarantee the splitter boxes associated with the same module are anywhere near each other.   To keep the splitter boxes associated with any individual module within the same group of nearby positions, you need to indicate what the groups are by right clicking on them and assigning a group name to the “Section” field in the edit position properties dialog.  Each group of nearby positions should have the same section name, which can simply be a number or letter or any text string, whatever you want to call it.

If you look closely at the “Address show…” dialog or the “Create addressing blueprint…” dialog, you will see that the module constraints line says, “Each module is restricted to a single section and…” (emphasis added).  Modules are automatically restricted to single sections, so you don’t need to change your addressing blueprints at all.  Assigning your positions to different sections to indicate their groups will ensure that splitter boxes will only refer to modules used within their group of positions.

 

Table 3 – Blueprint restricting modules to serve a single position each

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

 

Slats at different rack clusters in the same launch position

Slats can also be used to distribute pins to different rack clusters or racks within the same position.  If you are planning to use Finale 3D for rack layout, which is optional, please see Rack layout basic instructions to familiarize yourself with the rack layout capabilities.

Suppose again that you have one Explo module with 70 pins that are distributed using three splitter boxes with twenty pins each (10 pins being left over, unused), but imagine that each splitter box was to attach to a group of racks (called a “Rack Cluster“).  When addressing the show you would need to apply the constraint that each slat is restricted to serving a single rack cluster, but each module is only restricted to serving a single position.  The settings are shown in Table 4.  As in the previous scenario, you would also set the module type in the “Addressing show…” dialog or the edit position properties dialog to “Explo 3 x 20K” to indicate you want to address the positions using splitter boxes.

 

Table 4 – Blueprint restricting slats to serve a single rack cluster each

Modules constrained to same Position
Slats constrained to same Rack cluster

 

Slats at different racks in the same launch position

Distribute pins to different racks is the same as the rack cluster scenario, except the slat constraint is just “Rack” instead of “Rack Cluster” as  shown in Table 5.

 

Table 5 – Blueprint restricting slats to serve a single rack each

Modules constrained to same Position
Slats constrained to same Rack

 

Associating slats one-to-one with racks or rack clusters

By constraining slats to the same rack, you are ruling out the possibility that a slat can have e-matches extending to multiple racks, which might not be near each other.  However you aren’t ruling out the possibility that multiple slats can have e-matches to the same rack.  Imagine you had a single-shot rack with spaces for 24 tubes and you were using Explo 20-pin splitter boxes.  If you address the show with the constraints of Table 5, you might end up filling all 24 spaces with effects and using two slats (splitter boxes) to do it, the first slat covering the first 20 effects and the second slat covering the remaining 4 effects.  Since you are constraining slats to a single rack, the second slat’s remaining 16 pins will be unusable for any other racks and thus for any other effects.  They will lie unused.

Depending on the availability of firing system hardware and racks, you may view it as wasteful to leave 16 pins of a 20-pin splitter box unused.  You might prefer to leave 4 tube spaces in the single-shot rack unused, if that meant that your 20-pin splitter box would be fully utilized on a single-shot rack of its own.  You could implement this trade off by adding the constraint that each rack is constrained to a single slat.  The combination of the rack constraint and the slat constraint forces the slats and racks to associate one-to-one — each rack would have one associated slat, which would serve only that rack.  The constraints are summarized in Table 6.

Associating slats one-to-one with racks or rack clusters can facilitate integrating firing system slats into pre-built assemblies of racks or rack clusters.  If you know that racks or rack clusters will be associated with a single slat no matter what, then you can integrate the slat hardware physically with the rack assemblies in advance, before designing or addressing the show, and re-use the assemblies over and over again without needing to adapt them to the addressing requirements of any particular show.

 

Table 6 – Blueprint associating slats and racks one-to-one

Modules constrained to same Position
Slats constrained to same Rack
Racks constrained to same Slat