netPI Node-Red fieldbus node Error

[PersEE]

    Hello,

We have got a netPI RTE 3 with the system version 1.1.5.

We used the image hilschernetpi/netpi-nodered-fieldbus.

By following the tutorial of https://youtu.be/2WBt8XAurVU, we have established a PROFINET connection with a Siemens S7-1200.

However, every time we start the node, an error will occur after several minutes of normal operation and the error LEDs on the machine will be on.

The connection will be re-established when we redeploy the node-red flow but after a few minutes the error will occur again.
Error message:

error: 2148270098
add_desc: "xChannelIOWrite return error (0x800c0012) [Device not running (running flag failed)]"
datatype: "OctetString"

Screenshots can be found in the attachments

Could you please help us with this problem? Thanks.
   

[Armin@netPI]

Hi there,

the netX fieldbus chip used on netPI RTE 3 monitors a software watchdog that needs to be triggered by Node-RED at least once in a second.

In case the Fieldbus node reports "Device not running" apparently the software watchdog was not triggered in time.

So the question is what else are you running on your netPI RTE 3 either within node-red or any other container that you have maybe deployed.

Please remember Node-RED is javascripting based and a periodically running single threaded application. If you would write a bad code like while(1) as and endless loop the whole node-red runtime would stand still.

Thx
Armin

[PersEE]

Hi there,

the netX fieldbus chip used on netPI RTE 3 monitors a software watchdog that needs to be triggered by Node-RED at least once in a second.

In case the Fieldbus node reports "Device not running" apparently the software watchdog was not triggered in time.

So the question is what else are you running on your netPI RTE 3 either within node-red or any other container that you have maybe deployed.

Please remember Node-RED is javascripting based and a periodically running single threaded application. If you would write a bad code like while(1) as and endless loop the whole node-red runtime would stand still.

Thx
Armin

Hello Armin,

Thank you for your reply.

Actually apart from the node-red-fieldbus, a container of codesys-basic is also deployed (in the host mode) but it uses only the standard Ethernet port.

I have tried to deactivate all the other flows but leave only the one in charge of the PROFINET communication, however, the error appears again.

I have no idea what is going on.

Thanks for your help.

[Armin@netPI]

Yes this is exactly what I expected.

I can confirm that running Fieldbus Container at the same time as Codesys container on one netPI causes this problem. I have seen this with my device too.

This happens exactly at the time when Codesys is performing its licence checks (this is our assumption) after around 5 minutes of running. During this license check it talks to the GPU of the Raspberry CPU and does a lot of other things. This mechanim seems to have influence on the netX communication over SPI and interrupts it so that the netX watchdog triggers (default 1000msec) and the PROFINET protocol stack stops to work within netX and finally the Node-RED node stops operation. The SPI communication is reestablished by the netX driver but then it is too late.

The only chance you have is to manually increase the watchdog time that is configured by the Fieldbus webConfigurator dialog along in netX. The file responsible for configuring the watchdog time is /usr/lib/node_modules/WebConfigurator/PROFINET_IO/Device/WebContent/Structures/ConfigurationStruct.js. In there you find a string

Code:

this.WdgTime=1e3

1e3 = 1 exponent 3 = 1000 -> so 1000msec

Change it to "10e3" and save the file.

After that change you need to go again into the Fieldbus Web configurator and click "save" to overwrite the existing configuration file. Then redeploy the Node-RED flow

Overall we cannot recommend to run Codesys and netX based communication (Fieldbus container) at the same time.

Thx
Armin

[PersEE]

Yes this is exactly what I expected.

I can confirm that running Fieldbus Container at the same time as Codesys container on one netPI causes this problem. I have seen this with my device too.

This happens exactly at the time when Codesys is performing its licence checks (this is our assumption) after around 5 minutes of running. During this license check it talks to the GPU of the Raspberry CPU and does a lot of other things. This mechanim seems to have influence on the netX communication over SPI and interrupts it so that the netX watchdog triggers (default 1000msec) and the PROFINET protocol stack stops to work within netX and finally the Node-RED node stops operation. The SPI communication is reestablished by the netX driver but then it is too late.

The only chance you have is to manually increase the watchdog time that is configured by the Fieldbus webConfigurator dialog along in netX. The file responsible for configuring the watchdog time is /usr/lib/node_modules/WebConfigurator/PROFINET_IO/Device/WebContent/Structures/ConfigurationStruct.js. In there you find a string

Code:

this.WdgTime=1e3

1e3 = 1 exponent 3 = 1000 -> so 1000msec

Change it to "10e3" and save the file.

After that change you need to go again into the Fieldbus Web configurator and click "save" to overwrite the existing configuration file. Then redeploy the Node-RED flow

Overall we cannot recommend to run Codesys and netX based communication (Fieldbus container) at the same time.

Thx
Armin

Hi Armin,

Thank you for your reply. I'm sorry for the delay in my feedback.
 
As you suggested, I have changed the Wdgtime to a larger number, however, the problem is not solved (as shown in the attached pictures).

       

Could you please help me with this?

Much appreciation.

[Armin@netPI]

Hi There,

I gave you the wrong file. The correct file is /usr/lib/node_modules/WebConfigurator/PROFINET_IO/Device/WebContent/GSDMLManager/GSDMLInterpreter.js.

In this file change n.WdgTime=1e3 to n.WdgTime=10e3

I checked it now with my netPI and now it works more than 10 minutes without stopping. Before it stopped after 20 seconds.