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:
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
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
Select the serial baudrate 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 baudrate, 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 control tasks and communicate with other I/O modules through other ports, etc.
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 in which the management station or Merbon IDE are.
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.