Kitobni o'qish: «Табличный ПЛК.Табличное программирование контроллеров»

Предисловие

Управление объектами при помощи вычислительных устройств со временем трансформировалось из важного компонента в основную задачу при проектировании различных систем и оборудования. Современные микропроцессоры и контроллеры на их основе помогают реализовать алгоритмы управления как отдельными частями оборудования, так и всей системой, учитывая сложные внутренние связи. Увеличение скорости вычислений и объема памяти контроллеров способствовало созданию сложных программных комплексов, использованию многоуровневых интерфейсов обмена данными.

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

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

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

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

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

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

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

Решение данной проблемы – не новая задача, и в программируемых логических контроллерах (ПЛК) наряду с текстовыми языками программирования применяются графические: LD (Ladder Diagram) – язык релейных схем, FBD (Function Block Diagram) – язык функциональных блоков, SFC (Sequential Function Chart) – язык диаграмм состояний. Они стандартизованы для применения в программируемых контроллерах в МЭК 61131-3¹. Чтобы увидеть графическое отображение работы программы, созданной на одном из этих языков, необходимо подключить к ПЛК компьютер с установленной на нем средой разработки, в которую загружен исходный файл программы. Далее нужно синхронизировать программу в компьютере с программой в ПЛК. И тут возникает множество вопросов, не всегда имеющих адекватные ответы:

– поставляется ли с оборудованием файл исходной программы?

– имеется ли в оперативном доступе компьютер с установленной средой разработки?

– есть ли возможность подключения компьютера к ПЛК?

– необходима ли лицензия на использование среды разработки?

– есть ли вообще специалист, знакомый со средой разработки и умеющий разбираться в программах на перечисленных языках?

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

Из приведенных в пример графических языков у специалиста по информационным технологиям, не знакомого с ПЛК, только язык диаграмм состояний может не вызвать вопросов. Для небольших алгоритмов достаточно прост и понятен язык релейных схем LD, но программы с большим количеством блоков, написанные на нем, могут вызвать серьезные затруднения. Язык функциональных блоков FBD похож на принципиальную схему электронного устройства на логических микросхемах и более понятен специалистам по электронике, чем программистам.

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

Языки, входящие в стандарт МЭК 61131–3, упорядочивают процесс разработки программ и снижают затраты на их перенос с контроллера на контроллер разных производителей. Специалист, освоивший стандартные языки программирования контроллеров, сможет разобраться в прикладных программах ПЛК разных производителей, но для поиска неисправностей еще необходимо знание особенностей контролируемого процесса и алгоритма работы, осуществляемого при помощи данного оборудования. К примеру, специалист, разбирающийся только в работе вентиляционной системы, скорее всего, не сможет быстро перейти на обслуживание газовых турбин или грузоподъемного оборудования, хотя язык программирования в этих системах будет использоваться один и тот же.

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

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

Во-вторых, необходимо иметь однозначную информацию о назначении входных и выходных сигналов. Так как функция программируемого контроллера, управляющего оборудованием, – формировать выходные сигналы и данные, то специалисту по ремонту необходима информация о том, как это происходит, причем представленная в простом и понятном виде.

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

Теперь стоит задаться вопросом о том, как эта информация может быть доведена до пользователя и воспринята им. И здесь пора отойти от оборудования и алгоритмов его работы и рассмотреть уже сложившиеся способы донесения информации.

1. Введение в табличное программирование контроллеров

1.1. Почему таблица?

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

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

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

Появление Microsoft Excel версии 3.0 и выше отодвинуло существовавшие на то время программы электронных таблиц других производителей на задний план. Хотя необходимо отметить, что электронная таблица Quattro Pro 9, входящая в Corel Word Perfect Office 2000, по своим возможностям не уступала аналогичной версии Microsoft Excel, но к этому времени MS Excel фактически стал стандартом. Особенно порадовала функция заморозки части таблицы, как по вертикали, так и по горизонтали – это позволило работать с довольно большими таблицами, используя замороженную часть как многострочный заголовок с возможностью видеть большое количество вычисляемых параметров. К примеру, таблица прихода и расхода комплектующих в MS Excel была сделана за пару часов и учитывала жизненный цикл каждой партии товара. Недостаток таких решений, состоящий в невысокой защищенности данных от случайных изменений, с лихвой покрывался скоростью получения интересующей информации и ее наглядностью.

Вообще материал, представленный в виде таблицы, легко воспринимается и анализируется человеком. Горизонтальные и вертикальные связи не затрудняют восприятие, а наоборот, облегчают его. Достаточно беглого взгляда на товарный ценник, составленный в виде таблицы, чтобы понять, сколько представлено товарных позиций и какой у них диапазон цен. Мы непрерывно тренируемся в скоростном восприятии информации, представленной в виде таблиц. Календари, расписания, товарные чеки, окно с файлами на экране компьютера – не что иное, как таблицы, отформатированные особым образом. Даже арифметические вычисления в столбик в тетрадке в клеточку прививают нам способность быстрого анализа табличных данных. Остается вопрос, как применить эту замечательную способность человека к решению рассматриваемой задачи – программированию контроллера, управляющего оборудованием.

