In the previous few articles, I have described the possibilities of using the modbus protocol to create my own Scada system based on python. This time I would like to share the experience of building a system for polling slave devices using OCR technology.
The disadvantages of OPC servers are that they can only be used in the Microsoft Windows operating systems (as a rule, they are paid), and you could forget about devices using Linux OS.
But over time, the OPC Unified Architecture specification (the OPC Unified Architecture) was created, which made it possible to use this data transfer technology on other operating systems other than Windows. This also applies to embedded systems where full-fledged Linux can be launched.
Read more
here.
For example, you can run several different OPC UA servers on the Raspberry Pi single-board computer to poll terminal devices, meters, sensors, etc., while the system will work quite stably.
')
Installing Libraries
Xubuntu 17.04 Desktop and Windows 8.1 are used to work with OPC UA and modbus servers. On Xubuntu 17.04, Python 2.7 and Python 3.5 are already installed by default. Choosing Python 3.5.
If the necessary packages have not been added to the computer after installing the operating system, then you need to run:
sudo apt-get install python3-pip sudo pip3 install pytz PyQt5 sudo apt-get install python3-opcua, libxml2-dev, python3-lxml
We solve the problem of dependencies:
sudo apt-get –f install
After we put the necessary libraries:
sudo pip3 install requests pyserial
For windows, you can install via pip3.exe, the library and examples are located
here.
To start the server, the library must be imported:
import sys from opcua import ua, Server
Now we create an OPC UA server.
server = Server()
That's all the python code to run OPC UA. As it turned out nothing complicated, and if you now connect to the running server using
UA Expert , you can see a hierarchical list of our objects and variables with values.
To modify the values of variables, use the
set_value function of the type:
Discret_1.set_value([1,1,1,1,1,1,1,1])
Of course, this is a very primitive example, but the OPC UA library contains many more features that can be found
here .
The only thing that could not be figured out is how to set the login and password on the server, something like through politics, I think I will solve this problem later.
Server configurator
In continuation of the above, the task arose of quickly configuring each newly created server.
For this purpose, the Server Configurator was written in the PyQt5 library.
Principle of operation:
- database is created on sqlite3
- tables are formed for the slave and master parts of the server.
- the tables are filled with the necessary parameters.
- formed startup script.
The main idea is that servers should work equally in Windows and Linux.
Download
here
Directory structure:
srvconf.py - Server Configurator program
db - the srvDb.db database file is located.
img - .png files for buttons
source - server template files
- mercury.py - a library to survey the counters mercury 230
- modbustcp_master_dcon.py is a modbusTCP slave server, master - polls slave devices using the DCON protocol (Advantech). Currently only the 4050 module.
- modbustcp_master_http.py is a modbusTCP slave server, master forms a request using a GET method using a URL or IP, and we receive a list of int or string values separated by commas. Used for embedded systems with http servers onboard, I used for ESP8266 with wi-fi connection.
- modbustcp_master_ping.py - a modbusTCP slave server, master - sends an ICMP ping packet to the specified server, in the case of true, forms a discrete 1, in the case of false, 0.
- modbustcp_master_rtu.py is the modbusTCP slave server, master is modbusRTU. Used for polling slave devices using the modbusRTU protocol
- modbustcp_master_tcp.py is the modbusTCP slave server, master is modbusTCP. Used to poll remote devices using the modbusTCP protocol.
- opcua_master_dcon.py - OPC-UA slave server, master - polls slave devices using the DCON (Advantech) protocol. Currently only the 4050 module.
- opcua_master_http.py - OPC-UA slave-server, master - forms a request using a GET method using a URL or IP, in response we get a list of int or string values separated by commas. Used for embedded systems with http servers onboard, I used for ESP8266 with wi-fi connection.
- opcua_master_mercury230.py - OPC-UA slave-server, master - polling commands for counters Mercury 230 are generated. The implementation is exclusively for OPCUA, since not all response parameters for this protocol can be uniquely processed in order to be placed in modbus registers.
- opcua_master_ping.py - the OPC-UA slave server, master - sends an ICMP ping packet to the specified server, in the case of true, forms a discrete 1, in the case of false, 0.
- opcua_master_rtu.py - OPC-UA slave server, master - modbusRTU. Used to interrogate slave devices using the modbusRTU protocol.
- opcua_master_tcp.py is the OPC-UA slave server, master is modbusTCP. Used to poll remote devices using the modbusTCP protocol.
scr - script files to start the server.
For Windows, a file of type start_XX.bat will be created, for Linux, a file of type start_XX.sh, where XX is the server sequence number in the servers table.
Contents of the start_XX.bat file:
rem 'ScadaPy v.3.11' rem 'Windows opcua_mercury230 ' rem Slave '192.168.0.103' rem Slave '4840' rem master 'master_mercury230' rem slave 'opcUA' rem tty 'com6' rem tty '9600' start c:\Python35\python.exe F:\scadapy\config\source\opcua_master_mercury230.py 68 F:\scadapy\config\db\srvDb.db
Contents of the start_XX.sh file for Linux:
Linux startup parameters use xfce4-terminal, since I work in Xubuntu 17.04,
but you can specify a different type of launch, like gnome-terminal.
xfce4-terminal --command='sudo /home/jack/config/scr/start_67.sh'
In the examples, the parameters for filling the tables are quite clearly described.
It is noteworthy that 4 servers were simultaneously launched on raspberry Pi - mobus_ping, opcua_http, opcua_mercury230 on / dev / ttyUSB0 and modbus_dcon on / dev / ttyUSB1, while it worked quite stably and without failures.
The control is currently implemented in part and only in master_dcon, therefore only tele-alarm and tele-measurements are used. In the future, I think to add and remote control.