SSCP protocol and the serial link
With the expansion of network technologies we have somehow got used to the fact that even process stations (PLC) communicate with development tools, visualization and other clients via network interface, ie Ethernet with TCP/IP protocol, over which the application protocol is standard (eg BACnet) or manufacturer specific. In addition to high transfer rates, this technology offers low cost, standard interfaces and high technology know-how. A huge advantage is the possibility of remote access and use of the Internet at no extra cost, which saves time during commissioning and service.
But sometimes we get into a situation where the only way to connect two or more controllers to each other or to the headquarters is a serial line – a two-wire line. The most common cases are:
- The racks are more than 100 m apart, which is the maximum length of the Ethernet segment. It is not possible to lay an optical cable that could cover a longer distance.
- It is a reconstruction of an older system, for example a network of heat exchange stations. Serial buses are already installed and their replacement with networks would be uneconomical or impossible.
- We supplement the existing system with another automation station.
- The topology records the use of a serial line: process stations are located in the line instead of in the shape of star or mixed. (This reason works only outdoors; buildings should have no problem building a star topology with Ethernet due to the smaller distances and better accessibility of the installation routes.)
In most systems with proprietary protocols on Ethernet, in these situations, we must use the available serial protocols, usually Modbus RTU, to exchange data between controllers or to bind to the central office. This route has major drawbacks: more complex engineering and less flexibility – it is not possible to play programs, configure the controller, etc. via Modbus serial, which complicates commissioning and service.
Merbon PLCs use their own open SSCP protocol for data exchange and system services, using TCP/IP as the transport layer. The controllers offer an interesting way to solve the above mentioned problem: routing of this native SSCP protocol to the serial link. This means that all controllers, including stopping and starting the program, playing software, reading data, functions such as port monitor, etc., can be implemented via the RS485 bus.
Fig. 1: PLC connection via SSCP serial line via SSCP router
This requires several assumptions:
1. One of the controllers is configured as an SSCP router. Client programs are written without exception for Ethernet communication. If we would like to connect from a laptop from Merbon IDE to controllers on a serial line, for example, via a USB/RS485 converter, we do not have the appropriate software. Only routers with Linux OS, ie mark220, mark320 or markMX can be used as a router.
2. Each controller has one serial port (usually RS485) dedicated to the SSCP protocol. It is no longer possible to connect other devices to this port, such as I/O modules, room controllers and controllers, etc. The port is used exclusively for SSCP communication.
3. Each controller that serves as an SSCP server must be configured accordingly, as shown below, and must have a unique line address (SSCP address) on the bus.
When designing, we must observe the general rules concerning the RS485 bus: the line must be terminated by a terminating resistor (switch BUS END) at both ends. Theoretically, there may be 255 automation stations on the bus, but in practice we will not exceed 30 to 40, even with a maximum bus length of 1200 m. The bus should be linear, although Domat components are quite tolerant of more varied topologies. The router does not necessarily have to be at the end of the bus – it behaves electrically like a controller in the role of SSCP server, so it can be placed anywhere on the line. We use communication cable – twisted pair, LAM DATAPAR or J-Y (St) Y 2 × 0.8 mm. Avoid transmission over longer distances (hundreds of meters) over telephone lines, often found in areas such as factory complexes, barracks, etc., the telephone wire is relatively thin and lacks a guaranteed number of twists per meter of length.
The sets in which we create projects are likely to be in Simplified mode so that we can use the automatic functions. Then we are limited to one PLC in an assembly. Both the router and SSCP server could be configured in Full mode and in a common configuration, but in more configurations the work will be clearer and faster, especially for larger programs.
Configuring the router is quite simple, the procedure is also described in the Merbon IDE help. In the PLC Properties, enable the serial router and select the serial port to be connected to the SSCP line. In our example, it is COM4.
Fig. 2: PLC setting in SSCP router function
We choose the communication speed according to the line length and quality of the line. In terms of data throughput, it is preferable to keep the speed as high as possible, on the other hand, for longer, older or less twisted cables, this would mean a higher error rate and hence an overall lower effective transfer rate. It is recommended that you try the maximum speed of 115200 bps first and gradually reduce it in case of problems. Obviously, all PLCs on the line must have the same speed, so be careful when remotely changing, it is easy to “slam.”
A PLC as a router need not be dedicated to SSCP routing: it can normally perform regulatory tasks and communicate with other I/O modules through other ports, etc.
For SSCP servers, the settings are similar:
Fig. 3: SSCP server settings
Note the first item in the group: SSCP address. It must be unique on the entire serial line and it is also referred to when establishing connections in Merbon IDE.
We leave the number of registered groups and Number of variables in the group at the default values. By increasing the values, the throughput can be optimized to some extent, but it depends on the quality of the line so that the effort is not counterproductive.
Remember to load the modified configuration into the controllers and restart the controllers. Due to the throughput of the line, we replay the stations gradually, one by one. When replaying all at once, as we are used to in Ethernet, the bus would be congested and the process could end up in timeouts.
When connecting from the SSCP client, we will use the IP address of the SSCP router and the SSCP address of the relevant controller for all controllers. For SSCP servers, the Ethernet interface is not connected, more specifically for SSCP communication with this client is not used. However, this does not mean that it cannot be connected to another client, such as the HT102 or HT200 local operator terminal. Just check in SSCP parameters that TCP server is enabled. However, we have to realize that terminals are no longer accessible from a network that has an IDE or headquarters.
Fig. 4: Connecting multiple PLCs via SSCP router
When connecting and updating values, we have to count on a somewhat slower response than on Ethernet. Usually this is not a problem.
Using a serial line for SSCP communication will allow us (except for reduced speed) to work fully with PLC including all configuration and programming functions. SSCP routing is particularly important in reconstructions and replenishment of the system where the installation of additional cables is technically impossible or would not make economic sense. Still, we prefer a more modern and significantly faster Ethernet network – plus we save a serial port in the PLC for additional I/O modules or third party integration.