Как минимум - читать измеряемые параметры и записывать уставки регулирования (в том числе и их дельты). Как maximum, разумеется, читать и записывать всё, что возможно, а протокол Овен можете вообще из ТРМ убрать, хуже не будет.
Как минимум - читать измеряемые параметры и записывать уставки регулирования (в том числе и их дельты). Как maximum, разумеется, читать и записывать всё, что возможно, а протокол Овен можете вообще из ТРМ убрать, хуже не будет.
Последний раз редактировалось SMH; 22.05.2008 в 19:44.
Лучше тоже, ИМХО.Сообщение от SMH
Как минимум - читать измеряемые параметры и записывать уставки регулирования (в том числе и их дельты). Как maximum, разумеется, читать и записывать всё, что возможно, а протокол Овен можете вообще из ТРМ убрать, хуже не будет.
Что Вы так, SMH, не любите протокол ОВЕН? Упрощённый по максимуму аналог CAN. 11 бит. Расширенный список ошибок - ModBus просто нервно курит в сторонке. Достаточно целостная структура и последовательность в стандартизации имён параметров.
Нет проблемы с числами с плавающей точкой, основная бага Modbus-а.
С документацией конечно ужас, тех кто её составляет, к стенке.
Конечно исключить протокол ОВЕН мы не сможем, да и нет в этом необходимости...
На мой взгляд по modbus-у как мин. нужно передавать:
- Измеренное значение
- Уставку(и)
- гистерезис(ы)
- пареметры группы COMM
- входная величина 1-го и 2-го входного устройства.
Максим Крец
Компания ОВЕН
Руководитель направления “Контрольно-измерительные приборы”
skype: m.krets
e-mail: tech@owen.ru
а вот будет ли удобно пользователю конфигурировать прибор по протоколу ОВЕН, а работать по Modbus...
Максим Крец
Компания ОВЕН
Руководитель направления “Контрольно-измерительные приборы”
skype: m.krets
e-mail: tech@owen.ru
Моё мнение, что ТРМ-ы серии 2хх не настолько сложные приборы, чтоб заморачиваться по поводу конфигуратора - быстрее с клавиатуры параметры забить. Я, во всяком случае, именно так и поступаю.
Это непосредственно код АЦП что ли? Если да, то действительно, может пригодиться.
Ещё неплохо было бы иметь возможность управлять выходными устройствами через Модбас.
Да потому, что он БЕСПЕРСПЕКТИВНЫЙ! Больше ни один производитель в мире не будет никогда поддерживать этот протокол!
Я так понимаю, что когда-то давно (впрочем, всего лет десять назад) специалисты Овена тешили себя мечтой завоевать рынок автоматизации в России и пошли одной из проторенных западными производителями дорог - изобрели свой протокол, чтобы их приборы работали только с их приборами и с их ПО. Но вместе с этим требовалось и максимально расширить линейку выпускаемых приборов, улучшить их качество, чтобы конкурировать на этом поле с мировыми брендами. Чего сделано не было. В итоге, сегодня, на мой взгляд, протокол Овен - всего лишь анахронизм. Если так нужен для конфигурирования - пусть будет. Только вот действительно ли он для этого нужен?
А какова альтернатива?
Перейти на чистый ModBus? И поиметь огромный геморой с кучей регистров настройки (на разл. приборах разных) ,проблемой с плавающей точкой, нестандартизированным байтовым обменом и пр.
CAN - соблазнительно, но ресурсы процессора на порядок выше должны быть + стандарт не распространённый.
PROFIBUS - ещё более "редкий" стандарт.
Какой протокол используют западные производители для конфигурирования приборов сложнее реле с интерфейсом? - свой собственный, закрытый, и не раскрывают его. Чтобы не нервировать чуткие нервы потребителей
Ваши права
Ответить с цитированием