Регулярно требуется, в плюс к основной задаче, подключить к ЛЭРСу приборы КИП для отрисовки значений на мнемосхемах и диагностики. Причем:
ассортимент таких приборов большой;
требуется от них в основном текущие измерения;
они в большинстве поддерживают протокол ModBus.
Эти простейшие приборы всегда вызывают неудобство при работе с ЛЭРСом, хотя почти любая SCADA “подключает их влет” используя стандартные решения для ModBus’а.
Стандартный путь: заказ драйвер - удержание прибора на связи с разработчиками - ожидание - тестирование - долго и бесперспективно. В новом проекте ассортимент приборов КИП будет обязательно иным.
для настройки драйвера, на мой взгляд, потребуется:
указать вариант протокола: RTU, ASCII или TCP;
определить параметры из имеющихся в ЛЭРСе: измерение температуры, давления, уровня, расхода;
указать адрес регистра и тип данных.
Если и забыл что то, ты Вы сами без труда добавите необходимое.
Это решение позволит ЛЭРСу быть более гибким.
При этом есть еще дополнительный плюс. Часть приборов, для который еще пишутся драйвера, уже можно подключить с помощью такого драйвера с ограниченным функционалом. И заказчику будет легче ждать написания драйвера под его прибор.
Есть у нас такая идея, но останавливает отсутствие необходимых настроек. В частности, даже в текущих данных некоторые приборы хранят значения с фиксированной точкой, а другие с плавающей в формате IEEE854, или вариациях. Плюс, имеются различные способы “упаковки” 4х-байтных значений в регистры. Это всё нужно указать на этапе настройки, но получается очень сложная система.
Но это всё касается устройств, с которыми нам доводилось работать. Возможно, те приборы, о которых вы говорите, хранят только целочисленные значения и значения с фиксированной точкой? Можете назвать несколько моделей?
Самый последний пример: модуль ввода МВ110 от компании ОВЕН. Приборчик рядом с учетом тепла и газа. Т.к. нет возможности забирать данные в ЛЭРС с МВ110, чтобы в дальнейшем отобразить на мнемосхеме, то пришлось реализовывать обходные решения и техническое решение усложнилось.
Появление обещанной поддержки OPC-серверов конечно упросит, простенький драйвер требует меньше ресурсов и в общем случае более надежен
Присоединяюсь к господину Квашнину
Есть большая нужда в универсальном модбас драйвере.
Совершенно не важно Овен это или что-то иное.
Нужно сделать список регистров уникальным для каждого объекта. В этом списке (фактически тегов) - можно предусмотреть все форматы переменных. Не так уж их и много.
Маркировка типов тегов может быть, например, таким - см. вложение (цитата из протокола Мегаполис ТМ, ВладимирОблГаз)
Предусмотреть дополнительно swapped для вещественного (float и double) и целого (short, int и long)
Поднимука я тему, может есть какие новости?
Клиент ЛЭРС-OPC пока откладывается, может все-таки тогда рассмотреть этот вопрос, так как тема очень нужная и востребованная.
Добрый день!Этот вопрос всё время откладывается из-за архитектуры идентификации моделей в ЛЭРС. Драйверы связываются с конкретной моделью, и чтобы он работал есть три варианта.
Мы вручную добавляем модель и связываем её с универсальным драйвером. Этот вариант в любом случае потребует обновления. Плюс, он не позволит в дальнейшем реализовать полноценный драйвер этой модели из-за того, что придётся соблюдать обратную совместимость. Исходя из этих минусов, вариант довольно плохой.
Добавляем какую-либо универсальную модель устройства, которая уже связана с драйвером Modbus. Минус в том, что серийные номера в пределах модели должны быть уникальными, так что одинаковые СН задать не выйдет. Ну и без дополнительных телодвижений не получиться выяснить какая модель всё-таки стоит на объекте. Модель у всех устройств будет одинаковая.
Позволить привязывать драйвер к пользовательским моделям. Это более разумный подход, но для этого придётся кардинально переделывать архитектуру идентификации моделей. Сейчас внутренние механизмы в ЛЭРС этого просто не позволяют.
Трудоёмкость этой задачи крайне высокая, поэтому, мы её держим в своём поле зрения, но, к сожалению, с низким приоритетом.
Добрый день.Изменения были, но насколько они упростят работы пока неясно. На следующей неделе обсудим возможные варианты с разработчиками и отпишемся по результатам.
Если трудоемкость реализации варианта № 2 не такая высокая - то я не вижу препятствий для “поэтапного” внедрения поддержки произвольных modbus устройств в ЛЭРС.
На первом этапе реализуется вариант № 2, где будет устройство “ModBus прибор”. Какой это конкретно прибор можно указать в комментарии, проблема с дублированием серийных номеров не такая уж и проблема на мой взгляд.
А на втором этапе уже реализовать “правильный” вариант № 3. Перенести уже созданные пользователями на тот момент устройства “ModBus прибор” по пользовательским моделям не составит труда.
Что думаете?
Обсудили, как вариант это предложение рассмотрим. Пока основная проблема всё-таки в том, чтобы указать типы считываемых данных. Этой возможности сейчас в системе нет, и нужно сначала спроектировать её. После того как мы этот этап закончим, выберем уже механизм для окончательной реализации драйвера.
Тут под типами данных понимаются часовые, суточные, месячные?
Если да, то в конкретно нашем случае в них нет необходимости. Нужны только текущие для использования на мнемосхемах, карте и т.д.