Not counted towards your tag license limit.
Driver multiplexer (DriverMUX) tags allow you to set up redundant or alternate lines of communication between I/O tags(*) and equipment.
The Driver Multiplexer will not work if you have enabled SharedRPC mode for your communications driver. This mode prevents the DriverMUX from detecting that one driver has failed.
Reference Notes:
(*) Note that the definition refers to communication between the I/O tag and equipment, not between the driver and equipment. Certain drivers, notably the CIP, will generate their own communication traffic in order to do health checks or update addressing. Because the DriverMUX does not stand between the driver and the PLC, it has no control over this automatically generated traffic.
Health checks are not performed when the DriverMUX is in Alternating mode.
It is recommended that all communications go through the DriverMUX tag(s) and not through the subordinate drivers at all. See DriverMUX I/O Addressing for more details.
Possible uses for this tag include:
- Establishing a fail-over communications route in the event that one driver is lost.
In its basic configuration, the DriverMUX tag will direct all communications to the primary driver. In the event that the connection to the primary driver is lost, communication will switch to the secondary driver.
- Upgrading to new communications equipment/drivers with zero downtime.
In this scenario, you would install the new equipment and drivers while the existing system remains in place. The new drivers would be connected to the DriverMUX tag instead of directly to your I/O devices. When you are ready to test the new system, you can direct the DriverMUX to switch to the new, secondary system. If there are problems, then communication will immediately and automatically switch back to the primary system with no loss of data.
- Load sharing between two lines of communication.
The DriverMUX tag can be directed to use both communication drivers in either an alternating or an as-ready basis. While one driver is busy with a large packet, the other can continue to send messages.
If a DriverMUX tag has a Polling Driver for one of its subordinate drivers, then it must have a Polling Driver as both subordinates.
A DriverMUX tag may be subordinate to a Polling Driver.
To log an event for each switch between the primary and secondary communication path, create an alarm that monitors the state of the expression, [DriverMUX Tag Name]\CurrentSubDriver. "CurrentSubDriver" is a property of this tag, identifying the subordinate driver in use.
To log an event for failure of either communication path, create an alarm for each driver. Refer to the topic Communication Driver Alarms for details.
DriverMUX properties ID tab
The ID tab of every tag includes the same common elements: Name, Area, Description, and Help ID.
Name:
Uniquely identifies each tag in the application. If the tag is a child of another, the parent names will be displayed in a separate area before the name field.
You may right-click on the tag's name to add or remove a conditional start expression.
Area
The area field is used to group similar tags together. By defining an area, you make it possible to:
- Filter for particular tag groups when searching in the tag browser
- Link dial-out alarm rosters to Alarm tags having a particular area
- Limit the number of tags loaded upon startup.
- Filter the alarm display to show only certain areas.
- Filter tag selection by area when building reports
When working with Parent-Child tag structures, the area property of all child tags will automatically match the configured area of a parent. Naturally, you can change any tag's area as required. In the case of a child tag, the field background will turn yellow to indicate that you have applied an override. (Orange in the case of user-defined types. Refer to Configuration Field Colors)
To use the area field effectively, you might consider setting the same Area for each I/O driver and its related I/O tags to group all the tags representing the equipment processes installed at each I/O device. You might also consider naming the Area property for the physical location of the tag (i.e. a station or name of a landmark near the location of the I/O device). For serial port or Roster tags, you might configure the Area property according to the purpose of each tag, such as System or Communications.
You may define as many areas as you wish and you may leave the area blank for some tags (note that for Modem tags that are to be used with the Alarm Notification System, it is actually required that the area field be left blank).
To define a new area, type the name in the field. It will immediately be added. To use an existing area, use the drop-down list feature. Re-typing an existing area name is not recommended since a typo or misspelling will result in a second area being created.
There is no tool to remove an area name from VTScada since such a tool is unnecessary. An area definition will exist as long as any tag uses it and will stop existing when no tag uses it (following the next re-start).
Description
Tag names tend to be brief. The description field provides a way to give each tag a human-friendly note describing its purpose. While not mandatory, the description is highly recommended.
Tag descriptions are displayed in the tag browser, in the list of tags to be selected for a report and also on-screen when the operator holds the pointer over the tag’s widget. For installations that use the Alarm Notification System, the description will be spoken when identifying the tag that caused the alarm.
The description field will store up to 65,500 characters, but this will exceed the practical limits of what can be displayed on-screen.
This note is relevant only to those with a multilingual user interface:
When editing any textual parameter (description, area, engineering units...) always work in the phrase editor. Any changes made directly to the textual parameter will result in a new phrase being created rather than the existing phrase being changed.
In a unilingual application this makes no difference, but in a multilingual application it is regarded as poor practice.
Help Search Key
Used only by those who have created their own CHM-format context sensitive help files to accompany their application.
DriverMUX properties Subordinate Drivers tab
Select the two drivers that the multiplexer will communicate with. Either of these may be another DriverMUX tag, with its own primary and secondary device drivers.
If the Primary I/O Device is a Polling Driver, then the Secondary must be a Polling Driver as well.
Primary I/O Device.
One of two device drivers that the DriverMUX tag can switch between. Depending on the purpose you intend use the DriverMUX tag for, this will normally be the device that will be used for the majority of I/O communications.
Secondary I/O Device.
The other of the two device drivers that the DriverMUX tag can switch between. This could be any of a backup route of communication, a new system that you are switching to or even another DriverMUX tag, allowing you to configure three or more redundant lines of communication.
DriverMUX properties Modes tab
Define the operation (and thereby the purpose) of the DriverMUX tag. For each of the three modes, you can select an option from a menu of choices, or you can use a tag or expression to provide external control over the mode.
If defining a tag or expression to control a mode, note that numbering starts from 0, with the top mode in each list being the 0 mode. For example, a tag or expression controlling the Selection Mode would need to set the values 0, 1 or 2 for Automatic, Exclusive Primary and Exclusive Secondary, in that order. If the controlling tag or expression goes to invalid, then the last known good value will be used.
Selection Mode
Automatic
Enables the DriverMUX to switch between the primary and secondary drivers, using rules defined in the other modes. (May be a constant, expression or tag that evaluates to 0.)
Exclusively Primary
Only the driver defined as primary is used for polling. Data may still be pushed in from the secondary, or arrive as a result of a driver health check, in which case you have the option to ignore data from the inactive subordinate. (Refer to the Settings tab.)
(May be a constant, expression or tag that evaluates to 1.)
Exclusively Secondary
Used when only the driver defined as secondary is to be used. Data may still be pushed in from the primary, or arrive as a result of a driver health check. (May be a constant, expression or tag that evaluates to 2.)
Sequence Mode
Primary Preferred
The primary driver is used for all communication unless it fails, at which point communication is handled by the secondary driver. When the primary driver comes back online, communication is transferred back to it. (May be a constant, expression or tag that evaluates to 0.)
Sticky Mode
Similar to Primary Preferred except that communication continues to be handled by whichever driver is in use until that driver fails. Upon failure of the active driver, communication switches to the alternate, where it remains regardless of whether communication is restored to the driver previously in use. (May be a constant, expression or tag that evaluates to 1.)
Parallel mode
Both drivers are used for communication on an as-ready basis. If one driver is busy with a larger communication packet, the other driver will be used for all packets until the first is ready for another packet. (May be a constant, expression or tag that evaluates to 2.)
Alternating mode
Both drivers are used in a strictly alternating basis. If the next driver in turn is still busy with its last communication packet, further communications will be queued until that driver is ready for another packet. (May be a constant, expression or tag that evaluates to 3.)
Secondary Preferred
In this mode, the secondary driver is used for all communication unless it fails, at which point communication is handled by the primary driver. When the secondary driver comes back online, communication is transferred back to it. (May be a constant, expression or tag that evaluates to 4.)
Failover Mode
Failover mode is of use in a multi-server application where backup servers are configured to handle communications in the event that a primary server fails.
Switch Drivers First
In the event that communication is lost with the driver in use, switch to the alternate driver. (May be a constant, expression or tag that evaluates to 0.)
Switch Servers First
In the event that communication is lost with the driver in use, attempt to switch to a backup server to re-establish communication with that driver before switching to the alternate driver. (May be a constant, expression or tag that evaluates to 1.)
Write Mode
By default, the driver multiplexer writes to only the active driver. If the drivers are connected to different hardware devices, then it is possible that one device might not be synchronized with regards to registers that are used as set points or other controls. This could cause unpredictable results in the case of a hardware fail over.
You have the option of forcing the DriverMUX to write to both devices.
Single Device.
The DriverMUX tag writes to the active driver only
Both Devices.
The DriverMUX tag sends all write requests to both the primary and secondary drivers.
DriverMUX properties Settings tab
In the event of a communication failure, the DriverMUX tag will poll the failed driver at a decreasing frequency, watching for communication to be restored. This is done to allow communication to be re-established as quickly as possible in the event of a momentary outage, but to also reduce network load devoted to polling in the event of a longer outage.
Minimum Test Rate (seconds)
The initial frequency at which checks are made to determine a failed driver's state.
Maximum Test Rate (seconds)
The longest period to wait between checks of a failed driver.
Backoff Rate (multiplier)
The time between tests is multiplied by this rate to obtain a progressively slowing frequency between tests until the Max Test time is reached.
Health Check Rate (seconds)
When the mode is set to Primary Preferred and the primary driver is in use, the secondary driver is tested at this rate to ensure its availability.
Health checks are not performed when the DriverMUX is in Alternating mode.
If using a DriverMUX with a Polling Driver, take note that the health check will run independently of the polling order and rate. The heath check is completely unaware that the Polling Driver exists.
Alternate Failure Triggers
It is possible for a driver to report that it is still working, even though no data is being transferred. An example is a radio link: All devices may be in perfect working order, but if the antenna is obscured, no data will be transferred. You can use the Alternate Failure Trigger to monitor some indicator other than the driver itself to determine when the DriverMUX should switch drivers.
A separate alternate trigger is provided for each driver. Use a tag or an expression that will evaluate to TRUE (1) to determine when a failure condition can be considered to have happened. An additional field, "Trigger Delay" is used to set the length of time that the alternate trigger must be true before the DriverMUX will switch drivers. For example, if monitoring for no data being received, it is necessary to wait several seconds to distinguish between a loss of communications and a pause between messages.
Store Last Output Values
When selected, the driver will maintain a record of the last value written to each output address.
If the last output values are stored, they may be re-written by either of two methods:
- Automatically, when communication is restored to the device. Auto-Rewrite must be set on the subordinate drivers that are to participate in automatic re-writing.
- Manually by way of a button press. Store Last Outputs must also be must also be set on both of the subordinate drivers. See, Rewrite Outputs Widget for details.
Changing this value from selected to unselected will cause all stored values to be erased immediately.
Ignore Data from Inactive Subordinate
Select this option to discard any data that is being received by the driver that is not the active one. The default behavior when the box is unselected and the DriverMUX is in "Automatic" mode, is to pass all unsolicited data from both drivers to input tags.
DriverMUX Tag Widgets
The following widgets are available to display information about your application’s DriverMUX tags. Note that, when the DriverMUX tag is in alternating mode, communication statistics shows only a count of switches.
