Communication between Merbon and SoftPLC process stations

Exchange of data between SoftPLC and Merbon systems may be required from the following reasons:

  • the project is built in several stages, and supplied by integrators who are using different systems
  • in a project equipped with Merbon controllers, communication drivers available only in SoftPLC controllers are needed
  • in a project equipped with SoftPLC controllers, some of the Merbon functionalities are needed, such as ST programming
  • in a building equipped with one system there is another technology installed which uses the other system as OEM controls (such as AHU or compact heat exchange station).

Every process station is a server in the Ethernet network, and accepts client connections over a communication protocol. Clients may be e.g. the engineering tool (SoftPLC IDE, Merbon IDE), SCADA (RcWare Vision, see figure), HMI panels (HT101, HT200), or any other program communicating over SoftPLC Link protocol for the SoftPLC controllers, or SSCP protocol for Merbon controllers. However, a client may be another PLC, too – both SoftPLC and Merbon PLC do have both communication protocols, SoftPLC Link and SSCP, implemented.


The arrows show the way the connection is established rather than the data flow (there may be both Read and Write variables in a single connection).

Communication from Merbon to SoftPLC

If the values originate in Merbon and shall be communicated to a SoftPLC controller, the easiest way is to insert a SSCP channel in the SoftPLC project, attach as a client to the Merbon PLC, and read the values into SoftPLC variables. As a list of available variables with their identifiers (GUIDs) in Merbon PLC there is a .vlist file, which is located in the [project_name]\bin folder after project build. The file is available in two formats, with Unicode and UTF-8 coding.

Note that this communication is only supported at IPLC501, IPLC510, MXPLC-L. Platforms IPLC201, IPLC301, MXPLC do not provide this option. For these platforms, use Communication from SoftPLC to Merbon as described below please.

The steps are as follows:

  • insert a new TCP channel with SSCP protocol in SoftPLC:


  • in Channel properties, set the IP address of the Merbon PLC, as the SoftPLC will connect to Merbon RT as a client:


  • in Driver parameters, set the user name and password as defined in the Merbon project
  • insert new variable in the Generic table
  • click Communication parameters to open the communication parameters editor; if the variable parameters are known, enter them; if not, load the .vlist file from the Merbon project (Load variable list source) and select a variable:


  • confirm and set the name, type, and optionally other parameters of the SoftPLC variable in the Variable dialogue.

If the Merbon variable is structured (array etc.), parameters Offset and Length may be used to specify the position of the requested data in the structure. Variables may be Read only or Write only: the Write variables are stored in RAM in the Merbon runtime, with periodic saving in the Flash memory. Variables defined in Merbon as RETAIN are written directly to NVRAM.

Similarly, go for other variables in the PLC. Only one connection to Merbon runtime is established even for more variables. If there are more Merbon PLCs to connect to, every PLC shall have a separate SSCP channel.

Communication from SoftPLC to Merbon

If there is an existing SoftPLC system and Merbon PLCs are added, the data from existing SoftPLC controllers may be integrated in Merbon.

  • Add a (client) communication channel in Merbon IDE and select the SoftPLC Link protocol.
  • Set timeout (Max. Telegram Duration) to about 300 ms and Pause between telegrams to about 50 ms.
  • Insert a Device into the channel, and set its communication parameters to connect to the respective SoftPLC Runtime (user name, password, IP address, TCP port). There is a slightly different concept from SoftPLC in Merbon IDE if communication to more SoftPLCs is configured: each SoftPLC is represented by a separate Device, but all of them are within a single SoftPLC Link channel.
  • Insert a data point Group into a Device, and set the Group Read/Write interval according to the required readout rate – for values like outside temperature, about 30 s should be enough.
  • Insert a new variable into the Device, and select the GUID to identify the variable in the SoftPLC project. To select variables, load the .splcproj file from the SoftPLC project:


  •  The variable type is configured automatically.
  • Check, and edit if necessary, the Group type parameter: every variable is either Read Only (from SoftPLC to Merbon) or Write Only (from Merbon to SoftPLC).

Similarly, add more variables, and more Devices if there are more SoftPLCs to communicate to.

Note that for the Write variables the SoftPLC runtime does not tell between connections from a HMI panel or SCADA (which means that the changed variables may be written into EEPROM immediately, as the changes are not very frequent), or from another runtime (which is writing periodically in short intervals, which would destroy the EEPROM after some time). For this reason, all variables in SoftPLC are saved in EEPROM about every 30 minutes.


Every controller has a limited capacity of resources for incoming connections. This has to be considered when designing the communication topology. One coneection should be reserved for servicing and program upload from the IDE. Number of variables within one connection is not limited, however, at hundreds of variables the response time will be longer.

SoftPLC runtime: For IPLC201, IPLC301, and MXPLC there is a limitation to maximum 5 incoming connections. For IPLC501, IPLC510, MXPLC-L, and Windows SoftPLC Runtime it is recommended not to exceed about 20 connections.

Merbon runtime: Process stations based on FreeRTOS (IMIO10x, ICIO20x, mark100, mark150/xxx, mark12x) accept maximum 5 connections from SSCP clients. Process stations with Linux operating system (markMX, mark320, mark220) accept up to 20 connections at a time.

For design of communication between different systems, use basically the same rules as for communication within a single system: it should not be used for critical signals and datapoints within a control loop (e.g. supply air temperature and heating valve control in an AHU). The communication would not work if there are problems in the network. To make the controls safer, use datapoints which indicate communication problems (CommError for a communication channel), or define a default variable value for case of a communication error in SoftPLC (Use default value on comm error in Variable properties).