OpenSCADAWiki: Home Page En/Doc/ Serial ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
Ukrainian (1 )
Russian (1 )
 (2 ) This page is frozen, actual one here.

The module <Serial> of the subsystem "Transports"

Module: Serial
Name: Serial interfaces
Type: Transport
Version: 1.6
Author: Roman Savochenko, Maxim Kochetkov, Maxim Lysenko (2009-2010)
Description: Provides a serial interface. It is used to data exchange via the serial interfaces of type RS232, RS485, GSM and more.
License: GPL



Module of transport Serial provides support of transports based on the type of serial interfaces RS232, RS485, GSM, and others to the system. Incoming and outgoing transports are supported. To add new incoming and outgoing interfaces is possible by means of configuration of the transport subsystem in the system configurator of OpenSCADA.

Into modem mode by the module support misc work mode. Misc mode mean an input transport allow, which wait ingoing connections, and also an output transport allow at idem device. That is the input transport will ignore all requests while the output transport's established connection allow, in idem time the output transport will not try make connection while the input transport have connection or other an output transport connected to other telephone, for example.

 (2 Kb) In normal mode, the serial interface is not allowed to reuse one and the same port incoming and outgoing traffic. Global blocking of the serial device is not carried out in mind the ambiguity of this process at the system level, and re-use can lead to unexpected problems. If necessary, Organization of a local serial line with a pair of connected ports is recommended to use the command "$ socat -d -d pty,raw,echo=0,perm=0666 pty,raw,echo=0,perm=0666".

1. Incoming transports

The configured and runnig incoming transport opens port of serial interface for the expectation of the requests of the clients. Each incoming interface is necessarily associated with one of the available transport protocols, to which the incoming messages are transmitted.

Configuration dialog of the incoming serial interface is depicted in Figure 1.

Configuration dialog of the incoming serial interface. (70 )
Fig.1. Configuration dialog of the incoming serial interface.

Using this dialog you can set:

Transport supports the ability to work as a modem. This mode is activated by the fifth parameter of the address and includes call waiting from the remote modem (request "RING"), answering the call (command "ATA") and the subsequent transfer the requests from the remote station to the transport's protocol. Turning off the communication session is made by the initiator of the connection and leads to the reconnect of the modem-receiver for the waiting for new calls.

To configure the modem of the incoming transport the special tab "Modem" is provided (Fig. 2).

"Modem" tab of the modem's configuration of the incoming serial interface. (67 )
Fig.2. "Modem" tab of the modem's configuration of the incoming serial interface.

With this dialog you can set the following properties of working with modem:

2. Outgoing transports

Configured and running outgoing transport opens port of the serial interface for the sending the requests through it.

Main tab of the configuration page of outgoing serial interface is shown in Fig.3.

Main tab of the configuration page of outgoing serial interface. (80 )
Fig.3. Main tab of the configuration page of outgoing serial interface.

Using this dialog you can set:

Transport supports the ability to work as a modem. This mode is activated by the fifth parameter of the address, and implies the phone call making at the number, specified in the fifth parameter, at the moment of transport's start. After installation the connection with the remote modem all requests are sent to the station behind the remote modem. Turning off the communication session at the transport's stop is made using the activity timeout.

Transport allowed for work with the hardware bus I2 if you select "/dev/i2c-{N}" and the bus permits to set a slave device address by command I2C_SLAVE, from the first byte of request. Speed and format don't play a role in that mode. From the timeouts here in fact works only the symbol time and generically for next request timeout calculate.

To configure the modem of the outgoing transport the special tab "Modem" is provided (Fig. 4).

"Modem" tab of the configuration of modem of outgoing serial interface. (77 )
Fig.4. "Modem" tab of the configuration of modem of outgoing serial interface.

With this dialog you can set the following properties of working with modem:

3. User programming API

Object "Outgoing transport" (SYS.Transport.Serial.out_{OutTransport})

4. Notes

Communications via the serial interfaces have a number of features. The most important feature is the criterion for the end of the message and the waiting time of this criterion. In some protocols, such a criterion is a sign of the end or the specified message size. In other protocols, such a criterion is no data in the input stream for a specified time, the character time. In both cases, the waiting time of criterion or character is a crucial and strongly affects the overall exchange time. Consequently, the smaller this time, the better. Here the problem of hardware and its drivers latency happens.

To check the latency of communication channel and thus optimally to configure the waiting time, character time, you can use the interface tab "Request" of outgoing transport. To do this you need to specify a model request to the protocol, indicating "Wait timeout", send a request and check its integrity. To obtain the more representative result you should repeat the request a few times. If there is getting incomplete answers, the character time should be increased, else it can be reduced.

On embedded serial interfaces RS232/422/485 hardware you can achieve low latency, up to several milliseconds. However, the latency of the high-loaded systems with multiple tasks on a priority of real-time can be nondeterministic in connection with the execution of the events' service thread of the Linux kernel in the low priority. To solve this problem you should install a high priority to these threads that can be done with a script, placing it, for example, to "/etc/rc.local":

The script has not any sense for real-time Linux kernels, includes patch PREEMPT_RT, as well all threads for interrupts and events just already call into real-time priority.

On the external serial interfaces hardware, such as adapters USB->RS232/422/485, you may meet the problems of high latency associated with the feature of hardware implementation or its driver. To solve this problem you need study the configuration of the equipment or adjust the large waiting time, character time!

In the like way you can determine an optimal connection time, specifically: set the connection time to default value for the speed (sets at the speed into the address set), clear "Wait timeout", send the request. If a respond came then let take measured respond time of the device, doubling and set the result value as the connection time. Unreasonable the connection time excess cause to big waitings at the device miss and the safety timers triggers of the internal procedures!

 (2 Kb) On the market meets USB->Serial converters which ones work only for terminals then their can transfer and process only ASCII symbols and unallowed for switch to binary mode. Known ones are: PL2303TA (Y-105).

Virtual/local serial interfaces

Often for local checking, without physical hardware, you may need the ports pair connected each other. For the ports creation and more other operations on serial stream you can use utility socat. For example, to create two linked ports you need call command which will create and print its addresses:

Serial interfaces forwarding through Ethernet network

In some cases there can be useful forward the serial interface port from remote computer to local port, for example to poll devices connected to serial interface of the remote computer. Sure also possible install OpenSCADA to the remote computer into PLC configuration and perform processing this data, previous buffering/archiving and other, but sometime the hardware maybe complicated for OpenSCADA running, where help possibility for serial stream forwarding through network. For the task solve you can also use utility socat or remserial, ser2net, which you can build and start on the remote computer. Examples for serial port forwarding:

In the case "socat", and also possible for other utilities, you can pass start the driver EthernetTCP->Serial on client side and connect from OpenSCADA straight to TCP-port of remote device.

 (2 Kb) In working through the driver EthernetTCP->Serial has one specialty with two connection timeouts, one into the driver and second into Transport.Sockets. Important the timeout value into Transport.Sockets must be more for it into the driver else you will possible get to the request response for previous one.

More manufacturers of industrial communication hardware produce ready converters from Ethernet to RS-232/422/485, which you can use with OpenSCADA in similar way. Here comments and list of the converters for what OpenSCADA working tested:


Referring pages: HomePageEn/Doc

There are 5 files on this page.[Display files/form]
There is no comment on this page. [Display comments/form]