Модуль «Owen (Master)»

Столкнулся со следующей проблемой.
Во вкладке PLC Configuration добавляю модуль «Owen (Master)».
Соединияю PLC с ТРМ101 и получаю измеренное значение с прибора.
Добавляю еще одну переменную (значение уставки регулятора), которую хочу получить с этого же прибора. Модуль «Owen (Master)» на попытку считывания добавленной переменной отвечает ошибкой 81. Причем очень редко связь проходит и модуль считывает эту переменную. На считывание переменной измеренного значения также часто возникают ошибки чтения.
Такая же ситуация, если вместо переменной на считывание заданного значения уставки поставить переменную на запись, только коды ошибок другие и разные.
Что делать? Задача под которую планирую использовать PLC требует работать с двумя переменными с одного прибора.
Использую PLC150 прошивка 1.31.

ТРМ 101 может отвечать на запрос с таймаутом до 160мс. В параметре RS-485 "Framing time ms" следует поставить 160.

Попробовал поставить значение Faming time в 160мс - проблема не ушла. В документации Framing time - Время, на которое необходимо задерживать ответ на запрос в мс. Как я понимаю, этот параметр нужно брать во внимание только при конфигурировании Slave устройств, и причем тут Master. Тем не менее стал подбирать параметр Framang time в настройках RS485 и параметр Max response delay в настройках Owen (Master) и чудо произошло. Добился устойчивого чтения двух параметров из ТРМ101. Параметр Max response delay должен быть выше 100мс, параметр Framing time в диапазоне 20...40мс для скорости связи 9600 бод.
Для скорости 115кбод диапазон рабочих параметров Framing time почему то стал 20...80мс.
Объясните пожалуйста эти вещи. Хотелось бы настраивать связь по руководству, а не методом подбора.

Далее настала очередь записи уставки регулятора в ТРМ101. Значение в прибор записыватся хорошо, но модуль Owen (Master) всегда выдает ошибку 41 не найдена сетевая функция, хотя дескриптор найден.
Пробовал приборы разных годов выпуска 2003,2005.

Господа разработчики, ответьте пожалуйста, на мое предыдущее сообщение. Описанная ситуация - это нормально, ненорамально, или моя ошибка, или с этим можно жить, или что-другое?

Пришлите, пожалуста, ваш проект

Прикрепляю файл проекта. Собственно проект только в PLC Configuration

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

Цитата:

---

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

Прикрепляю файл проекта. Собственно проект только в PLC Configuration

---

Обращаю Ваше внимание на то, что запись SP раз в 2 секунды приведет к истиранию EEPROM (предположим 1 миллион циклов перезаписи) за 23 дня!:eek: :eek: :eek:

1. То что при обращении к оперативной переменной прибора надо использовать индекс, взял из документа "Программируемые параметры TRM101 (08.06.04).doc". Документ во вложении. При отключении индекса значение из прибора не читается, код статуса 0x3157. В новом документе "Пр-мые пар-ры ТРМ101_v.02.0021.doc", скаченном сегодня с сайта, индексация уже не используется. Может изменили прошивку и в новой прошивке индексация уже не поддерживается. Уточните, пожалуйста. Как уже отмечал, пробую работать с приборами 2003 и 2005 годов выпуска.

2. Про EEPROM. Процесс записи новой уставки в EEPROM прибора должен выглядеть следующим образом:
- Вариант 1. Запись новой уставки в EEPROM прибора происходит только по изменению ее значения. Это классика!
- Вариант 2. Запись новой уставки в EEPROM прибора происходит из ОЗУ по выключению прибора, и восстановление из EEPROM в ОЗУ по включению.
Изменять слишком часто уставку регулярования прибора мы не собираемся. Таким образом сколько бы раз за определенный промежуток времени не записывалась уставка в прибор запись в EEPROM будет происходить только по ее изменению - для Варианта 1, а для Варианта 2 частота изменения уставок вообще не критична.
Если написанное не верно прошу уточнить - это важно для реализации проекта.

Цитата:

---

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

2. Про EEPROM. Процесс записи новой уставки в EEPROM прибора должен выглядеть следующим образом:
- Вариант 1. Запись новой уставки в EEPROM прибора происходит только по изменению ее значения. Это классика!
- Вариант 2. Запись новой уставки в EEPROM прибора происходит из ОЗУ по выключению прибора, и восстановление из EEPROM в ОЗУ по включению.
Изменять слишком часто уставку регулярования прибора мы не собираемся. Таким образом сколько бы раз за определенный промежуток времени не записывалась уставка в прибор запись в EEPROM будет происходить только по ее изменению - для Варианта 1, а для Варианта 2 частота изменения уставок вообще не критична.
Если написанное не верно прошу уточнить - это важно для реализации проекта.

---

