трм -> плк -> Opc-сервер

Из описания конфигуратора ПЛК:

В модуле Owen (Master) имеются несколько переменных, в которые записывается информация о функционировании опрашиваемых приборов и о произошедших ошибках.
Каналы модуля:
− «Последний адрес» (Last address) – последний адрес прибора, по которому обращался Owen (Master).
− «Код последней ошибки» (Last error) – код ошибки, которая произошла при последнем опросе.
− «Последний Hash-код» (Last Hash) – Hash-код параметра, который фигурировал в последнем опросе.

Ситуация:
ТРМ прибор пропал в сети RS-485 (пропало питание, обрыв сети и т.д.).
ПЛК его не видит и соответственно выдает 81-ю ошибку в переменную "Код последней ошибки", и ... в переменную, которая принимает значение из внутреннего регистра ТРМ, записывает 0.
OPC-сервер соответственно видит только этот 0, и ничего не знает о том, что прибор ПРОПАЛ!!! (Ведь проблем при обмене с ПЛК - нет!!!)

Вопрос:
Можно как-то реализовать контроль за актуальностью считанного значения?!
Как в ПЛК можно реализовать контроль за доступностью прибора и сообщить об ошибке OPC-серверу?!

честно говоря я себе это слабо представляю...
если связи с прибором нет - значит её нет...
если надо как то говорить что связь пропала (а какая в прочем разница пропало питание или кабель разрубили) - записывайте в передаваемую переменную заведомо недостижимое значение. а в Scada анализируйте это...

Ой!!! С удовольствием запишу недостижимое значение в переменную!!!
Только как я поймаю Last error <> 0 если он изменяется динамически!!!
Процесс опроса приборов протекает независимо от цикла программы или нет?! Как перехватить это событие ?!

Анализируется пара значений Last error & Last address.
Для каждого прибора можно создать переменную "исправен-неисправен" и передавать её в Scada.

Цитата:

---

Сообщение от Логвиненко Андрей

Анализируется пара значений Last error & Last address.
Для каждого прибора можно создать переменную "исправен-неисправен" и передавать её в Scada.

---

В какой момент эту пару надо анализировать?!
На линии несколько приборов.
Вы хотите сказать, что после опроса очередного параметра, управление сразу передается циклу пользователя. Мне кажется, что цикл опроса приборов протикает параллельно с циклом пользователя и не факт, что обратившись к этим переменным я получу верные значения. Тем более, что не ответивших адресов может быть и больше. Тогда нужен массив Last error & Last address!!!

Принцип работы ПЛК примерно такой:
опрос ОБЛАСТИ ПАМЯТИ ВХОДОВ(не физических входов)
Выполнение ПОЛЬЗОВАТЕЛЬСКОЙ ПРОГРАММЫ
Запись ОБЛАСТИ ПАМЯТИ ВЫХОДОВ (не физические выходы)
Сервисное состояние - опрос себя, запись в драйвера, обмен по интерфейсу и т.д.

Если несколько устройств - значит действительно нужно массив.
Last Error - одна.
Last Address - для всех устройств.
If last_error <>0 and (last address=adres_mva)then;
status_mva:=1;
end_if;

Ну или возьмите библиотеку ModBus и самостоятельно организуйте обмен в цикле ПЛК. Тогда уж Вам все флаги в руки.

Я вставил следующий код в цикл пользователя:

CASE Addr485 OF 'где Addr485 - это Last Address модуля Owen(Master)
0: ErrorTRM0:=Error485; ' где Error485 - это Last Error модуля Owen
1: ErrorTRM1:=Error485;
2: ErrorTRM2:=Error485;
' и т.д.
END_CASE

это работает!!! Я получил список переменных, отображающих текущее состояние приборов.
Но это значит, что после каждого опроса очередного параметра ПЛК передает управление циклу пользователя, чтобы тот как-то разрулил изменившееся состояние самого Owen(Master) модуля!!!
Спасибо! Меня такой ответ устроил!!!

Из опрашиваемых 96-адресов 5 адресов выдают коды ошибок не поддающиеся расшифровке:
49 или 0х31
35584 или 0x8B00
31232 или 0x7A00
61184 или 0xEF00
10327 или 0x2857 - это вероятно "Не найден идентификатор"

Может разработчики ПЛК разъяснят данные коды? :confused:

Спасибо!

Цитата:

---

Сообщение от николаев андрей

принцип работы плк примерно такой:
опрос области памяти входов(не физических входов)
выполнение пользовательской программы
запись области памяти выходов (не физические выходы)
сервисное состояние - опрос себя, запись в драйвера, обмен по интерфейсу и т.д.

---

правильно ли я понимаю, что между программными циклами происходит один опрос входов? тогда, возможно, это при моем количестве внешних переменных (около 140 по протоколу овен) и иногда дает задержки в получении переменных?

это описание в примитивном смысле.
скорее всего 140 переменных не успевает опросить...

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

Цитата:

---

Сообщение от Николаев Андрей

это описание в примитивном смысле.
скорее всего 140 переменных не успевает опросить...

---

Скорее при времени цикла 1мс опрос одной переменной будет происходить в течении нескольких циклов.
У меня сложилось впечатление,что Modbus-master в первую очередь опрашивает устройства, стоящие вверху конфигурации, обращение к последующим идет по остаточному принципу.Поэтому при наличии большого количества переменных на нескольких устройствах лучше самому организовать режим опроса в режиме by command. Перед посылкой очередного байта 0xFF надо проверять, чтобы командный канал обнулился после предыщего запроса.

Опять же про by command. Можно ли опросить 1(2, 3...) переменную? Упустил из виду режим этот. Типа, сколько раз 255 записал, столько и опросов?