• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Raspi 3 + netHAT = netPI?
I would like to know if the Raspi 3 + netHat behave like the netPI when it comes to develop docker app.
I bought the netHat, with the goal of using it as my dev. environment, and keep the netPI as my "production" platform, so I can test and develop into the Raspi and then upload the docker containers directly into the NetPi.

Is there any kind of differences into using both? I understood the netPi is locked and secured into the host part, so no docker CLI access / SSH... but what about the hardware / drivers / access to NetX51? is it the same?

I'm waiting to receive both this week, so I want to be sure that I made the right choice buying them.
Well vdupont this question can be easily answered.

Yes RPi 3 + netHAT behave the same as netPI. Even if netHAT uses netX52 industrial network controller and netPI uses netX51 they both communicate across SPI0.0 device with the raspberry CPU and have the same function API.

But with netPI you have more possibilities than with netHAT. netHAT is just a product for evaluation for all those who have interest in simple real-time ethernet connectivity. The driver that comes with netHAT in the download section here https://www.netiot.com/interface/nethat/ configures the module always to fix 32 bytes input and output. No flexibility.

With netPI we opened the whole netX interface to users. On one hand we have examples how to program netX yourself in C-language and for an easy understanding we have programmed a netX node for node-red that you can use.

You have recognized well that netPI is a docker host and only containerized software can be loaded into it. But no worry, you can of course connect to netX directly in a container.

To support all customers with examples we are providing ready-to-use docker containers here https://hub.docker.com/u/hilschernetpi/ which all have a direct link to their source code on Github.

I have one tip for you. This docker container example here https://hub.docker.com/r/hilschernetpi/n...-fieldbus/ is made for netPI and netHAT both. The container detects whether it is running on a Rpi with netHAT or netPI and then provides you a node-red with netx nodes where you have immediate access to real-time ethernet data of netX chip in node-red.

You are right that netPI does not have SSH and Cli. Instead you have a web page you start the containers with. For clearance watch the netPI videos showing you how all this works https://www.youtube.com/user/HilscherAutomation

Both netX51 and netX52 are "slave" chips in the view of the real-time ethernet system. They cannot be a master. But netX51 and netX52 can both be standard TCP/IP supporting devices in a container. So in this case netPI get three standard ethernet ports. The example container how to set up netPIs ethernet ports to be standard ethernet ports you find here https://hub.docker.com/r/hilschernetpi/n...ernet-lan/.

And of course netPI can include PLC functionality and send data across the standard ethernet ports. We have made a container where CoDeSys is running in a container on netPI here https://hub.docker.com/r/hilschernetpi/n...sys-basis/. I personally tested it with profinet as a master and it works fine. There is video with CoDeSys here https://www.youtube.com/watch?v=N4ePYf-9cS8.

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

I continue my exploration / discovery of the product. Currently looking to the "netpi-netx-ethernet-lan" image.
I was wondering how the fieldbus interfaces of the NetX behave with that firmware when it comes to connect with redundant links.
I notice that both ports act a layer 2 port, while the cifx0 interface (layer 3) is bound to them.

For the testing, I have my fieldbus controller (Wago 750-352) with 2 LAN ports, both active (no mirroring), and connected them straight to the NetPi fieldbus ethernet ports.

It looks like both connect correctly, with 1ms roundtrip delay (ping).
I disconnected one port, then see packets loss of less than 14 packets, then back to 1ms, meaning one of the device is converging at ethernet level. Reconnect / disconnect second port, same behavior , so all seams ok.

I'm currently looking at the NetHat documentation, but haven't find the explanation of the ethernet-lan firmware. Does the NetPi has loop protection mechanism or spantree protocol support?

My goal would be expose only the main LAN interface of the NetPI into my "user" LAN, while the fieldbus interfaces connect to the IO LAN directly (so isolated), without intermediate switch, reducing failure risk:
- Netpi_A LAN0 -> FB_A LAN0
- Netpi_A LAN1 -> FB_B LAN0
- Netpi_B LAN0 -> FB_A LAN1
- Netpi_B LAN1 -> FB_B LAN1

This is a simple scenario, which create a typical loop (so redundancy), but requires a loop free mechanism to work, otherwise there will be duplicated frames.
Hello Vincent,

there are no mechanisms implemented in the netX ethernet lan firmware to detect ethernet loops across protocols such as spanning tree. The two netX ports cannot be compared to professional switch made by Cisco for example.

With netHAT you will not find any similar standard ethernet LAN firmware like with netPI. netHAT just supports PROFINET, EtherNetIP and EtherCAT firmwares only. As I said, netHAT was made for students to evaluate real-time ethernet networks and not to add additional ethernet interface to a raspberry.

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

I understand. In the case of the Fieldbus interfaces are used for Ethernet (layer 2) usage, or when the control protocol (like Modbus) is loaded at the Application level, I think the better option would be to expose them into docker as 3rd party network interfaces, via a plugin into the host.

This way, the running app into the docker image doesn't have to take care of the firmware / specific interface activation. It might be also possible then to bind the fieldbus interfaces to multiple docker images, perhaps make use of the "Overlay" and "Macvlan" networks into docker.

And also, you can then provide NetX firmware updates via the host firmware instead, add features when available...

This way, we can load a standard docker image, without touching the network part inside the image, and still benefit of the fieldbus interfaces.

Possibly Related Threads...
Thread Author Replies Views Last Post
  Yocto Linux for Rpi3 + netHAT jenrei 4 148 July-16th-2018, 11:49 AM
Last Post: Armin@netPI

Forum Jump:

Users browsing this thread: 1 Guest(s)