DriverMUX I/O Addressing

The address used by an I/O tag may or may not need to change when the DriverMUX tag switches between drivers. It is recommended that all communications go through the DriverMUX tag(s) and not through the subordinate drivers at all. The issue is that the DriverMUX will attempt to control all of the polling through the subordinates, which can conflict with the setup of direct-to-driver I/O tags.

If either or both of the subordinate drivers provide an Address Selection dialog, that will be available to the I/O tags connected to the Driver Multiplexer. You have a choice of using the same address for both primary and secondary drivers or configuring separate addresses.

The following three scenarios are provided to help you plan how to use your driver multiplexer.

Scenario 1: Two lines of communication are set up between a PLC in the field and VTScada: one uses radio and the other uses a modem.

In this case, tag addressing is simple: The address is defined by the PLC device and does not change with the communication driver.

Scenario 2: Connecting to different RTUs.

For this scenario, the tag addressing used by the primary driver will be different from that used by the secondary. By way of example, perhaps one used Allen Bradley equipment and the other uses Modicon.

In this case, an I/O Tag will have to reference its intended data location by two completely different addresses. The address parameter of the I/O tag must therefore contain both addresses where each address is given inside curly braces and are given in the order of the Primary and Secondary subordinate drivers.

If (and only if) the DriverMUX is in Parallel or Alternating mode, you can make use of this address format to force an I/O tag to read from only one of the two drivers. Include both sets of braces, but leave the address blank for the driver that you do not want to read from.

Ex. {Primary Address}{Secondary Address}

Scenario 3: A subordinate driver is also a DriverMUX tag, and each driver requires a different address for the I/O devices.

In this scenario, the addresses in each I/O tag will be nested in curly braces where the left to right order matches the primary to secondary configuration of the DriverMUX configuration:

The subordinate DriverMUX should never be configured as the preferred driver1 For the following two scenarios, the primary driver is to the left and the secondary to the right.     For this scenario, MUX1 should be set to secondary preferred mode. This will result in the precedence C, A, B.     For this scenario, MUX1 should be set to primary preferred mode. This will result in the precedence A, B, C.The reason for this recommendation can be seen by examining the first scenario. Suppose that MUX1 is set to primary preferred mode with MUX2 as the primary (not recommended). If A fails, then MUX2 will switch to B. If B fails then MUX1 will switch to C. The difficulty arises when B is restored. MUX2 will continue to report an error mode because it is using its secondary, therefore MUX1 will continue to use C. Thus fail-over would work as intended A -> B -> C, but restoration would be C -> A, skipping B..

Ex. {Primary Address}{{Secondary Address}{Tertiary Address}}

When the need arises to get a value from a specific driver (for example, the battery level of "C") you can ensure the DriverMUX tags do not poll this value from the other drivers by providing empty braces. To get the value only from "B" using the tag layout in scenario 2, the address can be set to something like {}{BatteryAddress}.

For scenario 3, it would be a little more complex: {}{{BatteryAddress}{}} for "B". {BatteryAddress}{{}{}} for "A".