Контроллер сваливается в SERV

[sa6a931]

Помогите, пожалуйста, разобраться, куда смотреть. На обьетке, контроллер B&R вываливается в SERV режим часто, перезагрузка помогает, но через какое-то время опять вываливается, по логам ID ошибки 6403.

gaz.png

[Andreyit]

Близкая тема вот.
Если не проблема в карточки памяти, то "Despite having all modules stored redundantly in the file system (safe file system) it can happen that one or more B&R modules show an incorrect checksum after a number of restarts or after a CF is created.
Since the partitions show the correct status, however, this is not detected and the modules are not restored.
Since AR I3.09 this error can by eliminated by saving a blank text file named „AdditionalSecurityCheck.txt“ in the root directory (C:/) of the CF card."

[keysansa]

6403. Из справки:
Error 6403 is almost always caused by an application error; usually it's a pointer error. A pointer (dynamic variable) is pointing somewhere in memory and overwrites a B&R object. In this way, it writes directly to a task, data object, system module, etc.
A background operating system process checks each checksum. If it comes across a corrupt object, the system is stopped and error 6403 is entered into the error logbook.

Pointer errors are hard to find. Especially if they are only noticed when error 6403 occurs. Why?

The system only detects the error several seconds / minutes (usually 1 to 30 seconds) after an object has been overwritten. Other errors, such as 25314 "Exception Page Fault", are detected immediately by the system while memory is being accessed. It's also aggravating that a pointer error can exist in the application and neither the programmer or the operating system can detect it. Only when a B&R object is "coincidentally" written to is the error noticed. In practice, this means that a pointer error has been "lying dormant" for quite awhile in the application and then makes itself known by chance when the program is expanded – new tasks, libraries, data objects, etc. Oftentimes, the new objects receive the blame since the program worked before. However, this is not always the case.

The only remedy is to localize the error. To do this, the error must be able to be reproduced and occur as quickly as possible. Leaving out (not downloading) individual tasks is not a solution since the entire memory image changes. The error may no longer occur since the B&R object is no longer present at this point. So this eliminates this possible path. Other ways must be attempted.

Two cases/methods can be used:

Method A: The error doesn't occur directly after the PLC goes into RUN mode. The task classes or individual tasks can be stopped in Automation Studio online mode to determine which task is causing the error. First, stop entire task classes and then just the individual tasks until it can be clearly determined (reproduced) that the error is no longer occurring whenever a certain task is stopped. Of course you have to take into account that if Task A triggers an action in Task B, and Task B is the source of the error, then the error will not occur if Task A is stopped and Task B is not. Within the task, only program lines which contain pointers accessing memory can be responsible.

Method B: This method must be used if the error occurs immediately after a power-on. In the Init-Sp of a task (highest task class TC8, last class), allocate the entire available DRAM memory and enable checksum monitoring. This can look like this example:

MemLen= 65535 ; We start with 64 kB - variable "MemLen" must be defined as UDINT
DOCreate.enable= 1
DOCreate.grp= 0
DOCreate.pName= "all_dram"
DOCreate.len= MemLen
DOCreate.MemType= doTEMP ; DRAM !!!
DOCreate.Option= 0 ; with checksum monitoring!
DOCreate.pCpyData= 0
loop
DOCreate FUB DatObjCreate()
if DOCreate.status <> ERR_FUB_BUSY then
exitif DOCreate.status = 0
if DOCreate.status = doERR_NOMEMORY then


MemLen= MemLen - 1024 ; 1 kB less
DOCreate.len= MemLen
else
exitif 1 = 1 ; other errors? if so, abort.
endif
endif
endloop

This program code handles the entire available DRAM memory. Now you can start leaving out tasks (not downloading them). Otherwise, proceed as with Method A.
Method B also works for Case A.

Где-то в программе отсутствует проверка на неверный указатель. Чаще всего это с связано с ошибками работы с массивами (размерность указана с 0, а используется с 1, соответственно, задняя граница убегает) Решить это может только разработчик (или новая разработка). Ну, или, если подробнее расскажете, то, возможно, получится решить проблему. Если, конечно, объект уже не на гарантии.

[sa6a931]

В коде был косяк, обращался к не существующему массиву, как он прошел сборку, не ясно, но устранили с коллегой, работает стабильней.