Программирование для автоматизированного оборудования
Программирование для автоматизированного оборудования: основные понятия
Программирование – это процесс создания компьютерной программы.
В число основных понятий, относящихся к программированию автоматизированного оборудования, входят следующие понятия:
- Управляющая программа, представляющая собой совокупность команд на языке программирования, которая соответствует заданному алгоритму функционирования оборудования.
- Числовое программное управление — управление процессом обработки заготовки в соответствии с управляющей программой. В данном случае данные управляющей программы заданы в цифровой форме.
- Позиционное управление — числовое программное управление, в случае которого рабочие органы технологического оборудования перемещаются в заданные точки, но при этом траектории перемещения не задаются.
- Контурное управление — числовое программное управление, при котором рабочие органы оборудования перемещаются с заданной скоростью и по заданной траектории, с целью получения необходимого контура обработки.
- Адаптивное управление — числовое программное управление, при котором обеспечивается автоматическое приспособление процесса обработки к изменяющимся условиям.
- Групповое управление — числовое программное управление, при котором группа станков управляется одной электронно-вычислительной машиной.
- Ручная подготовка управляющей программы. В данном случае подготовка управляющей программы осуществляется практически без применения электронно-вычислительной машины.
- Автоматизированная подготовка управляющей программы. В данном случае управляющая программа подготавливается и контролируется при помощи электронно-вычислительной машины.
- Программоноситель — носитель данных, на котором записывается управляющая программа.
Подготовка управляющей программы для автоматизированного оборудования
Подготовка управляющей программы может рассматриваться как процесс передачи и преобразования данных в системе «чертеж — готовая деталь».
Система «чертеж – деталь» — это совокупность технических процессов и средств, которые направлены на преобразование информации чертежа в материальную деталь, которая соответствует техническим требованиям и ряду технико-экономических показателей.
С точки зрения преобразования данных при подготовке управляющей программы для автоматизированного оборудования (например, станков с числовым программным управлением) в системе «чертеж – деталь» содержатся следующие подсистемы: технологическая подготовка, математические расчеты, изготовление и контроль управляющей программы, внедрение процесса обработки согласно управляющей программе.
Подсистема технологической подготовки состоит из следующих этапов: подготовка исходных данных для проектирования технологического процесса изготовления детали, разработка маршрута, проектирование операционной технологии изготовления детали. На первом этапе проводится технико-экономический анализ целесообразности изготовления детали на оборудовании, выбирается конкретное оборудование на основе определенных усилий. В результате проводится анализ технологичности детали по чертежу, разрабатывается более крупный план обработки. В результате второго этапа определяется операционная последовательность обработки детали, а также выбирается комплекс инструментов. На третьем этапе разрабатывается подробный план каждой операции обработки, строятся траектории перемещений рабочих органов, составляется расчетно-технологическая карта.
Математические расчеты состоят из двух этапов: расчет траекторий перемещения рабочих органов во время обработки и кодирование управляющей программы. Первый этап состоит из расчета координат опорных точек эквидистант при реализации линейной и круговой интерполяции с заданными шагами аппроксимации в ранее выбранной системе координат. Также проводятся расчеты времени перемещений и величин перемещений. На этапе кодирования осуществляются перевод расчетных параметров в координатную систему оборудования; использование в управляющей программе конкретных технических характеристик оборудования; использование в управляющей программе подготовительных и вспомогательных функций оборудования.
Подсистема изготовления и контроля управляющих программ состоит из контроля управляющей программы вне оборудования и записи управляющей программы на программоноситель. Проверка программы управления осуществляется визуально с использованием графопостроителей, дисплеев и т. п. Затем изготавливается программоноситель. Подсистема внедрения управляющей программы состоит из отработки программы на оборудовании без установки, обработки контрольной детали.
Мой путь в пром. автоматизацию. Инженер-программист АСУТП
Итак, не так давно был пост Замкнутый круг — Siemens вокруг! не думал, что оставленный мною комментарий приведет к появлению у меня подписчиков и интересу к вопросу как стать программистом АСУТП.
Опишу вкратце саму специальность, обязанности и как я к этому пришел. Будет много текста.
Что делает любой программист? Правильно — программирует. И на этом можно было бы окончить описание, но не все так просто. Начнем.
АСУТП — автоматизированные системы управления технологическим процессом. Из расшифровки аббревиатуры уже можно понять, что задача инженера по автоматизации — создание программного продукта, который упрощает жизнь в первую очередь оператору механизма, который нужно автоматизировать (чаще происходит наоборот, так как не все хотят учить новое и упираются нововведениям всеми силами).
Обязанности могут быть самые разнообразные. В небольших компаниях инженер-программист может проектировать электрические схемы для автоматизируемого устройства, а затем и писать программу. В более крупных компания только программирование. Работал в компании где было 10 человек, не считая монтажников и в компании, где было свыше 200 сотрудников. Всегда будут командировки — вы будете участвовать в пуско-наладочных работах. Это если из основного. Не удивляйтесь и ситуации когда программист будет с отверткой что-то ковырять в щите управления чем-либо, отсюда следует, что вы обязаны уметь читать и при необходимости изменять электрические схемы, знать технику безопасности и ПУЭ ваша настольная книга. Иногда меня хотели заставить что-то изменить в силовой части подключения, но я этого не делал как бы косо на меня не смотрели электрики/монтажники. А вот объясню почему, на всех фирмах, где я работал у меня не было допуска по электробезопасности, а отсюда следует, что я вообще не должен лезть туда, где есть напряжение. Так что нет допуска — нет и каких-либо изменений схемах шкафа управления.
Часто бывает, что изначальная схема и то, что собрано по факту на объекте отличается. Причины могут быть разные — экономия (купили дешевле оборудование, решили поставить, что на складе нашлось, кто-то откат получил и т.д.). Задача программиста, который приехал на пуско-наладку подружить это все и заставить работать. Иногда это бывает очень непросто. Но про это будет позже, сначала необходима программа, а потом уже запуск объекта.
В общем выполнение работ по автоматизации проходит следующие стадии (упрощенно, на самом деле все немного сложнее):
1. Если участвуют несколько отделов в реализации проекта, то, когда приходит запрос из отдела продаж, каждый отдел предоставляет часы, которые потратит специалист на реализацию своей части. Далее это все суммируется и возвращается в отдел продаж. Они офигевают и ообычно на этом этапе уменьшаются часы, заложенные различными заинтересованными отделами, ибо дорого, и нужно продать. Ненавижу за это «продажников», хотя и понимаю, что это бизнес. Чтобы было понятно, в компании, где было больше 200 сотрудников были: департамент проектирования, департамент разработки ПО, департамент пуско-наладочных работ. И каждое подразделения выдавало кол-во часов на этот проект, необходимое для выполнения их части работ. И как итог выиграли тендер (если повезло, не будем говорить про остальные схемы).
2. На этом этапе обычно пишется ТЗ (технологическое задание) программистом на автоматизацию, хотя должно быть наоборот, заказчик должен предоставить описание того, что он хочет получить. Но у меня было так, как описываю. Дальше это ТЗ долго и нудно согласовывается с заказчиком, вносятся правки, ставятся подписи. Хотя это совсем не гарантия того, что ТЗ останется неизменным. Правки могут прийти, когда до начала пуско-наладочных осталось совсем немного времени, но почти всегда фирма-исполнитель прогибается под заказчика и программист потом в панике вносит изменения, что приводит к тому, что ПО будет не протестировано до конца, что приводит к задержкам при вводе в эксплуатацию и т.д. Но никого это обычно не волнует, хоть спи на объекте, но оно должно работать.
3. Когда есть ТЗ начинается, собственно, и реализация/придумывание того, как же оно все должно работать. Помимо программы для контроллера (ПЛК — программируемый логический контроллер) иногда нужно сделать и визуализацию. Для визуализации, в зависимости от поставленных целей применяется SCADA или HMI. В чем отличия отлично гуглится (статья и так уже огромная, сам не ожидал).
4. Тестирование программы на стенде или в симуляторах. Отлично работающая программа в симуляторе не равно иногда даже работающей на «живом объекте».
5. И самый интересный момент — это пуско-наладка (ПН). Об этом напишу подробнее.
Итак, что должен делать инженер во время ПН. Для удобства разделю на этапы.
1. I/O check проверка правильности подключения всех входов/выходов ПЛК (программируемый логический контроллер). И если что-то неправильно – то исправление. На данном этапе никакого ручного управления, не говоря уже про автоматизацию нет. Просто в контроллере можно жестко активировать выход и посмотреть, тот ли механизм включился. С входами проще, бегаешь вокруг механизма и тыкаешь кнопки, замыкаешь вручную концевые выключатели и смотришь, соответствует ли это тому, что ты заложил в программу. Для тех, кто не в теме, каждый контроллер имеет входа и выхода. Входа используются для сбора данных с механизма (всякого рода датчики, кнопки и т.д.). Выхода же нужны для управления устройством, например включить двигатель, закрыть задвижку и т.д. Это если очень упрощенно и не вдаваясь в подробности.
2. Если предыдущий этап закончился успешно и все собрано правильно (на более-менее больших объектах с первого раза никогда все правильно собрано не будет) – то приступаем к проверке в ручном режиме. Для этого либо со SCADA либо HMI включаем/выключаем узел агрегата и смотрим все ли правильно работает и все ли правильно отображается. Часто бывают ошибки (если используется визуализация) в привязках переменных к объекту на визуализации. Например, запустили один механизм, а на панели/скаде отображается, что включился другой, хотя работает правильный ну и т.д. Эти ошибки сразу же исправляются и процесс проверки продолжается.
3. Когда закончили ручное тестирование – переходим к самому сложному и интересному (вот тут симулятор, если тестировалась программа на нем, и дает прикурить иногда). Автоматический режим. Ну с ним все ясно, перевели все механизмы в автомат и запустили объект.
С этим режимом всегда могут быть проблемы. И когда вы пишете программу нужно учитывать максимально возможные варианты. Например, на двигателе перестал работать датчик температуры и из-за этого запускать этот узел в автоматическом режиме нельзя (ведь датчик не просто так там установлен), но если этот узел нельзя запустить в автомате, то и остальные по идее тоже нельзя, так как в автоматическом режиме реализовываются блокировки, которые отключат механизм при неисправности. Неисправность одного узла не дает запустить другой от него зависящий ну и т.д. И теперь нужно ждать пока починят неисправность, а производство в это время стоит. И владелец кричит какие в обще все, хм, хорошие люди. Но обычно так не делается. Почти всегда есть возможность запустить все в автомате, даже если какой-то из узлов агрегата не может работать в автомате. Часто дается возможность отключить контроль какого-то сигнала, например, тот же датчик. Активируем эту функцию и все у нас работает в автомате, так как сигнал от датчика не учитывается и в дальнейшем это может привести к проблемам, но это уже ответственность заказчика. Все эти режимы описываются в инструкции и с большими предупреждающими знаками. При использовании систем визуализации часто делают так называемый лог событий сюда входят аварии (это всегда делается) и действия оператора (имя оператора, что нажал, какой режим выбрал, что изменил и т.д.). И если возникает поломка механизма по вине заказчика, так как отключили какой-то элемент контроля – то это уже не гарантийный случай и фирма, что делала автоматизацию не попала на деньги. Так как любой гарантийный ремонт делается за счет изготовителя, а в этом случае они сами виноваты.
На этом пока хочу закончить. И так уже вышел далеко за рамки того объема, который хотел написать. Возможно получилось как-то не слишком структурировано, но я старался))) Будет кому-то интересно возможно продолжу еще что-то по теме автоматизации писать.