Протокол обмена M-bus

Просмотр 15 сообщений - с 1 по 15 (из 18 всего)
  • Автор
    Записи
  • #8849
    litmi
    Участник

    Здравствуйте! Кто-нибудь пытался подключать к RapidScada счетчики/расходомеры воды? У них встречается протокол обмена M-bus.

    #8852
    manjey73
    Участник

    Я на данный момент разбираюсь с данным протоколом чтобы сделать драйвер. Но это трындец как не просто…
    Написать драйвер под определенный счетчик не проблема, а вот конфигурируемый, со сканированием сети и так далее очень сложно.

    з.ы. еще купил у китайцев электросчетчик с M-Bus 🙂

    Если у вас есть устройство с данным протоколом и вы сможете предоставить к нему удаленный доступ, можно будет сделать драйвер чисто под него.

    Непосредственно к RapidSCada еще не подключал, так как только в процессе, но проблем там нет чтобы драйвер написать. Нужен преобразователь интерфейса и документация на прибор, если попадется такой как у меня теплосчетчик например.

    • Ответ изменён 8 лет, 5 месяцев назад пользователем manjey73.
    • Ответ изменён 8 лет, 5 месяцев назад пользователем manjey73.
    #8855
    Mikhail
    Модератор

    manjey73, на что похож M-Bus? Сложный?

    #8857
    manjey73
    Участник

    Не столько сложный, сколько заковыристый. В приборе могут быть переменные разных типов, int, float, bcd и так далее, так же могут быть фиксированный блок данных и переменный блок данных. Ну и кучка других фокусов.

    В принципе, можно пойти по пути драйвера Modbus и все руками настраивать, но хотелось бы более разумного подхода, но без ручной коррекции не обойтись из-за особенностей некоторых приборов. Например счетчик Weser Heat Meter в упор не имеет адреса счетчика, из-за этого не сканируется. К нему можно только по ID достучаться.
    Не полностью поддерживает стандарт.

    #8858
    Mikhail
    Модератор

    То есть у устройства можно запросить его регистры и таким образом автоматически настроиться?

    #8859
    manjey73
    Участник

    Да, идет запрос по адресу или ID и устройство отвечает пакетом данных, который надо обработать. Есть идентификаторы данных, тип переменной, ну и собственно блок данных.
    Но в протоколе несколько вариантов — блок фиксированных данных, блок переменных данных и многое другое. И что выберет конкретный производитель устройства одному ему ведомо, главное чтобы соответствовало протоколу. А вариаций там мама не горюй. Нужны приборы с разными вариантами, чтобы сделать универсальный драйвер.

    http://www.m-bus.com/mbusdoc/default.php

    собственно описание протокола
    Особенно хотелось бы увидеть какой нибудь прибор, где есть поля DIFE и VIFE и что в них запихнул производитель.

    • Ответ изменён 8 лет, 5 месяцев назад пользователем manjey73.
    #8883
    manjey73
    Участник

    Нужно выполнить опрос приборов (сканирование или прямое обращение) ДО организации тегов. На примере Modbus драйвера, когда мы вызываем редактор шаблонов устройств.

    Возможно ли из редактора шаблона устройств (аналог, который будет делаться) обратится к линии связи, настроенной в коммуникаторе — Com порт, скорость, четность и так далее для сканирования устройств или обращения к непосредственному устройству для определения его переменных ?

    Михаил, то, что вы написали мне не совсем понятно…

    Инициализировать теги в драйвере нужно в методе OnAddedToCommLine() то есть до возможности опроса. Поэтому действительно нужно запрашивать структуру тегов заранее.
     
    Вы можете из интерфейса драйвера отправить драйверу команду на запрос тегов и получить ответ через свой файл, который запишет драйвер.
    Записать команду драйверу можно методом CommUtils.SaveCmd

    по OnAddedToCommLine() — это действие выполняется уже в драйвере, когда известны переменные или лежит готовый файл xml.

    Интересует именно возможность из программы, обрабатывающей свойства, обратится к линии через Коммуникатор. Есть такая возможность или надо лепить отдельную утилиту, которая будет опрашивать прибор и создавать xml для дальнейшего использования в драйвере ?

    #8884
    manjey73
    Участник

    Отдельной утилиты делать как раз и не хотелось бы…

    #8887
    Mikhail
    Модератор

    Согласен, что утилиту не нужно делать.
    Напрямую обратиться к линиии связи нельзя, потому что оболочка — это другая программа. Я имел ввиду, что Вы можете из виндоуз формы свойств КП отправить команду ТУ на линию связи, чтобы сам драйвер по этой команде опросил регистры и записал результаты в XML. Я делал похожее (там была диагностика) в драйвере системы ИГЛА.

    #8888
    manjey73
    Участник

    Михаил, можете дать лично мне исходники драйвера ИГЛА (ну вырезав там что-нить сильно нужное) под мою ответственность неразглашения ? потому что без примеров я буду долго ковырять вообще саму идею…

    Вообще если идея понравится, то можно занести в туду…

    Смысл какой — чтобы «другая программа» могла использовать настроенную в Коммуникаторе линию связи — включать линию, перезапускать, отключать, использовать линию по своему усмотрению. При использовании по своему усмотрению выполнять опрос прибора определенных параметров через драйвер, например настроечных параметров прибора.
    И чтобы к функционалу можно было бы обратиться из Web плагина через общий файл настроек. Так же иметь возможность вкл/выкл линию и использовать для конфигурирования приборов.

    #8889
    Mikhail
    Модератор

    По поводу исходников — напомните, пожалуйста, на следующей неделе. Сейчас я в командировке и мне сложно это сделать. Я вырежу нужный кусок кода. Пока можете скачать пакет драйверов и посмотреть в драйвере ИГЛА, что я имел ввиду в описании реализации.

    Идея, которую Вы описали, теоретически возможна, но не тривиальна. Т.к. служба Коммуникатора и оболочка являются разными программами, то нужно, чтобы служба держала открытым некий TCP-порт для управления и через этот порт позволяла детально манипулировать линией связи.

    #8890
    manjey73
    Участник

    Можно перенеправлять запросы через сервер, ведь там порт всегда открыт. Мы запускаем плагин (один для кучи драйверов) с указанием текстового файла настроек команд прибора. Сервер это видит и дает команду Коммуникатору взаимодействовать с плагином.

    Было бы удобно иметь как раз один плагин, а не писать целую кучу плагинов под каждый прибор. Ну и добавить что-то в драйверах. Хотя что там собственно добавлять, номера команд есть, что делать при поступлении данных команд драйвер знает, а вот к чему это прикручивать — к базе или плагину уже другой вопрос.
    Например если мы не останавливаем линию связи, то можем только читать/писать в прибор в рамках обычной работы, то есть уже настроенный драйвер.
    Если надо выполнить какие-то настройки, требующие перезапуска линии. то останавливаем линию, выполняем манипуляции с прибором и запускаем линию снова.
    Тогда как раз такой плагин был бы более предпочтительным, особенно для Linux машин.

    #8911
    Mikhail
    Модератор

    Да, для Линукс очень актуальный вопрос.

    #9662
    manjey73
    Участник

    У кого есть приборы с M-Bus протоколом нужны логи запросов и ответов на ваши приборы.
    1. Что за прибор
    2. Если есть документация производителя по запросам и ответам тоже пригодится
    3. ну и сам лог. Можно получить при помощи наблюдателя порта Advansed Serial Data Logger и родной программой прибора, если такая есть.
    При помощи PiiGAB M-Bus Wizard
    Умеет не все, но может получить лог ответа от прибора в окне Debug
    Есть еще программы, которые могут посылать в порт HEX данные любые, но придется ручками посчитать CRC например в online калькуляторе и составить пакет.

    #9663
    Mikhail
    Модератор

    Добавлю, что информация указанная выше, будет очень полезна для разработки драйвера M-Bus.

Просмотр 15 сообщений - с 1 по 15 (из 18 всего)
  • Для ответа в этой теме необходимо авторизоваться.