• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Modbus TCP Connection via RTE Ethernet Ports
Hello all,

I'm just starting to work with the netPI RTE. I currently don't have any hardware to work with, but it is on order.
Nevertheless I have a question regarding the two extra Ethernet Ports of the netPI RTE.
Is it possible to connect a Modbus TCP slave via one of this ports?
The documentation only quotes that it supported "ROFINET, EtherNet/IP and more"
I just want to make sure that "more" also includes Modbus TCP.
The netX should be able to support Modbus TCP.

Thank for your help.

Best regards
Florian Lotze
Hello Florian,

yes this is possible. You have to turn the two ethernet ports of netX chip into standard ethernet ports away from their real-time ethernet capability. This requires to load a different firmware into the netX network controlle chip.

How you do this is available as ready to load container located here https://hub.docker.com/r/hilschernetpi/n...ernet-lan/. Read the page for more details.

When you start the container it creates next to the existing eth0 port (standard raspberry port) another LAN port named cifx0 in the container you can assign an IP address to. Then you can add your modbus tcp client app afterwards and set the modbus tcp/ip server (same subnet) in accordance to the ip address set up for cifx0 interface and all the TCP/IP frames will leave the two extra RJ45 port right away to your modbus server.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Hello Armin,

thank for your help. I have the container up in running and I'm able to ping my Modbus slave.

I have developed my application in Node-Red on another Hardware. Is there any way to use your netpi-nodered-fieldbus image for this purpose or is this only for Profinet and Ethernet/IP?
Or would it be better to create my own container based on the netpi-netx-ethernet-lan and add node-red on top?

Thanks again for your help.

Hi Flo,

the Node-RED fieldbus example is automatically loading a different firmware into the netX chip. This means starting two containers - one with LAN and one with PROFINET/Ethernet/IP - at the same time will never work. It is not predicable which container will succeed and in which order they are started. So this is a dead end.

Here is how I would do it: I would create my very own container. I would keep the LAN example like it is and would add from the fieldbus container github project the following source code lines from the dockerfile and would copy them into the netX LAN example and rebuild the new container.

#install node.js V8.x.x
url -sL https://deb.nodesource.com/setup_8.x | sudo -E bash - \
&& apt-get install -y nodejs \
#install Node-RED
&& npm install -g --unsafe-perm node-red \

This would just install node.js and node-red ... and no additional netX driver and fieldbus nodes that would cause a firmware reload into netX chip destroying your LAN interface.

As next I would modify the entrypoint.sh of the LAN example and would add a /usr/bin/node-red after the cifx0daemon has been loaded to let start node-red at each boot. Please do not forget to map port 1880 when starting the container.

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Hello Armin,

thanks again for your quick response. Unfortunately I've run into the next problem.
I have changed the dockerfile according to your suggestions.
No changes in the entrypoint yet.
I want to build the image via the docker development container for the netPi.
When I try to build my image the following error occurred:

cgroups: cannot find cgroup mount destination: unknown

Then I tried to build the netpi-netx-ethernet-lan without any changes and the same error occurred.
Do you have any tip how to fix this?
I have tried to use an older jessie image in my image but this didn't help.
Or do I need to make any changes (other then written in the docker hub docu) when I create the development container on my netPi?

Best regards
Well Flo this is easy explained why this happens.

As described in the readme of all provided examples containers the Dockerfile is supporting cross compilation on x86 machines. Since all our example containers are based on automated Docker Hub builds on Docker Hub servers - which are all x86 machines - a trick/modification of the Dockerfile allows compilation of ARM code on x86 machines.

But now you are on an ARM processor and cross compilation is no longer needed. So comment out the two lines RUN [ "cross-build-start" ] and RUN [ "cross-build-end" ] and docker build command will work as usual.

You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

Thanks for your quick answer.
Even if I comment these lines out I get the error with your Ethernet across Industrial Ethernet ports image.
I get this error when Docker tries to run the apt-get update ... line.
Any Ideas why this is happening?
Do I need to choose another debian:jessie image?

