ModBus RTU или ОВЕН

В CoDeSys, в конфигурации контроллера, можно выбрать либо ModBusRTU либо ОВЕН
Как я понял, овеновская периферия может работать с обеими
Не подскажете ли, какая прагматическая разница между ними
Я понимаю что это разные протоколы
Я понимаю что первый довольно давно создан а второй специально создан для этой периферии
Но вопрос не вполне об этом
В чем плюсы и минусы одного и другого ( помехоустойчивость, количество доступных адресов, производительность и т.д.)
Они взаимозаменяемы или имеют принципиально разные назначения?

Выскажу тут свое Imho.
Некоторые приборы работают только по протоколу овен, вот там он и нужен. В остальных случаях лучше использовать modbus. А так овен это более медленный протокол чем modbus. Еще протокол овен запомнился мне хитрожопой адресацией при доступе к индексируемым параметрам.
Что касается реализации modbus слейв (это если использовать plc configurator) - то работает вроде стабильно (правда в plc63 для modbus ascii - не корректно считается контрольная сумма для ответа).
Что же касается modbus мастера (это то как он реализован в plc configurator) - то его лучше не использовать. Его может так заклинить что он исказит все данные что там должен читать (похоже кто то не любит чистить буфер). Вместо него лучше использовать библиотеку modbus.lib. Она работает стабильно. Но ее использование будет по сложней чем тупая настройка в plc configurator.

Как работает мастер и слейв для овеновского протокола через plc configurator, а также отдельная библиотека для этого протокола не скажу т.к. не тестировал.

Спасибо
Полезно

Цитата:

---

Сообщение от kfvniiz

Выскажу тут свое Imho.
Некоторые приборы работают только по протоколу овен, вот там он и нужен. В остальных случаях лучше использовать modbus. А так овен это более медленный протокол чем modbus. Еще протокол овен запомнился мне хитрожопой адресацией при доступе к индексируемым параметрам.
Что касается реализации modbus слейв (это если использовать plc configurator) - то работает вроде стабильно (правда в plc63 для modbus ascii - не корректно считается контрольная сумма для ответа).
Что же касается modbus мастера (это то как он реализован в plc configurator) - то его лучше не использовать. Его может так заклинить что он исказит все данные что там должен читать (похоже кто то не любит чистить буфер). Вместо него лучше использовать библиотеку modbus.lib. Она работает стабильно. Но ее использование будет по сложней чем тупая настройка в plc configurator.

Как работает мастер и слейв для овеновского протокола через plc configurator, а также отдельная библиотека для этого протокола не скажу т.к. не тестировал.

---

Не соглашусь с предыдущим оратором: и ModBus master и ModBus slave в plc конфигураторе реализованы отлично, и при наличии определенных знаний все работает отлично и годами.
Для того, чтобы данные не искажались нужно ручками отлавливать ошибку на устройстве и в таком случае считать показания этого устройства недействительными. Вот и всё.

По поводу того, что OWEN протокол нужно использовать только там, где нету альтернативы - полностью соглашусь.

Цитата:

---

Сообщение от XopHeT

Не соглашусь с предыдущим оратором: и ModBus master и ModBus slave в plc конфигураторе реализованы отлично, и при наличии определенных знаний все работает отлично и годами.
Для того, чтобы данные не искажались нужно ручками отлавливать ошибку на устройстве и в таком случае считать показания этого устройства недействительными. Вот и всё.

---

То что modbus slave тот что в Plc configurator работает отлично это факт (ну есть косяки с plc63 для modbus ascii (хотя это мелочь))
А вот то что modbus master в Plc configurator работает отлично - это уж дудки. И при глюках он портит все регистры, что опрашивает и связь там не причем. Это дело я легко воспроизводил. И проблема там была похоже с тем что перед запросом не чистится входной буфер и не очень то жестко проверяется структура пакета.
А воспроизвести это просто берем plc110 и модуль mx110-16д, в plc кофигураторе по протоколу modbus rtu настраиваем опрос дискретных входов этого модуля и некоторых счетчиков импульсов этого модуля.
Соединяем контроллер с этим модулем по rs485 и так же туда же подключаем через преобразователь компьютер (с помощью него будем делать помехи). Наблюдать же за работой будем через codesys. Запускаем, смотрим - все работает.
Теперь на компьютере ставим симулятор modbus (например этот http://www.plcsimulator.org/) и в нем включаем симуляцию устройства с адресом совпадающим с mx110-16д. В общем то надо подсунуть PLC110 один левый modbus пакет. Далее симулятор можно закрыть. Естественно, что при получении левого пакета может быть всякое (получено неверное значение, ошибка связи), но вот после того как симулятор закрыт все должно вернуться в норму, ан нет. Содержимое всех регистров опрашиваемых modbus мастером остается искаженным причем там походу в данных оказываются адреса опрашиваемых modbus переменных и еще всякий мусор, но при этом modbus master говорит, что ошибок нет и все хорошо. Все придет в норму лишь только при перезапуске контроллера или при отключении и включении модуля mx110-16д (в отсутствии модуля видимо контроллер дочитывает буфер который не чистит). Аналогичный эксперимент с Modbus.lib к таким фокусам не приводит там при подсовывании левого пакета получаем ошибку, но как только симулятор закрывается все возвращается в норму.
Конечно кто то может сказать что такое при эксплуатации маловероятно. Может оно и так, но основной вывод - контроллер не чистит буфер и не очень строго следит за содержимым пакета, а это может нехорошо аукнуться и при более простых ситуациях например наводках.

Если работать с дискретными вх/вых по modbas опрос по маске,те опрашивается сразу регистр или двойной регистр ,очень удобно.

На ПЛК-100 бывало на нитке оказывались пара устройств с одинаковым адресом(по ошибке) , был косяк , т.е ошибка (не помню номер , 81 проскакивала) , страшных последствий из поста выше не обнаружено .

Что значит не чистит буфер ? Как он вообще тогда работает ?

Я бы постеснялся такие категоричные вещи озвучивать , 100% адекватно может говорить только Филоненко , ну еще может , кто из разработчиков .
Все остальное - досужие рассуждения , далекие (а может и близкие ,но Х.З) от истины.