CODESYS Profinet Controller - Reconnection Issue

[bkautzman]

I have a customer who is using the CODESYS Profinet controller to connect to a custom device. When they disconnect and then reconnect the ethernet cable they will frequently not be able to reconnect and they get a "Controller's IP address is already used by another device" in the PN_Controller status field. They've connected the device to a Siemens PLC and have not seen the same issues. They have assured me that there are not other devices connected concurrently to the ctrlX Core. I've attached the log from the Profinet Controller.

Does anyone have suggestions for troubleshooting?

[CodeWasi]

Hello ,
could you please tell the version the customer is operating with? RM2303 / 1.20? -  Codesys PN Package 4.2.2.0?
I try to reproduce your case and return to you.

Could you please request log-infos from the diagnose system?
The setup-info of the network-connection (core) and the PLC-Ethernet/PN-Controller (Screenshots maybe) would be helpful as well.

Thanks.

[CodeWasi]

Since the reduction rate and sendclock have impact ... please check if  ... SendClock * ReductionRate >= 4ms

[bkautzman]

The send clock is at 2ms and reduction ratio is 8, so with a product of 16 we are well above 4ms.

[CodeWasi]

Feedback from Codesys outstanding. Reply soon.

[CDSAddons]

Please check the following troubleshooting. This could be the "ARP flux" effect, which leads to the corresponding error message here:
https://content.helpme-codesys.com/en/CODESYS%20PROFINET/_pnio_error_ip_addresses.html  

[CDSAddons]

Please check the following:
When you add the PROFINET device, check for the setting for IP and name assignment is set to "Load remanent data".
- If the file is not present on the controller, the driver resets the network settings.
-> After switching to "Use project parameters", the behavior should no longer occur as desired

[bkautzman · Accepted solution]

My apologies for the delay.

I was able to borrow the Profinet device from the customer to test on my own setup. I wasn't able to recreate the behavior they were seeing. 

I suspected there may have been an issue with the original version update we performed on the core, so I reimaged their core with a micro SD card and this has fixed their problem. When we originally upgraded their core from 1.12 to 1.20 we updated all of the system apps with the web UI, so it would appear there is some issue with that method.