This is topic диагностика Modbus TCP/IP in forum Микро Мониторы Реального Времени / Micro Real Time Monitors at Форум TRACE MODE: техническая поддержка.
Подскажите, есть ли в ТМ средства, позволяющие определить наличие связи с контроллером по протоколу Modbus TCP/IP? Причем таких контроллеров несколько, и хотелось бы диагностировать по-отдельности связь с каждым из них.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Общей диагностике обмена по MODBUS служит соответствующий канал в разделе ДИАГНОСТИКА. Там же имеется канал IP Error, уточняющий ошибки обмена. Для более точной локализации ошибок служат флажки НЕДОСТОВЕНОСТЬ в соответствующих каналах обмена. Их можно контролировать групповым образом, объединив каналы, например, по контроллерам.
Posted by ATMosphere (Участник № / Member № 115) on :
Недостоверность - всегда 0! IP_error насколько я понял принимает коды modbus exception, а они формируются самим slave устройством. Т.е. если нет связи, то и в IP_error ничего не запишется. Как узнать о падении slave устройства?
На данный момент если slave устройство - является пассивным, т.е. не программируется, то узнать об обрыве связи с ним - никак не получается. Если же устройство программируемое, можно организовать в программе TM программный watchdog и сбрасывать его меандром из контроллера. Но все это работает только если в сети один Slave. Если же их хотя бы два, то при падении одного - связь со вторым такая, что watchdog необходимо настроить на 1 мин., чтобы он не сработал, т.е. фактически ее - нет.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Странно, что Достоверность не выставляется - вроде в 5.15 это поправлено было... У нас сейчас нет в наличии двух устройств по ModBus TCP, поэтому провести испытания невозможно. Рекомендую Вам использовать для проверки какое-нибудь приложение, которое может анализировать трафик по ModBus TCP, например программу ModScan32. Необходимо посмотреть какие запросы реально выдает сервер ТМ, когда идет обмен с двумя модулями, и когда один из них выключен.
Posted by ATMosphere (Участник № / Member № 115) on :
Действительно, странно! Но достоверность у нас не работает. Может мы чего путаем?
Для проведения испытаний достаточно и demo версии. Запустите ее на паре ПК и посмотрите "какие запросы реально выдает сервер ТМ, когда идет обмен с двумя модулями, и когда один из них выключен".
Надеемся, что проблема скоро разрешится.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Да - эмулятор помог разобраться. Действительно с Достоверностью проблемы. Начсет замедления обмена с устройствами при отсутсвии одного из них - это обусловлено тем, что при каждой попытке установления связи через TCP/IP ОС ожидает установления соединения с удаленным узлом и величина этого таймаута неуправляемая (это уровень ОС), а так как каналы по отстсвующему устройству у Вас не отлючены, то на каждом их пересчете система выжидает установления соединения и весь обмен по данному интерфейсу тормозит в силу того, что он синхронен. Сейчас принимается решение по исправленю ошибки по Достоверности. О сроках мы сообщим в ближайшие дни.
Posted by ATMosphere (Участник № / Member № 115) on :
Отлично! Значит, будем считать, что достоверность каналов по Modbus TCP в ближайшем будущем все-таки заработает. Однако, считаем, что отключенные устройства не должны влиять на связь с работающими устройствами. Ведь есть же куча OPC серверов, работающих на Modbus TCP, в которых качество тегов одного устройства никак не влияет на скорость обновления тегов другого устройства. Если никогда этого не видели - могу также дать ссылку. Почему в ТМ этого нельзя реализовать - непонятно. Получается, если объект обвешан десятками устройств с Modbus TCP, то выключение любого из них - делает систему неработоспособной? Насколько нам известно, в спецификации на modbus - такого нет.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Управление опросом в ТМ полностью отдано на усмотрение пользователю, то есть - пользователь должен сам реализовать включение/отключение опроса каналов по тем или иным устройствам в своем проекте.
Posted by ATMosphere (Участник № / Member № 115) on :
Правильно ли я понял, что это означает создание отдельной программы, которая бы смотрела на Достоверность и выставляла бы Подключение?
Думаю, что при выключении устройства это бы прошло. Т.е. при потере связи мы выставляем атрибут Подключение и продолжаем обмен с остальными устройствами в штатном режиме. Но вот как потом узнать, что связь восстановилась? Ведь по отключенному каналу этого не оценишь.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Только лучше не Подключением управлять, а Состоянием. А Вы сами когда-нибудь задумывались над своим же вопросом: "как потом узнать, что связь восстановилась?"? Это довольно нетривиальная задача, ведь периодическая проверка пробным опросом вообще ничем не отличается от ситуации, когда каналы с аппаратной недостоверностью совсем не отключаются. А если вводить периодическую проверку с задержкой, то какой она должна быть? И не проще ли тогда ее сразу ввести в тот алгоритм, который управляет атрибутом Состояние по Достоверности? Posted by ATMosphere (Участник № / Member № 115) on :
Технически: абсолютно согласен, что задача нетривиальная. Тривиальных задач вообще очень мало, для некоторых - их просто не существует. Но решить ее можно и решают ведь. Например: можно буферировать запросы и ответы; можно пока ждешь ответа от одного устройства слать запросы другим и т.д. Политически: мне непонятно, почему этим должен заниматься я, ведь пользователю ТМ предоставлен гораздо менее гибкий инструментарий, чем разработчику.
"...А если вводить периодическую проверку с задержкой, то какой она должна быть? И не проще ли тогда ее сразу ввести в тот алгоритм, который управляет атрибутом Состояние по Достоверности?..." Ответ: Проще использовать абсолютное оружие - OPC сервер от авторитетного разработчика, тем самым сильно облегчив себе жизнь.
Проясните, пожалуйста, почему лучше управлять Состоянием, а не Подключением?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
"Например: можно буферировать запросы и ответы; можно пока ждешь ответа от одного устройства слать запросы другим и т.д." - ModBus не асинхронный протокол, чтобы так делать! Он подразумевает полудуплекс: Транзакция=запрос-ответ, и ни один из этих элементов протокола не кэшуруем...
Состояние вообще отключает канал от пересчета, соответсвенно прекращается его обработка и выставление в очередь на обмен по внешним интерфейсам. Подключение этого не делает - канал продолжает пересчитываться, он попадает в очередь обмена, только данные в него по обмену не записываются.
Posted by ATMosphere (Участник № / Member № 115) on :
Если говорить про modbus на RS-485, то, наверное, Вы правы. Однако, не понимаю, что мешает обойти это ограничение на ethernet. Послали одному - запустили счетчик, послали другому - запустили счетчик, приняли от первого - сбросили первый счетчик. На ethernet можно даже несколько modbus-мастеров в сети имет!
"... ОС ожидает установления соединения с удаленным узлом и величина этого таймаута неуправляемая (это уровень ОС), ..."
А таймаут в ip_modbus, получается и не нужен?
Впрочем, нам пришлось отказаться от поддержки Modbus TCP в ТМ в пользу соответствующего OPC сервера. Там таких проблем не возникает. Общаетесь с десятком устройств и выключение любого из них никак не сказывется на обмене с другими.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Таймаут, это когда устройство было и с ним было установлено соединение, тогда на каждый запрос осуществляется ожидание ответа по таймауту. Другое дело, когда устройства нет с самого начала, тогда сервер ТМ все время пытается с ним связаться.
По ModBus, кстати готовы бета-версии сервера с исправлениями. Если Вам критично, можем выслать сейчас, но только от Вас необходимо будет письмо по E-mail, что Вы согласны использовать бета-версию продукта.
Posted by ATMosphere (Участник № / Member № 115) on :
Спасибо, но нам и альфы хватило.
Posted by ATMosphere (Участник № / Member № 115) on :
Добрый день!
Разрешите поинтересоваться, сделано ли что-нибудь для устранения озвученных выше ошибок. Когда можно ожидать исправлений? Напомню, речь идет о флаге Достоверность для каналов, работающих на MOdBusIP, и о корректной работе (работоспособности) обмена с устройствами при отсутствии связи из одним из них.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
По поводу ModBus - смотрите мое предыдущее сообщение...
![[Вращающиеся глаза / Roll Eyes]](rolleyes.gif)
![[master / мастер]](graemlins/master.gif)
![[clever / умный]](graemlins/clev.gif)