Driver Server Lists

You can assign a server list to drivers using the ID tab of the tag's configuration panel. One server list can be shared by many drivers.

A list of excluded drivers is included at the end of this topic.
Custom drivers (those not included with VTScada) may not have a Server List parameter. Most of these will recognize a DriverServerListName parameter that is defined in a parent Context tag or Context-based type. See notes later in this topic.

There is no need to create a server list at a small site where there is only one server, or where all drivers use the default server list.

 

Any existing server list can be selected or you can define the name for a new server list. One server list can be used for as many drivers as needed, assuming that the servers in that list are able to connect to the specified hardware for each driver. Different types of drivers can use the same list.

If you create a name for a new server list within the driver, it will be flagged as shown in the following figure. The driver will use the system's default server list until you define the servers for the new list. (Servers for Specific Services)

Alternative: Assign a Server List in a parent tag

If a parent Context tag (or Context-based type) contains a setting named "DriverServerListName", whose value is set to a valid name, all driver tags that are descendents of that Context will use that list unless otherwise configured. This method is recommended for use with custom drivers that do not have a Server List parameter.

Notes:

• If you have defined a DrivernameSharedRPC or DrivernamePortSharedRPC property, it will have priority over the server list.
• If your driver has a valid Server List parameter, and there is a parent Context with a valid DriverServerListName parameter, the driver's local Server List will have priority.
• If there are parent and grand-parent Context tags, each with a DriverServerListName parameter, the closest parent to the driver has priority.
• Notes for Context tags apply equally to user-defined types that you create from Context tags.
• A server list name cannot contain a backslash character.

Server Lists versus SharedRPC

Traditionally, every driver in VTScada has its own service. This continues to be true. In older versions, you needed to create a server list for each driver's service. The feature described in this topic lets you create one server list that can be shared by many drivers of many types. Each driver keeps its own service, meaning that the failure of one does not affect any other driver sharing the server list.

The xSharedRPC property for a driver puts all drivers of the same type on the same service. While valuable in certain circumstances, this will cause all drivers sharing that service to fail over when one fails.

Excluded Drivers:

DataFlow driver (Always registers as "DataFlow" service)

PollDriver (Always registers as "PollDriver" service. See following notes.)

TransactionTag (Does not have RPCService)

WorkStationStatusDriver (Only uses the machine itself, no need for sever list)

SNMP Driver (Currently uses SNMP groups to set the RPC Service name)

Polling Drivers

There is a "PollDriver" service that is used for housekeeping tasks but primarily, the Poll Driver inherits the RPC service of its communication driver. To make sure that Poll Drivers work properly, all communication drivers that are attached to Poll Drivers in the same Polling Group must use the same server list.

Driver Multiplexer Tags

These work a bit differently. If you set up a tree of DriverMUX tags and subordinates, the root tag of that master / subordinate tree(*) controls the server list for all subordinate drivers. The server list capability for a subordinate driver will be disabled if a server list is defined in the master Driver Multiplexer.

If a DriverMUX has no subordinate driver, there is nothing for its server list to control. It can still be set, but you will be warned that the multiplexer is not controlling anything.

(*) Referring to the structure defined within the multiplexer, not a parent-child structure in the Tag Browser.

If creating tag-based server lists and using a legacy application created prior to version 10.2, refer to notes in FriendlyTagServiceNames