ПЛК 63 в примерах

[kucherik]

ШАГ 1 — инициализация, обработка сигналов
ШАГ 2 Два варианта вычисления погодозависимого графика
ШАГ 3 Работа с насосами (отопления, бойлера)
ШАГ 4 Работа с трехточечным сервоприводом отопления
ШАГ 5 Аварийные ситуации

Для начала надо разобрать логику работы, и что надо делать при аварийных ситуациях. И когда должно приниматься решение, что система в аварийном режиме. В данном случае, я опишу типовую логику. Для начала надо чтобы проверилась аварийная индикация, для этого в шаг INIT закладываем таймер, который задержит начало программы (до этого момента INIT у меня был пустым). Так как сигнал аварии в данном случае инверсный, то надо принудительно перевести все выходы в выключенное состояние. Время таймера в каждом случае выбирается исходя из технологических требований. Для систем отопления есть один момент, который называется гидроударом. Суть этого явления заключается в том что вода сразу не останавливается и содержит энергию движения, поэтому насос отопления, особенно когда они с резервированием, не переключают сразу, а нужна пауза на «успокоение».
Тоже надо сделать и в данном случае, или поддержать насос во включенном состоянии или сделать паузу чтобы не дергать насос (меня устраивают оба варианта). А в данном примере это уже сделано, если помните в насосе есть пауза для включения-выключения насоса отопления. Следовательно когда после снятия сигнала аварии, по схеме принципиальной насос выключится, если не будет сигнала на включение насоса. А в аварийном сигнале так же есть задержка на подачу сигнала авария в 1 минуту, после старта программного цикла.
Теперь коснемся работы смесителей отопления, для случая отопления в аварийной ситуации (тут возможно только в случаях отказа датчиков отопления и наружного воздуха) нам надо открыть смеситель на максимум, а вот для теплого пола такое делать противопоказано. для него лучше всего заблокировать смеситель в текущем положении до устранения аварийной ситуации (для него соответственно это отказ наружного воздуха или датчика контура). Логичные изменения данных утверждений вы встретите в шаге 4 (step4), для смесителей, в шаге 3 (step3), для насоса. Как можно было бы это выполнить для смесителей, но не стал делать. Например в случае аварии любого датчика, выводить в качестве задания, максимальную температуру контура, но в данном случае надо бы задуматься над ресурсом реле.
Обещаю выложить дополнительный пример который ограничивает количество срабатываний и бережет ресурс реле. Просто не хочется усложнять это пример.
Для обработки аварийных ситуаций нет смысла писать отдельный модуль, так как в каждом случае приходится писать свою логику. К тому же реакция на аварийные ситуации «размазана» по программе. В некоторых случаях она заставляет работать (открывает смеситель отопления), в других наоборот принимать безопасное состояние (блокирует работу смесителя теплого пола).

Дополнительный комментарий: Это последний аппаратно независимый ШАГ, далее уже пойдет привязка к железу. Все что было изложено выше и в данном шаге, можно будет включить в любой CoDeSys (пишу под второй, третий непонятно что и когда будет, и как решаться вопросы совместимости со старым железом) совместимый контролер. А после небольшой доработки напильником и на альтернативные платформы (именно поэтому опираюсь на стандартные библиотеки). Главное чтобы был понятен смысл действий. Еще один момент, дополнительные шаги мне кажется более правильным описывать опираясь на этот шаг. Он дает достаточно большую абстракцию относительно аппаратной платформы.

ШАГ 6 Финальная сборка и привязка к ПЛК63
ШАГ 7 Отображение данных

[LAM]

Kucherik - Я сразу говорил, что программа очень сырая, и многого еще нет, в дальнейшем кнечно планировал оформить все в виде ФБ, пока для меня так нагляднее.
Например очень большой минус а данный момент - то, что нет контроля положения задвижки, получается что при открытии идет анализ температуры на стрелке, и когда температуры приблизительно равны, релюхами не щелкаем.
А вот при понижении температуры, обратка как правило остывает довольно медленно, и при полностью закрытой задвижке релюха еще довольно долго щелкает.
Эту часть кода в принципе уже написал, просто еще не встроил.

