ТРМ2хх с Modbus

[Урмаков]

Протокол Овен удобен при резервировании Рабочих станций Режим "Просушки" реализуется легко

[SMH]

Протокол Овен удобен при резервировании Рабочих станций Режим "Просушки" реализуется легко

Я не совсем понимаю, что-за режим "просушки" Вы имеете ввиду... Если это режим "просЛушки", то я не вижу никаких преимуществ протокола Овен по сравнению с тем же модбасом.

[Филоненко Владислав]

Я не совсем понимаю, что-за режим "просушки" Вы имеете ввиду... Если это режим "просЛушки", то я не вижу никаких преимуществ протокола Овен по сравнению с тем же модбасом.

1. Протокол ModBus не позволяет организовать режим прослушки, т.к. невозможно логически определить является ли "услышанный" пакет запросом к модулю расширения или его ответом.
2. К тому-же в ответе нет и номера регистра, который запрашивали.
3. Логический анализ с подсчетом пачек в обе стороны будет работать до первой битой пачки, после чего см. п.1.

Для протокола ОВЕН же режим "прослушки" является стандартным и многие приборы (МВУ, ТРМ151/251, ТРМ148, СМИ1) и ПЛК его поддерживают в полном объёме.

[Maximus]

Уважаемые господа, я очень рад столь оживленной дискуссии на тему «ОВЕН или Modbus», но изначально она звучала как «ТРМ2хх с Modbus». Я не являюсь программистом и не могу судить на каком протоколе лучше работать… Могу только делать выводы, из того что слышал от клиентов по долгу службы. И у того и у другого варианта есть свои положительные и отрицательные стороны, но как было замечено выше, время для продвижения протокола ОВЕН потеряно (да если честно и не было такой цели), а Modbus набирает обороты. Есть желание следовать тем тенденциями которые имеют большие перспективы. Возвращаясь к контексту ТРМ2хх и Modbus хочется увидеть вашу реакцию на один из возможных вариантов реализации такой задачи:
А. В ТРМ2хх и Modbus и ОВЕН в полном объеме, передаются все параметры;
Б. В линейку ТРМ2хх добавили модификацию – Modbus, а ОВЕН в данной модификации не поддерживается;
В. В ТРМ2хх ОВЕН поддерживается в полном объеме, передаются все параметры, а по Modbus-у передается лишь некоторый ограниченный перечень параметров (измеренные величины, уставки…).

[SMH]

невозможно логически определить является ли "услышанный" пакет запросом к модулю расширения или его ответом.

Позвольте, но для реализации "резервирования рабочих станций", насколько я понимаю, этого и не требуется! Станция резервируются (начинает слать запросы) по факту отсутствия запросов (и ответов), как таковых ("безмолвие" в сети), мы говорим об одном и том же или я чего-то недогоняю?

[Филоненко Владислав]

Позвольте, но для реализации "резервирования рабочих станций", насколько я понимаю, этого и не требуется! Станция резервируются (начинает слать запросы) по факту отсутствия запросов (и ответов), как таковых ("безмолвие" в сети), мы говорим об одном и том же или я чего-то недогоняю?

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

Вариант 1 можно сделать и на ModBus.
Вариант 2, если не прокладывать доп. канал данных между контроллерами - только на ОВЕНе или аналогич. протоколах. При этом пропускная способности шины не теряется на посылки от основного к резервному контроллеру.

Вот и вся разница, на мой вгляд.

P.S. Есть и др. преимущество протокола ОВЕН. Режим прослушки позволяет расширить функционал существующей системы, добавив исполнительных устройств и даже доп. ПЛК НЕ МЕНЯЯ код мастера сети. Это редкое, но иногда необходимое применение, например когда систему нельзя остановить или нет исходных кодов (проекта) мастера сети.