Lora2ModBus и методы борьбы с ним
Lora2ModBus и методы борьбы с ним
Уважаемые коллеги!
Я начинаю эту ветку с целью поделиться своим опытом и услышать ваш в области работы с шлюзом Lora2ModBus. На мой взгляд это нужная вещь - сейчас она является основной связью между серверами LoRa и системами RAPID SCADA и PI. К сожалению, как я понимаю, ВЕГА почти перестала поддерживать это направление...а зря.
Большим недостатком этого шлюза является работа только в одну сторону - от сервера, т.е. управление через ModBus с ним не получится. Ну на это у меня есть свои мысли с названием MQTT
Возможно эту тему надо было разместить в разделе "Обмен опытом", тут как раз все про LoRa так что здесь все это уместнее.
К делу.
Сегодня под воздействием поста про невключение выходов у M-Bus1 собрал стенд, проверил ну и заодно решил поработать с СИ-12 - давно уже собираюсь. Пост про это описан в ветке про M-Bus1.
Поскольку в результате я планирую заведение сигналов с датчика на SCADA и управление выходами оттуда же, то завел устройство в шлюз...и увидел что есть простор для доработок (слава разработчикам ВЕГА, что они все делают через json, который легко правится ). Что сделал в результате:
1. В пакетах 0х04 (сигнал о включении/отключении внешнего питания) я решил вынести время включения/выключения внешнего питания в отдельный регистр, чтобы он не перетирался другими пакетами - зато всегда знаем, когда питание выключилось. В оригинале время получения данных в любом пакете писались в один регистр;
2. Добавил обработку пакета 0х05 - состояние выходов, взял три значения - номер выхода, состояние и время изменения. Дальнейшая обработка будет вестись уже SCADA, в том числе и сохранение истории.
Файл с корректировкой во вложении.
Я начинаю эту ветку с целью поделиться своим опытом и услышать ваш в области работы с шлюзом Lora2ModBus. На мой взгляд это нужная вещь - сейчас она является основной связью между серверами LoRa и системами RAPID SCADA и PI. К сожалению, как я понимаю, ВЕГА почти перестала поддерживать это направление...а зря.
Большим недостатком этого шлюза является работа только в одну сторону - от сервера, т.е. управление через ModBus с ним не получится. Ну на это у меня есть свои мысли с названием MQTT
Возможно эту тему надо было разместить в разделе "Обмен опытом", тут как раз все про LoRa так что здесь все это уместнее.
К делу.
Сегодня под воздействием поста про невключение выходов у M-Bus1 собрал стенд, проверил ну и заодно решил поработать с СИ-12 - давно уже собираюсь. Пост про это описан в ветке про M-Bus1.
Поскольку в результате я планирую заведение сигналов с датчика на SCADA и управление выходами оттуда же, то завел устройство в шлюз...и увидел что есть простор для доработок (слава разработчикам ВЕГА, что они все делают через json, который легко правится ). Что сделал в результате:
1. В пакетах 0х04 (сигнал о включении/отключении внешнего питания) я решил вынести время включения/выключения внешнего питания в отдельный регистр, чтобы он не перетирался другими пакетами - зато всегда знаем, когда питание выключилось. В оригинале время получения данных в любом пакете писались в один регистр;
2. Добавил обработку пакета 0х05 - состояние выходов, взял три значения - номер выхода, состояние и время изменения. Дальнейшая обработка будет вестись уже SCADA, в том числе и сохранение истории.
Файл с корректировкой во вложении.
Re: Lora2ModBus и методы борьбы с ним
Спрашивал сотрудников Веги про доработку Lora2ModBus и пришёл к выводу что надо писать своё...
Пишу в свободное время, конвертер в Lora в Модбас TCP/RTU написал с возможностью передачи данных на устройства,
дописываю конвертер Lora в EXOline для работы Lora и EXO scada
В такой связке нет необходимости в покупке лицензии для скады для одного пользователя
и нет необходимости в добавлении каких то контроллеров.
Пишу в свободное время, конвертер в Lora в Модбас TCP/RTU написал с возможностью передачи данных на устройства,
дописываю конвертер Lora в EXOline для работы Lora и EXO scada
В такой связке нет необходимости в покупке лицензии для скады для одного пользователя
и нет необходимости в добавлении каких то контроллеров.
Re: Lora2ModBus и методы борьбы с ним
Меня так же опечалило отсутствие возможности управления выходными сигналами с программы Lora2ModBus, что сильно ограничивает применение в SCADA. Я пытаюсь подключить Вегу к моей СКАДА-системе. Первоначально, данные о состоянии охранных входов СИ-12 передавались через Lora2ModBus только при передаче данных со счётных входов. При замене файла "SI-12.json" с предыдущего поста, данные стали прилетать сразу при срабатывании охраны, за что большое спасибо petrov_ab.
Уважаемый Boris.M, прошу Вас поделиться вашей разработкой конвертера Lora в ModBus TCP/RTU.
Уважаемый Boris.M, прошу Вас поделиться вашей разработкой конвертера Lora в ModBus TCP/RTU.
Вячеслав Михайлов
Re: Lora2ModBus и методы борьбы с ним
Если не секрет - что за SCADA? Я пользую RAPID, бесплатную (относительно ). До этого немного пообщался с TraceMode - хорошая система, но уж очень дорогая...
Проводил эксперименты с СИ-12 (управлением), стенд и сейчас еще не разобран. В общем было так:
RAPID Scada -> кнопка в интерфейсе -> канал управления -> MQTT драйвер
|
V
MQTT Broker Mosquitto (на локальной системе)
| ^
V |
Самописанная прога на Python 3.7, которая читает и анализирует топик на брокере от SCADA| =====> WebSock ==> VEGA Server - СИ-12
Состояние входов СИ-12 -> VEGA Server --> SCADA -->отображение
Коряво и не полно, но логика примерно такая, и, что интересно, работает
Там много игр получается с задержками и вследствие MQTT повтор команды не проходит - такова уж логика драйвера MQTT в SCADA - читает или по изменению топика или с частотой цикла SCADA (!) - поэтому сделана "обратная связь"
Состояние выхода СИ-12 --> Vega Server --> MQTT драйвер (его еще вроде бы как нет ) --> прога на Python (зануляет топик) --> SCADA
В общем с задержками получается, что через 1 - 2 секунды команду можно повторять.
Понятно, что это игрушки, если есть рабочий шлюз "двухстороннего" Modbus к серверу VEGA - было бы прекрасно!
Проводил эксперименты с СИ-12 (управлением), стенд и сейчас еще не разобран. В общем было так:
RAPID Scada -> кнопка в интерфейсе -> канал управления -> MQTT драйвер
|
V
MQTT Broker Mosquitto (на локальной системе)
| ^
V |
Самописанная прога на Python 3.7, которая читает и анализирует топик на брокере от SCADA| =====> WebSock ==> VEGA Server - СИ-12
Состояние входов СИ-12 -> VEGA Server --> SCADA -->отображение
Коряво и не полно, но логика примерно такая, и, что интересно, работает
Там много игр получается с задержками и вследствие MQTT повтор команды не проходит - такова уж логика драйвера MQTT в SCADA - читает или по изменению топика или с частотой цикла SCADA (!) - поэтому сделана "обратная связь"
Состояние выхода СИ-12 --> Vega Server --> MQTT драйвер (его еще вроде бы как нет ) --> прога на Python (зануляет топик) --> SCADA
В общем с задержками получается, что через 1 - 2 секунды команду можно повторять.
Понятно, что это игрушки, если есть рабочий шлюз "двухстороннего" Modbus к серверу VEGA - было бы прекрасно!
Re: Lora2ModBus и методы борьбы с ним
SCADA InTouch на базе Wonderware System Platform. Двухсторонний обмен данными с нескольких контроллеров DirectLOGIC по Ethernet и RS-232/485 и по прозрачному радиоканалу через OPC сервер Kepware AutomationDirect. Так же опрашиваем тепловычислители ВКТ-7 коммерческого учёта через их OPC-сервер. Больше тысячи тегов управления, сигнализации и измерений. Совмещает систему диспетчерского управления энергетическим хозяйством завода и систему технического учёта всех видов энергоресурсов (электроэнергия, сжатый воздух, промышленно-бытовые стоки, отопление, горячая и холодная вода). Автоматическое поддержание температуры воздуха в цехах за счёт управления приточной вентиляцией с калориферами и многое другое. Систему поэтапно внедряем с 2002 года, расширяя обхват и функционал. На данный момент остаётся много мелких объектов, к которым сложно или невозможно подключение проводных каналов связи. По этому мой выбор пал на оборудование Вега. Необходимый радиус обхвата до километра от базовой станции. Счётчики и расходомеры удалённые читать то без проблем по импульсному выходу, а вот управлять простым удалённым объектом через СИ-12 не получается.
Данные с Веги читаю от LoRa2ModBus по протоколу ModBusTCP OPC-сервером Wonderware DASMBTCP DAServer и далее в Wonderware System Platform и визуализацию InTouch.
Данные с Веги читаю от LoRa2ModBus по протоколу ModBusTCP OPC-сервером Wonderware DASMBTCP DAServer и далее в Wonderware System Platform и визуализацию InTouch.
Вячеслав Михайлов
Re: Lora2ModBus и методы борьбы с ним
InTouch - красота...завидую белой завистью..
В свое время на филиале делали телемеханику (отображение и управление) на ней (девятка) с РТ-Софт.
Сейчас никого не осталось кто бы мог с ней работать. И отобрать никак
Я в свое время тоже оценивал разных производителей, у ВЕГА лучше на порядок и номенклатура и цена...да и все разумно и понятно.
Хорошо что кто то есть с промавтоматизацией, не ЖКХ...
В свое время на филиале делали телемеханику (отображение и управление) на ней (девятка) с РТ-Софт.
Сейчас никого не осталось кто бы мог с ней работать. И отобрать никак
Я в свое время тоже оценивал разных производителей, у ВЕГА лучше на порядок и номенклатура и цена...да и все разумно и понятно.
Хорошо что кто то есть с промавтоматизацией, не ЖКХ...