Вид для печати
Добрый день.
Версия библиотеки Owen Communication: 3.5.11.6.
Функциональный блок исполняется в задаче цикличностью в 10 мс. В случае, если клиент внезапно обрывает соединение, функциональный блок навсегда зависает в попытке восстановить соединение, лечится только сбросом флага xEnable. Если исполнять ФБ в задаче с более редкой цикличностью (например, 200 мс) проблема не воспроизводится.
Добрый день.
Что значит "внезапно"? Когда с него снимают питание или выдергивают Ethernet-кабель?Цитата:
если клиент внезапно обрывает соединение
Это не так. Управление соединением является ответственностью клиента, а не сервера.Цитата:
функциональный блок навсегда зависает в попытке восстановить соединение
Подробнее см. в этом посте:
https://owen.ru/forum/showthread.php...l=1#post389894
Проблема возникает тогда, когда..
Цитата:
Сообщение от Евгений Кислов
Это так. Если во время опрашивания мастером слейва, коим является ПЛК/СПК и ФБ MB_TcpSlave, выдернуть Ethernet-кабель и вставить его назад - функциональный блок на запросы не отвечает.Цитата:
Сообщение от Евгений Кислов
На мой взгляд, между фразами "функциональный блок навсегда зависает в попытке восстановить соединение" и "функциональный блок на запросы не отвечает" есть существенная разница.
По ссылке выше описано, что именно происходит.
Прочёл, благодарю. А то что соединение не считается закрытым при отсутствии запросов, это правильная, на ваш взгляд, реализация?Цитата:
Сообщение от Евгений Кислов
Это реализация, проистекающая из стандарта TCP/IP.Цитата:
Сообщение от Scenix
Ситуация, в которой из контроллера может быть каким-то образом выдернут кабель Ethernet, мне тоже не кажется правильной - желательно, чтобы шкаф автоматики был заперт на ключ, который не смогут получить те лица, которым не надо иметь к нему доступ.
Само собой, так и делается. Но линия связи не ограничивается пределами шкафа.Цитата:
Сообщение от Евгений Кислов
Может быть множество ситуаций, из-за которых связь оборвётся: неисправность кабеля, перебои в работе сетевого оборудования и т. д. Так как в блоке не предусмотрен механизм автоматического разрыва соединения, то выхода два: ставить его на костыли самому (например, я сбрасываю вход xEnable при отсутствии новых запросов в теч-ии определённого времени), либо перезагружать автоматику по питанию. Какой из этих вариантов наиболее адекватным считаете вы?
Если этот функционал будет со временем реализован - тогда вопросов больше не имею.Цитата:
В нашем трекере задач есть пожелание на доработку блока - чтобы у него появился вход tSocketTimeout, который будет обрабатываться по описанному выше алгоритму (нет запросов в течение заданного времени - значит, разрываем соединение).
На мой взгляд - он должен быть реализован.Цитата:
Сообщение от Scenix
Я приложу усилия со своей стороны, чтобы выделить на эту доработку время разработчика библиотеки после завершения нашего текущего большого проекта.