Вид для печати
Приветствую Вас уважаемые посетители форума!
Хочу обсудить с Вами еще одну тему. Не раз поднимался вопрос о поддержке в ТРМ200-й серии протокола Modbus. Наконец на эту тему можно говорить как о реальном проекте.
Тут есть ряд вопросов мнения по которым расходятся. В первую очередь хочу спросить Вас о списке параметров которые необходимо передавать по этому протоколу.
Как минимум - читать измеряемые параметры и записывать уставки регулирования (в том числе и их дельты). Как maximum, разумеется, читать и записывать всё, что возможно, а протокол Овен можете вообще из ТРМ убрать, хуже не будет. :)
Лучше тоже, ИМХО.Цитата:
Сообщение от SMH
Что Вы так, SMH, не любите протокол ОВЕН? Упрощённый по максимуму аналог CAN. 11 бит. Расширенный список ошибок - ModBus просто нервно курит в сторонке. Достаточно целостная структура и последовательность в стандартизации имён параметров.
Нет проблемы с числами с плавающей точкой, основная бага Modbus-а.
С документацией конечно ужас, тех кто её составляет, к стенке.
Конечно исключить протокол ОВЕН мы не сможем, да и нет в этом необходимости...
На мой взгляд по modbus-у как мин. нужно передавать:
- Измеренное значение
- Уставку(и)
- гистерезис(ы)
- пареметры группы COMM
- входная величина 1-го и 2-го входного устройства.
а вот будет ли удобно пользователю конфигурировать прибор по протоколу ОВЕН, а работать по Modbus...
Это непосредственно код АЦП что ли? Если да, то действительно, может пригодиться.Цитата:
Сообщение от Maximus
Ещё неплохо было бы иметь возможность управлять выходными устройствами через Модбас.
Моё мнение, что ТРМ-ы серии 2хх не настолько сложные приборы, чтоб заморачиваться по поводу конфигуратора - быстрее с клавиатуры параметры забить. Я, во всяком случае, именно так и поступаю.Цитата:
Сообщение от Maximus
Да потому, что он БЕСПЕРСПЕКТИВНЫЙ! Больше ни один производитель в мире не будет никогда поддерживать этот протокол!Цитата:
Сообщение от незарегистрированный
Я так понимаю, что когда-то давно (впрочем, всего лет десять назад) специалисты Овена тешили себя мечтой завоевать рынок автоматизации в России и пошли одной из проторенных западными производителями дорог - изобрели свой протокол, чтобы их приборы работали только с их приборами и с их ПО. Но вместе с этим требовалось и максимально расширить линейку выпускаемых приборов, улучшить их качество, чтобы конкурировать на этом поле с мировыми брендами. Чего сделано не было. В итоге, сегодня, на мой взгляд, протокол Овен - всего лишь анахронизм. Если так нужен для конфигурирования - пусть будет. Только вот действительно ли он для этого нужен?
А какова альтернатива?Цитата:
Сообщение от SMH
Перейти на чистый ModBus? И поиметь огромный геморой с кучей регистров настройки (на разл. приборах разных) ,проблемой с плавающей точкой, нестандартизированным байтовым обменом и пр.
CAN - соблазнительно, но ресурсы процессора на порядок выше должны быть + стандарт не распространённый.
PROFIBUS - ещё более "редкий" стандарт.
Какой протокол используют западные производители для конфигурирования приборов сложнее реле с интерфейсом? - свой собственный, закрытый, и не раскрывают его. Чтобы не нервировать чуткие нервы потребителей :)
Я тоже согласен. Протокол ОВЕН хороший протокол. Работать с ним гораздо удобнее, чем с Modbus. Если у меня будет выбор - использовать Modbus или Овен выберу Овен. А насчет западных производителей. Такой мэтр как Omron (хотя он скорее восточный производитель), такое откаблучивал (особенно поначалу). Их панели оператора работали только с их контроллерами. У меня например есть панель оператора NT11 и CQM1H, там обмен вообще без протокола - в памяти сделаны специальные общие регистры, вот через них и работай. СКАЗКА!!!
Щас правда у них получше дела, можно к ним чужие панели приворачивать.
Протокол Овен удобен при резервировании Рабочих станций Режим "Просушки" реализуется легко
Разъясните, если не трудно, при помощи каких программных средств и какого оборудования Вам удобнее работать с протоколом Овен, чем с Модбасом? Может, и мне понравится? :eek:Цитата:
Сообщение от Sniper007
Я не совсем понимаю, что-за режим "просушки" Вы имеете ввиду... Если это режим "просЛушки", то я не вижу никаких преимуществ протокола Овен по сравнению с тем же модбасом.Цитата:
Сообщение от Урмаков
1. Протокол ModBus не позволяет организовать режим прослушки, т.к. невозможно логически определить является ли "услышанный" пакет запросом к модулю расширения или его ответом.Цитата:
Сообщение от SMH
2. К тому-же в ответе нет и номера регистра, который запрашивали.
3. Логический анализ с подсчетом пачек в обе стороны будет работать до первой битой пачки, после чего см. п.1.
Для протокола ОВЕН же режим "прослушки" является стандартным и многие приборы (МВУ, ТРМ151/251, ТРМ148, СМИ1) и ПЛК его поддерживают в полном объёме.
Уважаемые господа, я очень рад столь оживленной дискуссии на тему «ОВЕН или Modbus», но изначально она звучала как «ТРМ2хх с Modbus». Я не являюсь программистом и не могу судить на каком протоколе лучше работать… Могу только делать выводы, из того что слышал от клиентов по долгу службы. И у того и у другого варианта есть свои положительные и отрицательные стороны, но как было замечено выше, время для продвижения протокола ОВЕН потеряно (да если честно и не было такой цели), а Modbus набирает обороты. Есть желание следовать тем тенденциями которые имеют большие перспективы. Возвращаясь к контексту ТРМ2хх и Modbus хочется увидеть вашу реакцию на один из возможных вариантов реализации такой задачи:
А. В ТРМ2хх и Modbus и ОВЕН в полном объеме, передаются все параметры;
Б. В линейку ТРМ2хх добавили модификацию – Modbus, а ОВЕН в данной модификации не поддерживается;
В. В ТРМ2хх ОВЕН поддерживается в полном объеме, передаются все параметры, а по Modbus-у передается лишь некоторый ограниченный перечень параметров (измеренные величины, уставки…).
Ну, лично я за вариант "Б". Ещё раз хотел бы акцентировать внимание на добавление возможности принудительной записи значения в выходные устройства ТРМ-ов. При этом предусмотреть реакцию на потерю связи с "мастером" в трёх вариантах, выбираемых пользователем при конфигурировании: 1. Не реагировать (ВУ остаётся в текущем состоянии). 2. перевести выходы в указанное при программировании значение (от 0 до 100%) 3. переключить выходы в режим работы от встроенного регулятора.
Думаю, что это очень даже может пригодиться... Мне - точно! :)
Что бы дитё не делало, лишь бы не с ОВЕном :)Цитата:
Сообщение от SMH
Позвольте, но для реализации "резервирования рабочих станций", насколько я понимаю, этого и не требуется! Станция резервируются (начинает слать запросы) по факту отсутствия запросов (и ответов), как таковых ("безмолвие" в сети), мы говорим об одном и том же или я чего-то недогоняю?Цитата:
Сообщение от Филоненко Владислав
Не понял Вашего сарказма...Цитата:
Сообщение от незарегистрированный
Если ресурсы микроконтроллера позволят, то лучше реализовать вариант "А". Прибор усложнится, но зато будет универсальным. Думаю так будут довольны все, может быть даже SMH будет доволен.
Я так понимаю резервирование может быть разным.Цитата:
Сообщение от SMH
1 вариант - резервирование управляющего контроллера, к-й только определяет наличие посылок и если их нет долгое время, то заменяет вышедший из строя - в этом случали либо резервный контроллер работает по жёсткой антиаварийной программе (заглушить реактор и включить большую сирену), либо надо организовывать доп. канал связи между основным и резервным контроллером для синхронизации их состояний, чтобы резервный продолжил управление по программе.
2 вариант - резервирование с лог. контролем - резервный контроллер выполняет ту-же программу что и основной, основываясь на тех-же данных от модулей расширения, но только не выдаёт сигналы управления в сеть. Если обнаружено молчание или неправильная работа основного контроллера - резервный подхватывает управление.
Вариант 1 можно сделать и на ModBus.
Вариант 2, если не прокладывать доп. канал данных между контроллерами - только на ОВЕНе или аналогич. протоколах. При этом пропускная способности шины не теряется на посылки от основного к резервному контроллеру.
Вот и вся разница, на мой вгляд.
P.S. Есть и др. преимущество протокола ОВЕН. Режим прослушки позволяет расширить функционал существующей системы, добавив исполнительных устройств и даже доп. ПЛК НЕ МЕНЯЯ код мастера сети. Это редкое, но иногда необходимое применение, например когда систему нельзя остановить или нет исходных кодов (проекта) мастера сети.