• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
netPI use case for House Automation

I currently ordered a netPI and a netHAT products for a personal project. While searching for a Raspberry PI which can be DIN rail mounted and industrial grade, I found your products and was surprised to see it was matching my needs: robust, recent Linux BSP & Kernel, open, docker for app, support for field protocols.
So I ordered them yesterday to test.

However, while reading a bit today the documentation, I understand that the netPI couldn't replace a PLC? I'm not sure to understand why or due to what limitation yet. So I prefer to tell you my use case, so you can guide me or advise if I must cancel my order... into the FAQ, it states « This is why netPI cannot be a master or controller of the underlying industrial network.".

Here is my use case:
I own today a large amount of relays connected to Wago 750 fieldbus couper (750-352) with I/O clamps. This fieldbus supports Modbus TCP and EtherNet/IP. My goal would be to run on the NetPi an automation application (written myself or one like OpenHab/Home Assistant).
I do not think it will be a problem to run the automation software into a docker container, I'm already used to Resin.io and docker. I'm more asking myself about the 2 industrial ethernet ports and the netX 51.

While I see they are controlled by the netX 52, I started to read the GitHub and docs, and found the statement about your FAQ. I'll be honest, I have no experience into EtherNet/IP, I mainly used Modbus which currently read IO input, and write IO coil from my Raspi to the Wago coupler. The coupler is not a PLC, it just give me access to the IO maps through Modbus TCP. I haven't figured out how EtherNet/IP works yet.

While looking at Netpi exemple, I find EtherNet/IP, but no modbus exemple ... so I read a bit about EtherNet/IP and couldn’t find easily how the netPI will read/write on the remote I/O…

while searching I found the NetX51 has also an open modbus tcp firmware here : https://www.hilscher.com/products/produc...nxlfw-omb/ . Can this firmware been used on the NetPI too?

I'm a bit wondering if I will be able to achieve my goal, so that's the reason of my question:

Can I consider that this use case is feasible?

- Remote IO control ( read input, write output ) to my fieldbus controller via Modbus TCP or EtherNet/IP , to control my switches and lights/plugs (there are 140 IO total btw).

- Automation software into a docker container, using the netX 51 and the two ports interfaces

- Cloud (MQTT...) access via the main LAN interface

In summary, I want to automate my IO into the NetPi and keep my house electrical light/plug into my existing Wago IO bus.

I don’t mind writing the bridge / binder / middleware between the netX 51 controller and the automation software into a docker image, but I want to be sure that ether:
- it is possible to use Modbus TCP (protocol that I know already)
- or EtherNet/IP ( protocol I need to learn first)
- simply use the NetX51 to send ethernet frames, so using the 2 LAN ports as regular Linux ETHx interfaces.

I just notice that Codesys runtime is supported (?), so having Codesys controlling a remote IO through Modbus is already possible , no ?

Perhaps a suggestion, as it looks like this is a new forum : perhaps you could create a category like "Use Cases or Projects".

Hello Vincent,

if you have read netPI and netHAT cannot support PLC master functionality this was in relation to the type of industrial network chips both units support. Both units use netX chips that can only be loaded with industrial network slave protocols. And for a PLC you usually need a master protocol functionality with accurate timings. Only chips like our netX100 chip support an embedded master stack. But since more and more protocols are Ethernet based, that are not physically bound to a specific hardware like Profibus and CAN, more and more software protocols stacks are coming to the market. So yes netPI can also be a PLC and master if standard ethernet is the precondition.

So if you do not have specific protocol requirements in terms of timings and accuracy like Modbus TCP of course netX slave chips can be standard TCP/IP protocol stack supporting chips as well. So in this case netPI RTE 3 has one ethernet port coming from the Raspberry CPU and two additional standard ethernet ports supported by the netX CPU.

You have found that netPI supports EtherNet/IP as slave protocol. This is correct. But as a slave only and the whole protocol stack is handled in netX. Even high loads can be handled a normal Raspberry CPU can't. So with netPI we are in the same status as your WAGO IO. netPI and WAGO needs an EtherNet/IP master both to exchange process data with units such as PLCs from Allen Bradley.

But back to your focus ... Modbus TCP. In order to support Modbus TCP on netPI you have two possibilties.

1.) Install containerized Node-RED on your netPI. Then use the function embedded in Node-RED to install additional nodes. With this option install the Node-RED Node Modbus TCP https://flows.nodered.org/node/node-red-contrib-modbus and you have netPI supporting Modbus TCP in some minutes over Node-RED. The best of Node-RED is, once you have the data in Node-RED you can spread it around to nearly everywhere with one of the other 1500 pissible nodes. Unfortunately I have not found any EtherNet/IP master supporting node-red node.

2.) Install containerized CODESYS SoftPLC for raspberry on your netPI. CODESYS has immediate support for Modbus TCP Master and EtherNet/IP Master and PROFINET master over standard TCP/IP ethernet ports. A license per device costs you just $50 as far as I know. You can try it unlicensed for two hours before it stops operating. For testing this is excellent.

