Особености алгоритмизации для циклической обработки в PLC

[petr2off]

Добрый день. Не уверен, что в правильном разделе тема, если что простите бога ради - злого умысла точно нет.
Поучаствовал я тут в теме по вычислению среднего значения, и понял, что осознания специфики программирования для PLC часто не осознается. Потому как первое предложение (которое было предложено) было создать глобальный массив, залить туда данные измерения и посчитать среднее значение через циклическую обработку. Если выразится в более общей форме - мы имеем 2 подхода:

Подход, естественный для классического программирования (Обработка массива).
Pn = F(X[1..N],N)
где Pn – некоторый параметр, вычисляемый как функция от массива X, размерностью N.
Подход, естественный для АСУ ТП (циклической обработке в PLC)
Pn =F(Pn-1,Xn)
где Pn – некоторый параметр, вычисляемый как функция от значения параметра Pn-1 и последнего значения X - Xn

Т.е. алгоритмизация для PLC имеет свои особенности, к коим отношу:
1 - уже имеющийся цикл обработки
2 - желание иметь алгоритм, с фиксированным временем обработки (в первом подходе время обработки зависит от N)
3 - как правило, для PLC параметр часто считается за определенный временной период, и соответственно N (а значит и размерность массива зависит от периода подсчета и времени цикла PLC - что усложняет организацию массивов для промежуточного хранения.
Ну тут еще ряд доводов привести можно, но не суть. Я хочу обсудить разницу в подходах алгоритмизации для классической обработке и для обработке в PLC.
Уфф. Все - кидайте тапки :)

[Jackson]

:)
Приветствую.

Разница тут не в программировании, а в работе самого ПЛК (по сравнению с ПК). В ПК Вы в любой момент можете опросить состояние входов/выходов любого устройства. В ПЛК есть определённый цикл, он разный для разных ПЛК и описан в их документации, но в общем и очень упрощённо он такой:

1. самодиагностика
2. опрос состояния входов и выходов
3. выполнение программы пользователя
4. запись команд на изменение выходов
5. конец, переход в п.1

Хотите подробнее об этом - посмотрите документацию например от Шнайдера.

То что Вы программируете на ПЛК - это только п.3. Весь этот цикл может выполняться ASAP, может выполняться с заданной Вами периодичностью (задаётся в настройках задачи). П.3 - это главная задача (main task). Существуют ещё быстрые задачи (fast task), которые могут выполняться либо циклично либо по вызову из главной задачи, на время их выполнения обработка других задач (главной задачи, чтение и запись в/в) приостанавливается. По сути это подпрограммы.
Вы можете и сами внутри главной задачи организовывать циклы (завести счётчик, расставить метки перехода), но делать это на ПЛК в общем случае нецелесообразно (а по некоторым нормативам даже запрещено) потому что сам по себе ПЛК уже содержит в себе системные средства для организации подпрограмм и контроль выполнения (не зависло ли) главной задачи, подпрограмм и общего цикла.
Хорошая программа на ПЛК не содержит ни одного оператора перехода (ни условного ни безусловного) и ни одного цикла - всё это и так выполняется, надо только использовать. С делением аккуратнее. Если в знаменателе не константа то лучше проверять в начале цикла, что это значение не равно нулю.

[+] хохма

Из разговорного словаря для программистов:
- мне нужно такси
- мне нужен врач
- можно ли в вашей стране делить на ноль?
...

Готовые буферы FIFO и LIFO тоже есть - их можно использовать в Вашем случае для накопления значений вместо массивов) если глубина накопления небольшая). Когда сделаете программу, то запустив её на эмуляторе сможете проверить, сколько времени занимает один цикл. По моему опыту, математические вычисления отнимают приличное время цикла.

Тут надо сразу разобраться, среднее значение Вы хотите получить за период времени или за количество последних значений. Первое сложнее поскольку ПЛК не предназначен для исторического хранения большого кол-ва данных и математические операции в нём имеют меньше возможностей - он всё-таки в 1 очередь логический контроллер. И вообще, я считаю что задача усреднения значений в общем случае должна решаться не в ПЛК, а в HMI и SCADA (если это не нужно для собственно управления).

[petr2off]

Задача усреднения встречается довольно часто, скажем моментальное значение расхода - особенно не интересно, а вот средне часовое потребление - это уже интересный параметр, и он должен регистрироваться и писаться в архив. Scada в этой цепочке используется эпизодически, на предмет посмотреть.
В теплоэнергетике вообще, усредненные значения часто используются. И именно в контроллерах (вычислителях). Они часто вообще без скады работают (приехал с ноутбуком и снял архив) или в пакетном режиме - раз в сутки опрашиваются, и раскачиваются например среднечасовые расходы за сутки по часам.

