GenBroker

GenBroker puts GENESIS64 in communication with legacy OPC servers residing on other machines in the same network or the internet. So you must set up and use GenBroker if you are talking to a legacy OPC server. You don’t need to use GenBroker if you are talking to OPC UA servers.

GenBroker is a high-speed communications utility you can use to designate network communications for a networked set of workstations. Communications established using GenBroker are used for all GENESIS64 applications. Employing a network of applications, GenBroker uses TCP/IP and SOAP/XML channels to achieve real-time and secure communications between Web browser clients and WebHMI servers. GenBroker technology simplifies the setup of Internet and intranet communications and provides Internet connectivity and operation with firewalls and routers. The basic philosophy of GenBroker communications lies in its use of reliable Request/Response protocols: The client sends requests, and the servers reply to them.

Using GenClient/GenBroker TCP communication gives you the following advantages:

• It works well within, across, and in the absence of NT domains.

• It works well on slow and/or unreliable networks (such as the internet).

• The client side works well behind a firewall.

The GenClient/GenBroker architecture consists of two main parts: GenClient.dll and GenBroker.exe. The GenClient.dll resides on the client side. It can communicate directly with OPC servers (using the traditional DCOM method), or it can establish a connection with GenBroker, which then communicates with the OPC servers on behalf of the client. Unlike DCOM, GenBroker can communicate over the Internet.

For example, a thin client sends a request over the internet to the WebHMI server, using GenBroker to transmit the request. The WebHMI server's response to the request is also returned via GenBroker. But if the thin client's request requires a response from a remote server in a local area network (LAN), WebHMI could be configured to use DCOM. The machine would use DCOM to return the response to the WebHMI server, which then would use GenBroker to relay the response to the thin client.

GenBroker uses the following basic methods for networked communications:

• OPC direct channel. In an OPC direct channel, the client applications, such as GraphWorX64, TrendWorX64, and AlarmWorX64, communicate directly with OPC servers. This method uses standard fast DCOM over an intranet or local area network (LAN). This method of communication is similar to that of OLExpress.

• Direct channel over DCOM. In a direct channel over DCOM, client applications communicate with GenBroker software located on remote nodes on an intranet or LAN. GenBroker communicates (locally) with the target OPC servers on behalf of the client application.

• Direct channel over TCP/IP. In a direct channel over TCP/IP, the client applications communicate with GenBroker software located on remote nodes on an intranet or LAN as well as over the Internet. GenBroker communicates (locally) with the target OPC servers on behalf of the client application.

• Direct channel over SOAP/XML. In a direct channel over SOAP/XML, GenBroker responds to requests from clients that use SOAP/XML communications. SOAP (Simple Object Access Protocol) is an internet communications protocol that uses XML (eXtensible Markup Language) transmitted over HTTP (Hyper Text Transfer Protocol). The main advantage of using SOAP is that, because SOAP operates at the HTTP level (above TCP/IP), data can pass through a firewall without having to change the firewall settings. In other words, SOAP uses the same protocol that we usually use to get web pages. HTTP uses port 80 to establish communication with a server, and this port is usually enabled on most firewalls. The disadvantage of SOAP is that it is slightly slower than TCP/IP.

Most channels, direct or indirect, translate the OPC COM calls into one of two protocols and transmit them to the remote node, where GenBroker can execute them. (The OPC Direct channel is the only exception; it uses OPC calls.) Protocols that every channel can use for these transmissions are:

• DCOM. Suitable for local networks enabled with DCOM.  Not recommended for Internet use.

• TCP/IP. Communicates over the intranet/Internet through routers and firewalls.

• SOAP/XML. Communicates over the intranet/Internet through routers and firewalls.

GenBroker Configuration Properties

You configure GenBroker properties using the FrameWorX Server, as following:

1. Click on Start > All Programs > ICONICS > Tools > FrameWorX Server Configurator.

2. In the Project Explorer, expand Classic OPC, then double-click GenBroker. The GenBroker Configuration Form appears, as shown below.

GenBroker Configuration Connections Tab

