![]() |
requirement : reading of ethrnet/ip data & storing - Printable Version +- Hilscher Community Forum (https://forum.hilscher.com) +-- Forum: netPI 3 - Docker featuring Industrial Raspberry Pi 3 platform (https://forum.hilscher.com/forum-1.html) +--- Forum: Software (https://forum.hilscher.com/forum-5.html) +--- Thread: requirement : reading of ethrnet/ip data & storing (/thread-698.html) |
requirement : reading of ethrnet/ip data & storing - MGharat - January-29th-2021 Hello Armin, One of our customer has below requirement: 1] wants to read data from AB PLC ( Etehrnet/IP Scanner) & send to azure cloud . 2] store the plc data into gateway in case of cloud communication breaks & update data again after reestablishment of cloud connection. 3] remote access of PLC So I hope we can do this application with netPI RTE 32 GB + Tosibox. we already tested ok 1] & 3] with netPI RTE. About 2] can you please confrim how this can be implemneted? please advise. Thanks & BR Madhumati RE: requirement : reading of ethrnet/ip data & storing - Armin@netPI - January-29th-2021 Well Madhumati, there is one major problem in this constellation:: The two RJ45 ports of netPI need to be running in "Ethernet/IP mode" and at the same be running in "TCP/IP mode" as cifX0. This is not possible with netPI. With netPI the two RJ45 ports can only be running in either this or this mode, not both at the same time. Only the gateway "Connect" supports "EthetNet/P" using preinstalled Node-RED and also running "TCP/IP" traffic across cifX0 at the same time. So finally just adding the Tosibox container on top "Connect" gateway should get it to a state where it is managable from remote. But all this without guarantee since I have not tested it. Thx Armin RE: requirement : reading of ethrnet/ip data & storing - MGharat - January-29th-2021 (January-29th-2021, 12:24 PM)Armin@netPI Wrote: Well Madhumati, Dear Armin, we already tested attached architecture with Tosibox. where eth0 port we connected to CIFX0 port externally. we can access remotely both the ports without LAN container installed on netPI RTE. please check & let us know if anything wrong . BR Madhumati RE: requirement : reading of ethrnet/ip data & storing - Armin@netPI - January-29th-2021 Yes I know that you have successfully tested Tosixbox and TCP/IP on cifX0. But now you want to run EtherNet/IP on netPI. This means you have to remove the hilschernetpi/netPI-netx-ethernet-lan container and replace it with hilschernetpi/netPI-nodered. When you do this the cifX0 will disappear and Node-RED with the EtherNet/IP fieldbus node will appear. Now your netPI "speaks" EtherNet/IP on dual-ethernet port, but no more TCP/IP. But to get access to Allen Bradley PLC over Tosibox the dual-ethernet port needs to "speak" EtherNet/IP on one hand and TCP/IP on the other at the same time. But it can't since the TCP/IP container was replaced by Node-RED container. They cannot run at the same time. Thx RE: requirement : reading of ethrnet/ip data & storing - MGharat - February-1st-2021 Dear Armin, As you suggested us , we are going to test netfield connect + Tosibox for this application i.e reading of ethernet IP IO data over CIFX 0 port & remote PLC access through Tosibox container. I will update you for this. I had another query also i.e data storage into gateway in case of cloud connection breaks & data update again in case of reestablishment of cloud connection. ---- how this is possible ? Do we have to program into our gateway accordingly? can you please suggest ? Thanks & BR Madhumati RE: requirement : reading of ethrnet/ip data & storing - Armin@netPI - February-1st-2021 Here is how I would to it. use gateway "connect" named NIOT-E-TPI51-EN-RE instead of NIOT-E-NPI3-51-EN-RE * gateway connect supports Node-RED installed natively and not as container! * gateway connect supports cifX0 installed natively and not as container! * gateway connect has preinstalled azure node in Node-RED to send data to azure * gateway connect has preinstalled influx db node in Node-RED to send data to influxdb * gateway connect has preinstalled fieldbus node to support Ethernet/IP device function to receive data from PLC * gateway connect supports docker to install tosibox container additionally * gateway connect supports docker to install influxDB database container additionally But before you order such a gateway type please prgram first of all Node-RED with fieldbus to influxdb to azure communication on your existing netPI. Programming such a Node-RED flow can be done independently of Tosibox function. Lateer you can switch to "connect" gateway at any time RE: requirement : reading of ethrnet/ip data & storing - Armin@netPI - February-1st-2021 What I can definitively say is that you need indeep Node-RED programming skills to program a good working Node-RED flow for this specific customer demand. Here in this forum you will not find programmers who can help you with programming a good working Node-RED flow. You need to do this on your own since it is not really a netPI related question but an application related one. Even Hilscher HQ is not able to program such alike applications. Here in HQ we forward such requests to local engineering companies who have programming skills. Based on the azure Node-RED documentation https://flows.nodered.org/node/node-red-contrib-azure-iot-hub we can assume the azure Node-RED node returns an information when there is no connectivity to azure at all or the internet connection is lost. So when it indicates a fail for sending the data to azure the data needs to be backuped in influxdb database instead. And then of course you need to program an algorithm to read back the data stored from the influxdb database and send it to azure when it is back online. My personal opinion: to be 100% reliable means to me that Node-RED should cache/buffer all fieldbus data influxdb DB always and then as a second task forward the data to azure node so that you get the max chance of the cache/buffer being set before detecting whether the connection works or not . You also need some kind of feedback to detect a failed send. As the send happens over TCP/IP, that could take an appreciable amount of time - TCP timeouts can be up to minutes though. So in any case writing the data stream to influxDB always first is a safe way to me. This is only possible with 32GB high endurance card. The 8GB card will get destroyed too soon for this kind of use case. One word to Influxdb in general: when creating a database in influxdb you can specify enter a rentention time for the data stored. Influxdb will delete then data stored that is older than a certain amount of time e.g. 24 hours or 1 week (minimum is 1 hour) .... This prevents the database from getting too big after years. You should consider this in your pogramming My opinion about a possible Node-RED flow: 1. The "fieldbus input" node has to inject the fieldbus data to the "influxdb out" node always which in turn stores all the data in the related influxdb database. 2. With an inject node create a cyclic node. This node connects to "influxdb in" node which reads stored data from the influxdb cyclically. For each read you can specify the time you want to read data from the database somewhere in the past. So you get back exactly the data from a specific time written in the past. The output of the influxdb out node is then connected to the azure out node and hence sent to azure cloud then. 3. If now the azure output node reports a successful write to azure cloud then you are sure that data is in the cloud and you can increase the time for the next influxdb read cycle. How to detect a message could be sent to the azure cloud successfully the documentation says https://flows.nodered.org/node/node-red-contrib-azure-iot-hub that the azure debug output message is "Message sent.". So you can check this value and you know about the status. 4. If now the azure node reports a fail when sending the data to azure you know the data is not in the cloud, then do not increase the influxdb time and in the next cycle it will read the same data from influxdb and hence tries to send the data again that failed before. Thx Armin |