К сожалению, в ТРМ101 (именно в нем) реализован вариант №3:
Запись значения в еепром при любом обращении.:(

Мы планируем реализовать в мастере ОВЕН функцию записи значений в прибор при изменении значения переменной (как в ModBus и DCON мастерах) в ближайшем будущем. Тогда проблема с протиранием EEPROM исчезнет.

Цитата:

---

К сожалению, в ТРМ101 (именно в нем) реализован вариант №3:
Запись значения в EEPROM при любом обращении.

Мы планируем реализовать в мастере ОВЕН функцию записи значений в прибор при изменении значения переменной (как в ModBus и DCON мастерах) в ближайшем будущем. Тогда проблема с протиранием EEPROM исчезнет.

---

По EEPROM понятно - ждем реализации новой функции записи переменных. Такой вариант записи характерен для всех приборов ОВЕН или только для ТРМ101? Как насчет ТРМ138? Дело в том, что мы уже используем многоканальную систему на ТРМ138, где управляющий PC подкидывает уставки регулирования каждую 1 минуту, и если учесть время с момента запуска , то работать приборам осталось ~1,5 года.:confused:
Проясните про использование индекса при работе с ТРМ101, а также использование параметров Framing time и Max response delay в настройках Owen (Master). В этом направлении пока не получил однозначного ответа.

1. ТРМ101 и ТРМ20х при записи однозначно перетирают значение уставки в EEPROM. ТРМ138,148, 151, 133 при записи сначала сравнивают предыдущее значение параметра с новым и если есть изменения - то производят запись
2. Уточните версию прошивки Вашего ТРМ101. В зависимости от версии прошивки работа с индексами параметров проходит по разному.
По параметрам модулей написано в
http://www.owen.ru/documents/catalog...figuration.pdf

Версия ТРМ101 v01.0016. Надеюсь это не приговор.

Документ OWEN PLC-Configuration.pdf читал и пытался настроить параметры на связь с прибором именно исходя из этого документа.
Владислав посоветовал поставить параметр Framing time = 160мс.
Получилось следующее (писал ранее в теме):

Цитата:

---

Попробовал поставить значение Framing time в 160мс - проблема не ушла. В документации Framing time - Время, на которое необходимо задерживать ответ на запрос в мс. Как я понимаю, этот параметр нужно брать во внимание только при конфигурировании Slave устройств, и причем тут Master. Тем не менее стал подбирать параметр Framang time в настройках RS485 и параметр Max response delay в настройках Owen (Master) и чудо произошло. Добился устойчивого чтения двух параметров из ТРМ101. Параметр Max response delay должен быть выше 100мс, параметр Framing time в диапазоне 20...40мс для скорости связи 9600 бод.
Для скорости 115кбод диапазон рабочих параметров Framing time почему то стал 20...80мс.
Объясните пожалуйста эти вещи. Хотелось бы настраивать связь по руководству, а не методом подбора.

---

Может проблема также в прошивке?

Цитата:

---

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

Версия ТРМ101 v01.0016. Надеюсь это не приговор.

Документ OWEN PLC-Configuration.pdf читал и пытался настроить параметры на связь с прибором именно исходя из этого документа.
Владислав посоветовал поставить параметр Framing time = 160мс.
Получилось следующее (писал ранее в теме):

Может проблема также в прошивке?

---

Значит ситуация выглядит так:

Для ПЛК в роли Slave - Framing time устанавливает задержку между приходом запроса и ответом ПЛК (для нек-х медленных автоматических и полуавтоматических преобразователей)

Для ПЛК в роли мастера - Framing time устанавливает задержку между ответом прибора на предидущий запрос и новым запросом мастера. Это бывает необходимо в 2-х случаях:
а) опрашиваемый прибор не успевает перейти в состояние приема и необходимо сформировать задержку.
б) при работе ПЛК в режиме мультимастера, для формирования промежутков между посылками по различным протоколам (чтобы slave-ы успевали отвечать)

Для мастеров есть еще один параметр (время ожидания ответа), именно с ним и надо играться для обеспечения устойчивой связи с ТРМ101. Установите его в значение 160-200 мс.

Для ТРМ101 v1.0000 - v1.0016 параметры PV,SP,o -индексируемые. Остальные без индекса.

Max raspons delay для ТРМ101 тоже очень важен. Из за низкой скорости процессора прибор иногда не успевает отвечать за стандартные 50ms. При этом если повторный запрос уйдет одновременно с ответом прибора в линии появится мусор. Т.е. оба параметра рекомендуется установить не менее 160ms. Если вы используете только 1 прибор опрашивать чаще чем 1 раз в секунду его нет смысла (данные температуры чаще не обновляются).

А приборы у нас уже есть и все с прошивками до v1.0016.
Получается, чтобы в дальнейшем потребитель системы не знал, что вообще у приборов существует прошивка, сделаем два элемента на опрос одного параметра того же прибора - один с использованием индекса, другой без использования индекса, а результат разрулим программно.:o

Большое спасибо за ответы.

Пытаюсь подключить устройство измерения активной мощности переменного тока ЩВ02 (Электроприбор г.Челябинск). Протокол DCON.
В поле Last error - 0. В поле Status запрашивоемого device - 80 (dec).

1. Что это за ошибка? В документации не нашел.

2. Пытался разобрать ответ прибора, используя в работе библиотеки UNM и SysLIbCom. Работать с UNM просто, но иногда неудобно, т.к. в качестве параметра функции используется только STRING. Переключился на SysLibCom, но не получилось открыть порт функцией SysComOpen. Функция всегда возвращает 16#FFFFFFFF. Опишите, пожалуйста, процедуру открытия порта с помощью этой библиотеки?

