+- 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: Profinet name lost after reboot (/thread-656.html)
Profinet name lost after reboot - Dipro - November-3rd-2020
Hello Hilscher Support Team
we found an issue regarding the naming in Profinet:
The NetPi loses its Profinet name after restarting the NetPi via the config page and after power loss and we even observed a case when rebooting the container we had to name the Netpi another time. After renaming the NetPi with the PLC (Profinet Master) the communication is working as expected until another shutdown.
Right now we are not sure where the problem comes from.
Where and how is this Profinet name stored?
Best regards
Michael
RE: Profinet name lost after reboot - Armin@netPI - November-3rd-2020
Hi there,
the PROFINET name set over the PROFINET Ethernet based protocol is stored inside a flash memory connected to netPI's industrial network controller netX non-volatile. This guarantees the name's availability after a shutdown/reboot/power-on reset. The name is not stored in netPI's host Linux system or in a container elsewhere.
The only chance for a standard netPI user do delete the netX flash memory content ( and herewith the name) is to reload the netX network controller's firmware. The firmware loading procedure is executed by the Linux driver automatically. In this case the flash memory of netX is cleared completely and also the stored PROFINET name is erased. Only in this case you have to set the PROFINET name again. Whenever the driver is initially called it checks the checksum of the firmware found loaded in the netX controller with the checksum of the firmware located in the Linux driver's folder. If there is a checksum difference the driver loads it, if not the driver keeps the firmware untouched and netX continues to operate as usual.
What software are you running on netPI causing this phenomena?
Thx
Armin
RE: Profinet name lost after reboot - Armin@netPI - November-3rd-2020
There is one thing as additional remark:
The upper 4 leds of netPI named ERR RUN APL SYS are all connected to netPI's netX network controller.
Whenever there is a firmware download activated you see the LED SYS going to state "off" for a short time and then turning "on" again. This is an indication that netX controller has performed a shutdown/reset/firmware load which is totally unusual to see if you are always starting the same container application with the same netX firmware inside.
As I said the netX driver always checks if the firmware on Linux side is the same as loaded in netX. If there is a checksum difference the driver automatically loads the software again into the netX controller.
RE: Profinet name lost after reboot - Dipro - November-16th-2020
Hi Armin
We tried to localize the process causing the issue, considering the information you provided us about saving the profinet name.
We run into some errors in the cifX logs with the first startup:
<2> 11.11.2020 19:36:00.928.387: Firmware download, checking / starting: CHANNEL #0, 1 file(s),
<8> 11.11.2020 19:36:22.978.702: Failed to send MD5 request, lRet = 0x800c0019,
<8> 11.11.2020 19:36:22.978.970: Error checking for download '/opt/cifx/deviceconfig/FW/channel0//R160D000.nxf'!,
[…]
<8> 11.11.2020 19:36:27.988.744: Error reading subblock information, Error: 0x800C0019 (AreaIndex=2, SubblockIndex=4),
[…]
Waiting for added 'cifx0' network interface ... ,
'cifx0' network interface not ready in time,
We again named the NetPi in Profinet and cut the internet connetction of the NetPi to block possible automatic container updates. We rebooted all containers at once and the NetPi didn’t lose its ProfiNet name:
<2> 11.11.2020 20:56:29.576.654: Firmware download, checking / starting: CHANNEL #0, 1 file(s),
<2> 11.11.2020 20:56:30.613.148: MD5 not identical, process file download,
<8> 11.11.2020 20:56:36.875.270: Error downloading firmware to device '/opt/cifx/deviceconfig/FW/channel0//R160D000.nxf'
- (lRet=0x800C0016)!,
[…]
<8> 11.11.2020 21:28:38.243.694: Error reading subblock information, Error: 0x800C0019 (AreaIndex=2, SubblockIndex=0),
[…]
- (lRet=0x800C0016)!,
Provisioning 'cifx0' interface now.,
Waiting for added 'cifx0' network interface ... ,
'cifx0' network interface not ready in time,
After that we rebooted the containers for NodeRed and the ethernet in different order, we again lost the Profinet name and got the following log error:
Error adding plugin (netx-spm.so) device 0@0x0. (Status=0x800C0018),
Additionally we observed issues with the NodeRed Container and the Fieldbus Node not starting correctly until one or more manual reboots of the container.
I hope we could give enough information to give you a detailed view about the issue.
Attached: Complete Cifx Container Log; Complete Node Red Container Log
Regards Michael
RE: Profinet name lost after reboot - Armin@netPI - November-16th-2020
Hi there,
1. Are you running the original netPI software on your netPI or do you use your own OS like Raspian OS?
2. Which application software are you running exactly? Please tell me all the containers you are loading the same time.
3. I suppose all your software is running as docker containers, right?
4. You say something about "NodeRed and the ethernet" ? What exactly does that mean? Two applications?
Thx
Armin
RE: Profinet name lost after reboot - Armin@netPI - November-16th-2020
I have the impression that you want to use Node-RED on one hand and at the same time you want to to use also the 2 RJ45 port of netPI as standard Ethernet port on the other. Am I right?
RE: Profinet name lost after reboot - Dipro - November-16th-2020
(November-16th-2020, 08:49 AM)Armin@netPI Wrote: Hi there,Hi
1. Are you running the original netPI software on your netPI or do you use your own OS like Raspian OS?
2. Which application software are you running exactly? Please tell me all the containers you are loading the same time.
3. I suppose all your software is running as docker containers, right?
4. You say something about "NodeRed and the ethernet" ? What exactly does that mean? Two applications?
Thx
Armin
1. We are running the original OS
2. The containers are: netpi-nodered-fieldbus, netpi-netx-ethernet-lan,netpi-desktop-hdmi
3. yes, all are docker containers
4. We where talking about the two container/images from your docker hub, netpi-nodered-fieldbus and netpi-netx-ethernet-lan respectively
All containers are build with the latest image
(November-16th-2020, 10:59 AM)Armin@netPI Wrote: I have the impression that you want to use Node-RED on one hand and at the same time you want to to use also the 2 RJ45 port of netPI as standard Ethernet port on the other. Am I right?
yes one for some network application and the other for the profinet connection.
Regards
RE: Profinet name lost after reboot - Armin@netPI - November-16th-2020
Well ... if you run Node-RED and Ethernet LAN at the same time then each of the containers is grabbing the single resource netX51 industrial network controller for its own purpose. This will no and never work. You can either let netPI a PROFINET device or you let him do Ethernet LAN. Both at the same time is not possible.
This is by the way why the cifx0 loading procedure fails. The LAN container has a firmware file that is loaded into the netX51 chip during container start and also the Node-RED container has another PROFINET firmware file that loads it into netX51 .... if both are loading the netX51 chip over SPI the same time or with a little delay in between this will cause a conflict on single SPI bus.
As I said each firmware load will delete the netX flash memory completely. So once the Node-RED configures the chip to be a PROFINET device ... right after that the LAN container overwrites the firmware and the flash memory is getting empty again and the given PROFINET name is gone.
Thx
Armin