Refer to the following topics for descriptions of GenBroker's tabs:

• Channels tab - Refer to the Channels topic

• Redundancy Node Pairs tab - Refer to the Configuring Redundant Servers topic

• Controlled Redundant Servers tab - Refer to the Controlled Redundant Servers topic

• Advanced tab - Refer to topics below for the Advanced tab's sub-tabs:

• • Tag Syntax tab - Refer to the GenBroker Tag Syntax topic

  • Miscellaneous tab - Refer to GenBroker Miscellaneous Tab, below

  • OPC Engine tab - Refer to GenBroker OPC Engine Tab, below

  • Optimization tab - Refer to GenBroker Optimization Tab, below

  • Connection tab - Refer to GenBroker Connection Tab, below

GenBroker Miscellaneous Tab

The Advanced tab's Miscellaneous sub-tab, shown below, contains settings for the client-side cache and its refresh rates and synchronization feature.

GenBroker Miscellaneous Tab

The Default button restores all default property settings to their installation default values.

• Client Side Cache: A check mark in this check box allows you to specify the frequency (in minutes and seconds) in which data on the client side is cached.

• Tag Retry Rate: Define the rate (in seconds) at which the client retries requests for tags or OPC data items from the server after an initial request has failed. Failed alarm and event subscriptions are also requested at the same rate.

The Tag Retry Rate applies to tags where a subscription could not be established for any reason.

Tags that return bad quality (through a previously established subscription) are not considered "failed" for the Tag Retry Rate. They don’t have to be "retried". The server will just send their 'good' value as soon as it becomes available.

A tag may be "failed" in these cases:

• The node or server it belongs to is not available (e.g. due to network disconnection) or does not exist.

• The server returns errors when the client tries to subscribe to the tag.