Пробовал встроить ПИД регуляторы, там даже часть кода есть, но потом отказался за ненадобностью, т.к. и так температура подгоняется довольно быстро и точно, тут твоя идея мне понравилась (чем больше рассогласование - тем длинее сигнал).

[kucherik]

LAM - программа рабочая, это пока главное. Причесывание кода, можно провести в любой момент. А вот с модуляцией длительности импульса надо чуть осторожней, я подбираю границу ограничений на каждом объекте индивидуально. Временные ограничения для реле дописываю, увы в свободное от работы время и его мало %(

kolyan - реальный проект, достаточно продуманный. Если будут вопросы пишите. Кстати проверил на двух машинах и всех кого мог попросил для тестирования, проблем пока не было.

С уважением, kucherik

[ASo]

Вот когда defo покажет класс на продуктоориентированном, а не на клиентоориентированном рынке именно в РФ - первый сниму перед ним шляпу.
А так проблемы понятны, они даже озвучены руководством ОВЕНа Дмитрием Владимировичем Крашенинниковым в АиП №38, с.3 снизу

С момента выпуска первого ПЛК прошло 5 лет, за это
время продано свыше 30 тысяч экземпляров – и эти цифры
говорят сами за себя. Я считаю, что накопленные знания и
бесценный опыт позволят нам в ближайшее время создать
ПЛК мирового уровня.

Было бы смешно, если не было бы грустно.

[ASo]

А что ктото гдето пишет благодарности????
Можно, я не поверю.
И я знаю неск. форумов, где подобное стирают, и даже банят.

[ASo]

Вы с ума сошли!
Я вообще не присутствую на АВОКе

[kucherik]

Странно, тему маленько зафлудили %(
И код никто видно не тестирует %(
Есть маленькая ошибка, авария никуда не выводится
step 5, соответственно откорректирован

[kucherik]

Сохранение ресурса сервоприводов и других регуляторов.

Описание касается и данного примера и всех случаев когда требуется увеличить или сохранять ограниченный ресурс. Как было изложено, например для насоса отопления, это можно было решить введением таймеров задержки. Например, для насоса установлено производителем требование не более 12 включений в час. Если схема позволяет это просто реализовать задержкой на включение на 5 минут. Если не позволяет, т.е. оборудование должно включиться в любом случае, тогда задержка на выключение. Если не то и не другое, тогда ограничение включений, и аварийная индикация в случае превышения, возможно и блокировка. Так как большинство технологического оборудования и решений планируются с учетом требований к частоте включения (обычно решается «инерционностью» среды). А раз количество срабатываний выросло, значит что-то случилось. Первая часть относится к двухпозиционным или двухточечным регуляторам. То есть он или включен или выключен.
И так простой функциональный блок PulseLimit. Состоит из входа IN на который приходит параллельный сигнал, и вход (тип время) DTIME на который подается время, через которое уменьшается количество счетчика на единицу, еще один вход PLIMIT, он определяет ограничение выше которого срабатывает выход STOP. Устройство данного функционального блока, основывается на стандартной библиотеки с инкрементно / декрементным счетчиком (смотри документацию на библиотеку STANDART.LIB — СTUD, этот счетчик достаточно просто можно написать самостоятельно, но не хотелось изобретать велосипед), на вычитающий вход подается значение с таймера который выполняет задержку между включениями. Таймер работает до момента пока значение счетчика не снизится до нуля. Обращаю внимание, что по прежнему есть значения по умолчанию, меняйте их по собственному усмотрению, это только конструктор. Дополнительно хотелось бы отметить ограничение на количество счета. Значение со входа IN проходит через элемент AND, если Вам потребуется по прежнему считать количество включений, тогда его надо будет удалить, а на вход CU подавать значения прямо из IN.
Наконец, подошли к еще очень интересному ограничению по времени нахождения во включенном состоянии. Пример, для горелок есть ограничение в 24 часа, по истечении которого она должна опять пройти через циклограмму запуска. Это достаточно было бы просто решить таймером сброса. А вот например, для случая ограничения времени нахождения по включенном состоянии в течении часа, и был разработан ниже изложенный функциональный блок.
Как видно из его структуры он (TimeLimit) не сильно отличается от PulseLimit, однако при инвертировании сигнала (это пример реализации и подходил только для длительных процессов, обязательно прочитайте сноску «Важно»), включается обратный отсчет, который начинает уменьшать накопленное значение. Соответственно, вход DTIME переименован в PR, теперь это время определяет точность измерения (вспоминаем теорему Котельникова), а вход PLIMIT превращается в относительное значение количества импульсов (время ограничения определяется как PLIMIT*PR). Если представить типовую ситуацию, то данный функциональный блок находится в ограничении длительности импульса, и при замыкании через обратную связь при работе появится меандр, по времени определяемый PR. Фактически в данном случае, получается «прибор», который измеряет скважность сигнала за время ограничения. В процентах это можно оценить разделив CURRENT на PLIMIT и умножив на 100. В более близком к практике случае надо добавить время на восстановление RT (Restore/Relax Time соответственно и функциональный блок в этом случае назвал TimeLimitRT). То есть при снятии сигнала с входа IN, выход STOP будет активен время RT, если за это время RT сигнал восстановится, блокировка не прервется . Самый плохой случай, это когда сигнал случайно включается и выключается и его время больше времени восстановления RT. Я бы еще использовал бы сигнал сброса RST,или замкнул бы его после того как истечет время восстановления. Тут больше зависит от практических задач. Для далее изложенных блоков, внешний сброс обязателен для компенсации накопленной ошибки. TimeLimirRT это пример модификации того что есть, под конкретные задачи, и не обязательно так как изложено. Например его можно было реализовать и при внешнем использовании таймера блокировки с блоком TimeLimit, на нужное время, элемент AND с инверсным входом для TimeLimit, А вход на TimeLimit с выхода AND. Получим соответственно эффект, что оборудование гарантированно будет «отдыхать» нужное время.
Пример использования на практике. Есть у меня котельная с насосом за 35 киловатт, при старте этого насоса сильно греются теплухи (защита по току) и если запускать его чаще 1 раза за 2 минуты, теплуху вышибает. Решение беру функциональный блок PulseLimit ставлю количество импульсов 1, время восстановления 5 минут. Другой пример уже ближе к этой теме форума, он связан с сервоприводом смесителя, от одного крайнего положения до другого 120 секунд, соответственно если мы говорим о фиксированной длительности импульса например в 1 секунду, получается 120 импульсов от края до края. Напоминаю, заявленная задача сохранение ресурса реле, нам надо не больше примерно 240 импульсов в сутки. Решение, ставим ограничение на количество импульсов 120 (оно нужно для быстрой настройке в случае отключения питания), а время восстановления получаем 1 раз в 6 минут (24 часа - 240 импульсов, получаем не больше 10 импульсов в час ). В стационарном режиме примерно 250 срабатываний реле в сутки, при количестве срабатываний 100 000 получим ресурс — 400 дней (в предыдущем примере 35), а увеличив время восстановления до 1 часа получим 4000 дней, перебор %). Если увеличить время восстановления до 1 часа то в стационарном режиме будет не очень приятный режим что за сутки смеситель сможет пройти только 20% по своему диапазону (24 импульса — мало, практика показала что оптимальный диапазон 40%-60%) соответственно надо выбирать исходя из условий эксплуатации. (например при выходе за критические значения игнорировать импульсные ограничения, или время восстановления выбрать 12-15 минут, тогда получим 100%-80%)

Было искушение написать, вторую часть используя выше изложенные функциональные блоки, но это привело бы к ограничению функционала. Нельзя было бы импортировать его независимо, опираясь только на стандартные библиотеки.
Наконец, ограничение для сервопривода и иных устройств с трехточечным управлением. Например сервопривод, когда он отработал на открытие-закрытие больше времени, чем заложено производителем, смысл по прежнему подавать на него сигнал открытия-закрытия. Этому посвящены два функциональных блока, которые учитывают данную особенность. Их названия P3PulseLimit и P3TimeLimit. Так как тут описывается универсальный случай и текущее положение сервопривода неизвестно, то рекомендую выбирать в качестве ограничения двойное время или количество импульсов. Более универсальное решение можно было бы получить, если ввести отдельные уставки для верхнего и нижнего значения.
Тут исчез таймер обратного отсчета, вместо него используется понижающий вход. А касаемо ограничения при счете в минус использован элемент сравнения, можно вместо элемента умножения на минус единицу заменить на элемент вычитания из нуля, если не хватает времени исполнения. Не хотелось использовать тут второй счетчик, а так получилось более просто. С него же берется сигнал о срабатывании ограничения по минимальному значению. В данном случае это означает отрицательное значение уставки. Это сделано для того чтобы не считать подбором двойную величину импульсов. Достаточно замерить ход в одну из сторон (из одного крайнего положения в другое). А двойная величина нужна только для случаев большой разницы во времени импульсного хода относительно непрерывного. В тяжелых случаях по прежнему подбирается по факту. Хотя в малых котельных я от этого отказался. Пока работает без проблем, правда в программе используется сброс и инициализация сервопривода один раз в сутки, а в случае перезапуска, контролера так же инициализируется положение.

[kucherik]

Приведенные функциональные блоки можно комбинировать в различных последовательностях получая разные эффекты. Еще раз напоминаю это конструктор и с его помощью можно и главное нужно, увеличивать время работы приборов, в данном случае ОВЕНа. Я больше работал с контролерами у которых вместо реле использовались твердотельные реле с токами утечки в единицы микроампер и меньше. Там не приходилось ограничивать число циклов. Приведенное выше нужно для увеличения сроков работы реле прибора с 35-350 дней до 5- лет и более. Надеюсь это поможет Вам, решить данную задачу.

Дополнительный комментарий: может кому потребуется использовать текущее значение, вычисленного положения, для этого используется выход CURRENT. Я не рекомендую использовать изложенные функциональные блоки как тип RETAIN, потому что в этом случае не получится сбросить значения, например при выключении питания. А так будет стартовать с нуля, не забываем присваивать двойное значение ограничений для пульсирующих ограничений, если не производим инициализацию, сервопривода. То есть перезапустил по питанию и нет проблем, просто бережем ресурс. Дорабатывайте эти функциональные блоки, под Ваши задачи, если желаете выкладывайте на форум. Только вместе можно создать что-то достаточно интересное и универсальное. Я специально затягиваю добавление данного функционала в описанный пример для ПЛК63, хочется сделать определенную проверку на профессионализм. Поэтому оставил место для сервопривода который стартует после инициализации из нулевого положения. Если вы сможете самостоятельно интегрировать и адаптировать эти блоки, значит все в порядке. Остальные предупреждены %)

Важно: Все что изложено для измерения времени это “обман”, таймеры нельзя (можно но при соблюдении некоторых условий) использовать для этой цели и сейчас я объясню почему. Для проверки рекомендую собрать конструкцию из таймера TP и любого счетчика. Задайте время 1 секунду и посмотрите какое рассогласование набежит за 10 минут. Откуда оно берется, очень просто время длительности импульса мы задали, а вот время цикла программы нет. То есть один цикл таймер будет в отключенном состоянии, затем только пойдет отсчет импульса. Отсюда и набегает ошибка и если вы это учтете и зададите например циклический запуск процесса через фиксированные промежутки времени, то использовать можно. И надо конечно учесть время цикла программы при определении PR.
Для некоторых процессов это конечно не критично, и этот пример можно использовать для определенных задач, даже для сервоприводов, но как всегда с определенными оговорками (например по точности) и инициализацией положения через определенный интервал времени чтобы сбрасывать накопленную ошибку. Или как альтернативный вариант, когда длительность импульса всегда одна и та же используем ограничения количества импульсов P3PulseLimit.
А как же быть там где используется ШИМ сигналы для управления, нужен более точный и тонкий подход. Он изложен далее.

[kucherik]

Все что будет изложено далее опирается на стандартную библиотеку (Standart.Lib)
Главный элемент для измерения времени это RTC, здесь же приведен пример функционального блока который измеряет время нахождения оборудования в включенном состоянии (OnTime). В некоторых моих программах приведенных на форуме видно что когда я делаю измерение времени без RTC это возможно только используя фиксированный во времени процесс который менял свое состояние каждые полсекунды. Обращаю внимание на тип используемых переменных для различных задач. Для измерения времени лучше всего подходит DATE_AND_TIME (сокр. DT) с шагом значений в одну секунду. Для оценки времени работы оборудования более чем достаточно, а в случае сервоприводов и других процессов надо бы использовать TIME уже с шагом в милисекунды, но и тут есть подводный камень (Максимальное значение для типа TIME : 49d17h2m47s295ms (4194967295 ms)) соответственно надо оборудование сбрасывать или начинать отсчет заново по достижении определенного значения.
И так функциональный блок OnTime просто состоит всего из двух последовательных элементов RTC и MOVE (использовал EN/ENO из-за простоты в данном конкретном случае), что-то тут комментировать кажется излишним, все очень просто. Чуть сложнее его OnOffTime, он еще измеряет время простоя оборудования. Можно путем внешних операций даже выводить процент использования и тому подобное. Нужен ли тут вход для сброса накопленных значений не значений не знаю, сделать его просто добавится только еще один элемент и логика для сброса и блокировки. С процессами длиннее нескольких секунд понятно, теперь надо вернуться к проблеме измерения миллисекундных процессов. А именно к вопросу вычисления текущего положения по времени работы трехточечных сервоприводов. Проблема заключается в том что хочется измерять с миллисекундной точностью, но без использования дополнительных библиотек. И выход в данном случае нестандартное использование таймера TON.
В данном случае я использую выход таймера (функциональный блок OnTimeTON) для получения текущих значений времени с момента отсчета. Здесь была определенная сложность чтобы выполнить этот код без использования EN/ENO, как видно можно и тут выкрутиться. В момент снятия сигнала срабатывает триггер по обратному фронту, он затягивает отключение таймера, на один такт, и в этот момент снимаем текущее показания времени. Важный момент, правильность работы возможна только за два такта программы, это надо учитывать при использовании данного функционального блока. Далее стоит ограничитель на 24 часа (не правило можно и месяц поставить кому как удобно но меньше 50 дней), и при его использовании погрешность на один такт в сутки, гарантировано перекрывается погрешностью хода часов, кому важно сделать это точно, надо как уже писалось надо выставить фиксированное время цикла запуска и это время вычесть из 24 часов. Например запуск один раз в секунду тогда время сброса соответственно 23 часа 59 минут 59 секунд . Ну и вход RST для сброса текущих показаний.
Теперь поговорим об учете положения для трехточечного сервопривода. Сам тип переменных TIME не дает возможности работы с отрицательными значениями, хотя они хранятся в памяти как DWORD что дает возможность к абстрактной работе с ними (например при конвертации). Как же быть, например видно из функционального блока OnOffTime два выхода, в данном случае можно говорить о двухточечном управлении. Но тут нет ограничения в случае простоя двухточечного регулятора. следовательно его можно использовать ограничитель либо встроенным в блок или внешним в программе. Законный вопрос как же это можно реализовать, если сам тип переменной не имеет отрицательных значений. Ответ лежит на поверхности переконвертировать в знаковую целочисленную переменную, но это влечет за собой второй вопрос, а как быть с отрицательными значениями. Или надо отказаться от текущего вывода текущего положения (сделать например процентный вывод) или работать только в положительной зоне (то есть сдвинуться в середину допустимых значений и считать это положение нулевой точной). По мне более предпочтительно работать с целочисленной переменной и оставить ее значения в этом виде, конвертация сопровождается переводом миллисекундные значения в целочисленные. И данный тип уже более удобен для дальнейшей обработки. Он уже не будет привязан к значениям времени и его удобней отображать и видоизменять в программе.
Здесь пришлось реализовать похожий на счетчик алгоритм управления (TimePositionTON). Причем позволяется одновременная подача сигнала на оба входа, ограничение осталось тоже минимум два такта программы сигнал не должен вернутся для корректной обработки. Блокировки от этого нет, не хочется сильно усложнять код. В момент снятия сигнала производится подведение так сказать итога, так же это происходит в случае достижения ограничителя. Из особенностей хотелось бы подчеркнуть возможность асимметричного использования. Два входа для времени TimeUp и TimeDw, они могут быть указаны произвольно, напоминают ограничитель у счетчика импульсов. В данном блоке есть защита от одновременной подачи сигнала на оба входа UP и DW, все ничего до момента что это не будет висеть длиннее чем время в таймере (25 часов) было желание завести выхода с таймеров на сброс в данном случае, но не хотелось снижать универсальность функционального блока, но сложности обычно начинаются там где не ждешь, а что бы произошло если бы сигнал пропал одновременно, тоже самое, записалась бы позиция выполняемая последней. Так же нет проверки на то что TimeUp>TimeDw, но она и не нужна %). Ограничение типовое, для этого типа подхода, между импульсами в любое положение должна пройти пауза в два такта программы. Это ограничение можно избежать если использовать уже приведенный выше функциональный блок OnTimeTON, для учета работы в любую сторону, тогда смена направления пройдет без пробелов.
Но в данном блоке есть очень большая неприятная вещь она происходит когда программа доходит до ограничителя, тут надо подробно разобрать как работает таймер. В момент времени когда приходит сигнал работы, начинается отсчет времени с нулевого положения. Соответственно в момент времени когда приходит сигнал выключено, надо еще раз считать текущее положение с таймера, так как если выключим сразу то выход времени с таймера будет равен нулю. Тогда логично получается что не требуется еще один проход в случае когда срабатывает ограничитель, и как только отходим в противоположном направлении, надо снять сигнал Stop. Как видно данный блок разрешает небольшой заход за величину ограничения, определяемую скоростью выполнения программы.
Ну вот сложный вариант изложен, наверно чтобы больше показать возможности «акробатики» кода (Функциональные блоки OnTimeTON и TimePositionTON воспринимать как «шутку»). А между тем есть более изящное решение. Но для этого потребуется знать чему была равна длительность предыдущего такта программы (в качестве доп. материала см. TaktMeter) и очень будет хорошо если вы используете синхронный (запускаемый через равные промежутки времени) программный процесс. В итоге зная такт можно с высокой точностью работать уже с временными значениями. Написанный функциональный блок T3Position не имеет явных недостатков (если только сигнал не будет висеть больше месяца ), ему не требуются паузы между сигналами, можно подавать сигнал одновременно на два входа, можно сразу после снятия сигнала, в следующем шаге заново подать сигнал. Тут можно выделить три зоны. Первая, здесь происходит вычисление времени исполнения программы, засечка по времени, в случае достижения ограничения, приращение останавливается. Вторая, формируются внутренние сигналы управления и вычисляется текущее положение. Третья, здесь проверяются ограничители. Надеюсь дополнительные комментарии тут излишни. Если что не понятно, спрашивайте, попробую растолковать альтернативно.

Дополнительный комментарий: Что полезного можно написать используя данные функциональные блоки. Например приложение которое будет знать приблизительное положение заслонки, на основе его можно уже улучшить управляемость объекта. Можно высчитать передаточный коэффициент, по мне это то что не хватает в стандартных библиотеках. Кому интересно прилагается блок измеритель длительности программного такта TaktMeter разбит на три последовательных действия для простоты понимания. Еще один важный момент, для понимания сути происходящего процесса надо знать что при импульсе например одна секунда время работы будет например 0.99 секунды а при длительности 2 секунды уже 1.99, то есть определенное время уходит на срабатывание реле, отсюда и накапливается ошибка позиционирования, и для этого я рекомендую производить инициализацию положения например раз в сутки. В моих задачах это очень хорошо работает и проблем пока не было. Порядок обработки данных в функциональных блоках в соответствии с потоком данных, правильно написанный код не требует дополнительного указания порядка обработки. Как в свое время меня учили, например: правильная программа на С/Pascal не требует использования goto и полученный код будет «красивым». Пишите правильно %). А мне пришлось помучатся чтобы получилось красиво и без использования EN/ENO где можно, оно того стоило.