Здравствуйте уважаемые Господа разработчики! Обмен по протоколу ModBus TCP. При обрыве связи (сбой коммуникационного оборудования Ethernet) не восстанавливается связь по 502 порту у РТМ который работает под ОС Windows XP. Т.е. не восстанавливается достоверность у каналов связанных с источниками ModBus TCP, при чём в файле IP_modbus параметр OFFCOUNT установлен в 0!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Проверили на OC Windows XP. Связь восстановилось через 2-3 сек.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Попробуйте "выдернуть" сетевой кабель из ПК, дождитесь недостоверности и подсоедините кабель. Мы проверяли на нескольких машинах, результат отрицательный. Причём,если отсоединить само устройство от сети, с которого читаем данные, то связь с ним восстанавливается, но если происходит сбой сетевого оборудования (допустим близлежащий switch) то помогает только полный перезапуск самого RTM.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Попробуйте настроить <число> TMDICONN - таймаут в миллисекундах на удаление подключения к IP-адресу при наличии постоянных ошибок обмена с ним (возможно, подключение не было корректно удалено ОС).
Также можно посмотреть код ошибки при DEBUG = 400.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Продолжали ли Вы эксперименты с нашими рекомендациями? Каковы результаты?
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемые Господа!
Проанализировали статистику за 2 месяца работы РАЗНЫХ ПРОЕКТОВ, с групповыми и не групповыми типами организации запросов:
Связь восстанавливается, только время восстановления слишком велико, и составляет в пределах 3-12 минут! Для групповых в большую сторону, для не групповых в меньшую, причём не зависит от сложности проекта, но зависит от числа устройств (НЕ КАНАЛОВ) с разными IP, чем больше тем дольше восстановление.
Попробуйте всё таки у Вас организовать сеть RTM+2-3 источника (устройства с разными IP и пусть у каждого из них будет с десяток регистров). И повторите эксперимент. Мы думаем что время восстановления увеличивается кратно числу устройств (IP адресов источников).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Тест был такой. Профайлер (IP 192.168.2.120) Устройство Iskra MC760 (IP 192.168.2.178) Два симулятора (IP 192.168.2.221 и 192.168.3.30)
Эксперимент 1. Выдергиваем шнур у Iskra. Через пару минут вставляем обратно. Связь восстанавливается в течении 10-15 сек.
Эксперимент 2. Выдергиваем шнур у PC с профайлером. Вставляем обратно. Связь восстанавливается через 20-30 секунд.
Условия переподключения сильно зависят от устройств, т.к. алгоритмы удаления соединения могут отличаться. А также устройства по разному интерпретируют разрыв связи до роутера и от роутера до МРВ.
Если есть какие-нибудь замечания по тесту, напишите. А также, если можете, укажите устройства, с которыми Вы работаете. Возможно, они у нас есть, и мы тогда протестируем связь на них.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Отправьте пожалуйста Ваш проект нам,мы попробуем изменив адреса устройств и адреса регистров на свои реальные и протестируем у себя.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Отправлено. Пожалуйста, сообщите потом о результатах.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Спасибо, получили! О результатах сообщим как только проведём тестирование.
Posted by Grigorovskih (Участник № / Member № 1915) on :
Здравствуйте уважаемые Господа!
Мы решили продолжить обсуждать этот вопрос. Т.к. в новой версии у нас те же неудовлетворительные результаты по времени восстановления связи. Устройства, с которыми у нас осуществляется обмен, это контроллеры фирмы ICPDAS: I7188EX и I7188E5D. На них запущено ПО которое преобразует протокол обмена с устройствами сторонних производителей в MODBUS TCP. Количество регистров читаемых RTM-ом с каждого составляет 20, контроллеров в сети около десятка. При потере связи с двумя-тремя такими контроллерами, восстановление происходит от 5 до 20 минут. Если у Вас есть возможность (Наличие таких контроллеров) проверки мы можем выслать прошивку на них и файл проекта.
Posted by Sergei (Участник № / Member № 161) on :
Тоже столкнулся с этой проблемой. Контроллер I-7188EX опрашивается по протоколу ModbusTCP через два DSL модема на расстоянии около километра. Через какое-то время МРВ перестает видеть ответы контроллера. Добавлял в файл ip_modbus 1000 RECTIMEOUT 5 TIMEOUT 5 ERROR 0 OFFCOUNT (Может значения больше, надо глянуть на объекте) Связь держиться дольше, но все равно падает. Есть запись обмена (через microsoft network monitor). Судя по логу контроллер только и успевает слать аскноледжменты и иногда невпопад отвечать. Зато МРВ не ждет таймаута и валит запросами как из рога изобилия, по 5-6 запросов в одном пакете не редкость. Я плохо разбираюсь в TCP, может Вам удастся понять причину такого поведения. Отправлю лог обмена на hotline@adastra.ru
Posted by Avgorr (Участник № / Member № 2607) on :
Такая же проблема с контроллером WinCon, связь через два SHDSL модема. Приходиться ехать на объект и перезагружать контроллер, и после этого перезагружать МРВ, только тогда они начинают видеть друг друга.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
to Grigorovskih
10 контроллеров у нас нет. Настроено ли у Вас отключение при неудачных попытках (параметр OFFCOUNT). Если нет, то Trace Mode продолжает интенсивно его опрашивать, забивая сеть. При этом обращения к другим контроллерам происходит реже.
to Sergei
Попробуйте поставить таймаут более, чем 1 секунда. А также увеличить паузу между запросами. А также советуем перейти на более свежий релиз. В релизе 6.05 файл IP modbus был устроен по-другому.
to Avgorr
IP адреса у Вас статические или динамические. Указываете ли Вы их в настройках?
Posted by Avgorr (Участник № / Member № 2607) on :
Все адреса у меня статические, все прописаны в свойствах узла.
Posted by Sergei (Участник № / Member № 161) on :
Я сейчас на объекте, поэтому могу сообщить подробности. В какой то момент контроллер не отвечает вовремя на запрос, МРВ шлет следующий, контроллер отвечает на предыдущий. При этом МРВ не ждет TIMEOUT и шлет следующий запрос сразу после ответа контроллера. Так они и общаются. Сам момент потери взаимопонимания я не поймал, но снял лог в этом и нормальном режиме опроса. Причем TIMEOUT я увеличивал до 250, все равно была рассинхронизация. Вчера увеличил до 500. Как оно сейчас не знаю, завтра проверю.
Проверить не получилось, умер блок питания на одном из модемов
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
to Avgorr
Пришлите логи обмена, как Trace Mode, так и сторонние.
to Sergei
Вам нужно увеличивать не Timeout, а RECTIMEOUT.
Posted by Sergei (Участник № / Member № 161) on :
RECTIMEOUT у меня 1000
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Его и надо увеличивать. За 1 сек не успевает ответить контроллер.
Posted by Grigorovskih (Участник № / Member № 1915) on :
:"Настроено ли у Вас отключение при неудачных попытках (параметр OFFCOUNT). Если нет, то Trace Mode продолжает интенсивно его опрашивать, забивая сеть. При этом обращения к другим контроллерам происходит реже." Если другие работали, они и продолжают дальше работать, а если б МРВ интенсивно продолжал опрос устройства, которое "отваливалось" то восстановление бы проходило мгновенно, поэтому исходя из хелпа и из того что Вы сказали параметр должен быть OFFCOUNT = 0, в противном случае (OFFCOUNT = n) после обрава связи мы вообще не "увидим" это устройство!
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Пришлите Вашу программу. Будем пробовать как-то протестировать данную ситуацию.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Вам отправлено небольшое обновление, ждем логов.
Posted by Андрей Мельников (Участник № / Member № 3046) on :
Здраствуйте! Не могли бы Вы прояснить ситуацию с ключом ERROR в файле IP_modbus. Дело в том, что как замечено на продуктивных системах, а затем проверено на тестовой, существует следующая тенденция: если ключ ERROR установлен от 50 до 200, тогда система восстанавливает связь пределах 1 минуты (1.5 минут). Если от 200 до 500, тогда 2 до 7 минут. Если от 500 до 1000, впределах 10 - 15 минут. 5000 - это 1 час. В документации сказано, что "при отсутствии соединения монитор будет пытаться установить его с заданным в этой строке периодом (в миллисекундах)." Вопрос, во-первых, в чем измеряется ERROR и как правильно этот ключ настраивать?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В новой редакции справки этот ключ описан так.
<число> ERROR
при отсутствии соединения монитор будет пытаться установить его с заданным в этой строке периодом (в секундах).
