January-22nd-2018, 05:38 PM
To keep the interface to Node-RED very very very simple, the only bit Node-RED is looking for is the "communication" bit of netX, which indicates that netX is exchanging cyclic process data with the PLC master or not. In your case the bit is not set because the netX is in watchdog error. And it will never come again until netX is reset by the fieldbus node due to a Node-RED deploy.
Node-RED does not embody any time measurement function. If you want a reliable result with an application and netX then you have to write indeed your own application as we did it with the Docker image https://hub.docker.com/r/hilschernetpi/n...-examples/. This Docker image embeds a "c" source code on how to program netX as PROFINET IO device with an own application. In such an application you can of course make time measurements yourself and you get predictable results far better than with Node-RED.
Another solution can be to disable the netX watchdog. Then netX will never go into an error state and waits endlessly for new application data.
Node-RED does not embody any time measurement function. If you want a reliable result with an application and netX then you have to write indeed your own application as we did it with the Docker image https://hub.docker.com/r/hilschernetpi/n...-examples/. This Docker image embeds a "c" source code on how to program netX as PROFINET IO device with an own application. In such an application you can of course make time measurements yourself and you get predictable results far better than with Node-RED.
Another solution can be to disable the netX watchdog. Then netX will never go into an error state and waits endlessly for new application data.
„You never fail until you stop trying.“, Albert Einstein (1879 - 1955)
