- В этой теме 52 ответа, 4 участника, последнее обновление 2 года, 7 месяцев назад сделано
.
-
Сообщения
-
Собственно бета версия драйвера здесь https://github.com/Manjey73/OpnenKPs/releases/tag/KpMbus
Обновлённая ссылкаДрайвер платный. На данный момент настроить драйвер можно только вручную.
Так как у меня в наличии только два прибора (и как назло оба передают одинаковый тип Телеграммы) драйвер поддерживает только Переменный блок данных без текстовых и иных переменных произвольной длины.
В архиве есть описание настройки конфигурационного файла и два рабочих примера для теплосчетчика Weser HeatMeter и электросчетчиков Eastron SDM220 и SDM230.У кого есть приборы с M-Bus протоколом нужны логи запросов и ответов на ваши приборы.
1. Что за прибор
2. Если есть документация производителя по запросам и ответам тоже пригодится
3. ну и сам лог. Можно получить при помощи наблюдателя порта Advansed Serial Data Logger и родной программой прибора, если такая есть.
При помощи PiiGAB M-Bus Wizard
Умеет не все, но может получить лог ответа от прибора в окне Debug
Есть еще программы, которые могут посылать в порт HEX данные любые, но придется ручками посчитать CRC например в online калькуляторе и составить пакет.(перенес из другой темы. Все еще требуется для продолжения работы над драйвером)
Производители должны сопровождать свое оборудование (счетчики) драйверами, за рубежом часто можно увидеть с помощью wi-fi или по сотовой связи все измерения и на маршрутизатор. Этот драйвер для Украинских или Российских счетчиков что ли?
Это драйвер протокола M-Bus для RapidScada., страна происхождения счетчика не важна.
У меня на столе Weser (теплосчетчик)- Германия или Россия (на морде есть надписи по русски) и Eastron (электрический) — Китай.
По данному протоколу есть и Российский ГОСТ но он полностью повторяет иностранный документ только на русском языке. (есть в архиве родной документ по протоколу)Производитель должен сопровождать свое изделие документацией. В архиве примеры для Weser и Eastron. Там примеры запросов и ответов. Зная документацию можно написать драйвер для отдельно взятого прибора с M-Bus протоколом, который не будет никак работать с другим прибором с таким же протоколом.
Это зависит от страны производителя и фирмы (Производитель должен сопровождать свое изделие документацией). Этот протокол продвигался когда-то в Европе. Единственное не понятно, почему для передачи дискретных данных (значение расхода за определенный период) нужен отдельный протокол. Ведь это можно сделать любым другим протоколом.
Если конечно эти счетчики способны отключать неплательщиков или расходующих сверх нормы.Это просто протокол передачи данных, как Modbus. Ничего более.
Поддержка команд тоже есть, но пока я это не реализовывал.
Если производитель захочет, то может реализовать все что угодно, но для этого необходимо заинтересовать производителя.Есть BacNet, Modbus, Lon, и куча куча других, в том числе и M-Bus.
У нас на рынке с данных протоколом больше всего представлены Теплосчетчики.
Так уж повелось, что первые теплосчетчики были импортными из Европы.Можно, только цена конвертеров протокола из одного в другой как правило выше, чем просто преобразователя Ethernet — «Протокол». Часто так на несколько тысяч дороже.
Например есть фирма ADFWEB, которая выпускает много конвертеров, сейчас использую на проекте Modbus RTU master — SNMP. ценник выше 20 тысяч рублей. Вот только цена/качество хромает. Просто как-то использовал другой фирмы и подороже и есть с чем сравнить.
но он полностью повторяет иностранный документ только на русском языке
Это гораздо лучше, чем если бы добавили своих велосипедов в гост ))
Расскажите про ценовую политику. Думаю, что желательна бесплатная версия с какими-либо ограничениями. Тем более, что пока бета-версия.
Цена 2000р или скидка 50% при предоставлении логов в HEX формате с любых M-Bus приборов.
Бесплатными будут только драйвера отдельно взятых устройств с фиксированным списком переменных. Чуть позже буду делать, сейчас не до этого.
Данный драйвер автоматически разбирает телеграмму, согласно протокола, тут главное правильно составить запрос, например воспользовавшись документацией на протокол от производителя прибора. Примеры на два прибора есть в архиве.Ссылка на google disk
Driver_MBusЕсли конвертеры такие дорогие, не лучше ли использовать миникомпьютер (или микросхему) на стороне клиента, который получает данные по какому то протоколу и далее на центр передает только по одному (двум) наиболее продвинутому протоколу (ТСP например). Или миникомпьютер поставить на стороне сервера (это вообще универсально) который будет работать по аналогии. Чтобы центральный сервер где стоит СКАДА работал по нескольким обычным протоколам. И автоматизировать работу оператора по минимуму настроек канала. А все нагрузить на этот миникомпьютер. Разве нельзя такую коробочку изготовить с встроенным набором протоколов?
И тут примерно тоже самое. Давайте определимся с понятиями.
Есть конвертеры интерфейса и есть шлюзы между протоколами.
Конвертер это простое сквозное устройство, через которое производит опрос непосредственно Scada (для этого и предназначен драйвер)
Есть конвертер Пульсар Ethernet — M-bus — 17450 рублей
http://krasnodar.teplovodokhran.ru/products/interface-transformers/preobrazovatel-m-bus250-rs232-ethernet-pulsar.html
Есть китайские на разное количество приборов, ссылка на вариант 150 приборов учета:
https://ru.aliexpress.com/item/MBUS-M-BUS-Ethernet/32941579815.html?spm=a2g0s.13010208.99999999.263.63cd3c00NuRcOFЕсть в том числе и фирменные подороже. Но вот шлюз будет стоить еще дороже, так как это свободно программируемое устройство со своей программой.
Ну и так, для понимания, не дай бог прибор чуть-чуть некорректно работает по протоколу, шлюз вам тогда ничем не поможет. Или прибор не увидится, или данные будут идти через одно место и в Scada придется приводить их в порядок.
- Вы должны авторизироваться для ответа в этой теме.