СПК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]

Добрый день.

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

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

[Lexman]

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

[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/e...ums/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 часов без сбоев, что на мой взгляд, подтверждает выше описанную гепотезу.