Многозадачность Codesys

В одноядерных процессорах используется менеджер задач, который является инструментом для решения вопросов многозадачности за счет разделения выполняемых задач по времени и приоритетности. Обычно входы/выходы мы обрабатываем чаще, а прикладные задачи и визуализацию – реже. Таким образом, мы выстраиваем цикл выполнения для разных задач. Так, например, есть программа чтения входов, которая обрабатывается с дискретностью 10 миллисекунд, есть программа с алгоритмом управления. Указанные программы обрабатываются последовательно. Если вышло время обработки входов, то переходим к обработке прикладной программы. Если время еще не вышло, то, минуя обработку прикладной программы, мы обращаемся к блоку записи в выходы. И так по кругу. Вроде бы всё достаточно просто и понятно, но это до тех пор, пока таких задач только две. Когда таких задач становится больше, когда они заняты серьезными вычислениями, тогда роль менеджера задач в выполнении программ с различной периодичностью значительно возрастает. Мы сталкиваемся с необходимостью разделения процесса обработки программ по приоритетам.

Разграничения по периодичности необходимы для более правильного использования процессорной мощности CPU (центрального процессора контроллера). Не имеет никакого смысла выполнять одни и те же вызовы программ, которые можно выполнить реже. Причём нужно хорошо понимать, что программа с использованием видеопроцессора занимает больше времени, чем, например, обработка каких-нибудь формул или логики. Сам процесс рисования достаточно ресурсоемкий процесс и совершенно необязательно обновлять картинку чаще, чем это нужно для реализации основных функций. Определим основные отличия сред программирования. Приоритеты в Codesys 2.3 указываются в размерности от 0 до 15, в Codesys 3.5 они уже в диапазоне от 0 до 31. Все эти приоритеты связаны с распределением процессорного времени. Чем меньше число приоритета, тем приоритет выше и тем больше будет выделено процессорного времени для выполнения связанной программы. Тип многозадачности в Codesys 2.3 называется «замещающий», когда одна задача замещает другую. Менеджер задач в данной версии реализует заданную логику по приоритетам. Выполняться будет тот приоритет, который выше. В Codesys 3.5 принцип многозадачности – «вытесняющий». Если есть две задачи, которые должны выполняться одновременно, в программе будет реализовано последовательное выполнение, одна задача за другой. Более высокоприоритетная задача получит право быть выполненной первой, однако менее приоритетная задача будет также выполнена следом за ней. Если вызываются задачи с одинаковым приоритетом, будет выполняться та, которая ждет больше, чтобы не возникло такой ситуации, что одна задача не выполняется вообще. Рассмотрим указанную разницу на следующем примере. Создадим на Codesys 2.3 и на Codesys 3.5 две несложные программы в рамках одного проекта. Одну программу сделаем с циклом выполнения в 10 миллисекунд, а другую программу сделаем специально с ошибкой – с бесконечным циклом. Добавим в менеджере задач две задачи, разделяя их по приоритетам, делаем вторую задачу (с бесконечным циклом) с более низким приоритетом. В каждой программной секции добавим по счётчику. Что получится, когда совпадет их время выполнения? Что будет с нашим контроллером и как он себя поведет? После запуска Codesys 2.3, если не была задействована функция «watchdog», мы увидим остановку контроллера, так как он остановился на одной из задач и не смог из неё выйти. Он занялся обработкой одного-единственного процесса и перестал отвечать. Это связано с архитектурой выполнения программного кода в среде Codesys 2.3.

Таким образом, существенное отличие между Codesys 2.3 от Codesys 3.5 заключается в разности в определении приоритетов. Если приоритеты в Codesys 2.3 определяет старшинство и чётко выполняется приоритет «высшее над низшим», то в Codesys 3.5 производится перераспределение ресурса процессорного времени. Выделение его для того или иного приоритета – это и есть особенность вытесняющей многозадачности. Следует отметить, что в случае «вытесняющей» многозадачности мы говорим всегда о процессоре с одним ядром. Там, где много ядер, процессы несколько сложнее и об этом в данной статье говорить не будем.

