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 out-of-box solutions
- For those who are looking for SCAD for themselves, but cannot be determined
- For those who abandoned this project, without understanding how it works
What for
- This solution allows you to read the meter readings of Mercury 230 and Mercury 200 without any limits
- It's free
The openscada project (oscada.org) is paid little attention to, just one article on Habré is written about it. Most engineers are afraid to touch this product with a three-meter stick, God knows what this Linux is for you. Developing it for more than a decade is actually one person, Roman Savochenko.
Not having previously experience with SCADA in general (and was a little friendly with Linux), I chose him to implement the monitoring of objects in the enterprise. Since I had nothing to compare with, I took the interface and all the data connections with each other for granted. The “quick start” video tutorial helped a lot. I personally think that 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 Neod + for a long time could not understand why it is not working. After all, as compatible with the DCON protocol, it was listed as a project (more precisely, its equivalent). I got into the source of the protocol and ... it turned out that it was completely incompatible with it, like many other collection modules from the list. The first appeal to the forum corrected my problem and a few more errors quite quickly. I will not talk about all the intricacies of the system, it is better to read the above article in Habré or see the “quick start”.
')
After some time, it took me to take readings from the electricity meters Mercury 230. 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 for CSD. But everything is not as bad as it could be, the openscada system is extremely modular and you can even write your own module in C ++, even in a high-level language right in it. The description of the exchange protocol for Mercury 230 can be found on the network without any problems, the manufacturer of Incotex can of course provide you with a description on request, but I did not want to get involved with this red tape.
So, we connect the bus with meters, for clarity and better orientation in the protocol we put konfigurator and sniffer sequentially of the port, open the documentation. We are trying to read the data from the counter with the address 75.
all screenshots are clickable
We see how our data ran.
The exchange protocol for Mercury 230 is very similar to the modbus protocol.
A request to open a communication channel is intended to allow access to data with an indication of the level of access. Two-level data access is implemented in the meter: the first (lowest) is the consumer level, and the second (highest) is the host level
We will try using the configurator to interrogate our counter and see that the first request is the password, and the counter response is 4 bytes. inclusive
Now we will try to implement it on openscada. In C ++, I am not strong, so I decided to implement it in the language embedded in SCAD itself, which is called JavaLikeCalc.Javascript. The poll code itself is implemented in two modules UserProtocol and DevLib. Create a device in the device library and call it m230. Add the attributes netaddr (network address), password (password), transport (serial port) and answer (response to a password request). And write a request.
We now turn to the protocol part and create our user protocol in the UserProtocol and call it m230 as well. Let's start with the network address translation. The code for calculating the modbus CRC16 checksum has already been written a long time ago, I just have to insert it into my code.
Let's create and transport, having registered in it the necessary port, speed and timings.
Now we will create devices in LogivLev, in it we will create a controller as well as parameters (they are also counters). Choose our template, in the configuration we prescribe 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 response from the counter. Password accepted, great !!!
What we try to read the testimony of electricity. Add in the attributes of the template a few entries a few more lines of code for each tariff and for their amount.
Next, add more lines to our protocol. It would 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, it is visible in the screenshot for reading energy. At the end of the 16ric system we translate the data into decimal, besides, this number should be divided by 1000.
We go back into the configuration of the template, set the checkbox “Read energy from reset” and in the attributes we already see data on tariffs.
We are not going to stop at this and 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 from the counter.
We add a few changes on the protocol side. We check the answer to the bytes from which we build an assumption about its length and check it, add our own byte sequence, translate into the decimal system and divide by 100 to answer the voltage and power and 1000 to answer the current.
Now, in the attributes of our counter, we see all its basic data, which of course is many times larger and, if desired, you can add more, for example, the frequency in Hertz and much more.
Add for clarity a few more counters. But this is not all, the data must not only be read but also presented in a convenient form. To do this, in openscada there is a Vision (working user interface) in which the data can be presented in any form convenient for you, even in the form of a mnemonic scheme, in the form of graphs, in the form of documents, etc. Take the standard document from the template and edit it to make it so.
And in the processing of the document we add a line 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 provide instant values ​​or from the archive, create a graph by adding our values ​​there. Here is an example of the values ​​for a voltage meter.
But some time later, the idea of ​​writing a protocol for single-phase meters Mercury 200 did not let go. I did not find the protocol description, 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 is the request and response packet
The serial number of the counter is too long to fit it into a 32-bit integer, so we divide it into two parts.
Tariff request code 0x27, write the request structure and allocate 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, 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 to do if the counter is encoded by the program adjuster +? Fortunately, the encoder + has been encoded by everyone for a long time, so we add a line to the beginning of our code.
We turn to the protocol side. We convert our address into hexadecimal system. Calculation of the checksum and request as in the previous protocol.
Add a few counters and in the configuration of the template write our settings.
And in the Attributes tab, we see how the counter gives the values ​​we need.
Create a document to view these values ​​in a more convenient way. Edit our document template. Run our project.
Everything turned out to be quite simple. This protocol can be downloaded on the oscada.org/ru/forum forum in the "Development of OpenSCADA" section. 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, I just recently decided to share it.
PPS The article most likely has inaccuracies with which Roman would obviously be unhappy.
- For those who use OpenSCADA, but cannot implement more than out-of-box solutions
- For those who are looking for SCAD for themselves, but cannot be determined
- For those who abandoned this project, without understanding how it works
What for
- This solution allows you to read the meter readings of Mercury 230 and Mercury 200 without any limits
- It's free
The openscada project (oscada.org) is paid little attention to, just one article on Habré is written about it. Most engineers are afraid to touch this product with a three-meter stick, God knows what this Linux is for you. Developing it for more than a decade is actually one person, Roman Savochenko.
Not having previously experience with SCADA in general (and was a little friendly with Linux), I chose him to implement the monitoring of objects in the enterprise. Since I had nothing to compare with, I took the interface and all the data connections with each other for granted. The “quick start” video tutorial helped a lot. I personally think that 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 Neod + for a long time could not understand why it is not working. After all, as compatible with the DCON protocol, it was listed as a project (more precisely, its equivalent). I got into the source of the protocol and ... it turned out that it was completely incompatible with it, like many other collection modules from the list. The first appeal to the forum corrected my problem and a few more errors quite quickly. I will not talk about all the intricacies of the system, it is better to read the above article in Habré or see the “quick start”.
')
After some time, it took me to take readings from the electricity meters Mercury 230. 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 for CSD. But everything is not as bad as it could be, the openscada system is extremely modular and you can even write your own module in C ++, even in a high-level language right in it. The description of the exchange protocol for Mercury 230 can be found on the network without any problems, the manufacturer of Incotex can of course provide you with a description on request, but I did not want to get involved with this red tape.
So, we connect the bus with meters, for clarity and better orientation in the protocol we put konfigurator and sniffer sequentially of the port, open the documentation. We are trying to read the data from the counter with the address 75.
all screenshots are clickable
We see how our data ran.
The exchange protocol for Mercury 230 is very similar to the modbus protocol.
A request to open a communication channel is intended to allow access to data with an indication of the level of access. Two-level data access is implemented in the meter: the first (lowest) is the consumer level, and the second (highest) is the host level
We will try using the configurator to interrogate our counter and see that the first request is the password, and the counter response is 4 bytes. inclusive
Now we will try to implement it on openscada. In C ++, I am not strong, so I decided to implement it in the language embedded in SCAD itself, which is called JavaLikeCalc.Javascript. The poll code itself is implemented in two modules UserProtocol and DevLib. Create a device in the device library and call it m230. Add the attributes netaddr (network address), password (password), transport (serial port) and answer (response to a password request). And write a request.
We now turn to the protocol part and create our user protocol in the UserProtocol and call it m230 as well. Let's start with the network address translation. The code for calculating the modbus CRC16 checksum has already been written a long time ago, I just have to insert it into my code.
Let's create and transport, having registered in it the necessary port, speed and timings.
Now we will create devices in LogivLev, in it we will create a controller as well as parameters (they are also counters). Choose our template, in the configuration we prescribe 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 response from the counter. Password accepted, great !!!
What we try to read the testimony of electricity. Add in the attributes of the template a few entries a few more lines of code for each tariff and for their amount.
Next, add more lines to our protocol. It would 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, it is visible in the screenshot for reading energy. At the end of the 16ric system we translate the data into decimal, besides, this number should be divided by 1000.
We go back into the configuration of the template, set the checkbox “Read energy from reset” and in the attributes we already see data on tariffs.
We are not going to stop at this and 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 from the counter.
We add a few changes on the protocol side. We check the answer to the bytes from which we build an assumption about its length and check it, add our own byte sequence, translate into the decimal system and divide by 100 to answer the voltage and power and 1000 to answer the current.
Now, in the attributes of our counter, we see all its basic data, which of course is many times larger and, if desired, you can add more, for example, the frequency in Hertz and much more.
Add for clarity a few more counters. But this is not all, the data must not only be read but also presented in a convenient form. To do this, in openscada there is a Vision (working user interface) in which the data can be presented in any form convenient for you, even in the form of a mnemonic scheme, in the form of graphs, in the form of documents, etc. Take the standard document from the template and edit it to make it so.
And in the processing of the document we add a line 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 provide instant values ​​or from the archive, create a graph by adding our values ​​there. Here is an example of the values ​​for a voltage meter.
But some time later, the idea of ​​writing a protocol for single-phase meters Mercury 200 did not let go. I did not find the protocol description, 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 is the request and response packet
The serial number of the counter is too long to fit it into a 32-bit integer, so we divide it into two parts.
Tariff request code 0x27, write the request structure and allocate 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, 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 to do if the counter is encoded by the program adjuster +? Fortunately, the encoder + has been encoded by everyone for a long time, so we add a line to the beginning of our code.
We turn to the protocol side. We convert our address into hexadecimal system. Calculation of the checksum and request as in the previous protocol.
Add a few counters and in the configuration of the template write our settings.
And in the Attributes tab, we see how the counter gives the values ​​we need.
Create a document to view these values ​​in a more convenient way. Edit our document template. Run our project.
Everything turned out to be quite simple. This protocol can be downloaded on the oscada.org/ru/forum forum in the "Development of OpenSCADA" section. 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, I just recently decided to share it.
PPS The article most likely has inaccuracies with which Roman would obviously be unhappy.
Source: https://habr.com/ru/post/315430/
All Articles