Зависание ФБ MB_TcpSlave

[Scenix]

Добрый день.

Версия библиотеки Owen Communication: 3.5.11.6.

Функциональный блок исполняется в задаче цикличностью в 10 мс. В случае, если клиент внезапно обрывает соединение, функциональный блок навсегда зависает в попытке восстановить соединение, лечится только сбросом флага xEnable. Если исполнять ФБ в задаче с более редкой цикличностью (например, 200 мс) проблема не воспроизводится.

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

Добрый день.


если клиент внезапно обрывает соединение

Что значит "внезапно"? Когда с него снимают питание или выдергивают Ethernet-кабель?


функциональный блок навсегда зависает в попытке восстановить соединение

Это не так. Управление соединением является ответственностью клиента, а не сервера.

Подробнее см. в этом посте:
https://owen.ru/forum/showthread.php?t=36837&p=389894&viewfull=1#post389894

[Scenix]

Проблема возникает тогда, когда..


выдергивают Ethernet-кабель




Это не так

Это так. Если во время опрашивания мастером слейва, коим является ПЛК/СПК и ФБ MB_TcpSlave, выдернуть Ethernet-кабель и вставить его назад - функциональный блок на запросы не отвечает.

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

На мой взгляд, между фразами "функциональный блок навсегда зависает в попытке восстановить соединение" и "функциональный блок на запросы не отвечает" есть существенная разница.

По ссылке выше описано, что именно происходит.

[Scenix]

На мой взгляд, между фразами "функциональный блок навсегда зависает в попытке восстановить соединение" и "функциональный блок на запросы не отвечает" есть существенная разница.

По ссылке выше описано, что именно происходит.

Прочёл, благодарю. А то что соединение не считается закрытым при отсутствии запросов, это правильная, на ваш взгляд, реализация?

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

Прочёл, благодарю. А то что соединение не считается закрытым при отсутствии запросов, это правильная, на ваш взгляд, реализация?

Это реализация, проистекающая из стандарта TCP/IP.
Ситуация, в которой из контроллера может быть каким-то образом выдернут кабель Ethernet, мне тоже не кажется правильной - желательно, чтобы шкаф автоматики был заперт на ключ, который не смогут получить те лица, которым не надо иметь к нему доступ.

[Scenix]

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

Может быть множество ситуаций, из-за которых связь оборвётся: неисправность кабеля, перебои в работе сетевого оборудования и т. д. Так как в блоке не предусмотрен механизм автоматического разрыва соединения, то выхода два: ставить его на костыли самому (например, я сбрасываю вход xEnable при отсутствии новых запросов в теч-ии определённого времени), либо перезагружать автоматику по питанию. Какой из этих вариантов наиболее адекватным считаете вы?

[Scenix]

В нашем трекере задач есть пожелание на доработку блока - чтобы у него появился вход tSocketTimeout, который будет обрабатываться по описанному выше алгоритму (нет запросов в течение заданного времени - значит, разрываем соединение).


Если этот функционал будет со временем реализован - тогда вопросов больше не имею.

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

Если этот функционал будет со временем реализован - тогда вопросов больше не имею.

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