•Тип задач «Циклический». Когда наступает время, программа начинает свое выполнение. Она выполняется столько, сколько требуется самой программе, потом программа останавливается, дожидается следующего времени срабатывания таймера и выполняется повторно. При использовании нескольких циклических задач следует стараться выставлять им разное время, чтоб уменьшить количество возможных коллизий, и расставлять всем разные приоритеты. •Тип задач «Событие» Менеджер задач следит за связанной переменной типа «BOOL», и когда переменная меняет свое значение с «FALSE» на «TRUE», то происходит однократный, длиной в 1 цикл, вызов связанной программы. Например, так можно зафиксировать замыкание датчика, передать диагностическое сообщение о произошедшем событии в SCADA-систему. Для данного типа задач желательно задавать наивысший приоритет, чтоб ему гарантированно дали выполниться циклические или свободные задачи. •Тип задач «Свободная» С первого цикла контроллера начинается опрос связанной программы, по окончанию действия этой программы она выполняется следующий раз без задержек, просто сразу запускается. Она не имеет никаких временных рамок, она вызывается с периодичностью своего выполнения, то есть данная периодичность может меняться в зависимости от загрузки процессора, от объёма логических вычислений данной программы. Соответственно, если мы выполняем такие типы задач, то их лучше выставлять ниже по приоритету, чем другие типы задач, иначе последние просто не будут выполнены. •Тип задач «Состояние» Задача будет выполняться, как и свободная, с минимально возможным циклом опроса, пока связанная с ней переменная типа «BOOL» будет находиться в состоянии «TRUE». Следует уменьшать приоритет у данной задачи, так как она, и как свободная, действует без задержек в выполнении и может «затереть» любую из задач. У контроллера свои отдельные циклы (такты), которые не привязаны ни к чтению входов, ни к выполнению программ. Это циклы операционной системы. Немного подробнее о функции «Watchdog». В менеджере задач присутствует функция отслеживания подвисаний – «Watchdog». Данная функция предназначена для остановки выполнения программы по превышению времени выполнения. Так, если какая-то из программ будет выполняться дольше отведенного ей времени, то при срабатывании «Watchdog» не произойдет зависание контроллера или задачи. Появляется возможность корректировки программ или перезагрузки контроллера. Для корректной работы функции таймера «Watchdog» имеется параметр «чувствительность». Данный параметр определяет, сколько раз может быть превышено время до момента срабатывания «Watchdog». Так, например, если срабатывает «Watchdog» в Codesys 2.3 , то он автоматически перезагружает ПЛК. Это сделано для того, чтоб при возникновении ошибки в коде исключить или уменьшить степень воздействия зависшего ПЛК на технологический процесс, появляется некий шанс вернуть всё в норму или хотя бы вернуть всё выходы контроллера в безопасное состояние. Если у нас подвиснет одна из задач в Codesys 3.5, то это не приведёт к зависанию процесса или перезагрузке ПЛК, соответственно, контроллер продолжит работу, программа сформирует диагностическую информацию о исключении задачи из обработки. В Codesys 3.5 мы имеем диагностику и можем посмотреть текущее состояние выполнение задач. Диагностика менеджера задач (мониторинг): «Статус» – показывает текущий статус выполнения, если «Не создано» – задача не запускалась с момента последнего обновления, «Создан» – задача распознается в системе исполнения, но не в работе, «Valid» – задача работает нормально, «Исключение» – задача выведена из обработки. Бывает еще «Активная», что означает, что данная задача имеет проблемы. «Счетчик» – имеет два поля, МЭК и общий. Связан с типами вызовов блоков. Общий обычно больше. «Посл. (µs)» - Время последнего измеренного цикла в микросекундах, постоянно должно меняться. «Сред. время цикла (µs)» – общее среднее время всех циклов по данной задаче в микросекундах. «Макс. время цикла (µs)» – максимальное измеренное время цикла [µs]. Данное время может быть больше заданного, если программа не успевает отрабатывать. «Мин. время цикла (µs)» – минимальное измеренное время цикла [µs]. «Джиттер (µs)» – последний измеренный джиттер [µs]. Джиттер – это разница между временем, когда задача должна начаться, и временем фактического начала выполнения задачи. Например, если задача должна запускаться каждые 1000 µs, а на деле она не успела и вынуждена запуститься через 1100 µs, то джиттер составляет 100 µs. Время вызова задачи с каждым вызовом может сдвигаться. Это разница между тем, когда задача должна была начать выполняться, и тем, когда она реально начала выполняться. Джиттер, по сути, выступает по сути числовым количественным параметром, измеряющим величину данного сдвига. Чем он меньше, тем лучше выполнена настройка ПЛК.