When a tag is "failed", it still might exist in the future (i.e., it makes sense to repeatedly try to subscribe to it - a computer may need to be turned on, an OPC server's configuration may change, etc.).

The tags with invalid syntax are not "failed" in this sense, because they can never become OK.

If a device is in "commfail" but the OPC server lets us create a subscription to the tag (and probably returns the "bad - communication failure" quality), then the Tag Retry Rate will not apply. If the OPC server itself has failed, and no subscription is made or the pre-made subscription is broken, then the Tag Retry Rate will come into effect.

The Tag Retry Rate is independent of the polling rate for the tag. Most systems have fast polling rates. Accordingly, a fast Tag Retry Rate for failed tags is reasonable in these types of situations. It allows for fast recovery in situations where the OPC server has only briefly dropped offline, or is slow to respond to an initial request. However, for situations where you need a much slower rate, the Tag Retry Rate can be configured to be something slower.

• Sync Call Timeout: Specify the default time out rate (in seconds) for synchronous calls. Some of the GenBroker functions (such as, registering applications, login and logout to and from the Security Server) fail if the relevant server does not respond in the time specified here.

Back to Top (GenBroker Overview)

GenBroker OPC Engine Tab

The Advanced tab's OPC Engine sub-tab contains settings for allowing the use of different OPC versions, setting OPC DA group names, and some additional queue and status settings. The OPC Engine offers the following options:

GenBroker OPC Engine Tab

The Default button restores all default property settings to their installation default values.

• OPC Versions: Tells the GenClient which OPC version(s) to use. Select the versions of OPC Data Access that apply.

• Group Name Format: Specify a format to be used as the OPC Data Access group name. This format typically consists of a name for the OPC data access group, and asterisks (*) that identify each position to be replaced by group numbers. When GenClient creates an OPC group on a DA server, it uses the format defined here. Asterisks (*) are replaced by the group numbers, so each group has a unique name. If there are no asterisks in the format, the group number is appended to the value provided in this field. When no group name is specified here, GenClient lets the server create a group name.

• Runtime Status Retrieval Rate: A server may get stuck or become so slow that it cannot process requests from GenBroker, even though it is still considered to be alive. When this happens, the requests to the server are stored in a queue in GenBroker. The Request Queue Length Limit defines the maximum size of the queue. We strongly recommend that you set the queue length limit to a number greater than the number of points on the largest display.

• Refresh from device instead of refreshing from cache: In the Runtime Status Retrieval Rate field, specify the time (in seconds) the cache will keep an item requested. When a client releases an OPC item (such as a tag), the item is not actually removed from the server but instead is moved into the item cache. Then, when the client requests the same item again, the item is retrieved from the cache instead of being released from the OPC server again. However, if Refresh from device instead of refreshing from cache is checked, the item is retrieved from the I/O device to which the OPC server is connected.

• Get attributes when the server configuration: This check box sets an option to force the client to re-acquire attributes (such as ranges, canonical data type, access rights). If this check box has a check mark, when the server sends a bad quality value with a substatus of "configuration error", the client re-acquires the attributes. If this checkbox is empty, the attributes are obtained only initially.

Back to Top (GenBroker Overview)

GenBroker Optimization Tab

The Advanced tab's Optimization sub-tab, shown below, controls update and cache items which can be helpful in adjusting the performance of the service.

GenBroker Optimization Tab

The Default button restores all default property settings to their installation default values.

• Minimum and Maximum work period length ( ms): GenBroker periodically collects requests from the clients. It uses an adaptive algorithm to set the collection rate, but the rate (in milliseconds) is always within the range you specify here. The longer the period, the more requests GenBroker may collect. Requests collected together in a period are processed together, which is more efficient than processing them separately. Also, the longer the period is, the longer clients have to wait for responses to their requests. So a short period means quicker responses but less efficient processing of the requests. With a longer period, the DCOM calls may be more efficient, but the response delay is longer.

• Smoother Updates: When GenBroker is idle, it can prepare updates in advance. As a result, it sends more updates to the client and runs more smoothly. But this also means more traffic over the network and more CPU utilization. If you want GenBroker to prepare updates in advance, select Always or Only Direct OPC from the Smoother Updates drop-down list. In the Prefetch Queue Max Length specify the limit to the number of updates prepared in advance. If you don’t want to use this feature, select None from the Smoother Updates drop-down list.

• OPC Item Cache: Put a checkmark in the OPC Item Cache checkbox to cache OPC items such as tags. When the cache is enabled, released OPC items are put into the cache rather than removed from the server; when the items are requested again, they will be taken from the cache.

Caching OPC items is optional, and you can switch this feature on and off. To your advantage, it improves the speed of screen switching. Caching takes place for both OPC Direct operation and operation via GenBroker channels. If you use caching, in the Cache Size specify the maximum number of items to be stored in the cache.  If you like, put a check mark in the Remove Items Older Than (X) Seconds check box, then define how long (in seconds) the items should be kept in the cache. When Deactivate Cached Items is checked, the items are deactivated when put into the cache, thereby decreasing the number of updates coming in from the OPC servers (otherwise the items in the cache are also updated).

• Attribute Enumeration: This section specifies how enumeration is made. Enumeration is a way to get OPC items‘ ranges and access rights:

None: Turns enumeration off so the attributes are not obtained. When ranges are not required, this could improve display switching speed.

Standard: Enumerates all items in the current OPC group. When an item is added to a group (for example, an item in a pop-up window), the whole group is enumerated again.

Intelligent: A separate group is created for the newly added items, and the new group is enumerated and then removed. Intelligent enumeration only enumerates the newly added items, but it uses some overhead to create and destroy the auxiliary group. Standard enumeration does not have this overhead, but it also enumerates items already on the display. If your users have large displays with pop-up windows, intelligent enumeration is typically faster. But if your users just switch between displays, standard enumeration is faster because there is no overhead.

• Enumerate Attributes One by One (slower): Putting a check mark in the Enumerate Attributes One By One (slower) check box forces GenBroker to ask for attributes one by one rather than getting them all together in one call. Put a check mark here only if the OPC server that is in use has compatibility problems with gathering all attributes.

Back to Top (GenBroker Overview)

GenBroker Connection Tab

The Advanced tab's Connection sub-tab, shown below, controls different communications properties for each of the defined connections.

GenBroker Connection Tab

The Default button restores all default property settings to their installation default values.

The Connection sub-tab offers the following options:

• Connection Control: Use the options in this section to test the client’s connection to the OPC server.

• Connection test rate local/remote (secs): Define how often (in seconds) GenBroker should test each OPC server connection to make sure the connection and the server are alive. The client tests an OPC server by periodically reading the server’s status.

The frequency of the test for remote servers can be different than the frequency for local servers. Specify the test rate for the local OPC server on the left, and for the remote OPC server on the right. Note that a remote server is actually local for a GenBroker that is located remotely but on the same node as the server.

• Connection test time out rate local/remote (secs): Specify how long (in seconds) the client is to wait for a response from an OPC server before considering the connection to that server to be broken or the server to be unavailable. Note that regardless of the value you enter here, if the server returns a failed status, the client considers the server to be unavailable.

The frequency of the test for remote servers can be different than the frequency for local servers. Specify the time out rate for the local OPC server on the left, and for the remote OPC server on the right. Note that a remote server is actually local for a GenBroker that is located remotely but on the same node as the server.  

• Connect Retry Period: When GenBroker has lost its connection to a server or the server is unavailable, it will try to reconnect after the number of seconds specified in the Connect Retry Period field. The client will continuously try to reestablish the connection every n number of seconds.

• Callbacks section: Use the options in this section only if you are using Windows on your clients and servers. When the client gets OPC data using DCOM, the OPC server creates a callback connection to the client that it uses to notify the client of value changes; conditions in a Windows server environment may prevent the client from checking the callback status using the settings in the Connection Control section, so it is important that you use these settings to test the callback connection. Use options in this section to detect and repair failed callbacks from the OPC server to the client if you are running Windows.

• Minimal Callback Rate: Specify the number of seconds that can pass between updates from an OPC server for the server to be considered alive. When determining a number of seconds, keep in mind that the OPC server does not have to send updates at a predetermined rate; instead it sends updates when it has them. The frequency you set should reflect how frequently data is typically updated in the OPC server. A value of 0 (zero) means that no test will be done.

If a server’s values are typically constant, it is acceptable for the server not to send updates. However, if the server doesn’t send an update inside the time frame specified in the Minimum Callback Rate option, the client can force the server to send an update so that client knows the server and the connection are still alive. You can choose one of the Force options (below) so that the server must refresh even the constant values. (Make sure you choose no more than one; choosing more than one generates additional, unnecessary traffic.)

• Force Callback with Refresh: This option forces the server to send all values, even constant ones. Using this option may increase network traffic dramatically because all values are being sent periodically; for this reason, choose this option only if data changes so frequently that a forced callback is rare. If you choose this option, specify how often (in seconds) GenBroker should force OPC servers to refresh the data values. Enter 0 (zero) to turn this feature off.

• Force Callback with Async Read: This option forces the client to read one item in each OPC group to check the state of the callback connection. Using this option creates less network traffic than, and therefore is preferred over, the Force Callback With Refresh option. If you choose this option, specify how often (in seconds) you want GenClient to force the asynchronous read. Enter 0 (zero) to turn this feature off.

• Force Callbacks with OPC 3.0 Keep Alive Calls: (For use with only servers conforming to OPC DA 3.0.) This option makes use of Keep Alive callbacks defined in OPC 3.0. If you choose this option, specify how often the server sends empty callbacks so the client can check that the callback connection is alive even when there is nothing to read or refresh. Enter 0 (zero) to turn this feature off.

• Action on Callback Failure: Specify what GenClient is to do when a callback connection failure is detected. A failure is detected when no callback occurs inside the time frame specified in the Minimum Callback Rate field, and then no forced callback occurs. Choose one of the following options:

Re-advise (the default): The client re-creates the callback connection.

Re-create OPC Group: The client destroys the group the callback connection is bound to, then re-creates the group along with the callback connection.

Re-Create Server: The client destroys the whole server, as when the whole server dies.

Back to Top (GenBroker Overview)