Kirill, может быть тему все таки завести? пускай и мы( пользователи) отписывали бы, что знаем и, что "набило оскомину". А тему сделать жестко модерируемой. Во всяком случие хотя бы попробывать это сделать, делетэ всегда можно успеть сделать.
Доброго времени суток!
Тема та же - изменение параметра C.SP приборов ОВЕН ТРМ138 с помощью ПЛК.
Использую ПЛК-150-I-L с прошивкой 2.06.3 и таргет 2.06 (хотя в InstallTarget он отображается как 2-02-3). Версия прибора ТРМ138 - P037.
Изучение матчасти это конечно хорошо, но:
1. Приведенный пример FB pkp_convert дает на выходе ложный результат (может я чего не понял?).
2. При опросе параметра со значениями 49 и 0.001 (возможны и другие комбинации) в переменную типа unsigned variable (2 байт) прилетает одно и то же значение 49dec или 0011 0001b. В результате не ясно как интерпретировать полученное значение.
3. При записи параметра вроде бы выкрутился, записывая в старшую тетраду 2-го байта знак числа и положение десятичной точки. НО... встает проблема подтверждения установки параметра в приборе, ибо при натравлении переменных типа unsigned variable (Listen) и unsigned variable (Write) на один параметр прибора происходит конфликт и ПЛК останвлливает работу.
Может кто-то решил эту проблему?
Действительно есть некоторые трудности с обменом с ТРМ138.
Сейчас делаем специальную библиотеку для опроса данных приборов. Точнее уже тестируем и доводим до ума.
В мае обязательно появится.
Могу выслать рабочую версию - обращайтесь на plc@owen.ru
И снова здрасьте.
Получил комплект библиотек (в частности из необходимых Owennet.lib, ComService.lib). Попытался разобраться (кое чего даже получилось) и появились следующие вопросы.
1. При использовании ФБ OWEN_GET_REAL с использованием различных значений RealType получаем Error=55.
2. При использовании ФБ TRM138CFG_GET_REAL для параметра прибора C.SP получаем значение уставки (вроде все хорошо), но... Если опрашивать параметр rEAd, то полученное значение не соответствует реальности (для сравнения val - значение считанное ФБ, ValReal - значение полученное при опросе того же параметра штатными методами из ПЛККонфигурации).
3. Ехаем дальше... Запись значений... ФБ TRM138CFG_SET_REAL... Запись значения в rEAd не нужна по определению, потому оставим... Переходим к уставкам C.SP. А вот тут уже что-то интересное. При попытке записи значения, например, 0.001 в результате видим немного меньше, чем ничего. Это не единственное значение, которое не проходит жесткой цензуры протокола(или формата передачи чисел с фиксированной точкой?). Если учитывать, что программист, знаниями не обременный, не имеет понятия, какие же уставки взбредет устанавливать воспаленному мозгу оператора объекта, то неопределенная ограниченность доступных значений вносит элемент случайности в стабильность работы объекта в целом.
4. Прошу подтвердить или опровергнуть слух о том, что в PLCConfiguration не стоит добавлять опрос более, чем 4-х(?) приборов ОВЕН ТРМ138.
Благодарю за внимание.
С Уважением и прочим-прочим.
я написал. пока тишина. напишу здесь - вышлите пожалуйста данную библиотеку. asutmvdk@gmail.com спасибо!Сообщение от Николаев Андрей
Последний раз редактировалось asup_svk; 03.10.2015 в 09:55.
Через ПЛК100 получаем данные с входов ТРМ138 по протоколу Owen (Master). Как можно отследить нештатные ситуации (обрыв, КЗ температурного датчика или то и другое вместе) с указанием канала, где это произошло?
подниму последний вопрос от aleks: столкнулся с такой же проблемой - раньше использовали МВА - там все просто ... а ТРМ при обрыве датчика отдает ПЛК последнее значение входа... как сделать чтобы он отдавал еще какой нибудь параметр для отслеживания авариии?
Особенность ТРМ138.
Можно интеллигентно выйти из ситуации:
Делаете программную заплатку - каждые, скажем 1,5 секунды сравниваете предыдущее полученное значение с новым. Если значение не изменилось - данные не идут.
Значение с прибора обычно хоть в десятых или сотых долях изменяется во времени.