In the last post about the new features of the D2000 V21, we focused on the Configuration and Version control and the extended security. The significant changes in both areas make the latest version more user-friendly and secure. They also open new possibilities for developers.
In this blog post, you will learn more about the new features in the field of communication.
Once again, the number of devices that the D2000 platform can communicate with has increased. And thus, the usability and versatility of the platform grew as well. So, what do we have in store for you? This blog post provides an overview of all the new features with a brief explanation. If you are interested in more detailed information - watch the embedded video.
General Electric SRTP protocol
The first communication protocol is the General Electric SRTP protocol. Request for the protocol came from one of our OEM partners. It enables you to communicate not only with the PLCs from General Electric but also with Fanuc robots, as there was a joint venture between the two companies in the past during which the protocol was developed.
The communication runs via the TCP/IP connection and supports access to multiple PLC memory types. The access is possible by bits, bytes, or 2-byte registers.
You can find more information in our online documentation. It also contains an extensive section dedicated to Fanuc robots and how to access their data and registers: Robot Input, Robot Output, Group Input/Output Position Registers, the current position of the arm, and so on.
You can also read two blogs about this protocol. And a third blog that describes the use of this protocol for developing a diagnostic and monitoring application for Fanuc robots is currently being prepared for publishing.
RFC2217 Client line
The new version of the D2000 brings also a new line type: the "RFC2217 Client". The request for this line also came from one of our OEM partners. This is a standard describing the control of serial port parameters, such as baud rate, parity, number of bits, and so on. It uses the escape sequences directly within the data connection. So, a single TCP connection is sufficient for both the data transfer and the serial port control.
In the picture, you can see some devices that implement this standard. As you can see, our favorite Moxa devices are among them. The picture shows the configuration of this type of line.
You can also see the "RFC2217 Client" tab, where you can define parameters in more detail.
So, when is it appropriate to use this line, and what are its benefits for you? The protocol may require changes of baud rate or other communication parameters, for example, the electricity meters communication standards DLMS/COSEM, IEC 62056-21.
We can also do this by utilizing a virtual serial port, or, in the case of Moxa devices, using the "Moxa IP Serial Library" line.
The advantage of the RFC2217 line is that it doesn’t require additional drivers or libraries provided by the manufacturer.
The second and even more beneficial advantage, for which the line was actually implemented, is its ability to work in a complicated network infrastructure where firewalls, NATs and other complications are present. In these cases, handling a single TCP connection is easier than various combinations of TCP and UDP channels (with potential dynamic ports), which are used by the MOXA IP Serial Library, or by various implementations mapping the remote serial port to a virtual serial port of a computer.
The baud rate change is also handy in another case. On a single serial or RFC2217 line, you can install multiple devices - stations.
Each of them can communicate using different parameters. Therefore, we have in our serial and RFC2217 line configuration the possibility of defining up to four communication modes, as you can see in this picture. Assuming that these are Request-Response protocols (it means that the devices do not send data spontaneously), the KOM process will change the line mode according to the station configuration, in other words, according to the addressed device.
Omron FINS protocol
Another novelty in the V21 is the Omron FINS protocol. The protocol enables working with Omron PLCs. These are used for example in the food industry.
The protocol implementation was once again requested by practice. The protocol has two variants. The original FINS/UDP uses UDP packets for communication.
The more recent protocol FINS/TCP uses TCP connections. When do you want to use individual variants? If you need communication in a simple network environment, we recommend the FINS/UDP variant. If you are working with a complicated network with firewalls, network address translation, or some other specialties, we recommend the FINS/TCP variant - assuming the PLC supports it.
The disadvantage is a larger overhead. Every request and response is wrapped in a 16-byte envelope. Additionally, during the connection establishing, the initial handshaking takes place. Here both parties exchange several communication parameters.
More information about the protocol can be found in the video located at the top of the blog post.
Siemens SIMATIC 3964(R) CW
Another new protocol is the "Siemens SIMATIC 3964(R) CW" protocol. CW stands for "Control Web". By this, I don’t want to promote our competition :) Let me explain.
This protocol can help in replacing the existing Control Web application that communicates with SIMATIC S5 or with newer S7, by an application built using the D2000 technology. The existing serial protocol SIMATIC 3964(R) for reading data from SIMATIC PLC, has been utilized by Control Web in such a way, that a proprietary header was defined - you can see it in the picture.
Using the header, they can request or write specific data from a particular data block. Since the data block is specified by a single byte, the protocol is limited to data blocks ranging from 0 up to 255. Data that are received after this header, must be interpreted as is common in "Siemens SIMATIC S7 ISO on TCP" protocol.
Thus, the new protocol is a hybrid created by combining the 3964(R) and the "Siemens SIMATIC S7 ISO on TCP" protocols. Currently, only reading is supported with this protocol. We implemented support for both passive and active mode. In passive mode, we can listen (eavesdrop) to the existing communication. We can listen to either only the PLC side or to both Control Web and PLC. In the active mode, we can also send reading requests, and therefore we replace the Control Web application.
KNX protocol
KNX protocol is an open standard for commercial buildings and home automation. It is the world’s most widespread one and it was developed by the KNX association. With this protocol, the D2000 has become more ready for IoT and home automation.
The protocol is characterized by a very simple implementation and a free topology. The topology can be either a star, tree, or a single line. Access to devices can use four different media. The first medium is a twisted pair, which serves to power individual devices, except for those needing external power access. Media access is conducted via CSMA/CA protocol which serves for collision prevention in messages. Other media are the Power-line, Radiofrequency, and IP protocol.
KNX developed its own KNXnet/IP protocol which uses the IP protocol as a "carrier" on a standard Ethernet network. Every KNX device has a unique address. It is divided into three parts. The first part is the Area consisting of four bits, Line with four bits, and the specific device address consisting of 8 bits. This means that in a single configuration, there can be more than 57,000 devices.
The available devices are divided into three different types. The first type contains sensors. They include pushbuttons, thermostats, and various other sensors. For example, the movement sensors. Actuators are the next type. They are used for action members control. Among them are, for example dimming units used for light control, and heating valves used to control heating. The last types are system devices and components. They are used to connect the individual device lines.
We have an entire video dedicated to the KNX protocol. In the video, you can learn a lot of important information about the protocol and the way that it was implemented into our platform. My colleague Marek also gives you a live preview of a showcase application working with real KNX devices in practical conditions.
Browsing in the IEC101 and IEC104 protocols
The last new feature I would like to mention is browsing in the IEC101 and IEC104 protocols. What is the purpose of browsing? Browsing simplifies the configuration of the measured point address or the station address based on the data received from the communication.
Therefore, browsing only works for functional communication. In the latest D2000 version, we implemented browsing support for IEC101, in the balanced mode, master mode and slave mode. And for IEC104 in both client and server variants. So, what is supported? Firstly, we can browse the station address.
That is the ASDU address in these protocols. In the configuration dialog, shown in the picture, you can see in addition to the ASDU address in the first column, also the station name, if the address is already used.
Measured point browsing is also supported. How does it work? Point addresses that are received by the IEC101 and the IEC104 communications as values or as commands are stored in the cache located on the station object. When the browser dialog opens, are they thus immediately available. This is convenient and it's a good feature, but in some cases, the cache data may cause significant memory consumption.
Conclusion
The D2000 real-time application server is constantly evolving and implementing the latest industry trends. We also realize that the practical needs of our customers are an important driver for successful innovation. As you could see in this blog post, many of the new features of V21 have answered requests from our partners. Other features react to the changes and innovations in the industry.
Together, all the features significantly increased the range of available devices. This way you can use the platform to build and control more complex and efficient projects.
I wish you a lot of success during the utilization and deployment of new communication features.
