Moxa NPort or an industrial Raspberry? You choose…

Image Description

Peter Humaj

May 07 2019, 7 min read

A demonstration of how you can replace the Moxa NPort for a Raspberry PI, e.g. during data acquisition from electrometers.

When we need to communicate through a serial interface (e.g. with energy meters, PLCs and so on) using various protocols (Modbus, DLMS/COSEM, IEC 60870-5-101...), we standardly use a Moxa NPort converter.

A practical example of such communication with the use of an NPort converter is shown in this diagram.

Figure: A diagram showing the connection of electrometers in the case of using the Moxa NPort

The principle of the operation is as follows:

One or more electrometers are connected to the RS-485 serial bus which is connected to the NPort converter. The converter is connected to the Ethernet switch. There is also a computer connected into this network on which the D2000 system runs.

The D2000 KOM communication process sends requests to the NPort converter (using TCP, UDP)  or else writes into the virtual COM port representing the NPort converter. NPort sends received data to a serial line to electrometers. Then, it receives an answer with data which it sends to the KOM process via the Ethernet network.

One NPort can have one to sixteen serial interfaces. So, it also works as a communication concentrator.

Since we started to support Raspberry PI devices starting with the D2000 V12.0 version, the following figure explains the possibility of its practical usage – we can replace the NPort with the Raspberry PI which will work as a remote communication server.

Figure: Diagram showing the connection of electrometers in the case of using a Raspberry PI

On or more electrometers are connected to RS485 bus  which is now, however, connected to the serial interface of Raspberry PI. In our case, we used the industrial version of Raspberry – NPE X500 from the Techbase company.

If we want to use a standard Raspberry PI, we will have to equip it with an extension using HAT that will implement the RS-485 interface. You can find various renditions on the Internet – simpler or more professional with galvanic isolation. Needless to say, you will pay more for quality J.

The KOM process is configured and running on the NPE X500 – DLMS.KOM in the figure which processes data from the RS485 bus and then sends it via the Ethernet network to the D2000 server.

Unlike the “standard” solution based on the NPort when the KOM process was running as one of the processes on the server, in the configuration with Raspberry PI the KOM process is run on the Raspberry PI which thus serves as a remote communication server.

One of the advantages of such a solution is decreasing of the CPU load of the D2000 server – operation of the KOM process is now handled by the Raspberry PI. In case of configuration with more distributed KOM processes and the use of protocols with higher data flow which are more demanding on the CPU load (e.g. Modbus TCP or Siemens SIMATIC S7 ISO on TCP) it is possible to distribute the load among more communication servers (however, every RPI 3 has a quad-core processor clocked to 1.2 GHz, RPI 3+ up to 1.4 GHz).

Another advantage is speeding communication up (network latency is omitted) and at the same time decreasing the load of a local network (all requests and responses don’t have to go via the network but the KOM process sends only changed data to the server). This might be important in geographically large installations using networks with higher latency and lower throughput. At the same time, this enables to use of a mobile network for creating a virtual network (you can buy the NPE X500 with GPRS, 3G or LTE modem).

The last advantage is that during potential connection outage between the D2000 Kernel and the KOM process, there will be no data loss since the KOM process supports also local data archiving form communication (so-called KOM archive mode). The KOM process can independently read data, store it to disc and after reconnecting, it is possible to “dragged” data on request or the KOM process will send it automatically (depends on the setting of the start parameter /KA).

In the following figure, there is a practical connection of a realized working solution – when using the industrial NPE X500 and two electrometers. Since the NPE X500 configuration, which was available to us, had two serial ports (each could be configured as RS-232 or RS-485), we connected each electrometer to one of them. We used a newer electrometer Iskra and an older Landis&Gyr.

Figure: electrometers connected to the industrial NPE X500

The configuration was as follows:

The port COM1 (more precisely COM4 in the RS-485 mode) was connected to the older electrometer Landis & Gyr ZMD405C with "Short Name" addressing (objects are addressed using 16-bit addresses). The port was on the Raspberry side represented by a logical device /dev/ttyAMA0.

The port COM2 (more precisely COM3 in the RS-485 mode) was connected to the newer electrometer ISKRA MT880 with "Logical Name" addressing (using 6-byte OBIS codes). The port was on the Raspberry side represented by a logical device /dev/ttySC0.

Figure: communication with electrometer Iskra: line, station and two I/O tags for reading power and time
Figure: communication with electrometer L&G: line, station and two I/O tags for reading time and voltage for individual phases

Testing of the KOM archive functionality

We will look at behaviour after the communication loss between the D2000 KOM process and the D2000 Server.

Instead of pulling out cables, we used forbidding of the TCP communication on the Windows firewall (so that we wouldn’t have to run between a server and a workplace where electrometers are and pull out cables form the NPE X500). After forbidding we could see in the CNF tool that the KOM process – from the point of view of the D2000 server – has crashed (state CRASH):

Figure: after a connection loss, the DLMS.KOM is in the state CRASH since 12:14:44

We see the voltage development in the graph – the I/O tag M.DLMS_LG.VoltageL1. On the right side of the figure, there is a clearly visible several-minute-long straight line corresponding with time when the connection loss with the KOM process occurred.

Figure: voltage graph after the connection loss at around 12:14

After the KOM process was reconnected, the value in graph continued to “live”:

Figure: voltage graph after reconnecting at around 12:21

Understandably, the state of the DLMS.KOM process also changed:

Figure: after reconnecting, the DLMS.KOM is in the RUN state since 12:21:45

After re-reading data into a graph, we can see the development with the “dragged” data covering the period of outage.

Figure: graph after re-reading data – the time gap from 12:14 to 12:21 was patched

When looking at the data in the table, it is possible to distinguish “dragged” data from the data acquired continuously – this data has the OLDVAL flag. This flag means that these are “old” values which go only to the archive – unlike the current values which are distributed everywhere they’re needed – into diagrams, calculated tags, events, alarm subsystem and so on.

Figure: values read from the KOM archive have the OLDVAL flag.

In the KOM process log on the NPE X500 (file /opt/d2000/log/KOM-DLMS.log), it is possible to find information about data sent to the D2000 Server after reconnecting:

Figure: the KOM process log displays information about reading from the KOM archive. 1786 values for time interval from 12:12:09 to 12:21:45 were sent. The real gap 12:14:44 – 12:21:45 was thus patched also with a small overlapping so there will be no value loss at the beginning of the outage.


In this blog, I tried to demonstrate the possibility to replace the Moxa NPort converter with a remote communication server based on the industrial Raspberry PI – the Techbase NPE X500. This solution enables to decrease the load of the application server as well as load of the network infrastructure.

Moreover, it is possible to use also networks with higher latency (mobile networks) for communication – since communication between the KOM process and the other side is not influenced by the network latency.

The third important advantage is the use of the KOM archive feature that enables to avoid data loss in the case of network problems.

Subscription was successful

Thank you for submitting form.

Image Description