- В этой теме 52 ответа, 5 участников, последнее обновление 5 лет, 3 месяца назад сделано
.
-
Сообщения
-
Mikhail так фокус в том, что используется Modbus 🙂
не хватает пользовательских функций и возможности при отправке команды вызывать календарь, чтобы выбирать дату и отправлять ее Коммуникатору в виде данных на определенную команду.
По данному поводу есть идеи, но к сожалению нет у меня таких устройств под рукой, чтобы в них были так организованы архивы, как в документации на данный прибор для тестов. Но подобное уже в описаниях других приборов встречал уже.
Нужна надстройка над существующим драйвером Modbus в идеале, и аналог скриптового языка, или использовать механизм существующих формул для создания требуемых команд для отправки и разбора ответов. В общем что-то нужно, но вот тестировать не на чем.
ИМХО достаточно будет надстройки, которая сможет отправлять команду на устройство, возможно (как и писал) как внешняя процедура, где достаточно легко реализовать и выбор даты и формирование команды. Дальше защелки запомнят значение и их можно прочитать «штатным» драйвером.
Я здесь вижу еще одну проблему — как понять, что команда прошла и в регистрах сформировалось нужное значение? По изменению значения не вариант — а если не было расхода? Разве что отправлять команду 0х43 с явно неправильным номером ячейки чтобы признак достоверности был неверным (не =0) а потом с правильным, анализировать, что признак =0 и только после этого читать значения.
«Тяжело…» (с) Гюльчатай, «Белое солнце пустыни»P.S. — коллеги, а планируется реализация запуска из формул СКАДы внешних процедур? Как я понимаю это вызов process() библиотеки C#…
Я пытался, но пишет, что «Метод не поддерживается»…Пишется драйвер. В нем набор команд для запросов. Глубина считывания архивов задаётся в настройках драйвера. Далее scada запоминает какой последний архив она считала и от этой даты продолжает считывать архив. С помощью стандартной команды из web можно отправить количество дней или часов, которые нужно переопросить вручную.
Надстройка в виде скрипта над драйвером modbus это не выход. Написание скрипта — это по сути повторение протокола общения драйвера с этим прибором. Только с кучей геморроя.
Прихожу к выводу, что базовая версия RAPID-SCADA непригодна для работы с оборудованием, где необходимо опрашивать архивную память устр-ва.
А у какой scada базовая версия работает с архивами. Scada системы — это системы реального времени. Работа с архивами это уже отдельная специфика каждого прибора. И здесь сделать какой-то универсальный инструмент нереально. Приборы и их протоколы очень разные. По крайней мере готовых решений в других scada я не встречал. Только набор готовых драйверов под определенные приборы.
ppwkh Совершенно верно Romiros говорит, нереально на существующем драйвере сделать опрос архивов. Да и вообще в текущей организации Коммуникатора и существующих архивов Scada. Появятся архивные БД, будет счастье 🙂
Про настройку я больше говорил, что драйвер Modbus должен быть более гибок по коду, чтобы делая драйвер на его основе вызывать его процедуры не прибегая к формированию новых команд, самостоятельному расчету CRC и так далее.
То есть драйверу передаем команду, и получив ответ формируем например по шаблону его ответ. Посмотрите свою документацию, там набор регистров это по сути структура.
Вот эту структуру и надо описать шаблоном для драйвера.Работа с архивами и прочими «вчера-позавчера» — это уже MES системы — более высокий уровень. Но там уже нет никакого реального времени. Да и работают они все равно со своими архивами, а никак не с приборными.
Насколько я понимаю по любому надо либо писать драйвер, который будет делать запросы к устройству (иначе в структуре регистров данные меняться не будут), либо внешний опросник — как вариант можно посмотреть штатные программы опроса, которые как правило даются с прибором или есть на сайте изготовителя. Кстати тут можно Modbus парсером посмотреть «правильные» пакеты.Но там уже нет никакого реального времени. Да и работают они все равно со своими архивами, а никак не с приборными.
Если мы говорим о коммерческом учете(по крайней мере газа, другими областями я не занимаюсь, поэтому утверждать не буду), то это не так. Архив в системе должен соответствовать архиву в приборе.
Большой плюс RapidScada в том, что она позволяет получить от прибора и хранить у себя
— текущие данные
— архивные данные (пока это часовой и минутный, в шестой версии планируются произвольные архивы)
— события и вмешательства (это такая же неотъемлемая часть коммерческого отчета)Причем со всеми этими данными вы можете реально взаимодействовать — производить вычисления, подписываться на события, экспортировать в другие системы и т.д. и т.п.
Далеко не все системы на это способны. И эта система и задумывалась как система, которую можно доработать и заточить под свои нужды. Поэтому Вы можете создавать любые драйвера, модули и плагины. Т.е. развивать систему модульно, в том направлении, в котором нужно именно Вам. Сделаете сами или закажите у разработчика — это уже Ваше личное дело.Поэтому в данном случае самое правильное (это только мое мнение) — это написать драйвер под РУС-1 и взаимодействовать с прибором без ограничений. Я к тому, что зачем писать какой-то сторонний сервис(читалку), который будет передавать данные на сервер, если уже дана готовая архитектура взаимодействия от чтения приборов до отображения их данных и нужно просто ей следовать.
Я с вами полностью согласен по всем пунктам. Я работал с АИИС КУЭ в электроэнергетике, знаю что это такое не по наслышке. Не зря в одном из постов писал про «Средства измерения» 🙂
Чтобы архив попал в СКАДА, его нужно как то вычитать. Сам Коммуникатор посылать команду (да еще достаточно сложную) не умеет. Драйвер писать под этот прибор на один раз вряд ли кто захочет. Поэтому я и предлагал (на любителя экспериментировать разумеется) опрос (точнее запрос на обновление информации в регистрах прибора) делать внешней процедурой, а читать уже методами Коммуникатора.
Я на этом абсолютно не настаиваю, в данном случае я бы поступил именно так (есть положительный опыт подобной реализации для метеостанции МК-26). Просто для меня написание драйвера на C# достаточно проблемно.
Беда в том, что «заказчик» в данном случае не совсем похоже понимает как все это работает…P.S. про «реальное время» я говорил в контескте того, что MES системы не являются системами реального времени.
Вот чтобы не писать драйвера под каждый прибор (ессно с Modbus на борту), и было бы неплохо доработать драйвер Modbus и добавить в него сценарный режим.
Это не первый прибор, по документации которого я вижу применение пользовательских команд. Это так называемый Extended Modbus где можно запросить пачкой целлый массив данных, но в простом понимании команд 0x03 или 0x04 драйвера оно там несколько посложнее.
А нужно шаблоном описывать весь набор переменных и отмечать им что это и куда уже по документации производителя.
Что-то подобное я делал в драйвере M-Bus и для Allen Bradley.Просто писать с нуля надстройку это тяжко и долго. Да и физически нет приборов таких, чтобы поиграться и попытаться написать.
Вот с появлением 6-й версии посмотрим что там будет с архивами и как с ними работать. Есть другие приборы, где есть архивные данные, но нужно
1. Опрос Коммуникатором только по команде а не в цикле или раз в сутки
2. Возможность передавать в Коммуникатор дату или даже диапазон дат как блок данных
3. добавить настройку в посылку команды вызов Календаря с выбором даты или диапазона дат.Каждый реализует так как он умеет. Я здесь против ничего не имею. Главное чтобы работало стабильно. Просто написал, как сделать более правильно с точки зрения системы.
Чтобы написать драйвер конечно нужно потратить время. Здесь Вы правильно написали (Modbus парсером посмотреть «правильные» пакеты) — это сильно ускоряет процесс, когда видишь, что должно быть отправлено и получено. Я когда писал драйвер, только на эти «правильные» пакеты и смотрел. Потому как хоть протокол и есть, но можно затупить в какой-то мелочи и сидеть часами разбираться, что не так.1. Опрос Коммуникатором только по команде а не в цикле или раз в сутки
Согласен, можно было бы в настройках КП добавить чекбос «автоопрос». Команда ручного опроса итак уже реализована.2. Возможность передавать в Коммуникатор дату или даже диапазон дат как блок данных
В команде мы передаем double по сути это может быть и дата. Просто некрасиво с точки зрения пользователя.3. добавить настройку в посылку команды вызов Календаря с выбором даты или диапазона дат.
Тоже согласен для интерфейса очень полезно.
- Для ответа в этой теме необходимо авторизоваться.