foreword
This article will use an OPC UA gateway created based on the open source project HslCommunication to facilitate the creation of an OPC UA gateway center through configuration. For specific operations and supported device information items, please refer to the following:
The github address of the open source project HslCommunication: https://github.com/dathlin/HslCommunication If you like it, you can star or fork it, and you can also give a reward for support. This project is very popular in the industry, used to collect data from equipment and transfer data between multiple software, as well as some simple control display.
You can download and install it in the NuGet manager in Visual Studio, or you can directly enter the following command in the NuGet console to install:
Install-Package HslCommunication
NuGet installation tutorial http://www.cnblogs.com/dathlin/p/7705014.html
Technical support QQ group: 592132877 (The version update details of the component will also be released in the group as soon as possible) Component API address: http://www.cnblogs.com/dathlin/p/7703805.html
HslSharp trial download
The version will change with the update function, and the corresponding blog will also be updated. Some update log statements will be made as follows:
v0.0.1
May 1, 2018 13:47:22
Pre-release, preliminary testing.
Feature support
- Supports empty device nodes, creating simple nodes for device reading and writing
- Supports the device node of Mitsubishi PLC, aiming at the binary and ASCII mechanism of the MC protocol
- Support Siemens equipment node, support S7 protocol, Fetch/Write
- Support Omron device node, support FINS/TCP node
- Support Modbus-Tcp device node
- Support for heterogeneous Modbus-Tcp device nodes
- Support for NetSimplify client nodes, this protocol can transmit data between multiple computers.
Instructions for use
The node configuration of OPC UA of this software needs to be composed of a node configurator and a parsing rule configurator. The node configurator configures the OPC UA node classification rules, node descriptions and other information, but the specific data label is composed of the parsing rule configurator.
The following is a detailed description of the general configuration steps of the program:
- Configure the client classification information, add the desired device, and select the corresponding device type when adding a new device.
- After creating a new device type, you need to configure the data request, specify the read address, read length, and then configure the parsing rule code.
- If there is no parsing rule code, you need to configure rule parsing first. This system supports visual rule configuration. The specific configuration method will be explained in depth in this article.
A brief introduction to the main interface
Open the main interface of the software, as follows, when the software is used for the first time, the system defaults to three fixed root nodes
- The root node of the Devices device class
- ModbusServer Modbus server node, currently not supported
- ModbusAlien Alien ModbusTcp device object
If the software node information is not configured, you need to click the node configuration menu of system configuration first. The main interface is as follows
The interface of the node configuration is as follows, there is a detail here, click the node name, you can display the detailed information of the currently selected node in the data list on the right, do the operation of the node on the left, and operate through the menu of the right mouse button:
Add node classification operation
The simple demo here adds a simple categorization action message. Right-click on Devices to operate
Then an edit box will pop up, so that we can add a category node. Note: category nodes can be nested with each other, which can form complex categories
Examples of complex type nodes:
Then click Save File menu, then close the current window, return to the main interface, click Start Engine , click Test Client menu, start a general OPC UA client to browse what data information is on the server
You can see that the OPC UA server has created the data node information as we imagined. Then restart the software, and we re-enter the Node Configurator node to operate.
Edit and delete node operations
Which node you want to operate on, select which node, then right-click, and find that there are 2 additional operations to select, Edit Node and Delete Node . Note that the editing and deletion here are applicable to all classification nodes and device nodes. To be precise, except for the three root nodes that cannot be modified, other nodes are modifiable.
When deleting a node, you need to pay attention to one detail: if the currently deleted node has no child nodes, the node will be deleted directly. If it contains child nodes, a dialog box will pop up.
Added a demo device example, Modbus-Tcp device
Here we demonstrate an example, add a Modbus-Tcp device, why take this demo, because a Modbus server demo project is provided in the project based on the HslCommunication component, which can easily perform local debugging and testing, etc. .
Download address: ModbusTcpServer.zip
Before starting development, one thing should be explained. Although the HslCommunication component supports reading coils, registers, and input points, it only supports reading registers. If you want to read coils, the solution you can use is to The data is first moved to the register, and then resolved.
OK, everything is ready, let's get started.
Then we enter the basic information of the device, such as name, description, IP address, port number, client station number, etc.
Then click Confirm . Go back to the node configurator as follows:
In this way, a device is successfully added. After we select this node, the data list on the right shows the relevant information of this device.
Don't rush to add an access request to the device, because there is currently no parsing rule configured , then the next operation is to click the Save file button in the figure above, and then return to the main interface
At this time, we enter a key operation, which is to configure parsing rules. What does this mean? Let me explain first. The data we read from the device is usually byte data, not some basic data types, such as short, For data such as ushort, int, uint, float.double, this parsing rule plays such a role. For example, in ModbusTcp, we need to read 20 registers of address length, then after reading it, it will be 40 bytes in length. What data are there in these registers?
[ 0 - 1 ] Data a short type
[ 2 - 3 ] Data two ushort type
[ 4 - 7 ] temperature float type
[ 8 - 31 ] Robot joint data A total of 6 float arrays of length
[ 32 - 39 ] Barcode Total 8 bytes in length
The above is the data we assumed, because I don't know what kind of situation you will encounter in practice, here are some more empirical assumptions, and also assume the existence of an array, the existence of the barcode string, OK, there is With this information, we can add parsing rules.
Still the old operation, let's see what information we need to enter next.
Enter any rule name and click OK .
Next we need to add the real rule parsing.
First fill in the information of data one according to the above information, the index is 0, and the data length is 1, because there is no array. Click Confirm .
Then go ahead and add rules
Then add temperature data
Then add the robot position data, note that this is an array with a length of 6, then according to the following settings, the data length information needs to be set to 6
Add last data as barcode
So far, we have added all the data, go back to the parsing ruler configuration interface , and take a look at the results just configured,
The byte information is displayed on the left, and a total of 40 bytes of data are configured. The background color of each data type is inconsistent, which is used to quickly distinguish different types of data. The visual interface displays all the configured data information. Type, the byte position where it is already located. A handy quick check for missing information.
After confirming that it works, click the Save File button in the menu, and then go back to the Node Configurator
This time, the data configuration interface can be really completed. Here we assume that the data we need to read is in the registers of 20 addresses starting from address 0.
Next, enter the information according to our assumption
The request address here is the address of the register, and the address rules are as follows:
- Modbus protocol is purely digital content
- Mitsubishi PLC D100, or W1A0
- Siemens PLC M100, DB20.30 and the like
- Omron D100, A100
- SimplifyNet pure numbers, or 1.0.3
What is the law? We can find that the format of these addresses needs HslCommunication support, so before configuration, it is best to use the HslCommunicationDemo software for a simple test. About the download address of the software:
After adding, save. Return to the main interface of the software. Then click to start the engine . At this time, we have not started the Modbus server, let's see what effect it has.
A device is found in the loaded device information shown below. The type is a ModbusTcp device. We have not started the server of this device, so the device is flashing in the device monitoring item. Let's move the mouse to the small box to see. ,
You can see the basic information, name, status, last received time of some devices, what does the last received time here mean, in the case of initialization, the default is 1 day ago, okay, then we open the server software.
As soon as we click the Start Service button, the operation log immediately shows that a device is connected.
What happens when HslSharp's device is connected to the server.
The background color has turned green, the last reception time has also been updated, and the status has also become online . Then we are looking at the OPC UA client and what effect it has.
Then we try to change the data, in the interface of the Modbus server, write the float type data in address 2, try 123.456
Then go to the OPC UA client interface to refresh the data to see the data effect
The verification is successful here, write another one, write a barcode information, and write ABCDEFGH in the address 16-19;
we can see
There is a small bug here. It is too late to change this bug when making a demo screenshot, and it will definitely be fixed later. and declare in the log
Special Note
You see, we did not specify the endianness of the data when configuring the data parsing rules. For example, Mitsubishi has little endian first and big endian last, Siemens has big endian first and little endian last, Modbus protocol and Omron are Reversed in word units. In fact, we don't need to care about it in this software, we only need to pay attention to what data and how much length it occupies. Still quite convenient. If you have better suggestions, you can contact the author to improve.