Docker Build output
Step 1/8 : FROM resin/armv7hf-debian:jessie
---> 16a1a7000edb
Step 2/8 : LABEL maintainer="netpi@hilscher.com" version="V0.9.1.0" description="netX based TCP/IP network interface"
---> Using cache
---> bf0e0d9efee1
---> Using cache
---> 4879940e35e0
Step 4/8 : COPY "./init.d/*" /etc/init.d/
---> Using cache
---> f39f214d4000
Step 5/8 : COPY "./driver/*" "./firmware/*" /tmp/
---> Using cache
---> 5d50783c4c77
Step 6/8 : RUN apt-get update && apt-get install -y openssh-server build-essential && useradd --create-home --shell /bin/bash pi && echo 'root:root' | chpasswd && echo 'pi:raspberry' | chpasswd && adduser pi sudo && mkdir /var/run/sshd && sed -i 's/PermitRootLogin without-password/PermitRootLogin yes/' /etc/ssh/sshd_config && sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd && dpkg -i /tmp/netx-docker-pi-drv-1.1.3.deb && dpkg -i /tmp/netx-docker-pi-pns-eth- && gcc /tmp/cifx0daemon.c -o /opt/cifx/cifx0daemon -I/usr/include/cifx -Iincludes/ -lcifx -pthread && rm -rf /tmp/* && apt-get remove build-essential && apt-get -yqq autoremove && apt-get -y clean && rm -rf /var/lib/apt/lists/*
---> Running in 48aa168c4293
cgroups: cannot find cgroup mount destination: unknown

Also there is an error in the development container:

Build Container Log

2018-06-29T06:47:41.518814961Z mount: cgroup is already mounted or /sys/fs/cgroup/cpu busy
2018-06-29T06:47:41.544934996Z cgroup is already mounted on /sys/fs/cgroup/cpuset
2018-06-29T06:47:41.559020764Z mount: cgroup is already mounted or /sys/fs/cgroup/cpuacct busy
2018-06-29T06:47:41.560117218Z cgroup is already mounted on /sys/fs/cgroup/cpuset

Does this have something to do with the error from within the docker building process?
Well Flo, I am running into the same problem.

I know it worked in one of the first releases of netPI definitively to use Docker daemon in a container (Docker in Docker). But the current restrictions of netPI's Host Docker in the latest released prohibits apparently using Docker in a container full featured nowadays.

Especially the cgroups that have been mounted on the Host Docker are making a problem here to grant full access in a container. I am sorry to say that I have no solution for that problem. The container development example container is useless.

There are only two options I see.

1.) use an original raspberry PI 3 for developments as the netPIs principle concept recommends it where you have full access to the Docker
2.) generate a Docker project on Docker hub/github yourself and let it generate automated there like we do it with all examples.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


I found out that I am getting the same error, even when I am using a standard Raspberry Pi 3 and this Docker development image. That made me curious why this happens. So I updated the https://github.com/Hilscher/netPI-contai...nvironment package using debianConfusedtretch as base image instead of debian:jessie as used before.

The result is positive: Now I am getting no longer the cgroup is already mounted error.

You can try it now yourself, it should work fine.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

HI Armin,

I would like to make a request. We are evaluating the NetPi and NetIOT platforms for a clould solution my company is developing. I really need to have Modbus/TCP on the realtime port or else the solution is not viable. I like everything else about the hardware, especially the Node Red implementation.

My request is this. First, would it be possible for you to create a Node Red container for the NetPi hardware similar to what you described in the steps in this post. Or possible create a Node Red deployment that already includes the standard Lan firmware load for the RTE port, or even if it was selectable as another option along side Ethernet/IP and Profinet. That would be ideal.

Second, I would like to make this same request for the NetIOT platform. The NetIOT is more attractive for our solution because of the Node Red, MQTT, etc pre-installed. But with no access to the docker system, I am stuck with never having Modbus/TCP as an option on the RTE port which is a must have for our option.



Possibly Related Threads…
Thread Author Replies Views Last Post
  Accessing a modbus device connected to RTE port from Node-RED tad 10 288 October-2nd-2020, 07:21 AM
Last Post: Armin@netPI
  Fieldbus Ports not working Schoko 13 617 June-29th-2020, 09:43 PM
Last Post: Armin@netPI
  Web browser reports "insecure connection" when accessing netPI for the first time Armin@netPI 2 235 January-31st-2020, 07:07 AM
Last Post: Armin@netPI
  normal ethernet port using for Profinet MGharat 4 214 August-7th-2019, 10:39 AM
Last Post: hannes
  [SOLVED] Slow network connection Andi 5 236 May-22nd-2019, 05:16 PM
Last Post: Armin@netPI
  RTE3 Use real time ethernet as "normal" ethernet interface hannes 50 2,184 May-9th-2019, 04:28 PM
Last Post: Armin@netPI
  niot-e-npi3-51-en (RS485 <-> Industrial Ethernet) merklethomas 6 331 April-26th-2019, 01:38 PM
Last Post: Armin@netPI
  USB/Ethernet adapter slos 4 272 April-8th-2019, 09:11 AM
Last Post: slos
  IP Realtime Ethernet michu252 7 621 August-21st-2018, 10:41 AM
Last Post: Armin@netPI
  [SOLVED] Modifying ports after container is being added. SteveO 2 284 May-9th-2018, 02:39 PM
Last Post: SteveO

Forum Jump:

Users browsing this thread: 1 Guest(s)