Tahsin Tosun is a member of PTC’s Kepware Solutions Consultants team, a global team of industrial connectivity experts who help users create connectivity solutions for industrial data acquisition, industrial automation and enterprise digital transformation. Tahsin has spent six years working in industrial automation, data acquisition, IT-OT integration, and has deep domain expertise in Kepware products, industrial networking and systems integration. Tahsin holds a BSc in Control and Automation Engineering from Istanbul Technical University.
When discussing optimized automation systems, network communications are a common concern because of their significant complexity. Luckily, Kepware Server has a number of tools available that make difficult optimizations easy to implement. In this post on project optimization, one of the optimization tools available of a Kepware Server project will be outlined: the channel optimization.
What is channel communication in Kepware Server?
First, a primer on channels. In Kepware Server, a channel defines two key parameters that the server uses when communicating to target devices: the protocol driver that will be used to correspond with target devices and a communications medium (usually Serial or Ethernet) that will allow messages to be transmitted and received. Channels are the parents of device objects in the server project. While channels define a protocol and communications medium, devices define how the protocol driver referenced in the channel should communicate with an individual device.
What is the difference between single channel and multi-channel communications?
When creating channels in Kepware Server, it is important to know that one communication thread is created per channel. This means that when multiple device objects are configured below a single channel, the single thread will communicate to one device at a time. The thread will correspond with each device to obtain data for all tags referenced by the clients connected to Kepware Server. If the device does not respond to the request messages, the driver will retry and time out per the settings configured in the Timing tab of Device Properties before moving on to the next device in the channel.
In some environments, this can be an advantage. For example, if multiple serially-connected PLCs are placed behind a Serial to Ethernet converter, a Kepware Server project that has one channel dedicated to each Serial Modbus PLC may quickly overwhelm the converter or the Serial network. In this environment, one channel with many devices would be appropriate. In contrast, if each Modbus PLC was individually connected to the Ethernet network, users could significantly improve the overall communication performance of the Kepware Server project by placing each device on its own channel. This way, Kepware Server would create one communication thread per device, and communication to each device would occur simultaneously. Further, a user could employ multiple channels to communicate to the same PLC, spreading the full tag load across channels, or dedicating a channel for reads and a second channel for writes.
How do you optimize communication channels?
Kepware Server also has optimization features at the channel level. Channel Serialization allows multiple channels to be grouped together into a “virtual network” where only one channel will communicate at a time. This feature is useful in environments where multiple protocols must be used to gather data from remote locations connected through a limited-bandwidth telemetry device (such as a low-performance Ethernet bridge or radio modem). In these cases, having one message transmission and receipt at a time yields better system performance than multiple simultaneous requests.
Another optimization at the channel level is Serial COM Port Sharing. This feature allows multiple channels in Kepware Server to utilize the same Serial COM port of the host machine regardless of the protocol driver used in the channel. For example, a channel using the Modbus RTU Serial Driver and a channel using the ABB Totalflow Driver and other channels using Serial drivers can take turns issuing requests and receiving responses over the same Serial COM port.
A third optimization at the channel level is the Inter-Device Delay. In understanding this feature, it is important to remember that when multiple devices are assigned to a single channel, the single communication thread created at the channel level corresponds with each device sequentially, one at a time. The Inter-Device Delay forces the single communication thread to wait a period of milliseconds before initiating communications with a device, thus slowing the communications thread as it initiates communication with each device in the channel. A Kepware Server communication thread moves extremely quickly between communications to devices in a channel: if target devices are connected through a radio, cellular, or other type of modem, the modem may be sent a request for the next device in the channel before it has switched from receive to transmit mode. This can result in failed reads or writes that must be retried — which, in turn, slows communication performance significantly. The Inter-Device Delay is only available on select drivers: simply refer to the driver’s help documentation to see whether it is supported.
Hopefully, this post has given you a better understanding of the tools available to optimize network communications when working with channels in Kepware Server.
Chat with an Industrial Connectivity Expert
Ready to learn more about how Kepware can help solve your industrial connectivity challenges? Talk with one of our experts today!
Contact Us