Руководства по программированию контроллеров delta

Руководство по программированию DVP

Время на прочтение
9 мин

Количество просмотров 6.3K

Промышленный логический контроллер (ПЛК) — это тот же компьютер, но попроще. В нем есть все или почти все, что есть в любом ПК, но только, может,  в меньшем объеме или не такой производительности. Но зато он может работать там, где обычный компьютер неприменим. У ПЛК есть то, что делает работу с ним проще при управлении оборудованием.  Например,  наличие «на борту» каналов ввода/вывода дискретных логических сигналов. Его программирование специфично. Выбор языков программирования достаточно ограничен, по  большому счету их всего-то пять, и определяется стандартом МЭК 61131-3 [1]. И этого, как убеждает практика, по большому счету вполне достаточно.

Выбор ПЛК фирмы DELTA, кроме наличия собственной IDE, предоставляет доступ к широкому перечню периферийного оборудования. Фирменное ПО, как минимум, удобнее тем, что не требует особой настройки и «в один клик» работает на всей линейке технических средств фирмы. Минусы могут проявиться в отставании от передовых тенденций программирования. Но для ПЛК это не самая большая проблема, т.к. языки, определяемые стандартом, достаточно консервативны, а их настройка под разные типы ПЛК, как правило, не так уж сложна.

Можно даже утверждать, что тип ПЛК достаточно условен, т.к. программирование при наличии промышленного стандарта для них фактически неотличимо (различие в IDE пока не рассматриваем). По крайней мере, сам стандарт на это настраивает. Нам же далее будет важнее реализация определенной идеи. И если уж, как мы увидим,  с этим справится столь элементарный язык программирования, как язык релейно-контактных диаграмм, то это будет вполне по силам и любому другому языку программирования для ПЛК.  И уж тем более по плечу почти любому из известных языков для ПК. 

Краткое введение в IDE

Установка IDE фирмы DELTA ISPSoft не требует от программиста каких-либо усилий. Установив ее, выберем из всего множества [стандартных] языков язык релейно-контактных схем (LD) и функциональных блоков (FB). На рис. 1 приведен пример проекта в среде ISPSoft.

В рамках программного проекта IDE код ПЛК разбивается на программные модули – POU (Program Organization Units), которые могут быть трех типов.

1. Программа – PROG (в IDE модуль имеет пометку PRG).

2. Функциональный блок — FB.

3. Функция — FC.

Дерево проекта содержит типовые узлы, среди которых Программы и Функциональные блоки для нас представляют наибольший интерес. Узел Программы содержит исполняемые модули типа PRG (тип программного модуля и язык, на котором он реализован, указаны правее имени модуля в дереве проекта). Программные модули узла Программы содержат исполняемый программный код и запускаются последовательно сверху вниз. Есть несколько режимов работы, на которые можно настроить их работу. Это циклическое исполнение модуля, запуск его по времени, и по прерыванию.

Каждый из программных модулей  разбивается на Цепи или Командные строки (Network), где каждая строка представляют код на языке LD. Он включает и программный вызов функциональных блоков на языке FB. Цепи исполняются сверху вниз, а код в пределах цепи – слева направо. И эта та специфика, которая кардинально отличает работу «программной схемы» от аналогичной по виду электронной схемы, элементы которой работают параллельно. И наша задача эту специфику, если не устранить, то хотя бы в чем-то смягчить.

Описанная выше структурная организация программ ПЛК, как и сам язык программирования LD, будут непривычны для программиста, знакомого с обычными языками программирования. Хотя на самом деле принципиальной разницы между ними нет. Особенно с учетом описанной специфики работы программных модулей и кода внутри них. Ведь, и там и там речь идет фактически об обычном последовательном программировании лишь с разной формой,  в общем-то, типичных операторов. А если учесть, что язык LD включает операторы типа пересылки данных, сравнения, вызова функциональных блоков и т.п., то такая связь становится еще очевиднее.

