1-wire at the enterprise, program level
The first article in this series is here.
The second part of this cycle is here.
So, the continuation of the topic about 1-wire, in the previous notes, I talked about general information about what 1-wire is and what it is eaten with, and also how we built a large network (cable structure and general idea). In this article, I will try to talk about what programs it all consists of.
')
We have three servers in three different buildings to which an adapter and a 1-wire network are connected through the RS-232 port. On the servers, a program is spinning, which, through an adapter, gives the command to switch branches to the DS2409 chips, interrogates all the sensors found in this branch, then switches to the next branch, and so on in a circle.
It was originally intended to provide data on all sensors via the OPC interface, since it is de facto an industrial standard and by bringing the data to this level we will get simple and wide opportunities for integration with almost any SCADA. Initially, we were looking for a ready-made OPC server solution for 1-wire, these searches brought truly sad results ... Despite the prevalence of 1-wire, it was not possible to find a suitable OPC, and in general it was practically impossible to find a ready-made one.
But they found a rather interesting thing: Fastwel UniOPC . They wrote their own library under it, which implements what is needed: collecting data from sensors in a circle and issuing them through OPC, and after each circle saves the current data to a table on the SQL server.
Lyrical digression:
By the way, this Fastwel project, it seems to me, has long been abandoned and not much updated: it supports only OPC-DA, but I would very much like to see OPC-XML-DA in it, all the same, time moves, technologies go forward, and - The thing is very simple and useful.
Since we are talking about the software, the servers are all based on Windows Server (the versions are different here and there), and the databases are MSSQL, respectively.
The picture shows what we have: three servers, transmit their own sensors via OPC, and also add the current values to the SQL database once in a while (approximately 3 minutes) for further analysis of the history.
As can be seen from the figure, there are two types of clients of this system:
In the workplace of the operator is an ordinary PC running winXP which runs SCADA. One of the initial options was to use a panel computer for the camera room, but it seemed a little expensive, and it was particularly pointless, they decided to limit it to an ordinary PC.
Then there was a long choice what kind of SCADA to use. We tried the demo version with a dozen different SCADA systems (and ours and not ours were both MasterSCADA and Genesis and many many different ...). As a result, stopped at LabView. (For those who are not familiar, I will explain: LabView is one of the oldest SCADA developments, is still maintained and updated, can do a lot of things, is very flexible)
We drew a project, it turned out this: an example of the operator's screen .
Actually, in real time, the operator sees the current temperatures, the alarms are displayed in red, blink, and very nasty chirp in zvukovuha.
For this group of users, it was decided to write a special application that can make a request to the MSSQL database and select data by objects for a specified period of time, compare them with another, stretch, scale and analyze it in various ways.
The application is written on VS2005 and uses a very popular component of ZedGraph.
In this picture you can see one specific refrigerator, for it there are two graphics, because Two parameters are controlled, the temperature in the freezer and in the refrigerator itself.
In conclusion, I want to say that this is not the final result, but what exists and works today. In the future, we are thinking of abandoning SCADA and OPC because these technologies use DCOM, and they are not very friendly. We are thinking of switching to Web applications, or simply creating our own application that will work directly with the database. SCADA and OPC technology as a solution does not justify itself.
If you have any questions, then welcome)
The second part of this cycle is here.
So, the continuation of the topic about 1-wire, in the previous notes, I talked about general information about what 1-wire is and what it is eaten with, and also how we built a large network (cable structure and general idea). In this article, I will try to talk about what programs it all consists of.
')
Server part
We have three servers in three different buildings to which an adapter and a 1-wire network are connected through the RS-232 port. On the servers, a program is spinning, which, through an adapter, gives the command to switch branches to the DS2409 chips, interrogates all the sensors found in this branch, then switches to the next branch, and so on in a circle.
It was originally intended to provide data on all sensors via the OPC interface, since it is de facto an industrial standard and by bringing the data to this level we will get simple and wide opportunities for integration with almost any SCADA. Initially, we were looking for a ready-made OPC server solution for 1-wire, these searches brought truly sad results ... Despite the prevalence of 1-wire, it was not possible to find a suitable OPC, and in general it was practically impossible to find a ready-made one.
But they found a rather interesting thing: Fastwel UniOPC . They wrote their own library under it, which implements what is needed: collecting data from sensors in a circle and issuing them through OPC, and after each circle saves the current data to a table on the SQL server.
Lyrical digression:
By the way, this Fastwel project, it seems to me, has long been abandoned and not much updated: it supports only OPC-DA, but I would very much like to see OPC-XML-DA in it, all the same, time moves, technologies go forward, and - The thing is very simple and useful.
Since we are talking about the software, the servers are all based on Windows Server (the versions are different here and there), and the databases are MSSQL, respectively.
The picture shows what we have: three servers, transmit their own sensors via OPC, and also add the current values to the SQL database once in a while (approximately 3 minutes) for further analysis of the history.
As can be seen from the figure, there are two types of clients of this system:
- 1. operators - who see current values and crashes when parameters go beyond any boundaries.
- 2. Responsible people - who want to analyze history for different periods of time and, for example, compare the behavior of different objects among themselves.
Camera part
In the workplace of the operator is an ordinary PC running winXP which runs SCADA. One of the initial options was to use a panel computer for the camera room, but it seemed a little expensive, and it was particularly pointless, they decided to limit it to an ordinary PC.
Then there was a long choice what kind of SCADA to use. We tried the demo version with a dozen different SCADA systems (and ours and not ours were both MasterSCADA and Genesis and many many different ...). As a result, stopped at LabView. (For those who are not familiar, I will explain: LabView is one of the oldest SCADA developments, is still maintained and updated, can do a lot of things, is very flexible)
We drew a project, it turned out this: an example of the operator's screen .
Actually, in real time, the operator sees the current temperatures, the alarms are displayed in red, blink, and very nasty chirp in zvukovuha.
Responsible people
For this group of users, it was decided to write a special application that can make a request to the MSSQL database and select data by objects for a specified period of time, compare them with another, stretch, scale and analyze it in various ways.
The application is written on VS2005 and uses a very popular component of ZedGraph.
In this picture you can see one specific refrigerator, for it there are two graphics, because Two parameters are controlled, the temperature in the freezer and in the refrigerator itself.
Conclusion
In conclusion, I want to say that this is not the final result, but what exists and works today. In the future, we are thinking of abandoning SCADA and OPC because these technologies use DCOM, and they are not very friendly. We are thinking of switching to Web applications, or simply creating our own application that will work directly with the database. SCADA and OPC technology as a solution does not justify itself.
If you have any questions, then welcome)
Source: https://habr.com/ru/post/109147/
All Articles