Стартовая страница › Форумы › Взаимодействие с устройствами › Протокол обмена M-bus
- В этой теме 17 ответов, 3 участника, последнее обновление 8 лет, 2 месяца назад сделано
manjey73.
-
АвторЗаписи
-
02.04.2018 в 18:19 #8849
litmi
УчастникЗдравствуйте! Кто-нибудь пытался подключать к RapidScada счетчики/расходомеры воды? У них встречается протокол обмена M-bus.
02.04.2018 в 22:56 #8852
manjey73УчастникЯ на данный момент разбираюсь с данным протоколом чтобы сделать драйвер. Но это трындец как не просто…
Написать драйвер под определенный счетчик не проблема, а вот конфигурируемый, со сканированием сети и так далее очень сложно.з.ы. еще купил у китайцев электросчетчик с M-Bus 🙂
Если у вас есть устройство с данным протоколом и вы сможете предоставить к нему удаленный доступ, можно будет сделать драйвер чисто под него.
Непосредственно к RapidSCada еще не подключал, так как только в процессе, но проблем там нет чтобы драйвер написать. Нужен преобразователь интерфейса и документация на прибор, если попадется такой как у меня теплосчетчик например.
03.04.2018 в 19:33 #8855
MikhailМодераторmanjey73, на что похож M-Bus? Сложный?
03.04.2018 в 21:59 #8857
manjey73УчастникНе столько сложный, сколько заковыристый. В приборе могут быть переменные разных типов, int, float, bcd и так далее, так же могут быть фиксированный блок данных и переменный блок данных. Ну и кучка других фокусов.
В принципе, можно пойти по пути драйвера Modbus и все руками настраивать, но хотелось бы более разумного подхода, но без ручной коррекции не обойтись из-за особенностей некоторых приборов. Например счетчик Weser Heat Meter в упор не имеет адреса счетчика, из-за этого не сканируется. К нему можно только по ID достучаться.
Не полностью поддерживает стандарт.04.04.2018 в 19:03 #8858
MikhailМодераторТо есть у устройства можно запросить его регистры и таким образом автоматически настроиться?
04.04.2018 в 22:41 #8859
manjey73УчастникДа, идет запрос по адресу или ID и устройство отвечает пакетом данных, который надо обработать. Есть идентификаторы данных, тип переменной, ну и собственно блок данных.
Но в протоколе несколько вариантов — блок фиксированных данных, блок переменных данных и многое другое. И что выберет конкретный производитель устройства одному ему ведомо, главное чтобы соответствовало протоколу. А вариаций там мама не горюй. Нужны приборы с разными вариантами, чтобы сделать универсальный драйвер.http://www.m-bus.com/mbusdoc/default.php
собственно описание протокола
Особенно хотелось бы увидеть какой нибудь прибор, где есть поля DIFE и VIFE и что в них запихнул производитель.-
Ответ изменён 8 лет, 5 месяцев назад пользователем
manjey73.
10.04.2018 в 15:43 #8883
manjey73УчастникНужно выполнить опрос приборов (сканирование или прямое обращение) ДО организации тегов. На примере Modbus драйвера, когда мы вызываем редактор шаблонов устройств.
Возможно ли из редактора шаблона устройств (аналог, который будет делаться) обратится к линии связи, настроенной в коммуникаторе — Com порт, скорость, четность и так далее для сканирования устройств или обращения к непосредственному устройству для определения его переменных ?
Михаил, то, что вы написали мне не совсем понятно…
Инициализировать теги в драйвере нужно в методе OnAddedToCommLine() то есть до возможности опроса. Поэтому действительно нужно запрашивать структуру тегов заранее. Вы можете из интерфейса драйвера отправить драйверу команду на запрос тегов и получить ответ через свой файл, который запишет драйвер. Записать команду драйверу можно методом CommUtils.SaveCmdпо OnAddedToCommLine() — это действие выполняется уже в драйвере, когда известны переменные или лежит готовый файл xml.
Интересует именно возможность из программы, обрабатывающей свойства, обратится к линии через Коммуникатор. Есть такая возможность или надо лепить отдельную утилиту, которая будет опрашивать прибор и создавать xml для дальнейшего использования в драйвере ?
10.04.2018 в 15:44 #8884
manjey73УчастникОтдельной утилиты делать как раз и не хотелось бы…
11.04.2018 в 14:48 #8887
MikhailМодераторСогласен, что утилиту не нужно делать.
Напрямую обратиться к линиии связи нельзя, потому что оболочка — это другая программа. Я имел ввиду, что Вы можете из виндоуз формы свойств КП отправить команду ТУ на линию связи, чтобы сам драйвер по этой команде опросил регистры и записал результаты в XML. Я делал похожее (там была диагностика) в драйвере системы ИГЛА.11.04.2018 в 15:34 #8888
manjey73УчастникМихаил, можете дать лично мне исходники драйвера ИГЛА (ну вырезав там что-нить сильно нужное) под мою ответственность неразглашения ? потому что без примеров я буду долго ковырять вообще саму идею…
Вообще если идея понравится, то можно занести в туду…
Смысл какой — чтобы «другая программа» могла использовать настроенную в Коммуникаторе линию связи — включать линию, перезапускать, отключать, использовать линию по своему усмотрению. При использовании по своему усмотрению выполнять опрос прибора определенных параметров через драйвер, например настроечных параметров прибора.
И чтобы к функционалу можно было бы обратиться из Web плагина через общий файл настроек. Так же иметь возможность вкл/выкл линию и использовать для конфигурирования приборов.12.04.2018 в 04:53 #8889
MikhailМодераторПо поводу исходников — напомните, пожалуйста, на следующей неделе. Сейчас я в командировке и мне сложно это сделать. Я вырежу нужный кусок кода. Пока можете скачать пакет драйверов и посмотреть в драйвере ИГЛА, что я имел ввиду в описании реализации.
Идея, которую Вы описали, теоретически возможна, но не тривиальна. Т.к. служба Коммуникатора и оболочка являются разными программами, то нужно, чтобы служба держала открытым некий TCP-порт для управления и через этот порт позволяла детально манипулировать линией связи.
12.04.2018 в 09:20 #8890
manjey73УчастникМожно перенеправлять запросы через сервер, ведь там порт всегда открыт. Мы запускаем плагин (один для кучи драйверов) с указанием текстового файла настроек команд прибора. Сервер это видит и дает команду Коммуникатору взаимодействовать с плагином.
Было бы удобно иметь как раз один плагин, а не писать целую кучу плагинов под каждый прибор. Ну и добавить что-то в драйверах. Хотя что там собственно добавлять, номера команд есть, что делать при поступлении данных команд драйвер знает, а вот к чему это прикручивать — к базе или плагину уже другой вопрос.
Например если мы не останавливаем линию связи, то можем только читать/писать в прибор в рамках обычной работы, то есть уже настроенный драйвер.
Если надо выполнить какие-то настройки, требующие перезапуска линии. то останавливаем линию, выполняем манипуляции с прибором и запускаем линию снова.
Тогда как раз такой плагин был бы более предпочтительным, особенно для Linux машин.13.04.2018 в 14:48 #8911
MikhailМодераторДа, для Линукс очень актуальный вопрос.
11.06.2018 в 10:41 #9662
manjey73УчастникУ кого есть приборы с M-Bus протоколом нужны логи запросов и ответов на ваши приборы.
1. Что за прибор
2. Если есть документация производителя по запросам и ответам тоже пригодится
3. ну и сам лог. Можно получить при помощи наблюдателя порта Advansed Serial Data Logger и родной программой прибора, если такая есть.
При помощи PiiGAB M-Bus Wizard
Умеет не все, но может получить лог ответа от прибора в окне Debug
Есть еще программы, которые могут посылать в порт HEX данные любые, но придется ручками посчитать CRC например в online калькуляторе и составить пакет.11.06.2018 в 15:58 #9663
MikhailМодераторДобавлю, что информация указанная выше, будет очень полезна для разработки драйвера M-Bus.
-
Ответ изменён 8 лет, 5 месяцев назад пользователем
-
АвторЗаписи
- Для ответа в этой теме необходимо авторизоваться.