• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Profinet Bus Failure
#1
During the last month testing a netPI running Node_RED I encountered twice a profinet failure (LED ERR Red Solid).
Is there somewhere a log file, which could give me some more information what could have caused the error?
  Reply
#2
The current source code example implementation in Node-RED does not allow to look closer to the error that happened. It is of course possible to extened the source code.

But I know this error very well and know when it happens. You have to know that once started the netX51 network controller runs a watchdog to monitor its user application - in our case Node-RED - if it is still running. If now during normal operation Node-RED crashed by any reason, or you slowed down Node-RED too much, or you simply call a "kill $PID" with $PID as process ID of Node-RED then Node-RED and the fieldbus node does not have any chance to trigger the watchdog in time and netX51 automatically goes into this fail state. This is the only error that can happen.

Node-RED is an application that is running in a single thread. So once you program an infinite loop in javascript for example with no return, this will lead to such an error.

What else can you tell us when you see this error happened? Was it happening during experimentation phase, during complex data aggregations in Node-RED? When did it happen in your case?
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
In one case it happened at startup. Within the fieldbus node I found following information:

Edit fieldbus in node
!Last Error -2146697183
!Description xChannelIORead return error 2148270113(0x800c0021) [COM-flag not set]

Edit fieldbus out node
!Last Error 2148270113
!Description xChannelInfo return error 2148270113(0x800c0021) [COM-flag not set]

From my own log within Node-RED I can tell, that Node-Red itself was running.

Any help is much appreciaped
  Reply
#4
Well the Error "COM-Flag not set" is a common error that just tells that the netX chip is expected to start process IO data exchange with PROFINET by indicating this with a special bit named "COM" = communication running. But this bit is not coming by any reason.

That Node-RED is running or not after the error happened can still mean that starting Node-RED and its application still consumed more time than the watchdog time is set.(1000msec by default). So netX is very strict monitoring the time. If it expires netX stops communication in all cases. Only deploying the Node-RED flow again recovery from this error.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#5
What do you mean with 'this bit is not coming by any reason'.
Also could I somehow measure the execution time of my flows within Node-Red.
  Reply
#6
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.
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#7
Where could I disable the netX watchdog. Would it be also possible to increase the time instead of disabling it.
  Reply
#8
Yes you can change the value to any value you want.

I think you have recognized that the Fieldbus Nodes are configured via web-configurator-fieldbus HTML pages. On the github source code project the whole web confgurator project in a zip file that is extracted when the Docker image is build. When you unzip it you find a folder named WebConfigurator V1.0200.725\PROFINET_IO\Device\WebContent\Structures\ and a file "ConfigurationStruct.js". In this file you find the default settings of the profinet configuration data including the watchdog time. There you find the "this.WdgTime = 1000" as default value setting the watchdog time to 1000msec. Change it to any value you want.

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

  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Profinet to Siemens PLC j.langlois 4 3,503 January-26th-2021, 06:11 PM
Last Post: j.langlois
  Profinet name lost after reboot Dipro 7 4,803 November-16th-2020, 01:07 PM
Last Post: Armin@netPI
  Profinet stopped working (spidev spi0.0: SPI transfer timed out) Schranz 7 5,019 November-2nd-2020, 04:20 PM
Last Post: Armin@netPI
  netPI profinet device name WalterSchaefer 2 2,491 October-7th-2020, 11:10 AM
Last Post: WalterSchaefer
  how to pick up PROFINET data and store them to OPC UA server on Node-RED/netPI. tad 7 5,584 March-16th-2020, 10:21 AM
Last Post: Armin@netPI
  PROFINET IO startup compilation arpan.patel@slscorp.com 3 2,807 February-24th-2020, 12:47 PM
Last Post: Armin@netPI
  Profinet Startup Time Schranz 3 3,399 November-18th-2019, 03:22 PM
Last Post: Armin@netPI
  Codesys RTE profinet echteler 2 3,364 September-25th-2019, 09:56 AM
Last Post: Armin@netPI
  normal ethernet port using for Profinet MGharat 4 4,638 August-7th-2019, 10:39 AM
Last Post: hannes
  Detecting NetPI in Siemens TIA via Profinet andrewc 3 3,798 April-11th-2019, 06:42 PM
Last Post: Armin@netPI

Forum Jump:


Users browsing this thread: 1 Guest(s)