СПК110 М01. CAA SerialCom, ошибка 5802

[Lexman]

Столкнулся со странностью.
Работа по СОМ порту, ST, CAA SerialCom.
На старте открываю все 5 портов на СПК110 М01, по одному из них начинаю опрос, 57600 8N1.
Всё работает штатно/нормально, но через некоторое время (зависит от выставленного цикла в таскменеджере POU) COM.Write возвращает ошибку 5802, и дальше оживить порт невозможно. З
Хендл порта не меняется, повторого открытия или закрытия в цикле не происходит - ставил бряки, не отрабатывают.
Интересное: отваливаюся ВСЕ порты (т.е. заново закрыть и открыть люббой порт невозможно - даже не доходим до xDone) - да же те, по которым обмена не было (!).
Только переброс питания - тогда всё восстанавливается, до следующего раза.
Пробовал открывать только один порт (остальные "молчащие" держал закрытыми) - эффекта ноль.
Но влияет тайминг в таскменеджере: чем меньше время цикла, тем быстрее приходим к ошибке.
В максимуме разгоял задачу до цикла в 6мс - по осциллографу всё укладывается, но ошибка прилетает через несколько минут работы.

Подозреваю на глюк ОС/библиотеки (хотя и кривые руки тоже, хех).
Прошивку ПЛК не обновлял пока - решил тут спросить, может было у кого-то такое. Куда копать?

PS прошивка spk1xxm01 2.4.0923.1000

[Евгений Кислов]

Добрый день.


Куда копать?

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

[Lexman]

Попробую. Но думаю быстро не получится, текущий проект правда немал.

[Lexman]

Добрый день.

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

Выделил логику в отдельный проект, запустил с циклом 6 мс - 24 часа полёт нормальный.
Вывод: библиотека не при чём -> либо порча памяти, либо... какие ещё версии есть? Пока попробую поубирать другие POU из таскменеджера, посмотрю как будет сказываться.

[Lexman]

Дневник мытарств, час 5й :)

Не нашёл явную причину и, что гораздо обиднее, не могу найти способа её найти.
"Спец. POU" по отлавливанию выходов за диапазоны массивов (подозревал тут проблему) не сработали - всё работает ровно, ничего не ловится.
При этом отвалы порта по времени - рандомные, иногда через 2 минуты, иногда через 25. Что делает ловлю багов ну очень медленной.

Решил, пока жду очередного отвала, полазить в кишках работающего Linux через SSH (я не линуксоид совсем), и нашёл интересное:

По порядку:

1) lsof /dev/ttyO0 во время нормальной работы даёт:

[root@spk1xxm01 ~]# lsof /dev/ttyO0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
codesysco 10965 root 153u CHR 247,0 0t0 120 /dev/ttyO0

дескриптор 153, его я и вижу в данных FB

2) после "отвала" порта (программа ПЛК продолжает крутиться) - без изменений:
[root@spk1xxm01 ~]# lsof /dev/ttyO0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
codesysco 10965 root 153u CHR 247,0 0t0 120 /dev/ttyO0

3) Идём в IDE Codesys>Онлайн>Сброс; программа уходит в "СТОП":
[root@spk1xxm01 ~]# lsof /dev/ttyO0
- ПУСТО - (дескриптор освобождён, ОС считает что порт свободен?!)

Жмём F5 в IDE Codesys, программа запускается, пытается открыть порт, НО:
при этом CAA COM.Open после попытки открытия порта (xExecute = TRUE) попадает в статусе xBusy = TRUE и там и остаётся!
Т.е. POU пытается открыть порт, но операция не доходит до завершения. Попытки "передёргивать" xExecute у Open эффекта не даёт.
При этом:
[root@spk1xxm01 ~]# lsof /dev/ttyO0
- ПУСТО - (дескриптор не выдан, порт по мнению ОС свободен?!)
Как так???

А теперь самое интересное:
Далее, идем в веб-интерфейс ПЛК, ПЛК->Настройки->Настройки CODESYS --> большая красная кнопка [ПЕРЕЗАПУСТИТЬ CODESYS...], жмём, подтверждаем.

* через некоторое время IDE теряет связь с ПЛК, снова Онлайн->Логин -> Загрузка приложения *

Запускаем приложение.... вуаля! Порт работает! (До этого помогал только ребут ПЛК по питанию):

[root@spk1xxm01 ~]# lsof /dev/ttyO0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
codesysco 17302 root 154u CHR 247,0 0t0 120 /dev/ttyO0


Евгений, что это может быть?

PS опыты не прекращаю.

[Lexman]

Нашёл у себя один косяк. Таки при некоторых условиях открытие СОМ-порта происходило дважды.

Но вот, что странно: ОС вместе с библиотекой спокойненько выдают два дескприптора одного порта одному процессу (вопреки моим представлениям об этом):


