Время цикла ПЛК больше 100мс

Вид для печати

28.06.2011, 17:51
Aplle

Время цикла ПЛК больше 100мс

Доброе время суток!

Использую ПЛК110-60М + СП270(RS-485-I) + МВ110-8АС(RS-485-II) +
МВ110(RS-485-II) для автоматизации котла ДКВР. Прошивка 2.12.7 Таргет 2.10.

Во время выполнения программы в ПЛК, время цикла составляет чуть более 100 мс. В модуле STATISTIC горит CPU Overloaded. Котел проработал примерно сутки, после чего ПЛК завис. Проявилось это в том, что на панели СП270 значение времени цикла ПЛК из модуля STATISTIC замерло на величине 110, не производилось регулирование ПИД регуляторов (по газу открылась заслонка на максимум и по воздуху закрылась на минимум), ПЛК не отлавливал нажатие кнопки СТОП (прописано в основной программе PLC_PRG). Min cycle length - 50 мс, Max cycle length 1000 мс.

Может ли CPU Overloaded каким нибудь образом способствовать зависанию ПЛК? Какие методы оптимизации рабочей программы можно использовать для предотвращения зависания ПЛК? Какие механизмы имеются в ПЛК, которые выведут его из зависшего состояния? Весь проект написан на ST.
28.06.2011, 21:27
lara197a

Ну, скорее всего нужно смотреть программу.
Где-то зацикливание.
Выкладывайте.
28.06.2011, 22:08
Александр Приходько

Не использовать While, переход на метку и тому подобное. Очень аккуратно обращаться с указателями и все в таком духе.
28.06.2011, 22:41
Aplle

Использую циклы for и крайне редко, указатели не использую вообще. Переходы на метку тоже не использую.
28.06.2011, 22:52
lara197a

Тогда удачи........
29.06.2011, 12:26
Serge_UA

Цитата:

Сообщение от Александр Приходько

Не использовать While, переход на метку и тому подобное. Очень аккуратно обращаться с указателями и все в таком духе.

Я бы уточнил:
не использовать циклы с неизвестным заведомо количеством итераций;
не использовать переходы на метку назад по коду.

По поводу оптимизации:
Не выполняйте весь код каждый цикл ПЛК. Каждый, логически отдельный, кусок кода выполняйте только тогда, когда есть потребность данных, получаемых в результате выполнения этого куска.
Например:
1. У вас в программе два (или больше) ПИД регулятора. Выполняйте их в периодической задаче каждые Х мс. Думаю для вашего случая Х = 100-200 мс. При этом, каждый ПИД выполняйте в отдельном цикле контроллера (отдельном от других ПИД).
2. Вы рассчитываете технологические параметры по каким-нибудь формулам. Посмотрите кто потребляет эти параметры. Если ПИД, то тех. параметры ему нужны только каждые Х мс, если панель оператора, то ей параметры не нужны чаще, чем раз в 500 мс.
3. Как часто обновляются измеренные аналоговые величины? Рассчитывать тех. параметры чаще, чем обновляются их аналоговые сигналы, не имеет смысла.
4. И т.д. в таком же духе.
29.06.2011, 22:36
Aplle

Очень интересен первый пункт, можно подробнее. Если не затруднит с примером реализации. У меня особенность: пид регуляторы включаются на разных этапах розжига котла. Что такое периодические задачи? Каким образом их применить в моем случае? У меня в проекте текущий этап обозначен через глобальную переменную. Каждый этап описан в своей программе. В PLC_PRG в зависимости от значения этой переменной вызывается программа отвечающая за выполнение текущего этапа.
30.06.2011, 08:20
Адрей

На мой взгляд, лучше для ST писать все в одной программе PLC_PRG без лишних переходов к POU. Делать всё по шагам с привязкой по таймеру.
30.06.2011, 08:43
Малышев Олег

отладка

Цитата:

Сообщение от Адрей

На мой взгляд, лучше для ST писать все в одной программе PLC_PRG без лишних переходов к POU. Делать всё по шагам с привязкой по таймеру.

Это ошибка - при проектах средней сложности время на отладку возрастает на порядок.

Мои рекомендации. Основная программа на ST. Внутри нее небольшая логика по перезапуску машины состояний. Основная машина состояний на SFC. Внутри SFC - на каждое состояние действие которое умещается на один экран. Если больше - лучше вынести в отдельный POU.

"Любимые" блоки - насосы, графики, защиты, регуляторы ... лучше вынести в отдельную библиотеку.
30.06.2011, 11:56
Адрей

Цитата:

Сообщение от Малышев Олег

Это ошибка - при проектах средней сложности время на отладку возрастает на порядок.

Я с вами согласен про машину состояний (движок программы) применимо для сложных задач вы ответили как штатный программист.... Но для алгоритма автоматики котла нужна высокая оперативность и минимальная загрузка ПЛК. Применять движок, смысла нет. Процесс работы котла ступенчатый значит и алгоритм должен быть таков. А для написания хорошего алгоритма время не должно быть критично. Котел все таки.
30.06.2011, 13:31
Александр Приходько

Цитата:

Сообщение от Адрей

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

Для разных задач по разному. Иногда смысла лепить ФБ нет. Что касается котла с вами согласен. Делал все на CASE с предварительным анализом аварий. По сути два Case было.

Но во могих задачах ФБ сильно проще.

Что касается разнесения алгоритма по циклам - Case это очень удобная вещь. Наверно почти в каждом из примеров или программ, написанных мной за последние полтора года они присутствуют. И очень отладку упрощают, сразу видно "где встало "
).

и еще примечание! использование ФБ не так сильно сократит время цикла, сколько уменьшит объемы кода и время отладки!
01.07.2011, 06:35
Aplle

Цитата:

Сообщение от Малышев Олег

Мои рекомендации. Основная программа на ST. Внутри нее небольшая логика по перезапуску машины состояний. Основная машина состояний на SFC. Внутри SFC - на каждое состояние действие которое умещается на один экран.

Почему именно SFC?
01.07.2011, 06:41
Aplle

Вопрос:совместное использование таймеров TP и TON сильно повлияют на время цикла?
Влияет ли CPU overload на зависание ПЛК?