New feature implemented - the RFC2217 Client line

In the D2000 version 12.2.67, a new type of communication line was added - RFC2217 Client. Let's have a look at what it is suitable for and why it has been implemented.

The RFC 2217 from the year 1997 is named “Telnet Com Port Control Option”. It defines the Telnet protocol extension for controlling the communication port properties:

· transfer speed

· parity (NONE, EVEN, ODD, MARK)

· number of data bits (5-8)

· number of stop bits (1, 1.5, 2)

· data flow control (none, RTS/CTS, XON/XOFF, hardware, DCD, DTR, DSR)

· setting of control signals (BREAK, DTR, RTS)

· setting the detection of errors and line conditions and sending information about them (timeout error, framing error, parity error, overrun error, data ready ..)

Devices that support RFC 2217 thus allow the use of a single TCP connection for both data transmission and transmission of control information (NVT - Network Virtual Terminal). What are the benefits?

In the first place, the ability to work directly with serial servers that support RFC 2217. Examples are the Viltrus RAY3 data logger, Advantech LR77v2 modular 4G router with a serial module, or Lantronix serial servers.

There are also third-party programs that enable collaboration - they emulate a virtual serial port in Windows and use the RFC 2217 to communicate with the serial server. Examples are Virtual Serial Port Redirector or Eltima SEC. However, such programs are usually paid for and not always reliable (according to information from our OEM partners, they had problems with similar software). The requirements of our OEM partners were also the primary reason for the implementation of the RFC2217 Client communication line.

Compared to the SerialOverUDP Device Redundant line, it is possible to change the line parameters (e.g. bit rate), which is required in some protocols (e.g. IEC 62056-21:2002 Serial).

Unlike the MOXA IP Serial Library, no third-party communication drivers are required - so the RFC2217 Client is available on all supported platforms (including Raspberry PI) - and all bugs are ours so we can fix them :-).

In complicated network environments requiring address translation, or in less reliable mobile GPRS networks, a TCP connection proves to be more advantageous than the UDP variant.

There are disadvantages nonetheless. Sometimes the UDP packet loss (which can be resolved by repeating the request) is less of a problem than a TCP connection being "stuck" for several tens of seconds due to packet loss.

In our applications, we have been using UDP communication with serial servers via the SerialOverUDP Device Redundant line for a long time. Moxa's NPort series serial servers (as well as OnCell designed for mobile networks), which support it and which we often use, allow the transmission of data received from the serial port to several IP addresses. This can be advantageously used in redundant D2000 systems (passive KOM process can obtain data by intercepting the responses). Servers in RFC 2217 mode often support only a single TCP connection (to avoid collisions between multiple clients).

Figure 1 – The configuration of the RFC2217 Client line parameters is similar to the configuration of the serial line but the IP address and TCP port number of the RFC 2217 server are entered instead of the serial port name.

Supported protocols

OEM protocols and the following serial protocols were supported on the RFC2217 Client line:

· Datalogger ESC8816,

· DLMS/COSEM,

· DNP3,

· Generic User Protocol,

· HOPF 7515,

· IEC 62056-21:2002 Serial,

· IEC 870-5-101 (balanced, unbalanced primary, unbalanced secondary),

· Johnson Controls N2-Bus,

· M-Bus Rev. 4.8,

· Microtel 700,

· Modbus Client,

· TG809 Server.

Others may follow in the future - you can find out the current status in the list of communication protocols supported in the D2000.

Testing

Testing was performed using an 8-port serial server Moxa NPort 5610-8, which supports work in the RFC 2217 mode. During testing, two serial ports were connected, communication through one was in the UDP mode, through the other in the RFC 2217 mode. The IEC 870-5-101 protocol was used for testing. Subsequently, the communication was tested with both ports in the RFC 2217 mode.

In addition to the physical device, we also tested the communication with the RFC 2217 software server. We used the com0com utility (null-modem emulator), which creates a pair of virtual serial ports that are interconnected (data written to one can be read from the other and vice versa). And the hub4com application, which is included in the com0com package, allows you to create an RFC 2217 server and connect to one of the virtual serial ports.

Specialties

When opening the RFC2217 Client line, it is to be found out whether the other party supports the RFC 2217 protocol (with the WILL CPO command). If so, the serial port parameters (device identification, speed, the number of bits, parity, control signal states) are determined. Thereafter, the commands are sent to change those parameters that are different than required by the line configuration.

When testing against the hub4com software server, we encountered a problem that it did not answer some of the requests. For such cases, we have "recycled" the Const Open configuration parameter (since the dialog for configuring serial parameters is identical to the dialog for the Serial category line). The original meaning of the Const Open parameter is not applicable on the RFC2217 Client line (constantly closing and opening a TCP connection would be a great overhead and would make virtually no sense).

If the Const Open parameter on the RFC2217 Client line is checked, then the D2000 KOM process waits for all RFC2217 requests to be answered when the connection is established, and if no answers are received, the connection is closed. If it is not checked, no answers are expected (except for the answer to the initial WILL CPO, which detects the RFC2217 support), so the connection will also work with servers that ignore some of the requests.

Closing the line

As with the Serial line, the RFC2217 Client line can be manually forced to temporarily close the line (TCP connection) with the LNSTAT CLOSE command. The RFC2217 server can then be used by other programs, such as diagnostic or configuration tools. Communication is restored with the LNSTAT OPEN command or after the communication process is restarted.

Conclusion

The new type of communication line RFC2217 Client implemented in the D2000 at the request of our OEM partners and usable from version 12.2.67 again enhances the communication possibilities of the real-time application server D2000. In specific cases, it simplifies and reduces the cost of its use by omitting third-party software add-ons and can thus increase the quality and reliability of communication.

Ing. Peter Humaj, www.ipesoft.com