Добрый день, люди добрые. Собственно, вопрос в названии темы: можно ли как-то подсчитать количество запросов и ответов от модбас-слейв устройства (в моем случае китайского реле)?
Вид для печати
Добрый день, люди добрые. Собственно, вопрос в названии темы: можно ли как-то подсчитать количество запросов и ответов от модбас-слейв устройства (в моем случае китайского реле)?
Если ввести переменную для чтения булевую, то наверное можно. Посмотрите, в настройках Logica, там можно сделать чтение по переменной.
И еще там есть переменная статуса. Ставите большой период опроса, взводите переменную на чтение, по статусу ответа сброс. ну и это все на счетчик.
з.ы. не пробовал ни разу, но что-то в этом роде.
Здравствуйте. Попробую объяснить свои хотелки. Есть ПР-103, и есть китайское модбас-реле, мастер и слейв соответственно. В ПР для китайца настроена переменная "статус".Вложение 72202
Для получения статуса китайца ПР же отправляет на него запросы, правильно? Допустим, было отправлено 10 запросов, на 7 из которых было получено "Тру", а на 3 - "Фолс". То есть процент положительных - 70. Как такой подсчет реализовать?
Если эта переменная вообще работает( в чём я сомневаюсь, надо проверить), то будет TRUE пока реле на связи, и False, когда не на связи.
Период опроса по умолчанию раз в 100мс, если вы засечёте время работы и отключения в секундах и умножите на 10, то получите примерное кол-во опросов ВКЛ и ВЫКЛ.
Вопрос нафига это надо?
Ну, я не уверен, но в ПРках есть переменная "Опрос".
По идее можно, если не важна быстрая скорость опроса, извратиться так:
* С какой-то периодичностью (BLINK) выставляем Опрос в True.
* Этим самым мы сами решаем, когда что опросить и можем подсчитать количество выставлений Опрос в True - число опросов.
* По идее (и это я не проверял) после выставления Опроса можно считывать Статус. Если повезёт - то она будет отображать статус устройства в момент последного опроса. И тогда можно всё это считать и суммировать.
...хочу только спросить, зачем это на ПРке. В ОВЕНских СПК я делаю диагностические экраны с такой статистикой - но там сам ПЛК сообщает о том, какое устройство он ща опрашивает.
Есть модбас линия с десятью такими китайцами на ней, которые по сработке датчиков свет включают. Подкинулся по отладке к ПР, к которой все стекается от китайцев - и у половины этих китайцев статус нестабильный. ПЛК туда слишком жирно ставить. А вот такую статистику, как я выше описал, хотелось бы выводить в веб-морду какую, чтобы наладчик прям в поле мог проводить работы с этими китайцами (контакты там протянуть, провод поменять, я не знаю, сопротивления воткнуть) и сразу на экране телефона видеть результат своих действий - обратную связь, скажем так.
Ага, понял! Ну, точно, диагностический экран (это из моей статьи - там ещё про тест всех выходов есть):
Вложение 72205
ИМХО, для ПРки ты слишком замахнулся: она такое не потянет по фишкам. Тем более что у ПРок-то встроенной WEB-морд нету и не будет.
Я делал простые диагностические экраны:
* Статус устройства
* Число ошибок
* Состояние всех входов
* Состояние всех выходов
Человек подключает систему к Scada, соответственно можно читать нужную переменную, в которой будет статистика.
Переменная на опрос действует на всю линию в ПР, если переменная 0, никакого опроса и мало того он прерывается.
Если переменная статуса устройства меняет свое состояние перед опросом и после, то ее можно использовать на счетчик.
Если она меняет свое состояние на false только в случае ошибки а остальное время типа true то ничего толком не выйдет.
Вообще ПР тут через Ж работает.
Блин, не могу уже вспомнить, так давно это было.
Прибор был полностью автономный и собирался из:
- Аккумулятор 18650
- Bluetooth HC-05
- RS485 board
Android приложение, что-то типа Modbus-анализатора,
которое прослушивало сеть и составляла дерево:
ветки - номера Modbus-slave устройств
листья - номера регистров + число запросов + число правильных ответов + число ответов с ошибками + число запросов без ответов
а так же учитывало активное время и время простоя в ожиданиях ответа + все это в процентах
Для анализа RS485-сетей в полевых условиях самое то!!!
китайцы простые очень.
https://pcus.ru/moduli/moduli-rele/r...-modbus-rtu-2x
Очевидно управляют чем-то через реле, судя по высказыванию выше освещением.
Вообще для контроля и качества линии достаточно просто подключиться через преобразователь интерфейса USB-RS485 с ПК и установленной Scada, например с ноутбука. Вместо ПР. И поклацать релюшками при ПНР, Scada покажет качество обмена, количество ошибок и т.д. (Например в RapidScada в свойствах устройства на линии есть данные по количеству запросов и ошибок, просто нужно создать правильный шаблон под ваши реле в драйвере Modbus)
А само ПР настраивать полностью на циклический опрос без заморочек. Ну в качестве аварии собирать битовые маски на статусы каждого реле и потом в Scada, так вы узнаете какое реле умерло и перестало отвечать)
То есть нет необходимости для ПНР усложнять сильно программу ПР, ограничиться только реальными авариями.
Валенок так там ПР, ну нафига всем этим ее нагружать то? :)
А сделать обвязку для контроля обмена в ПР это сколько % ее времени ковыряния? Сама то ПР не предоставляет готовых данных по обмену в какие-то системные регистры.
ПР включает-выключает свет, слушая этих китайцев. Ковыряется в носу )
Товарищи, есть такой еще вопрос. А можно как-то на этих китайцах отслеживать ноль? В чем суть: на вход "In1" китайцу приходит нормальнозамкнутый датчик охранки. То есть если ПР на входе китайца увидела ноль, значит есть три варианта: 1) датчик сработал. 2) датчик отвалился 3) отвалился весь китаец целиком. Вопрос - как без использования переменной "статус" отслеживать, что пришел именно ноль от датчика, а не отвалился китаец?
TaPX если вы собрались использовать RapidScada, то можно сделать финт ушами.
1. Все реле подключить непосредственно к RapidScada а не к ПР
2. Купить у разработчика Модуль Автоматического Управления и настроить пересылку данных от ПР к Реле и от Реле к ПР
3. Использовать в таком случае тег "Status" в RapidScada на каждое устройство - это зарезервированный тег для устройства Normal/Error (как раз потерю связи показывает)
Ну соответственно исходя из такой схемы писать программу на ПР.
Вопрос только в скорости сработки останется, например когда ПР решит включить свет то команда о включении пройдет еще и через Scada.
ПК со Scada должен быть на ИБП вместе с ПР, чтобы все работало.