Для решения большинства проблем, связанных с отображением внутреннего состояния управляющей техническим объектом программы, предлагается выводить ее текущие параметры в виде специальной таблицы на экран монитора или сенсорного дисплея удобного размера. Таблица с внутренним состоянием контроллера может находиться в одной из закладок монитора, на который в обычном режиме выводится информация о контролируемом процессе или другие необходимые данные. Специалисту, программирующему контроллер, не нужно создавать таблицу и организовывать отображение данных, таблица и является программой. Кроме данных в ее ячейках, нет никаких дополнительных блоков или файлов. Она же, по сути, и графический интерфейс между машиной и человеком. В ней мы видим состояние всех переменных. От программиста скрыт только код, пересчитывающий данные в ячейках. И самое главное, таблица является средством разработки программы контроллера. Отпадает необходимость в сложной и дорогостоящей среде для написания и отладки программ, загружаемых в контроллеры.

Так как отсутствует многоуровневое меню, с помощью которого можно изменять параметры, и на экран выводится одна-единственная таблица, отображающая весь процесс, то многократно сокращается время обучения программированию контроллеров. Может сложиться впечатление, что такая таблица будет иметь тысячи строк и столбцов, но это на самом деле далеко не так. Например, программа управления портальным краном, имеющим две лебедки, стреловой, поворотный механизмы и систему передвижения, содержит 180 строк и 30 столбцов. Простые программы управления небольшими объектами часто не нуждаются в прокрутке строк или столбцов, помещаясь на экране целиком.

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

1.2. Основы табличного программирования

Для начала рассмотрим таблицу, показанную на рис. 1. Нумерованные строки таблицы отвечают за входы контроллера, а нумерованные столбцы – за выходы. Состояние каждого входа контроллера описывается входной переменной, которая получает значение, равное логическому уровню на соответствующем ей входе. А логические уровни на выходах контроллера получают значения своих выходных переменных. Состояние каждой выходной переменной будем определять как логическое И в столбце под ней. Чтобы задать зависимость выходной переменной от нескольких входных переменных, продублируем значения входных переменных в ячейки под выходной переменной.

В приведенном примере состояние выходной переменной 2 будет равно логическому И входных переменных 1 и 4. Так как результат логического И равен единице, то на выходном контакте 12 будет высокий логический уровень.

Рис. 1. Пример таблицы

Чтобы таблица стала программой, внесем в нее некоторые изменения. Ячейки в теле таблицы, участвующие в расчете выходных значений, будем называть активными ячейками. Для их обозначения используем символ &, который в электронике и программировании обычно является символом битовой операции «логическое И». Чтобы увеличить наглядность таблицы, активные ячейки, состояние которых равно нолю, выделим синим цветом, а ячейки, состояние которых равно единице, – зеленым. Таким же образом обозначим результат логического И по столбцу. Простая табличная программа представлена на рис. 2.

Рис. 2. Пример простой табличной программы

Пересчет таблицы выполняется следующим образом. Сначала идет обработка строк сверху вниз. Значение в каждой строке определяется входной переменной. В данном случае оно соответствует логическому уровню на соответствующем входе контроллера. При наличии в строке активных ячеек всем им присваивается полученное значение. По окончании перебора строк вычисляются значения выходных переменных – как логическое И по ячейкам столбца под каждой выходной переменой. В этом виде данные в таблице сложно назвать программой, однако под определение программы по ГОСТ 19.781–90² – «данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма» – она подходит.

Чтобы написать или создать программу, в такой таблице сначала нужно заполнить первый столбец именами входных переменных или комментариями к ним и указать соответствующие номера входных контактов контроллера. Затем заполнить верхнюю строку-заголовок именами выходных переменных, также добавив номера контактов, соответствующие выходам контроллера. Теперь остается ввести в ячейки, которые будут участвовать в формировании выходных значений, символ &. В принципе все, программа написана.

В результате поисков удобного формата таблицы, который бы легко воспринимался специалистом, не писавшим программу, из всех возможных операций в столбце было оставлено только логическое И. Это сделано для удобства быстрого анализа состояния программы в таблице. Если в столбце хоть одна активная ячейка принимает значение ноль, то результат тоже будет ноль. Если все активные ячейки столбца будут равны единице, то выходная переменная над столбцом также будет равна единице. Выделение синим цветом ячеек, находящихся в состоянии «Ноль», и зеленым цветом ячеек в состоянии «Единица» помогает увидеть всю картину целиком, быстро найти ячейки, цвет которых не соответствует ожиданиям.