0A0F0002 PLC Exception and 080F60B0 after the PLC Online Change

[MateuszGrudzien]

Hello, we are having troubles with a few Core X3 devices that were recently updated to the firmware version 2.6 LTS. After the update, some PLC Online Change procedures are ending with an unknown exception. On the IWE side it looks like the code transfer halted at 0kB of transfer and it says that connection to the PLC was lost. On the CoreX web interface, I can see there is an error 502 when I try to open the PLC app page. Also, there is a PLC app exception "0A0F0002 PLC: Exception", but without any detailed diagnostic code provided (please see attached screenshot)! After the complete reboot then error "080F60B0 Condition detected that triggered a safe machine state" occurs, but this is probably secondary to the 0A0F0002. After the reboot everything is working fine.

As 080F60B0 description suggested, I downloaded the diagnostic log and also the exception log from the DataLayer/Framework/Exceptions (both attached). Also, once I was also able to see the exception log from the IWE (attached).

This error never occurs when the PLC code is Downloaded instead of Online Changed, so it is kind of a workaround. On some days it can never occur, and on other days it occurs during almost every other Online Change. As for now, I cannot see any pattern here.

How can we debug this?
Why there is no detailed code provided for 0A0F0002?
What is the cause of "Error on IO update of instance [...]" exceptions in IWE?
Is it a known issue?

[MateuszGrudzien]

As there is a limit of 5 attachements, I attached the screenshots here 🙂

[JerzyKłusek]

Hello, I also has a problem with online changes. I'm waiting for solution of this problem.

[georkueh]

Hi,

analyzing the log file I assume, that a memory corruption is the root cause ("<SysExcept> runtime received SIGABRT - system may be in an inconsistent state" file Logbook_default_2024-10-07_11-31-46.csv, line 87). This can be a result of wrong pointer handling in the user program. Are you using any pointer in your PLC program including the function blocks? Please check this first.

Another question: Are you using the checkfunctions in your PLC program?

Maybe we can give you some more information, if you add a systemreport here.

kind regards

Maybe we get more details

[MateuszGrudzien]

Hi,

I will try to provide you with a system report when I will have access to the machine. Should this system report be created exactly when the exception happens? I guess you meant the ctrlX Core system report, not the ctrlX Works system report?

In my PLC program, I do not use any pointers explicitly, nor do I use any library other than "starting" libraries when a new project is created. The only place where pointers are used is exactly in those standard check functions that you mentioned. Usually when there is exception because of the user program, IWE displays "exception" in the bottom and points out the problematic line of code. At least that was the case in the previous generation of PLCs, has that changed?

When I was testing the PLC code in Simulation today, I experienced a similar behavior. I tried to do an Online Change, but download of the code froze on 0% and a popup with exception was displayed. Message was: "*EXCEPTION* [CodeInit] code: App=[Sim.ctrlX_CORE.Application], Exception=[AccessViolation]". Please also see the attached screenshot with logs. It was a pure ctrlX PLC Engineering simulation, not a virtual Core. I'm not sure if this give us any additional info? 😄

[MateuszGrudzien]

And I also attach system report below 🙂

[CarloCtrl]

Hi, 

I'm facing the same issue. 
In detail, after update from 2.4 to 2.6, we receive a lot of Sig abort msg on PLC Eng, in different cases. 
Also in case of reset cold or warm (via PLC or via Browser). 

This is the detail found in framework/exception : 

{
"date": "2024-10-23 14:19:03 UTC",
"name": "/snap/rexroth-automationcore/1572/rexroth-automation-frame",
"signal": "11 (SIGSEGV)",
"code": "-1",
"register": {
"IP": "0x7f883be158",
"SP": "0x7f8882e5f0",
"BP": "0x7f8882e5a0"
},
"stack": [
{
"frame": 0,
"stack": "[0x7f883be158]"
}
]
}


logbook attached :