Однако, если окунуться в историю создания и развития ПЛК, то их языки программирования изначально были рассчитаны на технических специалистов, далеких от программирования. Другими словами, специалист, который знает, что такое реле, должен был уметь программировать, используя понятные ему вещи. И здесь таится тот когнитивный диссонанс, преследующий программиста под ПЛК слабо разбирающегося в программировании, но прекрасно понимающего работу электронных схем. Поэтому надо понимать то удивление или непонимание, которое может у него возникнуть при сравнении результатов работы программы для ПЛК и аналогичной ей электронной схемы (предположим, что в идеале и то и другое состоит из одних только реле).

Причина отмеченного выше противоречия достаточно очевидна: компоненты программы ПЛК работают последовательно, а компоненты электронной схемы – параллельно. Можно ли устранить эту разницу и, если можно, то как? Ответ следующий: пусть не полностью, но можно. И поможет нам в реализации этого автоматная модель программ и технология автоматного программирования (теоретическое обоснование его представлено в предыдущей моей статье [3]).

Теория – это, конечно, правильно и хорошо, но вопрос, как ее реализовать, используя достаточно скромные возможности [последовательных] языков программирования для ПЛК? И поскольку «лучше раз увидеть, чем сто раз услышать»  рассмотрим для этого программную реализацию RS-триггера на ПЛК. Его модель, как и автоматные модели отдельного элемента И-НЕ и всего триггера, приведены в упомянутой выше статье.

Реализация RS-триггера

Пример проекта реализации модели RS-триггера приведен на рис. 2. Он содержит  три программных модуля. Это два модуля типа PRG – RS_триггер и CopyStates и один типа FB – И-НЕ. 

В модуле RS_триггер первые две цепи просто инвертируют два установочных входных сигнала триггера. Инвертирование необходимо, чтобы в исходном состоянии они были в единичном состоянии (кнопки, имитирующие соответствующие сигналы, отжаты). Так триггер фиксируется в неком установившемся состоянии и при этом не нужно будет держать кнопки, имитирующие сигналы, в нажатом состоянии.  Переменные bX1 и bX2 будут внутренними локальными переменными, зависящими от состояния внешних входных сигналов ПЛК, соответственно сигналов от кнопок X1 и X2.  

На рис.3. приведена реализация программного модуля CopyStates. Его функция – на каждом цикле работы ПЛК копировать массив слов с именем awTempStates в массив с именем awStates. Эти массивы содержат сопоставленные друг другу теневые и текущие состояния программных автоматов. Каждому автомату соответствует один элемент массива текущих состояний и сопоставленный ему (с таким же номером) элемент массива теневых состояний. Каждый автомат в процессе функционирования воспринимает элемент массива текущих состояний (это и есть его текущее состояние), и устанавливает в ситуации перехода значение следующего состояния, помещая его значение в элемент массива теневых состояний. Вот собственно и весь механизм реализации функции переходов отдельного автомата и множества параллельных переходов автоматов некой автоматной сети.

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

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

Описанный процесс реализации функций переходов и выходов происходит последовательно во всех автоматах проекта. И только после этого массив теневых состояний копируется в массив текущих состояний. Это и реализует как раз модуль CopyStates. Далее этот цикл повторяется.

Реализация модели элемента И-НЕ

 Модель элемента И-НЕ реализована в форме функционального блока (FB). Его программная реализация на языке LD приведена на рис. 4. Переменные, назначенные функциональному блоку, представлены на рис. 5 (на рис. 4 они скрыты).

Любой FB может иметь переменные нескольких типов: локальные переменные – тип VAR,  входные переменные — VAR_INPUT, выходные – VAR_OUTPUT и их совмещенный тип – VAR_IN_OUT. Наша программная реализация элемента И-НЕ имеет только входные и выходные переменные. На диаграмме они представлены входными/выходными линиями соответствующих FB (см. FB с именами И_НЕ1, И_НЕ2 рис. 2). Таким образом, функциональные блоки представляют собой некий аналог, близкий понятию подпрограммы с параметрами в форме его входных и выходных каналов.

Цепь 1 (Network 1) в реализации модели элемента выполняет стандартную операцию для любого функционального блока в автоматной форме. Она устанавливает автомат в исходное состояние по сигналу сброса – bClear или при установке системной переменной M1002, принимающей однократно на один цикл работы ПЛК единичное значение при включении  ПЛК.

Тестирование и эксперименты

После записи программы в ПЛК она начинает свою работу, сразу входя в режим генерации. Это процесс отражают светодиоды выходов Y1, Y2. Нажатие кнопок установочных входов, приводит модель в то или иное устойчивое состояние. Ввести модель в режим генерации можно, нажав кнопку сброса – X2 (см. рис.2). И это то, что ожидалось от поведения данной модели в данной ситуации. Если генерация наступает, то можно говорить о верной реализации модели, которая правильно отражает поведение реального триггера.

С другой стороны, возможна также следующая реализация модели триггера, которая представлена на рис. 6. И отличие-то, вроде, при этом не очень существенное – просто перенесли установку выходного сигнала непосредственно в цепи, реализующие переходы, устранив в целях экономии две цепи. Но … поведение модели изменилось. Теперь она не входит в режим генерации.

В чем дело? А дело в привязке выходных каналов к состояниям модели. В первом случае так мы поступили, создав модель по типу автомата Мура. В ней выходной сигнал изменит свое значение, только при смене текущего состояния. В последнем варианте выходной сигнал реализован по типу автомата Мили и изменяется раньше — в процессе реализации перехода, т.е. до смены текущего состояния модели (оно на этот момент еще находится в теневом массиве состояний).  И именно это фатальным образом сказывается на поведении модели. Но, заметим, если бы был реализован механизм теневой памяти (см. [3]), то поведение модели не зависело бы от выбранного типа автомата.

Наверняка найдутся программисты, у которых автоматное программирование вызывает явное неприятие. И вот только для них мы разработали еще один вариант, который представлен на рис. 7. Глядя на него можно понять их чувства.  Но, господа-товарищи, что нам важнее – красивый код или верная его работа? Анализ результатов тестирования приведенных выше двух реализаций придает этому вопросу уже риторическую окраску.

Проектирование первой версии триггера, безусловно, займет больше времени. Но, во-первых, с увеличением сложности создание автоматной модели, наоборот, уменьшает время проектирования. И должно привлекать не время, а качество проектирования.  Оно иное, т.к. в противном случае теория автоматов потеряла бы смысл своего существования. Во-вторых, потратив больше времени на разработку модели, мы можем применять ее как компоненту более сложных проектов, будучи уверенными в результатах ее работы. В-третьих, становится возможным качественно иное документирование проектов, т.к. автоматная форма более компактна и информативна, чем блок-схемное сопровождение программных проектов. И в последнем случае нам в помощь будет положительный опыт использования UML [4].

Вместо заключения

Хотелось бы, заключая статью, продолжить жизнеутверждающую тему предыдущего раздела, но … не получается. А все дело в том, что захотелось получить визуальные подтверждения генерации триггера. И вот с этим-то, как раз,  и возникли проблемы… Чтобы однозначно убедиться, что триггер входит в режим генерации, нужно было просто замедлить его работу. И затем по результатам индикации (в нашем случае это светодиоды Y1, Y2) получить наглядное подтверждение, казалось бы,  очевидного. Но как это сделать, не изменяя его код?

В ПЛК скорость работы программ зависит от длительностью цикла ПЛК. А он зависит от общего времени последовательной работы программных модулей, находящихся в папке Программы проекта (см. рис.1). Добавляем еще один модуль. В него вставляем уже программный цикл (в ПЛК это будут цепи между командами FOR и NEXT). Смотрим на результаты и … видим, что к нашему удивлению, светодиоды не одновременно загораются/гаснут, а в некой очередности. При этом, что еще больше поражает, сама генерация протекает, пусть и большими задержками, но исправно.

Не буду утомлять предположениями, версиями и т.п. После вынужденного (в целях выяснения проблемы) создания транспортной/инерционной задержки (подробнее о ней см. [3]), после «камлания» с длительностью цикл в добавленном модуле выяснилось, что, похоже, проблема именно в длительности цикла ПЛК. Но как быть с ней? Тоже не сложно. Избегайте операторов FOR-NEXT. А в ситуации, когда нужен все же программный цикл?! Создайте автоматный алгоритм, как это описано выше. В них эти операторы не нужны и потому длительность цикла работы самого ПЛК не будет фатально от них зависеть.   

Т.е. мы разобрались с причиной проблемы, так сказать, вывернулись, т.к. теперь понятно, что и как делать, чтобы ее не было. Другими словами, несмотря ни на что, нормальное заключение, кажется, все же получилось… Благодаря все тем же автоматам. Вот, как все просто! Особенно когда знаешь про автоматы…

Литература

1.      Рылов С. Языки программирования стандарта МЭК 61131-3. [Электронный ресурс], Режим  доступа: https://finestart.school/media/programming_languages, свободный. Яз. рус. (дата обращения 18.07.2022).

2.      Серия AS. Руководство по программированию. [Электронный ресурс], Режим  доступа: https://deltronics.ru/images/manual/AS_PrM_RU_[112018].pdf, свободный. Яз. рус. (дата обращения 18.08.2022).

3.      АВТОМАТНОЕ ПРОГРАММИРОВАНИЕ: ОПРЕДЕЛЕНИЕ, МОДЕЛЬ, РЕАЛИЗАЦИЯ.  https://habr.com/ru/post/682422/

4.      Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя. Второе издание. Академия АЙТИ: Москва, 2007. – 493 с.

Базовые серии

	Программируемые контроллеры AH500 Высокопроизводительный ПЛК среднего уровня…
	Программируемые контроллеры AS200 | AS300 Высокопроизводительный ПЛК модульного типа…
	Программируемые контроллеры DVP-SX2 2-ое поколение компактных ПЛК со встроенными аналоговыми входов/выходов…
	Программируемые контроллеры DVP-SS2 2-е поколение компактных ПЛК стандартной серии…
	Программируемые контроллеры DVP-ES2/EX2 Стандартный ПЛК для простых применений…
	Программируемые контроллеры DVP-ES3 Высокопроизводительный контроллер серии DVP…
	Программируемые контроллеры DVP-PM Специализированный ПЛК блочного типа для управления движением…
	Программируемые контроллеры DVP-SA2 2-е поколение компактных ПЛК с расширенными возможностями…
	Программируемые контроллеры DVP-SE Компактный ПЛК с сетевыми возможностями…
	Программируемые контроллеры DVP-SV2 Высокопроизводительный компактный ПЛК с двумя шинами расширения…
	Программируемые контроллеры DVP-EC3 Экономичный, не расширяемый контроллер для цикловой автоматики…
	Программируемые контроллеры DVP-MC Сетевой контроллер движения 2-ого поколения…
	Программируемые контроллеры DVP-TK Модульные термоконтроллеры DVP…
	Руководство по программированию DVP 2-е издание книги SS2 | SA2 | SX2 | ES2 | EX2 | SE…

Программируемые логические контроллеры Delta DVP способны обеспечить высокоскоростную, устойчивую и надежную работу при применении во всех видах промышленного оборудования. В дополнение к высокой скорости выполнения логических операций, большому количеству прикладных инструкций, многофункциональным картам расширения и высокой ценовой рентабельности контроллеры DVP поддерживают большое количество коммуникационных протоколов, позволяющих интегрировать их практически в любую промышленную сеть.