[12818, 14071] Чтение состояний с универсального устройства ModBus

На адрес 95.167.224.34:2079 нет подключений с 11 апреля.

Перезагрузил Ethernet конвертер. Сообщите пожалуйста: подключается ли он к вам?

Ваш коллега просил настроить подключение на порт 2073.

На порт 2079 настроено подключение прибора со старой версией ПО, но он в данный момент к сожалению отключен.

Спасибо, доступ есть, базово чтение проверили. Однако, прибор, похоже, не запущен, поэтому все флаги событий возвращают нулевые значения. Возможно его запустить, чтобы он хотя бы показал аварии по датчикам?

Прибор перевел в режим “Работа”. Должен теперь отображать аварии датчиков.

Подключили Овен МВ110-32ДН. 178.47.37.3:9100. Адрес 16, скорость 9600. Дискретный контакт 1 замкнут.



re_mv110-x.32dn_m01__1-ru-34542-1.15_a4.pdf (1,8 МБ)

Честно говоря, ваш прибор ставит меня в тупик. Дискретные входы по спецификации modbus должны читаться функцией 0x01 (Read Coil Status). А ОВЕН, похоже, чтобы сделать себе жизнь проще, оставили всё в holding registers. Такую функцию мы пока не предусматриваем. Дискретные входы будут считываться командой 0x01

Т.е. Вы сделаете изменение, но оно не будет работать с Овен МВ110-32ДН?

Раз используете слово “похоже”, значит это предположение? Или это ответ от специалистов Овена

Да, пока с таким способом чтения универсальное устройство не заработает. Можно будет сделать чтение в специализированном драйвере, но не в универсальном. Такую привязку сложнее сделать, и пока не особо понятно как именно.

Я просто предположил, что разработчики контроллера решили не делать еще одну функцию, чтобы упростить разработку. Это обычная практика, но мы на такое не рассчитывали при проектировании драйвера. Посмотрите на РЭ ТРМ 1032. Там кроме функции чтения регистров сделана еще и функция чтения вводов-выводов. На такие устройства мы и и ориентировались.

Следовать стандарту - это правильно. Но " универсальный устройство ModBus" в моей вселенной решает 2 задачи:

  • модель, избавляющая от необходимости писать драйвер под каждый незначительный девайс, например, контрольно-измерительное устройство температуры или давления в котельных, ЦТП и т.д. и т.п. - не тратить на них время
  • уменьшить начальное время внедрения проектов при отсутствии готового драйвера; запустить проект сможем с " универсальным устройством ModBus", а драйвер появится в свое время.

При этом практика показывает странную картину. Проект по контролю параметров ИПТ, причина этой темы, содержит 3 устройства с modbus, показывающий измеритель температуры, измеритель давления и МВ 110. Оборудование уже на месте, цель проекта модернизация. Только измеритель давления - полностью соответствует требованиям протокола modbus, на первый взгляд. Про МВ 110 написано выше. Измеритель температуры - китайский Noname и значение температуры отдает в регистрах с номером 1000. Что странно, но так.

Т.е. 2/3 оборудования с modbus в этом проекте не полностью соответствует канону modbus. Китайского становится все больше, да и раньше было не мало.

Это еще не статистика. Но первые данные.

Предлагаю не быть столь строгим к соблюдению стандарта modbus, т.к. этот драйвер должен позволить не задумываться про драйвер работая с “солянкой” показывающего оборудования. Предполагаю, что часть этого оборудования точно не будет полностью соответствовать канону.

Кроме того, на примере МВ 110 потребуется писать отдельный драйвер, не потому что их много и есть большая потребность написании отельного драйвера, а потому что разработчики “оптимизировали” устройство.

Да мы бы с радостью сделали, но пока не понимаем как сделать настройку. Придется собирать заявки, чтобы изучить подходы.

Какая информация нужна от конечных пользователей? Перечень используемого оборудования, их протоколы обмена, или что-то иное?

Техподдержка “Овена” на мой вопрос про “некорректную функцию” ответила кратко - “Чтение дискретных входов на этом модуле только через битовую маску. Функцией 03.” Специально привел скрин с OPC Овен с настройками адресации.

Увидел устройство.

  1. Оно не поддерживает чтение дискретных входов функцией 03, т.е. для МВ110 не подходит. Поэтому видимо нужен драйвер. Если реализуете такое чтение в этом драйвере, значит новый драйвер не потребуется.
  2. В интерфейсе нет возможности наложить маску а в идеале обработать результат булевыми функциями. А я уверен - для дискретных входов это потребуется, это явно не особенность МВ110
  3. дискретные сигналы нельзя поместить на мнемосхему. Я не нашел как это сделать. А это почти основное, зачем они нужны.

Если ли в планах доработка замечений указаных в последнем моем посте?

Думаю, что вам проще оформить заявку на поддержку MB110, тогда все функции будут сделаны в специализированном драйвере. Устройство не поддерживает стандартные функции Modbus для чтения состояний, так что, универсальный драйвер для него не подойдёт.

Я не согласен.
Во первых: это не проще. Добавление поддержки каждого нового устройства это ожидание от 2 до 6 месяцев с обязательным предоставлением удаленного доступа.
Во вторых: чтение дискретных входов/выходов функцией 03 может быть полезно не только для конкретно МВ110, но и для множества других устройств.

Мы это сделали.

МВ110 [13374]](Добавление поддержки модуля дискретного ввода (с интерфейсом RS-485) МВ110 [13374] - #16 от пользователя Kvashnin)

И это и случилось. И история тянется уже год почти.

Именно так. Следующее же устройство с которым мы столкнулись, ПР200 от Овена, тоже выдает данные в нестандартный адресах. Это ПЛК, но как меня убедили, сделать вывод данных стандартным не получается.

Да и мы работаем с готовыми решениями. Переделывать под софт таблицу регистров странно.

Я не искал специально, но измерители температуры с которыми столкнулись также имеют таблицу регистров стандартную, измерители покупали подрядчики, они могут работать со SCADA-системами. Берем РС и начинаем работать.

В результате часть измерителей прятать про МСД-200, чтобы не плодить костыли на верхнем уровне.

Универсальный драйвер предлагали как средство решения для быстрого добавления множества устройств, в том числе noname. Множество производителей этого множества приборов, по своему понимают ModBus, но OPC их понимают и это критерий поддержки Modbus. Откуда у Вас взялось слепое следование канону :rofl:

Вы же его писали, что бы его исполовали, не для витрины и или музея чистоты ModBus? :grinning:

Ведь печально/смешно когда берем ОРС, тот что под рукой, для проверки устройств, проблем не возникает, переходим к ЛЭРСу и универсальный драйвер для него не подходит.

Поставили в план, предварительно на 3.57.

Можно уточнить как именно будет реализовано?
Разбор битовой маски?

1 лайк