The module <Serial> of the subsystem "Transports"
| Module: | Serial |
| Name: | Serial interfaces |
| Type: | Transport |
| Source: | tr_Serial.so |
| 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 |
Introduction
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.
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.
Fig.1. Configuration dialog of the incoming serial interface.
Using this dialog you can set:
- The state of transport, namely: "Status", "Running" and the name of the database, containing the configuration.
- Id, name and description of transport.
- Address of the transport in the format: "dev:spd:format[:fc[:mdm]]". Where:
- dev — address of the serial device (/dev/ttyS0);
- spd — speed of the serial devices from a number of: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 or 921600;
- format — asynchronous data format "{size}{parity}{stop}" (8N1, 7E1, 5O2, ...);
- fc — flow control:
- "h" — hardware (CRTSCTS);
- "s" — software (IXON|IXOFF);
- "rts" — using of the RTS signal for transferring(false) and checking for echo, for raw RS-485;
- "rts1" — using of the RTS signal for transferring(true) and checking for echo, for raw RS-485;
- "rtsne" — using of the RTS signal for transferring(false) and without checking for echo, for raw RS-485;
- "rts1ne" — using of the RTS signal for transferring(true) and without checking for echo, for raw RS-485;
- "RS485" — use RS-485 mode, by TIOCSRS485.
- mdm — modem mode, listen for 'RING'.
- The choice of transport protocol.
- The state, in which the transport must be translated at boot: "To start".
- Time intervals of the interface in the format of string: "character:frm[::rtsDelay1:rtsDelay2]". Where:
- character — character time, in milliseconds. Used for control of the end of the frame;
- frm — the maximum time of the frame in milliseconds. Used to limit the maximum size of the package of the request (frame);
- rtsDelay1 — the delay in milliseconds from the transmitter enabling by the RTS signal and to same the transferring;
- rtsDelay2 — the delay in milliseconds from the transferring finish and the transmitter disabling by the RTS signal.
- Input flow task priority.
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).
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:
- Requests timeout of the modem in seconds.
- The time delay before initializing the modem in seconds.
- The time delay after initializing the modem in seconds.
- The first initialization string typically contains the reset command of the modem "ATZ".
- The second initialization string.
- The result string of the modem's initialization, usually "OK", with which the modem answers for initializing and which must be expected.
- The call's request, usually is "RING", which is sent by the modem in the case of an outgoing call.
- The answer to the call, usually is "ATA", which is sent to the modem to answer the call.
- String result of the answer the call, usually is "CONNECT", with which the modem answers to the answer command, and that is to be expected.
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.
Fig.3. Main tab of the configuration page of outgoing serial interface.
Using this dialog you can set:
- The state of transport, namely: "Status", "Running" and the name of the database, containing the configuration.
- Id, name and description of transport.
- Address of the transport in the format: "dev:spd:format[:fc[:modTel]]". Where:
- dev — address of the serial device (/dev/ttyS0);
- spd — speed of the serial devices from a number of: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, 460800, 500000, 576000 or 921600;
- format — asynchronous data format "{size}{parity}{stop}" (8N1, 7E1, 5O2, ...);
- fc — flow control:
- "h" — hardware (CRTSCTS);
- "s" — software (IXON|IXOFF);
- "rts" — using of the RTS signal for transferring(false) and checking for echo, for raw RS-485;
- "rts1" — using of the RTS signal for transferring(true) and checking for echo, for raw RS-485;
- "rtsne" — using of the RTS signal for transferring(false) and without checking for echo, for raw RS-485;
- "rts1ne" — using of the RTS signal for transferring(true) and without checking for echo, for raw RS-485;
- "RS485" — use RS-485 mode, by TIOCSRS485.
- modTel — modem telephone, the field presence do switch transport to work with modem mode.
- The state, in which the transport must be translated at boot: "To start".
- Time intervals of the interface in the format of string: "conn:symbol[-NextReqMult][:KeepAliveTm[:rtsDelay1:rtsDelay2]]". Where:
- conn — waiting time of the connection i.e. response from the remote device;
- symbol — symbol time, in milliseconds. Used for control of the end of the frame and for timeout of the next request;
- NextReqMult — next request's multiplicator to the symbol time, 4 by default;
- KeepAliveTm — keep alive timeout in seconds for restart transport;
- rtsDelay1 — the delay in milliseconds from the transmitter enabling by the RTS signal and to same the transferring;
- rtsDelay2 — the delay in milliseconds from the transferring finish and the transmitter disabling by the RTS signal.
- No stop on proceed. Sometime opened device closing can be breakage, on ICP-DAS LP PLC for example, then you alowed to prevent it by that option.
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).
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:
- Requests timeout of the modem in seconds.
- Lifetime of the connection in seconds. If during this time there will be no data transmission over the transport the connection will be aborted.
- The time delay before initializing the modem in seconds.
- The time delay after initializing the modem in seconds.
- The first initialization string typically contains the reset command of the modem "ATZ".
- The second initialization string.
- The result string of the modem's initialization, usually "OK", with which the modem answers for initializing and which must be expected.
- Dialing string to the remote modem, usually is "ATDT". When you dial the phone number is appended to this prefix.
- The string result of the successful connection, typically is "CONNECT".
- The string result of the busy line, usually is "BUSY".
- The string result of the absence of the carrier in line, usually is "NO CARRIER".
- The string result of the lack of dial tone in the line, typically is "NO DIALTONE".
- The exit from data mode string, is usually "+++" and "the time delay before initializing" after it used.
- The command hang up, is usually "+++ATH". This command is called whenever there is need to break the connection.
- The string result of the hang up command, usually is "OK", with which the modem answers to the command and which must be expected.
3. User programming API
Object "Outgoing transport" (SYS.Transport.Serial.out_{OutTransport})- bool TS( bool rts = EVAL ) — To Send control by set request rts and return Clear CTS state.
- bool DR( bool dtr = EVAL ) — Device ready to communicate control by set Terminal Ready dtr and return Set Ready DSR state.
- bool DCD() — Data Carrier Detect return.
- bool RI() — Ring Indicator return.
- int sendbreak( int duration = 0 ) — Send to the stream a break by zero in duration (0 — some default duration).
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!
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.
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:
-
ICP DAS: tDS-7xx — configures by WEB-interface and works straight on connection to TCP-port;
- Tibbo: DS100 — configures only by the program for MS Windows®, provides self driver for virtual serial interfaces preparing on Linux, works straight on connection to TCP-port.