To your question about MQTT. You can install a mosquitto MQTT broker in separate a container on netPI. And Node-RED by default supports MQTT client functionality. We made a mosquitto MQTT broker example container for netPI already here https://hub.docker.com/r/hilschernetpi/n...tt-broker/

To your question how to make two ethernet ports of netX to standard ethernet ports just look to this example container https://hub.docker.com/r/hilschernetpi/n...ernet-lan/. Please consider that only one container in general can take control of netX at a time. Installing multiple container that all want to take control of the single netX resource will fail. Please consider also that all examples related to netX are made for netPI and not for netHAT. netHAT always needs different software binaries than netPI.

So If I was you I would do the following:

Build a single container (on your Raspberry Pi 3, I do it at home too):

* take parts of the source code of https://hub.docker.com/r/hilschernetpi/n...ernet-lan/ to make netX to standard ethernet ports
* install node-red into this container as shown in source code in the container example https://hub.docker.com/r/hilschernetpi/n...-fieldbus/. But do not install the netX Node-RED nodes please...cause netX shall be standard ethernet interface and not loaded with real-time ethernet slave protocols.

* install https://flows.nodered.org/node/node-red-contrib-modbus into your node-red as nodes

Then you are happy and have everything you need.

At home I do it the same on my raspberry (now netPI). I have containerized Node-RED and instead of Modbus TCP I am using CUL http://busware.de/tiki-index.php?page=CUL for wireless connectivity to my IOs.


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

Thanks for the detailed answers Armin, I'm currently reading all the GitHub examples Smile
I'm glad that I will be able to use the 2 LAN ports as regular ethernet interface, that was my goal to have them connected to the fieldbus. I found meanwhile the example on Git btw, so pretty confident now.
Reading your explanation, I arrived to the same conclusion, I will stay with Modbus TCP.

While waiting for the NetPi, I will continue testing with my Raspi3. One of my concern to remove my old PLC, was the reactivity for simple action like Switch ( Digital Input ) -> Light ( Digital Output / Relay ). On my present setup, the PLC is connected directly to the clamp IO bus, polling every 100ms and when I touch the switch, the light turn on without noticeable delay.
I hope that I will be able to achieve this with the new setup: Switch (DI) -> ModbusTCP -> Node-Red -> ModbusTCP -> Light (DO).

Perhaps, you have see it, about Modbus ... isn't the netX51 able to load that stack too? (https://www.hilscher.com/products/produc...nxlfw-omb/). If yes, wouldn't be interesting to offload the CPU if for instance we do frequent polling?

I keep you informed once I get the NetPi Smile
Well all the example containers that are not related to netX (except the one node-red-fieldbus example that will run with netHAT also) will run immediately on your RPi3. So you can test CODESYS as standalone application, you can test Mosquitto container the same time on your RPi3 ... nearly everything.

RPi3 respectively netPI is so fast, I have no doubt you get your network running much faster than 100msec. Even with Node-RED.

It is correct that netX51 supports Modbus TCP stack also. But the download you are referencing is made for netX51 customers only that integrate the chip into their IO system such as WAGO IO. Those units usually do not have any Host CPU on top that could execute protocol stacks. For product line netPI and netHAT we focus the use case for the netX chip to real-time ethernet protocols only which really demands CPU power. Other protocols such as Modbus TCP can be handled easily by Raspberry CPU since they are non-real time.

Have you ever evaluated the response time of your Wago coupler. I expect it responses in 2-3msec and higher. Even if you poll it on Raspberry CPU as fast as you can, it will not load the Quad-Core CPU for sure.

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

139 Wrote:Perhaps a suggestion, as it looks like this is a new forum : perhaps you could create a category like "Use Cases or Projects".

I like the idea. I will talk to the IT admins to create us a new topic as you proposed. Maybe you will find our chat shifted to this new forum in near future.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

144 Wrote:Have you ever evaluated the response time of your Wago coupler. I expect it responses in 2-3msec and higher. Even if you poll it on Raspberry CPU as fast as you can, it will not load the Quad-Core CPU for sure.

Yes, indeed I guess very good response time. For the moment, I have 2 docker images: one I can qualify as "Master Bus controller", which is polling the remote IO at a frequency of 50ms and has "basic" logics like direct mapping of Input -> Output. The trigger/action delay is not noticeable from user perspective. So it does enough for fail safe tasks.

This docker image consume something like 20% of CPU. I did first a test with a python script and modbus library, then I switched to Node-Red with basic call flows.

I have then a second layer of automation, which will focus on more user friendly interactions and complex behavior. This one will exchange trigger & status with the first one through MQTT.
I currently have running OpenHab and Home Automation for that purpose, until I decide if I will keep them.

I'm thinking about a third layer ( data storage , history , log , monitoring ) , running into a separate NAS, so I won't use the NetPi for persistent storage and reduce the amount of write into the internal flash.

This is still for testing and POC before I unplug my old ThinkIO PLC. But so far, it's going to the right direction...
In the coming version we will allow to map USB /dev/sdb /dev/sdb1 etc into a container which is today disabled. Then you have the possibility to als insert a USB storage media into netPI and access to it from a container
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)


Forum Jump:

Users browsing this thread: 1 Guest(s)