We write the protocols of counters Mercury 230 and Mercury 200 for OpenSCADA

For whom
- For those who use OpenSCADA, but cannot implement more than the solutions “out of the box”
- For those who are looking for SCADA for themselves, but still cannot decide
- For those who abandoned this project, they still have no idea how it works

Why
- This solution allows you to read the counters of mercury 230 and mercury 200 without any limits
- It's free


The openscada project (oscada.org) is not deservedly given much attention, only one article has been written about it on the hub Most engineers are afraid to touch this product with a three-meter stick, the devil knows what your Linux is. It has been developed for more than a dozen years by virtually one person, Roman Savochenko.

Having no previous experience with SCADA in general (and was a little friends with Linux), I chose it for the implementation of object monitoring at the enterprise. Since I had nothing to compare with, I took the interface and all data connections with each other for granted. The video tutorial “quick start” really helped, personally, I think such lessons could have been done more. The documentation also had to be re-read more than once, but it was worth it. Having connected the first data acquisition module, Nevod + for a long time could not understand why it does not work. After all, as compatible with the DCON protocol, he was listed in the project list (more precisely, its analogue). I climbed into the source code of the protocol and ... it turned out that it was completely incompatible with it, like many other modules for collecting from the list. The first appeal to the forum fixed my problem and a few more errors quite quickly. I will not talk about all the intricacies of the system,

After some time, I needed to take readings from Mercury 230 electric meters. There is no support for these meters in openscada. I tried the taskgroup utility from the creator of the well-known konfigurator, it turned out to be a dead number to poll counters on CSD. But everything is not as bad as it could be, openscada system is extremely modular and you can write your module even in C ++, even in a high-level language right in it. A description of the exchange protocol for Mercury 230 can be found on the network without any problems, the manufacturer Incotex can of course provide you with a description upon request, but I did not want to get in touch with this red tape.

So, we connect the bus with counters, for clarity and better orientation in the protocol we put konfigurator and a serial port sniffer, open the documentation. We are trying to read the data from the counter with address 75.

all screenshots are clickable. We see how our data ran. The communication protocol for Mercury 230 is very similar to the modbus protocol. The request to open a communication channel is designed to allow access to data indicating the level of access. The counter provides two-level access to data: the first (lowest) is the consumer level, and the second (highest) is the host level. Let's try using the configurator to poll our counter and see that the first request is the password, and the counter response is 4 bytes. including

















Now let's try to implement this on openscada. In C ++, I am not strong, so I decided to implement it in the language built into the SCADA itself, which is called JavaLikeCalc.Javascript there. The survey code itself is implemented in two modules UserProtocol and DevLib. Create a device in the device library and call m230. Add the attributes netaddr (network address), password (password), transport (serial port) and answer (response to the password request). And write a request. Now let's move on to the protocol part and create our user protocol in UserProtocol and call it m230 as well. Let's start by translating the network address. The modbus CRC16 checksum calculation code has already been written for a long time, I just have to insert it into my code. We will create a transport by writing in it the desired port, speed and timings.











Now we will create devices in LogivLev, in it we will create the controller and also parameters (they also are counters). We select our template, in the configuration we set the network address, password and transport. It will not be superfluous to enable archiving in the corresponding tab. Go to the Attributes tab and see our 4 bytes of the response from the counter. Password accepted, excellent !!! Well, let's try to read the readings of electricity. We add several more lines of code for each tariff and for their amount to the template attributes in several records.















Next, add another line to our protocol. It will not be superfluous to check the answer to whether the request came and check the packet length. Each 4 bytes of useful response information is interpreted by its sequence of bytes, for reading energy it is visible in the screenshot. At the end of the hexadecimal system, we translate the data into decimal, moreover, this number must be divided by 1000. We go again to the configuration of the template, put the checkbox “Read energy from the reset” and in the attributes we already see the tariff data. We are not going to stop here and will try to add instant data - voltage, current and power. Everything is the same here, we only change the second, third and fourth bytes, which are responsible for what information we want to get from the counter.













We add a few changes on the protocol side as well. We check the response to bytes from which we make an assumption about its length and check it, add our own byte sequence, translate to the decimal system and divide by 100 for the answer about voltage and power and by 1000 for the answer about current. Now in the attributes of our counter we see all its main data, which of course is many times more and you can add more if you wish, for example, the frequency in hertz and much more.







Let's add a few more counters for clarity. But that’s not all, data should not only be read but presented in a convenient form. To do this, there is Vision (working user interface) in openscada in which data can be presented in any form convenient for you, at least in the form of a mnemonic diagram, in the form of graphs, in the form of documents, etc. Take a standard document from the template and edit it to get it this way. And we’ll add a line to document processing so that you can easily read the data archives by day. As a result, we launch the project and open our document. If you need to present instant values ​​or from the archive, we create a graph by adding our values ​​there. Here is an example of a voltage meter value.















But after some time, the idea to write a protocol for single-phase mercury 200 counters at the same time did not stop. I did not find a description of the protocol on the network, but the world is not without good people.

The network address here is the counter password. By default, it is equal to the last 6 digits of the serial number. Let's try to write a template.

Here's the diagram of the request and response packet.



The counter serial number is too long to fit into a 32-bit integer, so we will divide it into two parts.

Tariff request code 0x27, write the request structure and select which bytes for which tariff we are responsible for. And we divide this value by 100. And we check our answer for the volume of characters.

To read the instantaneous values, we use the request code 0x63. Also check our answer for the number of bytes. The nuances for each of these values ​​are also taken into account.

But what if the counter is encoded by the setup + program? Fortunately, everyone knows how the installer + encodes, so we add a line at the beginning of our code. Let's move on to the protocol side. Convert our address to hexadecimal. Calculation of the checksum and request as in the previous protocol. Add a few counters and in the template configuration we will write our settings. And in the Attributes tab we see how the counter gives us the values ​​we need. Create a document to view these values ​​in a more convenient way. Let's edit our document template. Run our project.



















Everything turned out to be quite simple. This protocol can be downloaded on the forum oscada.org/ru/forum in the section "Development of OpenSCADA". And at the moment, as far as I know, this is the only free solution for mercury for an unlimited number of counters.

PS I wrote this case 3 years ago, only recently I decided to share it.
PPS In the article, there are most likely inaccuracies with which Roman would obviously be dissatisfied.

Also popular now: