Просмотр полной версии : Подсчет запросов к и ответов от modbus-slave устройства
Добрый день, люди добрые. Собственно, вопрос в названии темы: можно ли как-то подсчитать количество запросов и ответов от модбас-слейв устройства (в моем случае китайского реле)?
kondor3000
07.12.2023, 13:37
Добрый день, люди добрые. Собственно, вопрос в названии темы: можно ли как-то подсчитать количество запросов и ответов от модбас-слейв устройства (в моем случае китайского реле)?
А сами то как думаете? Сколько мастер пошлёт, столько и будет, а кто Мастер опять не написали.
Подключите реле к Овен ОРС серверу и посмотрите какие запросы и сколько отправляет мастер.
Если ввести переменную для чтения булевую, то наверное можно. Посмотрите, в настройках Logica, там можно сделать чтение по переменной.
И еще там есть переменная статуса. Ставите большой период опроса, взводите переменную на чтение, по статусу ответа сброс. ну и это все на счетчик.
з.ы. не пробовал ни разу, но что-то в этом роде.
А сами то как думаете? Сколько мастер пошлёт, столько и будет, а кто Мастер опять не написали.
Подключите реле к Овен ОРС серверу и посмотрите какие запросы и сколько отправляет мастер.
Здравствуйте. Попробую объяснить свои хотелки. Есть ПР-103, и есть китайское модбас-реле, мастер и слейв соответственно. В ПР для китайца настроена переменная "статус".72202
Для получения статуса китайца ПР же отправляет на него запросы, правильно? Допустим, было отправлено 10 запросов, на 7 из которых было получено "Тру", а на 3 - "Фолс". То есть процент положительных - 70. Как такой подсчет реализовать?
kondor3000
07.12.2023, 14:08
Здравствуйте. Попробую объяснить свои хотелки. Есть ПР-103, и есть китайское модбас-реле, мастер и слейв соответственно. В ПР для китайца настроена переменная "статус".72202
Для получения статуса китайца ПР же отправляет на него запросы, правильно? Допустим, было отправлено 10 запросов, на 7 из которых было получено "Тру", а на 3 - "Фолс". То есть процент положительных - 70. Как такой подсчет реализовать?
Если эта переменная вообще работает( в чём я сомневаюсь, надо проверить), то будет TRUE пока реле на связи, и False, когда не на связи.
Период опроса по умолчанию раз в 100мс, если вы засечёте время работы и отключения в секундах и умножите на 10, то получите примерное кол-во опросов ВКЛ и ВЫКЛ.
Вопрос нафига это надо?
Если эта переменная вообще работает( в чём я сомневаюсь, надо проверить), то будет TRUE пока реле на связи, и False, когда не на связи.
Период опроса по умолчанию раз в 100мс, если вы засечёте время работы и отключения в секундах и умножите на 10, то получите примерное кол-во опросов ВКЛ и ВЫКЛ.
Вообще она - переменная - работает. Я понял вашу логику.
Ну, я не уверен, но в ПРках есть переменная "Опрос".
По идее можно, если не важна быстрая скорость опроса, извратиться так:
* С какой-то периодичностью (BLINK) выставляем Опрос в True.
* Этим самым мы сами решаем, когда что опросить и можем подсчитать количество выставлений Опрос в True - число опросов.
* По идее (и это я не проверял) после выставления Опроса можно считывать Статус. Если повезёт - то она будет отображать статус устройства в момент последного опроса. И тогда можно всё это считать и суммировать.
...хочу только спросить, зачем это на ПРке. В ОВЕНских СПК я делаю диагностические экраны с такой статистикой - но там сам ПЛК сообщает о том, какое устройство он ща опрашивает.
Ну, я не уверен, но в ПРках есть переменная "Опрос".
По идее можно, если не важна быстрая скорость опроса, извратиться так:
* С какой-то периодичностью (BLINK) выставляем Опрос в True.
* Этим самым мы сами решаем, когда что опросить и можем подсчитать количество выставлений Опрос в True - число опросов.
* По идее (и это я не проверял) после выставления Опроса можно считывать Статус. Если повезёт - то она будет отображать статус устройства в момент последного опроса. И тогда можно всё это считать и суммировать.
...хочу только спросить, зачем это на ПРке. В ОВЕНских СПК я делаю диагностические экраны с такой статистикой - но там сам ПЛК сообщает о том, какое устройство он ща опрашивает.
Есть модбас линия с десятью такими китайцами на ней, которые по сработке датчиков свет включают. Подкинулся по отладке к ПР, к которой все стекается от китайцев - и у половины этих китайцев статус нестабильный. ПЛК туда слишком жирно ставить. А вот такую статистику, как я выше описал, хотелось бы выводить в веб-морду какую, чтобы наладчик прям в поле мог проводить работы с этими китайцами (контакты там протянуть, провод поменять, я не знаю, сопротивления воткнуть) и сразу на экране телефона видеть результат своих действий - обратную связь, скажем так.
Ага, понял! Ну, точно, диагностический экран (это из моей статьи - там ещё про тест всех выходов есть (https://cs-cs.net/technologii-testirovaniya-i-otladky-shhgitov-s-svtomatikoy-na-plk)):
72205
ИМХО, для ПРки ты слишком замахнулся: она такое не потянет по фишкам. Тем более что у ПРок-то встроенной WEB-морд нету и не будет.
Я делал простые диагностические экраны:
* Статус устройства
* Число ошибок
* Состояние всех входов
* Состояние всех выходов
Человек подключает систему к Scada, соответственно можно читать нужную переменную, в которой будет статистика.
Переменная на опрос действует на всю линию в ПР, если переменная 0, никакого опроса и мало того он прерывается.
Если переменная статуса устройства меняет свое состояние перед опросом и после, то ее можно использовать на счетчик.
Если она меняет свое состояние на false только в случае ошибки а остальное время типа true то ничего толком не выйдет.
Вообще ПР тут через Ж работает.
Блин, не могу уже вспомнить, так давно это было.
Прибор был полностью автономный и собирался из:
- Аккумулятор 18650
- Bluetooth HC-05 (https://www.chipdip.ru/product0/8013336632)
- RS485 board (https://www.chipdip.ru/product/rs485-board-3.3v)
Android приложение, что-то типа Modbus-анализатора,
которое прослушивало сеть и составляла дерево:
ветки - номера Modbus-slave устройств
листья - номера регистров + число запросов + число правильных ответов + число ответов с ошибками + число запросов без ответов
а так же учитывало активное время и время простоя в ожиданиях ответа + все это в процентах
Для анализа RS485-сетей в полевых условиях самое то!!!
Блин, не могу уже вспомнить, так давно это было.
Прибор был полностью автономный и собирался из:
- Аккумулятор 18650
- Bluetooth HC-05 (https://www.chipdip.ru/product0/8013336632)
- RS485 board (https://www.chipdip.ru/product/rs485-board-3.3v)
Android приложение, что-то типа Modbus-анализатора,
которое прослушивало сеть и составляла дерево:
ветки - номера Modbus-slave устройств
листья - номера регистров + число запросов + число правильных ответов + число ответов с ошибками + число запросов без ответов
а так же учитывало активное время и время простоя в ожиданиях ответа + все это в процентах
Для анализа RS485-сетей в полевых условиях самое то!!!
Это интересная штука
Что у этого китайца в карте есть ?
китайцы простые очень.
https://pcus.ru/moduli/moduli-rele/rele-s-interfejsom-rs485-dvojnoj-modbus-rtu-2x
Самый главный вопрос
был
Ответ в общем тоже
Т.е. дело не в счетчиках а в "посмотреть связь"
А какая модель взаимодействия ?
Это
не внятно.
Что именно непонятно?
Что именно непонятно?
что и как делаете с китайцами
Очевидно управляют чем-то через реле, судя по высказыванию выше освещением.
Вообще для контроля и качества линии достаточно просто подключиться через преобразователь интерфейса USB-RS485 с ПК и установленной Scada, например с ноутбука. Вместо ПР. И поклацать релюшками при ПНР, Scada покажет качество обмена, количество ошибок и т.д. (Например в RapidScada в свойствах устройства на линии есть данные по количеству запросов и ошибок, просто нужно создать правильный шаблон под ваши реле в драйвере Modbus)
А само ПР настраивать полностью на циклический опрос без заморочек. Ну в качестве аварии собирать битовые маски на статусы каждого реле и потом в Scada, так вы узнаете какое реле умерло и перестало отвечать)
То есть нет необходимости для ПНР усложнять сильно программу ПР, ограничиться только реальными авариями.
Очевидно управляют чем-то через реле..
Неочевидно. Если ли регулярные операции, их частота или только запись по изменению (оценочная частота изменений).
Всякие "слушатели" ничего не скажут относительно инициатора-мастера. Только "есть ответ, значит слейв увидел и ответил" А принял ли мастер ответ - не факт.
Валенок так там ПР, ну нафига всем этим ее нагружать то? :)
А сделать обвязку для контроля обмена в ПР это сколько % ее времени ковыряния? Сама то ПР не предоставляет готовых данных по обмену в какие-то системные регистры.
Этим это чем? Вы знаете чем еще ПР у ТС занимается?
А обмен по rs для ПР это 90% времени ковырятся в носу))
ПР включает-выключает свет, слушая этих китайцев. Ковыряется в носу )
Товарищи, есть такой еще вопрос. А можно как-то на этих китайцах отслеживать ноль? В чем суть: на вход "In1" китайцу приходит нормальнозамкнутый датчик охранки. То есть если ПР на входе китайца увидела ноль, значит есть три варианта: 1) датчик сработал. 2) датчик отвалился 3) отвалился весь китаец целиком. Вопрос - как без использования переменной "статус" отслеживать, что пришел именно ноль от датчика, а не отвалился китаец?
Вопрос - как без использования переменной "статус" отслеживать, что пришел именно ноль от датчика, а не отвалился китаец?
Ответ - завести датчик на вход себе, а не китайцу
Юзать не нз, а перекидной и завести его на 2 (два) Di которые в норме xor
Ответ - завести датчик на вход себе, а не китайцу
Это логично, но реализовать сложнее в силу разно- и сильноудаленности датчиков от ПР. А есть еще варианты?
Выше добавил
Датчики на объекте именно нз. Есть еще варианты? )
Молится. Духи религии "статус связи есть от диавола" помогут.
я вас понял.
TaPX если вы собрались использовать RapidScada, то можно сделать финт ушами.
1. Все реле подключить непосредственно к RapidScada а не к ПР
2. Купить у разработчика Модуль Автоматического Управления и настроить пересылку данных от ПР к Реле и от Реле к ПР
3. Использовать в таком случае тег "Status" в RapidScada на каждое устройство - это зарезервированный тег для устройства Normal/Error (как раз потерю связи показывает)
Ну соответственно исходя из такой схемы писать программу на ПР.
Вопрос только в скорости сработки останется, например когда ПР решит включить свет то команда о включении пройдет еще и через Scada.
ПК со Scada должен быть на ИБП вместе с ПР, чтобы все работало.
TaPX если вы собрались использовать RapidScada, то можно сделать финт ушами.
1. Все реле подключить непосредственно к RapidScada а не к ПР
2. Купить у разработчика Модуль Автоматического Управления и настроить пересылку данных от ПР к Реле и от Реле к ПР
3. Использовать в таком случае тег "Status" в RapidScada на каждое устройство - это зарезервированный тег для устройства Normal/Error (как раз потерю связи показывает)
Ну соответственно исходя из такой схемы писать программу на ПР.
Вопрос только в скорости сработки останется, например когда ПР решит включить свет то команда о включении пройдет еще и через Scada.
ПК со Scada должен быть на ИБП вместе с ПР, чтобы все работало.
"HMI Modbus Viewer" в плеймаркете мы используем. Это удобно парню в поле - он ковыряет и тут же видит результат
Powered by vBulletin® Version 4.2.3 Copyright © 2026 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot