По данному алгоритму программа на ПЛК работать не будет, она содержит бесконечный цикл. А в ПЛК вся прикладная программа выполняется от начала до конца в каждом рабочем цикле, и любая программа должна отдавать управление системной программе. Поэтому при такой организации алгоритма наш ПЛК зависнет.
Даже если и убрать, переход по метке на начало, программа не будет работать, так как нам хочется. Порт всегда будет в состоянии лог.0, так как физическая установка выходов производиться только после выполнения всей прикладной программы. И поэтому промежуточные состояния это всего лишь программные переменные в памяти, и на аппаратной части она ни как не отображаются.
В дополнение задержку времени тоже хорошо бы организовать с помощью таймера, периодически проверяя его значение, а не ожидать в пустую пока это время пройдет, наверняка для контроллера найдется другая более важная работа.
С учетом выше сказанного, правильный алгоритм будет выглядеть следующим образом:
1. Проверить таймер, если время паузы вышло, то
Программирование ПЛК. Пример ladder logic
а) инвертировать выход
б) начать новый отсчет
2. Конец программы
Реализуем данный алгоритм на практике ниже, а теперь рассмотрим основные особенности LAD (Ladder Diagram) языка.
Релейная схема представляет собой две вертикальные шины, между ними расположены горизонтальные цепи образованные контактами и обмотками реле. Пример на рисунке:
— нормально разомкнутый контакт
— нормально замкнутый(инверсный) контакт
— обмотка реле
Количество контактов цепи может быть разным, а обмотка одна.
Любому контакту ставится в соответствие логическая переменная, определяющая его состояние. Если нормально замкнутый контакт замкнут, то ИСТИНА, если размокнут – Ложь, для инверсного наоборот, он замкнут когда переменная имеет значение ЛОЖЬ. Имя переменной пишется над контактом и служит его названием.
Последовательно соединенные контакты равносильны логической операции И, а параллельно-монтажное ИЛИ. Инверсный контакт равносилен операции НЕ. Параллельное соединение обмоток допускается, а последовательное нет. Обмотка реле также может быть инверсной, тогда она копирует в соответствующую логическую переменную инверсное состояние цепи.
Идея релейных схем, такова, что все цепи работают параллельно, т.е. ток во все цепи подается одновременно. Но мы знаем, что программу процессор выполняет последовательно, и мы не можем это сделать одновременно. Так и в LAD программа выполняется последовательно слева направо, сверху вниз. Но цикл процессора мал, поэтому и получается эффект параллельности.
Программирование ПЛК. Как понять язык LADDER за 5 минут!
Любая переменная в рамках одной цепи имеет одно и то же значение. Если даже реле в цепи изменит переменную, то новое значение поступит на контакты только в следующем цикле. Цепи расположенные выше получают новое значение переменной сразу, а цепи расположенные ниже – только в следующем цикле. Строгий порядок выполнения очень важен, и благодаря ним LAD- диаграмма сохраняет устойчивость при наличии обратных связей.
Хоть это и противоречит аналогии LAD с релейными схемами, порядок выполнения LAD- программы можно нарушить с помощью меток и переходов. Это ухудшает читаемость программе, и в них бывает сложно разобраться, но как говориться если очень хочется, то можно. Для этого желательно разбить программу на модули, и делать переходы между модулями.
Возможности LAD программы можно расширить, вставляя функциональные блоки. Вставлять можно все стандартные функциональные блоки, которые содержаться в МЭК. Описание для функциональных блоков можно найти в справке.
Давайте составим нашу первую программу на LAD в среде CoDeSys. CoDeSys можно скачать в интернете, достаточно воспользоваться поисковиком
После установки, выбираем создать новый проект, и CoDeSys попросит выбрать целевую платформу для ПЛК. Указание целевой платформы необходимо, чтобы среда знала, для какого типа контроллера пишется программа. Выбираем 3S CodeSyS Sp PLCWinNT V2.4 и жмем OK.
Имя проекта оставляем по умолчанию, язык выбираем LD
Интерфейс программы на русском языке, и интуитивно понятен. При наведении на элемент всплывает имя. Советую рассмотреть все элементы, а также пункты главного меню.
Для добавления элемента в программу необходимо левой кнопкой мыши кликнуть в рабочее поле программы и потом ЛКМ кликнуть на элемент, который вы хотите поместить в программу. Например, нормально разомкнутый контакт, у вас должно получиться следующее.
Вместо вопросительных знаков пишем имя нашей переменной, например SB, и нажимаем Enter, выходит окно объявление переменной, выбираем Bool и нажимаем OК.
Рассмотрите, какие типы можно выбрать, а также какие классы переменных.
Давайте, реализуем программы для мигания светодиодом, а если говорить в общем, то программа для генератора одиночных импульсов
Для реализации программы используем функциональные блок таймер TP. Таймер TP – этой таймер одиночного импульса с заданной по входу PT длительностью.
Пока IN равен FALSE, выход Q = FALSE, выход ET = 0. При переходе IN в TRUE выход Q устанавливается в TRUE и таймер начинает отсчет времени на выходе ET до достижения длительности, заданной PT. Далее счетчик не увеличивается. Таким образом, выход Q генерирует импульс длительностью PT по фронту входа IN.
Временная диаграмма работы TP:
Для вставки TP, на панели элементов выбираем:
И у нас всплывает ассистент выбора функционального блока.
Скачайте файл проекта, и давайте рассмотрим как он работает.
В начальный момент X= False , поэтому инверсный контакт X замкнут и таймер T2 запущен, выход Q= True, поэтому цепь включена. А так как обмотка в цепи инверсная, значит она копирует инверсное состояние цепи в X , и X остается False, после переполнения таймера Q = False , и инверсная обмотка переводит X в True. После этого запускается T1, после переполнения скидывает X в False и все повторяется. Переменная X является выходом генератора. Таймер T2 устанавливает паузу, а T1 длительность импульса.
Компилируем проект Проект -> Компилировать
В пункте онлайн выбираем Режим эмуляции , а затем Подключение и Старт. И видим, наша схема начинает переключаться, цепь где «протекает ток» выделяется синим цветом. Также в области объявления переменных видим текущее значение переменных.
Выход генератора можно поглядеть с помощью цифрового трассировщика, для этого переходим на вкладку Ресурсы в нижнем левом углу
Выбираем Цифровой трассировщик -> Дополнение -> Настройка трассировки, выйдет следующее окно
Цикличность записи поставим Вручную, нажимаем на менеджер и выбираем переменные X(Bool)
Нажимаем Ok . Выбираем перо для нашей переменной
Выбираем в онлайн Подключение, нажимаем Старт , далее Дополнительно -> Начать трассировку, также выберите пункт Автоматическая трассировка
Рассмотрим еще один пример управление двигателем с электронной коммутацией обмоток статора
Саму программу представлять не буду, скачайте проект. А об алгоритме работы расскажу.
Все таймеры запускаются по сигналу старт. Каждый таймер отмеряет момент окончания фазы. Переменные Y1-Y3 являются выводами соответствующей фазы управления. Каждый выход включается в том случае, если таймер еще не переполнен и выключен предыдущий выход. Последняя цепь, является цепью автоматического перезапуска.
Прикрепленные файлы:
- CodeSys_LD.rar (10 Кб)
Теги:
sulika 
Опубликована: 2012 г. 
0 
Вознаградить Я собрал 0 0
Оценить статью
- Техническая грамотность
Источник: cxem.net
Разработка программного обеспечения для ПЛК путем генерации кода из созданной математической модели объекта управления.
Большинство современных автоматизированных систем управления строится на основе программируемых логических контроллеров (ПЛК), управляющих процессами по заданному алгоритму работы при помощи считывания данных с датчиков и отправки управляющих сигналов на исполнительные устройства. Использование ПЛК позволяет реализовать выполнение достаточно сложных и разветвлённых алгоритмов, а также применять различные способы автоматизации. В частности, во многих системах управления внедрено автоматическое регулирование параметров технологического процессов, которое традиционно осуществляется по законам релейного и ПИД-регулирования [1].
Чаще всего при написании программного обеспечения (ПО) для ПЛК его отладка производится непосредственно на объекте управления. В случае отсутствия или недоступности технологического объекта разработка и отладка ПО усложняется и замедляется, так как разработчику потребуется вручную имитировать данные, приходящие от датчиков, и отслеживать соответствие реакций системы алгоритму её работы на всех этапах процесса [2].
При создании систем со сложными алгоритмами управления и несколькими контурами необходимо гораздо больше ресурсов, особенно времени, для настройки управления и отладки программ, так как необходима проверка множества параметров объекта управления и правильности взаимодействия всех частей системы [3]. Кроме того, отладка ПО сложных систем на реальном объекте может приводит к повреждению оборудования, перерасходу материалов и т. п.
Таким образом, если программное обеспечение разрабатывается для систем управления повышенной алгоритмической сложности или при отсутствии доступа к объекту управления, то целесообразнее создавать имитационную модель быть, объекта управления, которая обеспечивает более быструю и точную отладку программ для ПЛК, исключает риск повреждения оборудования и позволяет сэкономить ресурсы [4].
Моделирование системы можно выполнить непосредственно в среде программирования ПЛК, используя средства языков программирования МЭК 61131-3. Тем не менее, такой способ проблематично использовать при необходимости создания более сложной математической модели, так как отсутствие функциональных блоков многих передаточных функций и ограниченность математического аппарата в системах разработки программ ПЛК значительно усложняют составление точной модели объекта управления [1, 5]. Несмотря на недостатки такого подхода, он остаётся достаточно популярным, так как является доступным и оперативным решением, но используется без построения точных математических моделей, на уровне имитации управляющих сигналов и состояния датчиков (см. рис. 1).
Рисунок 1 – UML-диаграмма моделирования в среде программирования ПЛК
Вторым подходом является создание имитационной модели в среде математического моделирования. Такое решение не является распространённым, так как работа ПО управления технологическим процессом осуществляется на ПЛК, а данный метод затрудняет возможность связи модели объекта с программой управления, работающей на контроллере.
Одним из решений этой проблемы является объединение сред программирования ПЛК и математического моделирования с помощью технологии OPC (Open Platform Communications) [5, 6], предоставляющей универсальный интерфейс для управления объектами автоматизации и обеспечивающей обмен данными между ПК и ПЛК в режиме реального времени (см. рис. 2). Применение такого метода позволяет оценить работу всего алгоритма АСУ ТП и применять изменения при отладке системы как в математической модели, так и в логике ПЛК [5], но это также подразумевает необходимость наличия ПК с математической моделью, запущенной в среде моделирования, и зависимость от корректной работы всех компонентов, используемых в комбинированной системе создания модели. Кроме того, в этом случае процесс организации связи между программой управления и моделью объекта является весьма трудоёмкой задачей, а программа управления требует добавления коммуникационного функционала.
Рисунок 2 – UML-диаграмма моделирования с помощью технологии OPC
В ходе изучения вопроса о повышении эффективности отладки управляющего ПО для ПЛК в Санкт-Петербургском политехническом университете Петра Великого был опробован и проверен метод разработки программного обеспечения в среде моделирования, при котором осуществляется генерация кода для ПЛК из созданной математической модели. Отладка сгенерированного ПО и связь модели с программой управления происходит уже непосредственно в среде программирования ПЛК. Этот способ позволяет воспользоваться преимуществами каждой из сред, применяемой для моделирования системы и проверки её работы [3], избегая необходимости полагаться на надёжность их совместной работы, обеспеченной сторонними решениями, и используя при этом только контроллеры без привлечения ПК. В данном случае модель объекта управления и программа управления находятся на разных ПЛК, связанных между собой с помощью физических сигналов, поэтому система управления не требует дополнительного функционала, обеспечивающего связь с моделью (см. рис. 3).
Рисунок 3 – UML-диаграмма связи системы и объекта управления
Для реализации данного подхода была использована среда моделирования MATLAB Simulink с последующей генерацией в код на языке структурированного текста (ST) при помощи специализированного пакета PLC Coder [7] и дальнейшей работой с программой в среде разработки приложений для ПЛК CoDeSys 3.5.
В качестве технологического объекта моделирования был взят индивидуальный отопительный пункт (ИТП) с водоструйным элеваторным узлом, представленный на рисунке 4. Элеватор необходим для понижения температуры теплоносителя, приходящего с магистралей тепловых сетей. Согласно пункту 6.1.6 СП 60.13330.2016 [8] предельная температура теплоносителя, поступающего в здание, должна составлять 95 °С, в то время как по внешним трубопроводам отопления подаётся теплоноситель температурой до 130 °С‒150 °С. В элеваторном узле смешивается теплоноситель, поданный из тепловой магистрали, с охлажденным, вернувшимся из системы отопления, в результате чего в здание подается теплоноситель, имеющий необходимую температуру.
Рисунок 4 – Схема элеваторного узла: К1 – задвижка, Т1, Т01, Т02 – термометры, ВЭ1 – водоструйный элеватор, G1, G2 – расход теплоносителя в подающем и обратном трубопроводах на вводе (G1 = G2), G3 – расход теплоносителя через перемычку, G0 – расход теплоносителя в системе отопления здания
Структура проекта в CoDeSys
