Диагностика по ModBUS-TCP

Сообщение **Jackson** » 27 окт 2018, 23:45

Никита писал(а): ↑26 окт 2018, 21:53 Это известная проблема, связана с тем, что конфигурационный софт использует свой протокол, который на 485 с модбасом не дружит. Есть такое.

Так и не понял. зачем ряд производителей делают именно так. Ладно бы отдельный порт под настройку - ещё куда б ни шло. А так - непонятно зачем усложнять жизнь и себе и пользователям.

Сообщение **VADR** » 28 окт 2018, 00:42

Вообще говоря, возможность настраивать Овновские модули ввода/вывода через modbus есть. По крайней мере, в мануале прописано, в какой регистр какую цифирь надо положить и каким битом активировать. И, возможно, при использовании в комплекте к контроллером, а не как у меня (в моём случае - только сбор данных без управления, контроллер по сути ни к чему, OPC-сервер лезет по модбасу прямо в модули ввода-вывода), можно было бы заставить контроллер этим заниматься. А вот сделать это средствами OPC-сервера - слегка проблематично: десяток дополнительных регистров на каждый прибор сожрёт любую лицензию. Впрочем, вполне возможно, что через некоторое время схему с контроллером я реализую...

TEB писал(а): ↑27 окт 2018, 23:45 Так и не понял. зачем ряд производителей делают именно так. Ладно бы отдельный порт под настройку - ещё куда б ни шло. А так - непонятно зачем усложнять жизнь и себе и пользователям.

Скорее всего, в данном случае исторически сложилось. Их протокол появился раньше, чем их же ПЛК, еще на приборах типа ТРМ. А потом уже добавили в модули DCON и Modbus.

VADR писал(а): ↑28 окт 2018, 00:42 А вот сделать это средствами OPC-сервера - слегка проблематично: десяток дополнительных регистров на каждый прибор сожрёт любую лицензию

А никто не заставляет на каждый прибор. Достаточно просто диапазона, перекрывающего все приборы и айпишника моксы. А обращение (и маршрутизация в моксе по портам) в вашем конкретном случае все равно делается через RTU-шный ModbusID. Отдельный "сервисный" OPC-сервер (можно опробовать и бесплатные, на 32 канала или на пару часов работы) на отдельной машине. Причем, в отличие от OPC, ModbusTCP должен поддаваться маршрутизации. Параметры можно прямо в OPC-сервере менять или Exel'евскую морду приделать.
Я, кстати, может и наврал насчет того, что ОВЕН и Modbus на одной шине не дружат. По крайней мере, Овен автоматически распознает протокол. И если все остальные будут молчать, то фокус может получиться. Но овеновский протокол через моксу не пролезет.

Сообщение **Jackson** » 29 окт 2018, 15:09

Никита писал(а): ↑29 окт 2018, 14:25 Скорее всего, в данном случае исторически сложилось. Их протокол появился раньше, чем их же ПЛК, еще на приборах типа ТРМ. А потом уже добавили в модули DCON и Modbus.

Исторически-то понятно. Но добавляя ModBUS ведь можно было в нём предусмотреть адресное пространство для конфигурации. Хотя, с другой стороны, это защита от диверсий (пром.безопасность наша любимая) - удалённо программу в контроллер будет не залить и не прочесть. Есть свои плюсы.

TEB писал(а): ↑29 окт 2018, 15:09 Исторически-то понятно. Но добавляя ModBUS ведь можно было в нём предусмотреть адресное пространство для конфигурации.

Как раз это мы с Саней обсуждаем. Там есть регистры и для конфигурации и для диагностики. Но держать их отдельными тегами для каждого прибора экономически невыгодно (на лицензии разоришься), а родная утилита работает с родным же Овеновским протоколом. Проблема как раз в софте, который будет уметь их конфигурить по модбасу.
Да и контроллера там как такового нет, просто модули ввода и преобразователь RTU в TCP. Ну и верхушка.
P.S. Предлагаю этот оффтоп убрать в отдельную тему.

Сообщение **Jackson** » 30 окт 2018, 09:49

Никита писал(а): ↑29 окт 2018, 18:00 Как раз это мы с Саней обсуждаем.

Так и я ж о том же ж.

Никита писал(а): ↑29 окт 2018, 18:00 Там есть регистры и для конфигурации и для диагностики. Но держать их отдельными тегами для каждого прибора экономически невыгодно (на лицензии разоришься)

А зачем их держать постоянно? Диагностика - процедура, которую делают далеко не все и далеко не всегда. Если я правильно понимаю, то можно ведь с отдельного АРМа это делать, мы ж по TCP подключены. Главное чтобы возможность была. Фактически придется сервисный софт самому создать (самое простое - на базе ModBUS Pool, но это ненаглядно), но зато не прерывая основного опроса.
Я как раз с того и начал: если б родной софт тоже работал по модбасу то и создавать бы ничего не пришлось.

Сообщение **petr2off** » 30 окт 2018, 12:24

Как вариант подключится OpenScada. Я недавно такой трюк провернул, но мне надо было с ОВЕНовского проекта пару десятков регистров посмотреть, по Modbus.

Если б родной софт работал по модбасу, то овеновский протокол можно было б нести на кладбище.
Кстати, модбас изначально - тоже фирменный протокол от Modicon.
По большому счету, проблем в создании интерфейса для работы по модбасу с конкретными регистрами нет. и OPC тут скорее вреден. Но этим кто-то должен заняться.

Форум АСУТП