Workbench-to-station communications

Workbench-to-station communications

Workbench-to-station communications (non-platform communications) occur when you view a remote station from workbench. Typically, this is during remote station engineering operations. Workbench-to-station traffic uses the Fox protocol and port 1911. Using the web workbench (embedded Workbench) both ports 80 and 1911 are used for HTTP access.

Remote programming can be a major consumer of both bandwidth and CPU resources. Proxy points in workbench represent source points in a station. Following, are some of the workbench features that enhance remote programming and can have a big influence on network traffic and CPU usage:

“Lazy loading” of proxy points.

Proxy points are not “loaded” (created in the remote workbench) until they (or one of their child components) are actually viewed in workbench. When a remote station is initially opened in workbench, components are not loaded automatically, but they load when you view the component. This prevents a large initial surge in communication between the remote station and workbench. When a point is loaded, all its ancestors are loaded and they are both cached for the life of the workbench session. A loaded state does not mean that the component status and values are “current” with the master component in the remote station. To make sure that the component values are synchronized and up to date with the master, the proxy component must be in a “subscribed” state.

Subscriptions

Subscription is a mechanism that allows proxy components to be notified when they need to be synchronized. This allows for savings in CPU, memory, and bandwidth resources because components that are not of current interest may be released from subscription (unsubscribed), thus saving resources. A subscribed state usually involves polling or eventing in order to maintain synchronization.

Note: It is possible to chain subscriptions across multiple tiers–causing delays and stale information in the proxy point. For example, you could subscribe to a component in workbench that subscribes to the master in a station. In turn, that station component could be a proxy point for a piece of data that is running in a JACE. The JACE component could be modeling an external device, thus involving another polling operation. This could continue or be multiplied so that update delays are caused and network traffic increased.

Nav tree synchronization

NavEvents communicate across the network to maintain the proxy tree structure in a remote workbench view independent of the complete set of component information. This allows the proxy points to maintain their structure and identity in the nav tree without passing all component information every time the proxy component is changed or moved in the tree.

Leasing

NiagaraAX provides a feature called “Leasing” that ensures that a proxy component is synchronized, but only as a snapshot for immediate use. A lease is a temporary subscription, typically for a minute, that reverts back to an unsubscribed state at the end of its lease time. This concept provides savings in resources by minimizing the time the subscribed state is maintained.

Batch calls

It is very easy to create an undesirable situation with many round-robin network calls in your application environment. This can lead to excessive network traffic and result in poor application performance as well. It is almost always more efficient to use one large batch network call than many small network calls. NiagaraAX provides APIs to batch many common operations, including resolving multiple ORDs to a component or batching subscriptions. For more details about batching calls, refer to the NiagaraAX Developer Guide.