Системы автоматизации и управления технологическими процессами
Методическое пособие - Разное
Другие методички по предмету Разное
? освобождает деталь, и она выходит из-под пресса.
Процесс продолжается, если выбран автоматический (циклический) режим, иначе останавливается. Вот как выглядит блок-схема последовательности описанных выше операций. Разбиение программы на логические блоки
Рисунок 5.3 - Блок схема программы управления конвейером
Для определенности дальнейшего описания, поставим в соответствие каждому сигналу нашего примера Х-образ дискретного ввода и Y-прообраз дискретного вывода:
Таблица 5.1
СИГНАЛИЗАЦИЯУПРАВЛЕНИЕКнопка пускаХ0Зажимное устройствоY0Датчик наличия детали под прессомХ1ПрессY1Концевик фиксации заготовкиХ2Движение конвейераY2Концевик освобождения деталиХ3Нижний концевик прессаХ4Верхний концевик прессаХ5Шаг конвейераХ6Переключатель режимаХ7Кнопка остановаХ8
Решение на языке LD
До появления программируемых логических контроллеров (ПЛК) проблемы управления решались с помощью реле и переключателей, жестко соединенных в релейно-контактные схемы. Более 30 лет назад стали искать способ, позволяющий легко и быстро вносить изменения, в логику управления не меняя монтажа. Так появились ПЛК. Разработчика "новой" технологии были хорошо знакомы с решением задач управления с помощью реле и переключателей, поэтому имело смысл имитировать релейно-контактные схемы в созданном специально для ПЛК языке программирования LD. Вот почему программы на LD похожи на релейно-контактные схемы.
На рисунок 5.4 показан пример части программы на LD, реализующей управление по алгоритму, описанному на предыдущей странице.
Рисунок 5.4 - Пример программы на языке LD
Вертикальная линия слева символизирует шину питания, а положение контактов и состояния обмоток реле определяют происходящие действия, которые в релейно-контактных схемах принято называть блокировками. Здесь хорошо просматриваются отдельные цепи контактов, подающие питание на обмотки реле - ступени. Программа на LD, имитирующая релейно-контактную схему, "просматривает" контакты и обмотки каждой ступени слева направо, а сами ступени сверху вниз. Это нормальный порядок действий в LD. Программа на LD в графическом представлении выглядит как ступени своеобразной лестницы, ведущей вниз. Нетрудно видеть, что "контакты реле" (нормально замкнутые и разомкнутые) фактически означают не только сами контакты, но и некоторые логические условия, при выполнении которых на каждой "ступеньке лестницы" происходит некоторое действие. После этого производится переход к следующей ступени вниз.
Говоря о современных инструментальных средствах, следует сразу же отметить важнейшую тенденцию: наиболее перспективными являются интуитивно-понятные разработчику средства визуального проектирования. В любой предметной области, в том числе и в автоматике, визуальные средства предполагают, что проектировщик (или пользователь) не должен писать практически никакого кода программы ни на одном из языков программирования.
Вместо этого он производит размещение тех или иных наглядных графических образов (обычно пиктограмм) на рабочем поле. Эти образы представляют собой отображение некоторых стандартных блоков, алгоритмов, устройств. Соединяя эти образы в соответствии с требуемой структурой, и задавая свойства отдельных компонент, пользователь быстро получает требуемое представление своей системы.
Инструментальные средства разработки, отладки и сопровождения программного обеспечения
Практически избежать программирования удаётся за счёт объектно-ориентированного характера такой модели, при котором необходимые коды программ уже инкапсулированы в стандартных блоках. То есть программирование заменяется заданием параметров (обычно числовых) в стандартных алгоритмах. Многочисленные преимущества такого подхода очевидны. Более того, большинство современных, в том числе и профессиональных, программных комплексов в различных областях техники, обработки изображений, звука и т.п. созданы именно в этом виде. Сложнейшие, но стандартные процедуры, при этом легко реализуются.
Возникает возможность использования опыта (программного кода) предыдущих разработчиков без его изучения. Фирмы - производители систем автоматизации предоставляют огромные библиотеки таких функций (классов), и создаётся обманчивое впечатление, что программирование вообще не нужно, что кто-то сторонний всё сделает за специалиста по автоматике. Это мнение старательно поддерживается и фирмами-производителями. Но именно здесь заключается и слабая сторона такого подхода. Реально имеются две негативные стороны использования стандартных библиотек функций (классов):
закрытость исходных кодов (и в смысле недоступности, и в том смысле, что пользователь не заинтересован глубоко разбираться в чужих кодах);
неоптимальность кодов именно для той конкретной ситуации, в которой находится данный разработчик системы автоматики ("универсальное - значит не оптимальное").
Эти два пункта реально приводят к тому, что пользователь - разработчик автоматической системы не может гарантировать надёжность работы всей системы, так как в неё входят закрытые компоненты, и не может гарантировать оптимальности в смысле быстродействия работы критичных к этому параметру частей системы. Таким образом, чисто визуальные методы программирования ограниченно пригодны в случае хорошо известных задач, не критичных, кроме того, к быстродействию и надёжности всей системы.
Не следует думать, чт