[root@spk1xxm01 ~]# lsof /dev/ttyO0
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
codesysco 31521 root 153u CHR 247,0 0t0 120 /dev/ttyO0
codesysco 31521 root 162u CHR 247,0 0t0 120 /dev/ttyO0


Вполне возможно, что это и было причиной - буду проверять.
Но вопросы изложенные выше актуальности не теряют.
Оставляю в ночь работать, ловушки расставил.

[Евгений Кислов]

Евгений, что это может быть?

Прежде чем дать какие-либо комментарии - мне бы хотелось увидеть проявление проблемы собственными глазами.
Как уже упоминал, для этого мне нужен минимальный проект, в котором она предсказуемо повторяется.


Но вот, что странно: ОС вместе с библиотекой спокойненько выдают два дескприптора одного порта одному процессу (вопреки моим представлениям об этом)

Это нормально для Linux.
Символьное устройство COM-порта (/dev/ttyO0) в сущности является обычным файлом.
Процесс может открыть его несколько раз, каждый раз получая новый дескриптор.

Максимальное количество дескрипторов, которыми может одновременно владеть процесс (в рамках платформы наших контроллеров) - 1024.

В дереве проекта в узле Debug отображается текущее количество дескрипторов, используемых процессом codesyscontrol (см. канал Open Files; предварительно требуется в канал Debug записать значение TRUE).

[Lexman]

Прежде чем дать какие-либо комментарии - мне бы хотелось увидеть проявление проблемы собственными глазами.
Как уже упоминал, для этого мне нужен минимальный проект, в котором она предсказуемо повторяется.


С отдельным проектом пока сложность. К моему ПЛК не вариант подключиться?

PS результаты ночи:

около 2х часов нормальной работы, после чего снова легли.

1) COM.Read зажигает ошибку (код ошибки в лог не вывел, а зря)
2) после этого я гашу блок Read и отправляюсь на отправку очередного запроса COM.Write из пула
3) Write возвращает 5802, после этого я перехожу к переинициализации порта
4) в процессе переинициализации гашу всем Open/Read/Write xExecute и вызываю COM.Close
5) COM.Close остаётся в состоянии xBusy - т.е. не выполняется до конца, никакие танцы с бубном пока не помогли.


Я вполне допускаю ошибку где-то у себя в логике, или порчу памяти, но не пойму, почему это всё не утилизируется при сбросе программы, и что-то блокирует доступ к нему после перезапуска?

[Евгений Кислов]

С отдельным проектом пока сложность. К моему ПЛК не вариант подключиться?

Вариант. Для этого свяжитесь, пожалуйста, со мной через контакты в подписи.

[Lexman]

Напишу о текущих итогах для истории. Явно может кому-то пригодиться.

По результатам анализа вместе с Евгениеем Кисловым, сделаны следующие выводы:

1) ошибка 5802 - это не ошибка работы СОМ-порта, а ошибка состояния CAA Async Manager (https://content.helpme-codesys.com/en/libs/CAA%20Async%20Manager%20Extern/3.5.17.0/CAA-Async-Manager/Enums/ERROR.html), которая говорит о неверном дескрипторе. Но не дескрипторе СОМ-порта, а дескрипторе асинхронной задачи внутри библиотеки CAA Async Manager (эта библиотека применяется много где, потому эта ошибка бывает и у работы с файлами, и у работы с СОМ портами).

2) как говорит документация на CAA Async Manager, количество асинхронных задач ограничено - не более 20.

3) судя по обрывочной информации в интернете, неверный дескриптор задачи говорит о том, что дескриптор есть, а задачи уже нет и/или о повреждении таблицы текущих задач внутри библиотеки (что по мне почти равносильно). А это в свою очередь может являться следствием ошибки в библиотеке CAA.SerialCom при работе с портом, либо о каких-то ещё неявных проблемах, которые без точного их понимания костылём не подпереть.

4) как следствие - данная ошибка приводит к какому-то повреждению среды исполнения программы ПЛК, которую пользователь загружает через IDE. Т.е., программу можно и перезагрузить и перезапустить, но среда (процесс внутри ОС) уже повреждён и при этом не перезапукается, и поэтому порты не оживают после перезапуска (в таблицах по-прежнему мусор). Помогает только рестарт процесса среды исполнения (см. нажатие кнопки в веб-интерфейсе ПЛК выше) или ребут ПЛК по питанию.

Это всё поверхностные предположения, т.к. внутрь этих библиотек заглянуть невозможно.


КАКОЙ ВЫХОД?
По совету Евегния перешёл с CAA.SerialCom на OCL.COM_control/OCL.UNM_SerialRequest.

Делов на час - переписать асихнхронную машину работы с СОМ портом, все параметры схожи, только FB заменить.
Как итог: проработало 12 часов без сбоев, что на мой взгляд, подтверждает выше описанную гепотезу.