Вывод из состояния зависания ПЛК

Здравствуйте.

На объекте работают два щита управления насосным оборудованием. В каждом щите имеется по одному контроллеру ПЛК160.
Оба ПЛК по Ethernet удаленно подключены к дипетчерскому компьютеру, на котором установлены InsatOPC server и MasterScada.
Все работает, но иногда отваливается от Ethernet или зависает любой один из двух контроллеров. Восстанавливается работа после
передергивания питания "виновного" контроллера.
Вот и пришла мысль - чтобы не бегать в насосную передернуть питание, поручить выполнение этой функции или самим контроллерам ,
или MasterScada совместно с контроллерами.
При отваливании от Ethernet какого-либо контроллера MasterScada выдает сообщение о потере связи.
Вопрос: можно ли этим сообщением создать событие, которое можно было бы использовать для выдачи аварийного сообщения и для формирования
команды (работающему ПЛК) выключить/включить питание зависшего ПЛК?

Спасибо.

Облюбуйте себе входной OPC-тег из контроллера, да и следите за его свойством quality ("Качество") и на основе значения качества этого (а то и ещё нескольких, чтоб наверняка) отправляйте команду в другой контроллер. Можете, кстати, в другой контроллер признаки качества отправлять на обработку с задержкой по таймеру.
В контроллере это сделать проще.
А ещё лучше связать контроллеры watchdog-ами. Это займёт по одному дискретному входу и паре выходов в каждом из контроллеров, но контроль зависания ПЛК и, заодно, исправности питания цепей управления так будет надёжней.

Чтобы избежать пропаданий связи, попробуйте сначала настроить ОРС сервер - в частности включите у устройства "Реинициализация узла при ошибке".
По вопрос сброса ПЛК - вам сказали верно. При помощи модуля "Событие" отслеживайте признак качества, и если он плохой, то посылайте сигнал на сброс.

Спасибо. Не догадался использовать признак качества.
to Ryzhij
А ещё лучше связать контроллеры watchdog-ами. Это займёт по одному дискретному входу и паре выходов в каждом из контроллеров, но контроль зависания ПЛК и, заодно, исправности питания цепей управления так будет надёжней.
По поводу watchdog не понятно.
Во-первых, когда он срабатывает, контроллер перезагружается, аналогично как и при включении питания. Если по признакам качества Скадой будет послана команда выкл./вкл. питание контроллера, последний перезагрузится и работа продолжится.
Во-вторых, как выход watchdog'а связать с цифровым выходом контроллера?
И в-третьих, один выход контроллера для манипуляцией питанием второго контроллера, а второй для чего?

Спасибо.

:) Давайте не путать зелёное с квадратным.
Внутрисистемный watchdog, о котором Вы пишете, это по сути дела сторожевой таймер, контролирующий время исполнения задачи внутри контроллера, Он защищает больше от программных ляпов.
Смысл же и принцип работы классического watchdog-а в том, чтобы аппаратно независимыми внешними средствами контролировать работу системы. ПЛК программно генерирует на одном из своих выходов меандр (это и есть выход "лающей сторожевой собаки" watchdog). Выход этот подключается ко входу внешней цепи независимого сторожевого таймера.
В нашем случае это второй ПЛК, но в природе есть и аппаратные реле типа watchdog.
Если выход "лающей сторожевой собаки" замрёт в 1 или в 0 надолго, то внешняя цепь (у нас это второй ПЛК) генерирует в зависимости от задачи или сигнал сброса, или сигнал аварийного отключения цепей управления.
Вот и получается один DO и один DI для выдачи/приёма постоянно меняющегося сигнала watchdog-а на/с другой(-го) ПЛК, и ещё один DO, как Вы правильно сказали, "для манипуляций с питанием второго контроллера".

А как Вы при отвалившемся изернете пошлете команду в ПЛК?
наверное проще посылать из скады импульсы и считать в ПЛК, если счет не меняется какое-то время, то к примеру вводить в бесконечный цикл(вызвать программу с ним) для перезагрузки.

То что пропадает связь по Ethernet не означает, что ПЛК перестал исполнять свою программу. Т.е. связь по Ethernet может пропасть, а меандр на дискретном выходе ПЛК будет успешно формироваться.

Согласен с IVM и, частично (cтранно, что для восстановления связи нужно перезагружать ПЛК), с lara197a.
Если связь не восстанавливается - это проблема Скады, а не ПЛК.

Цитата:

---

Сообщение от Валенок

Если связь не восстанавливается - это проблема Скады, а не ПЛК.

---

Чаще всего обмен зависает именно на стороне ПЛК. С контроллерами ОВЕН такое случается.

Цитата:

---

Чаще всего обмен зависает именно на стороне ПЛК

---

А в чем это выражается ?

Может не открываться соединение. Или запрос modbus уходит, а ответа нет.

В плане? Не приходит пакет TCP ACK?

Проблема была на ранних прошивках ПЛК110-60 - отваливался Modbus TCP. Точно не помню как именно это проявлялось.

Цитата:

---

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

Не с контроллерами, а у людей использующих плк

---

При организации обмена через конфигуратор проблемы возникают довольно часто и люди, использующие ПЛК, тут не при чем. Тут косяки у фирмы "ОВЕН". Вот у SIEMENS в ПЛК SIMATIC c Profibus таких проблем нет.

нормально все через конфигуратор работает.
Если кончено сеть правильно сделана.
Ни разу таких проблем не испытывал.

Я вот тоже бывает мбTCP-слейв в конфигурации юзаю. (ПЛК 100,30,32,60). Проблем опроса из внешнего приложения - нет. Тестирую связь/восстановление выниманием шнурка и втыканием с различными задержками.