Насчет массивов и переходов - согласен. Некоторые инструменты вообще массивов не имеют, (скажем Isagraf 3.22). Или их использование сопряжено с трудностями (я пару месяцев бился с S7-1200, прежде чем нашел способ параметрической обработки массивов. Но иногда они нужны, скажем - я как то анализировал работы разных фильтров, и медианный фильтр без использования массива реализовать мне не удалось.

По циклам тоже ситуация бывает разная, в том же ISGRAF понятия главного цикла нет.

Но, дело в том, что имеющиеся алгоритмы очень часто записаны в виде, предполагающие их использовании в ПК, а не PLC. В связи с чем и возникает потребность в наборе методов и методик их преобразования для более оптимального использования в PLC.
Одна из таких методик - это переход к рекурсивному алгоритму, для примера то же среднее значение.

Рекурсивное вычисление среднего значения.docx

Но если подумать, можно еще ряд приемов найти (наверно)

[Jackson]

В теплоэнергетике вообще, усредненные значения часто используются.

Верю, конечно есть и такие задачи.
Тут надо организовывать хранение данных, нужна энергонезависимая память на которую сбрасывать вычисленные значения в упорядоченном виде (чтобы скачанный потом архив можно было разобрать). Организовывать подхват после перезапуска....

Есть отдельные устройства, что-то типа ModBUS Data Logger, читает заданные параметры, складывает на карту памяти в настроенном формате, уже готовом для импорта куда-либо. Соответственно вычислять можно в ПЛК, а такой чёрный ящик может это всё забирать и писать архив. Использовать или нет - это дело личное, но это может оказаться дешевле и отказоустойчивее, возможно будет меньше сложностей с организацией хранения данных в ПЛК (эта задача снимается).

Тут начинаются и климатические нюансы, поскольку есть масса автономных систем, установленных в необогреваемых и/или сырых помещениях, там и флешки и контроллеры могут отказывать. Встречал (но не помню где) ПЛК, с рабочей температурой от -20, но вот энергонезависимая память к нему - от 0 градусов, и степень защиты без карты памяти IP22, а с картой указано IP20 (видимо отодвигается шторка когда вставляется карта памяти). Батарейки часов РВ в ПЛК при температурах ниже 0 градусов начинают садиться быстрее чем заявлено (примерно вдвое уменьшается срок службы при отклонении температуры на каждые 10 градусов).

Есть и теплосчётчики (и прочие счётчики), которые сразу сами вычисляют средние значения и формируют архив.

[winb]

С рекурсиями аккуратнее, для ПЛК часто ограничивается глубина вложенности вызова подпрограмм (функций, блоков). В 300-х, 400-х Симатиках - точно ограничивается. И рекурсия заткнется через несколько циклов.
Если нет ограничений по времени цикла, то вполне допустимо использовать "классические" алгоритмы, ограничив допустимое время цикла и настроив обработку прерываний по превышению этого времени. Современные "обычные" контроллеры (в основном) имеют хороший запас вычислительной мощности, который можно использовать не только для снижения времени цикла (не везде же нужен цикл в 1-5 мс, часто и 30 мс вполне допустимы), но и для математики, переборки массивов (вдруг понадобится реализация какого-нибудь хитрого фильтра) и т.п.

[petr2off]

Если вы посмотрите вариант расчета среднего - то там никакой затычки не будет в принципе. Потому как я не вызываю функцию из себя. Функциональный блок отличается от классической функции наличием собственного экземпляра данных. Т.е. я вполне могу сохранять предыдущее значение без доп. вызова функции. Хотя скажем, опасность исчерпания диапазона счетчика есть, и его нужно просто контролировать. Хотя наверно для этого алгоритма применение термина рекурсивный неправомочно, но как его назвать мне что то в голову не приходит. По внешнему виду S(n) = S(n-1)*(n-1)/n + Xn/n Он рекурсивный, по реализации нет.

[Dotarev]

Цикл контроллера дает хорошую базу для реализации цифрового фильтра. Например, S(n) = S(n-1)*(n-1)/n + Xn/n (формула 1) - это рекурсивный цифровой фильтр первого порядка. В общем случае, значение на выходе фильтра зависит от значений входа (измерений) всех предыдущих отсчетов Xn-1...X1.
В реальности, требуется учитывать ограничения по точности вычислений и возможность переполнения. Например, при реализации формулы 1 "как написано", могут проявиться следующие проблемы:
а) количество отсчетов превысит максимальное значение Type(n). Например, если Вы храните n как dword, то при отсчете > DWORD.MaxValue =3^32-1, or 4294967295, or 0xFFFFFFFF результат расчета окажется неверным.
б) Значение слагаемого Xn/n окажется меньше, чем погрешность округления типа, в котором производится суммирование. Например, если сумма вычисляется как real, а значение отсчетов Xn/n, начиная с некоторого n, меньше чем REAL.Epsilon (около 1,11e-16), то значение на выходе не будет зависеть от дальнейших измерений. (но даже и до достижения этого порога, погрешность округления может увеличить общую погрешность вычислений).
Если требуется усреднение от небольшого числа значений, вполне реально хранить все предыдущие значения как переменные в теле функционального блока Если требуется усреднение за определенный интервал времени (например, среднее значение за минуту), то возможный вариант - привязаться к часам ПЛК и периодически (раз в минуту, например) сбрасывать внутренние переменные, а результатом усреднения предоставлять вычисленное значение за предыдущий интервал времени. При таком подходе, проблем переполнения счетчика и погрешности округления можно избежать и без дополнительных вычислений в теле программы, поскольку максимальное количество отсчетов ограничено интервалом и частотой измерений, а порядок значений всех членов выражения 1 можно оценить заранее.