Ситуация следующая.
Спецификация TCP/IP описывает, что корректное завершение соединения должно производиться путем отправки специального пакета (FIN или RST).
Если вы физически отключаете и заново подключаете кабель - то в большинстве случаев master-устройство открывает новое соединение.
Старое соединение остается в "полуоткрытом" состоянии.
У ФБ MB_TcpSlave есть ограничение на число одновременных соединений; оно определяется константой g_c_usiMaxCountClients, у которой значение по умолчанию - 1.
Т.е. после физического разрыва канала связи - блок продолжает ждать запросов в рамках "полуоткрытого" соединения, а мастер пытается установить новое соединение и не может этого сделать.
Справедливый вопрос - сколько блок будет продолжать ждать пакетов в рамках "полуоткрытого" соединения, прежде чем закроет его сам?
На самом деле, это зависит не от блока, а определяется реализацией стека TCP/IP для конкретной операционной системы и ее настройками.
Я не могу сходу сказать, какое значение у нас; для Windows, насколько я помню, значение по умолчанию составляет 2 часа.
Вероятно, панель не успевает разорвать соединение со своей стороны и пытается работать по старому соединению, а ноутбук сразу создает новое.С чем связана разная реакция MB_TcpSlave на отключение кабеля от панели и от ноутбука?
Я так понимаю, кабель вы отключаете на несколько секунд.
Если подождать дольше (минут 5, например) - думаю, и поведение панели будет таким же, как у нотбука.
У блока есть выход xNewRequest.Как быть в такой ситуации?
Заводите его инвертированное значение на вход IN экземпляра таймера TON c PT, например, 30 секунд.
Если выход таймера сработал - значит, в течение этого времени от мастера не было запросов - тогда перезапускаете блок с помощью xEnable.
В нашем трекере задач есть пожелание на доработку блока - чтобы у него появился вход tSocketTimeout, который будет обрабатываться по описанному выше алгоритму (нет запросов в течение заданного времени - значит, разрываем соединение).
01-10-2022 21-34-05.png
Ответить с цитированием