1.Ошибки DCON описаны в http://www.owen.ru/documents/catalog...figuration.pdf
на странице 95. Ошибка 80dec=0x50 - "Устройство не отвечает". Только должна быть маска 0x1 - устройство послало запрос (т.е. 0х51). Как Вы сконфигурировали опрос - по команде или периодический?
2. Возможно порты открыть не удается т.к. неправильно устанавливаете номер порта.
0, // COM_0 (RS_485)
1, // COM_1 (RS_232)
2, // COM_2 (not used in PLC_100)
3, // COM_3 (not used in PLC_100)
4, // COM_4 (DBGU or RS_232 if Jumper is settings)
Порт так же не должен быть занят модулем опроса другого устройства. Для модуля UNM вы можете формировать в строке любую информацию для этого объявите ptr_to_str : pointer to array [0..255] ob byte; инициализируйте его ptr_to_str:=ADR(my_str); далее обращение к любому элементу строки ptr_to_str^[2]:=11;

1. Опрос ставил периодический 2 секунды, но не в этом дело.
Написал через UNM опрос прибора и увидел, что прибор отвечает, но первым байтом ответа летит мусор, затем нормальные символы посылки. Так что ответ ststus = 80 dec, мне не понятен, как и какая-то маска. Что за маска, разьясните подробнее? Модуль должен отвечать что-нибудь типа "не верный формат ответа" или подобное.

2. Пробовал и рашьше работать с указанными портами. Проблема осталась таже. Пишу в пустом проекте:

(* Открыть порт*)
IF F_ComOpen=0 THEN
dwHandle := SysComOpen(1); (* RS232 *)
F_ComOpen := 1;
END_IF

Результат dwHandle = 16#FFFFFFFF

1. Если ПЛК шлет запрос и не получает ответа, то в статус должен принимать значение 0x51. Т.е. запрос послан =0x1 + таймаут =0x50. Т.е. 0x51. Т.е. в документации сказано про 0x51 = (dec)81.
Вышлите пожалуйста что послылаете и что получаете от прибора (обмен).


2 Высылаю пример работы с последовательным портом.

1. Посылка в прибор: 23 30 31 38 34 0D
Ответ из прибора: 00 3E 2D 30 30 30 32 32 44 0D

Первый байт ответа почти всегда 00, иногда вместо него FE, 3E, C0 или другой мусор. Но прибор отвечает всегда!

2. Обнаружил следующую вещь:
- Для обмена с прибором набил программку с использованием библиотеки UNM. Программка работает. Собственно с помощью нее получил ответ из прибора см.п.1
- Прошил ПЛК100 до версии 1.31.3. Загружаю программку. Не работает?!
- Перепрошил на версию 1.31.1. Работает?!
- Перепрошивку сделал еще пару раз для подтверждения результата. ФУНКЦИИ UNM ПЕРЕСТАЛИ РАБОТАТЬ НА ПРОШИВКЕ 1.31.3.
Проект по вложении.

Все еще жду комментарии разработчиков на мое предыдущее сообщение :cool:

Посмотрел программу. Не нашел процедуры захвата порта LockDevice. Проверили библиотеку UNM на прошивке 1.31.3. Работает...

Ответ на сообщение 1 ждите в понедельник - по прибытии вед. программиста ПЛК.

Цитата:

---

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

1. Посылка в прибор: 23 30 31 38 34 0D
Ответ из прибора: 00 3E 2D 30 30 30 32 32 44 0D

Первый байт ответа почти всегда 00, иногда вместо него FE, 3E, C0 или другой мусор. Но прибор отвечает всегда!

2. Обнаружил следующую вещь:
- Для обмена с прибором набил программку с использованием библиотеки UNM. Программка работает. Собственно с помощью нее получил ответ из прибора см.п.1
- Прошил ПЛК100 до версии 1.31.3. Загружаю программку. Не работает?!
- Перепрошил на версию 1.31.1. Работает?!
- Перепрошивку сделал еще пару раз для подтверждения результата. ФУНКЦИИ UNM ПЕРЕСТАЛИ РАБОТАТЬ НА ПРОШИВКЕ 1.31.3.
Проект по вложении.

---

Добрый день!
Видно, что 1 символ ответа носит хаотический характер и его надо как-то исключить. Это можно сделать с помощью
команды (*)
* - любой символ (при разборе ответа не проверяется соответствие форматной строке), при запросе заполняется пробелами
Команда может предваряться модификатором длины.
Пример:
[1*]>[7F]

Только контрольная сумма не может использоваться, т.к. она считается по всему сообщению и будет считаться неправильно.

P.S. Странный прибор вы используете. А как решается проблема с первым неправильным символом в др. контроллерах?

Цитата:

---

P.S. Странный прибор вы используете. А как решается проблема с первым неправильным символом в др. контроллерах?

---

Вообще с таким столкнулись впервые, а решили бы так же как и на вашем контроллере - написали бы собственную процедуру опроса.

Спасибо за ответы.