Хотел уточнить как дела с устранением проблем с зависанием, поднимавшихся в марте-апреле? Ни здесь ни на мою личную почту, по которой более предметно обсуждали этот вопрос, чтобы не будоражить форум, до сих пор никакой информации.
Хотел уточнить как дела с устранением проблем с зависанием, поднимавшихся в марте-апреле? Ни здесь ни на мою личную почту, по которой более предметно обсуждали этот вопрос, чтобы не будоражить форум, до сих пор никакой информации.
Да похоже никак не решана. МКОН получил 07.11.2020. Похожая ситуация, потеря связи на 5-6 секунд. Более подробно описал здесь https://owen.ru/forum/showthread.php?t=33963
Каково у Вас время ожидания ответа от прибора на мастере модбус TCP? Оно должно быть не менее 300 мс.
Тролль-наседка, добрый, нежный и ласковый
У шлюза тоже есть таймаут ожидания ответа по 485. И если таймаут мастера больше чем таймаут шлюза - то мастер будет рвать соединение и конектится снова.
У МКОН 2 сокета для соединения. И мастер, быстро перебирая эти соединения добьётся их "забития" пакетами.
Учитывая что 80% известных мне мастеров закрывают соединение криво, т.е. "честь" реально оборвать коннект достаётся шлюзу (таймаут при отсутствии обмена 5 секунд)
Вот и получается. У мастера слишком маленький таймаут. Модуль вроде успевает, но если вдруг он призадумается, то мастер не дожидается ответа, и сразу реконектит.
Шлюз ждёт ответ 300 мс.
Мастер реконектит и снова шлёт запрос. Шлюз ставит запрос (по 2-му сокету) в очередь, т.к. порт 485 занят ещё первым запросом.
Мастер и тут не дожидается ответа и снова реконектит.
А сокеты всё... Ждем 5 секунд на принудительный сброс соединения шлюзом.
Что делать:
1. Таймаут мастера не менее 300 мс
2. Мастер должен закрывать коннект полностью, а лучше не закрывать его сразу, а ждать нескольких запросов без ответа.
3. Мы запланировали работы по добавлению настраиваемого таймаута в МКОН.
Мы очень интенсивно и многосуточно тестировали МКОН с 2-мя мастерами по ТСП одновременно на стенде из 31 приборов на 485. В нагруженной офисной сети. И проблем с пропаданием связи не было зафиксировано.
НО! таймауты у мастеров были выставлены реалистичные, а не 10мс, как я видел на некоторых проектах.
Последний раз редактировалось Филоненко Владислав; 21.11.2020 в 09:42.
Тролль-наседка, добрый, нежный и ласковый
В данном случае банальный вопрос, почему шлюз переключает сокеты от одного и того же мастера? где тут логика ?
Видя очередной запрос от того же самого устройства шлюз должен его просто игнорировать а не создавать новый сокет...
например мастер с IP 192.168.10.15 порт х, если второй запрос от него же, зачем создавать под него новый сокет ?
В качестве мастеров были ОВЕН и ИНСАТ ОРС-серверы. "Время ожидания ответа" (этот параметр?) были 300, 500 и 1000 мс с одинаковым отрицательным результатом. Честно сказать, сейчас спросил просто из любопытства, участвовать в тестировании и изучении оборудования, за которое, на секундочку, надо еще и платить деньги, никакого удовольствия.
Для себя я нашел решение, которое безотказно работает при тех же конфигурациях остального железа и софта, на которых МКОН виснет. Причем не приходится упражняться с выбором всевозможных параметров, а потом бояться, что на объекте через несколько минут-часов-дней это все зависнет. И даже если выставлял заведомо малые значения, оборудование не зависало, да, в этом случае были пропуски данных при некоторых запросах, но при следующем/следующих запросах обмен возобновлялся.
На этом по МКОН у меня всё.
Последний раз редактировалось Santi; 21.11.2020 в 10:18.
Тролль-наседка, добрый, нежный и ласковый
Не путайте претензию с "поболтать" , пожалуйста . Вам же ответили про время ожидания ,про эксперименты с другим конвертером....
электронщик до мозга костей и не только
Филоненко Владислав разные порты, разные сокеты, не спорю, но когда запросы с одного порта, неужели МКОН у вас получился таким чахлым и тупым, что не может проверить запрос тот же, что и предыдущий и отдать уже готовый ответ, если он получил его от устройства, даже если мастер разрывал соединение ?