Аккумулятор в ПЛК

[Николаев Андрей]

Добрый день господа.
Сейчас делаем новые контроллеры, и соответственно возникают вопросы к Вам.
Есть следующий вопрос: что делать при пропадании питания с контроллера.
Сейчас, в ПЛК100, 150 при пропадании питания контроллер "помнит" программу до 2-х минут. То есть при появлении питания контроллер не перезагрузится, а будет продолжать с того места, где пропало питание. Естественно, что все параметры в контроллере сохраняются, а физические значения уже могут быть другие. Некоторых клиентов это не устраивало. Да и у конкурентов никто столько времени программу не держит.

Есть следующее предложение:
Ввести в PLC Configuration параметр, который будет отвечать за то, что будет делать контроллер при пропадании питания (время в секундах).

То есть если пропало питание, а потом появилось нужно:
1. Если параметр равен нулю - при подаче питания на контроллер (после пропадания) нужно перезагрузится, и начать программу с начала,
2. Если параметр равен от 1 до 30 секунд - при пропадании помнить программу и передавать данные по всем портам в течении указанного времени.
То есть:
Если время пропадания питания <= времени выставленном в этом значении: сохранять программу и вести обмен по всем интерфейсам.
Если время отсутствия питания превышено - перезагрузится и начать с начала.

Ну и в общем то вопрос к необходимому интервалу времени... предполагается сделать до 15 - 20 секунд.

Просьба высказываться.

[Николаев Андрей]

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

[magirus]

гм...
выходные однако были...
функция мне кажется неплоха,

хотя на сколько будет востребована сказать не могу.
по времени мне кажется ~ 30 секунд достаточно.
тем более народ потихоньку голосует...
я 7-й.

[Serj_N]

То есть если пропало питание, а потом появилось нужно:
1. Если параметр равен нулю - при подаче питания на контроллер (после пропадания) нужно перезагрузится, и начать программу с начала,
2. Если параметр равен от 1 до 30 секунд - при пропадании помнить программу и передавать данные по всем портам в течении указанного времени.

IMHO - нормальное решение. Как нужно в конкретной ситуации, так и можно выбрать.

[Nik]

Когда есть выбор - всегда хорошо. Особено если будут поддержаны ситемные прерывания before restet, after retet,shutdown....

[Филоненко Владислав]

before restet, after retet - это значит резет из среды CoDeSys, а не аппаратный.
А shutdown - таск по фронту бита Power в Statistic поможет.

[Игорь Петров]

На практике, в каком случае эта фишка полезна? Есть ли такой реальный пример?

Представьте себе: свет пропал, все кругом вырубилось и уехало неизвестно куда, а ПЛК продолжает рулить, как будто кризиса нет :) Так? Не логичнее ли держать питание для всего остального, а ПЛК перезапускать при пропадании питания первым? Хотите сохранить работу мозга, когда тело уже остыло и закопано в землю?

[Малышев Олег]

На конкретном примере. В случае сбоя ПЛК 1хх можно отправить сообщение через сокет и уйти на заслуженый отдых. Кроме того это дает "интеллектуальный" retain т.е. записать данные в файлы не автоматом, а в зависмости от алгоритма. Кроме того, лично наблюдал как узо срабатывало порядка 30 сек. Хотя в общем случае надо купить УПС.

[Sniper007]

Мне кажется оптимальный вариант - дать пользователю возможность выбора. Хочет использует функцию аккумулятора, хочет - отключает.
Голосую за 4 вариант. А насчет объектов... Может быть для одного объекта при кратковременном отключении питания нужна одна логика, а на длительном другая. Например для стекловаренных печей.

[Mikhailo]

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

[Филоненко Владислав]

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

[Nik]

before restet, after retet - это значит резет из среды CoDeSys, а не аппаратный.
А shutdown - таск по фронту бита Power в Statistic поможет.

Из helpa: Системные события
Помимо "задач", еще и "системные события" могут приводить к вызову POU в проекте.

Доступные системные события определяются целевой платформой. Список стандартных событий может быть дополнен специфическими событиями пользователя. Возможные события, например: Старт, стоп, Online коррекция.

Если у вас есть список: какие системные события поддерживает целевая платформа OWEN поделитесь. Для меня это загадка.