Меню

Программирование для автоматизированного оборудования что это



Инфо Решения

Программирование для автоматизированного оборудования

Введение. Раздел 1. Подготовка к разработке управляющих программ

Этапы разработки УП. Операции, выполняемые на оборудовании с программным управлением. Задачи, решаемые на каждом этапе проектирования УП. Разработка расчетно-технологических карт.Определение номенклатуры деталей для обработки на станках с программным управлением. Классификация деталей по конструктивно-технологическим признакам. Проектирование технологических процессов по ГОСТ 31404-86. Разработка операционной расчетно-технологической карты (РТК). Разработка карты наладки (КН). Разработка рукописи УП, нанесение на программоноситель.

Требования к технологической документации. Справочная, исходная и сопроводительная документация.

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

Раздел 2. Кодирование и запись УП

Содержание УП в соответствии с ГОСТ 20523-80. Символы кода ИСО по ГОСТ 20999-78. Структура УП и символическая запись формата УП для системы ЧПУ

Виды программоносителей. Структура перфоленты. Представление УП на перфоленте. Код ISO – 7 bit. Устройство подготовки данных на перфоленте. Назначение. Состав. Режим работы.

Раздел 3. Программирование технологических процессов механической обработки

Тема 3.1. Программирование обработки деталей на токарных станках с ЧПУ

Переходы токарной обработки. Зона выборки массива материала. Открытые, полуоткрытые и закрытые зоны выборки массива материала. Типовые технологические схемы обработки зон, выборки массива материала. Схема обработки канавок, резьбовых поверхностей.Операционная расчетно-технологическая карта обработки детали на токарном станке. Карта наладки токарного станка с ЧПУ. Пример разработки УП обработки детали на токарном станке ЧПУ. Разработка УП обработки детали на токарном станке с ЧПУ.

Практическое занятие №1. Разработка УП обработки детали на токарном станке с ЧПУ.

Тема 3.2. Программирование обработки деталей на фрезерных станках с ЧПУ

Переходы фрезерной обработки. Типовые технологические схемы обработки открытых, полуоткрытых и закрытых поверхностей. Многокоординатная обработка контуров и поверхностей на фрезерном станке с ЧПУ.Операционная расчетно-технологическая карта обработки детали на фрезерном станке с ЧПУ. Карта наладки фрезерного станка с ЧПУ. Команды управляющей системы фрезерного станка с ЧПУ. Пример разработки УП обработки детали на фрезерном станке с ЧПУ.

Практическое занятие №2. Разработка УП обработки детали на фрезерном станке с ЧПУ.

Тема 3.3. Программирование на сверлильных станках с ЧПУ

Виды отверстий и последовательность переходов их обработки. Типовые технологические схемы обработки отверстий.Последовательный, параллельный и комбинированный методы обработки групп отверстий.РТК обработки деталей на сверлильных станках с ЧПУ. Определение положения нулевой плоскости. Карта наладки сверлильного станка с ЧПУ. Стандартные циклы обработки отверстий. Пример разработки УП обработки деталей на сверлильном станке с ЧПУ по упрощенной методике программирования.

Практическое занятие №3. Разработка УП обработки детали на сверлильном станке с ЧПУ.

Тема 3.4.Программирование обработки деталей на многоцелевых станках с ЧПУ

РТК обработки деталей на многоцелевом станке с ЧПУ. Безопасная плоскость. Нулевая плоскость. Карта наладки многоцелевого станка с ЧПУ. Команды управляющей системы. Пример разработки УП обработки детали на многоцелевом станке с ЧПУ.

Раздел 4. Программирование для промышленных роботов (ПР) и роботизированных технологических комплексов (РТК)

Тема 4.1 Особенности программирования для ПР и РТК

Виды программного управления ПР. Методы программирования: по упорам, обучением. Последовательность разработки УП при различных методах программирования. РТК. Взаимодействие ПР со станками. Методика разработки УП для РТК.

Раздел 5. Системы автоматизированного программирования

Тема 5.1. Основные принципы автоматизации процесса подготовки УП

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

Тема 5.2.Структура и классификация САП

Классификация систем автоматизированного программирования. Структура САП. Формы представления исходных данных.

Тема 5.3.Языки САП. Отечественные и зарубежные САП

Языки САП. Промежуточные языки CLDATA. Процессор, препроцессор и постпроцессор. Современные промышленные САП, реализуемые на больших и малых ЭВМ. Обзор их возможностей, особенностей. Тенденции развития современных САП.

Тема 5.4 САП для станков с ЧПУ токарной группы

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

Лабораторная работа №2. Разработка комплекта исходных данных для расчета УП обработки детали на токарном станке с ЧПУ в САП GTL-T.

Лабораторная работа№3. Разработка комплекта исходных данных для расчета УП обработки детали на токарном станке с ЧПУ в САП ЕХАРТ.

Тема 5.5 САП для станков фрезерной группы

Операционная РТК. Обозначение элементов контура. Запись геометрической информации. Запись технологической информации. Пример разработки комплекта исходных данных для расчета УП и обработки на фрезерном станке с ЧПУ.

Лабораторная работа №4. Разработка комплекта исходных данных для расчета УП обработки детали на фрезерном станке с ЧПУ в САП ТЕХТРАН.

Лабораторная работа№ 5. Разработка комплекта исходных данных для расчета УП обработки детали на фрезерном станке с ЧПУ в САП ЕС.

Тема 5.6 Автоматизированное рабочее место технолога-программиста (АРМТП)

Устройство АРМТП. Схема пульта оператора. Режимы работы. Виды и назначения операторов. Методика разработки УП в диалоговом режиме. Работа с периферийными устройствами

Источник

ОСНОВНЫЕ ПОНЯТИЯ И ОПРЕДЕЛЕНИЯ, ОТНОСЯЩИЕСЯ К ПРОГРАММИРОВАНИЮ АВТОМАТИЗИРОВАННОГО ОБОРУДОВАНИЯ

Управляющая программа (УП) — совокупность команд на языке программирования, соответствующая заданному алгоритму функционирования станка для обработки конкретной заготовки.

Числовое программное управление (ЧПУ) станком — управление обработкой заготовки на станке по УП, в которой данные заданы в цифровой форме. Позиционное ЧПУ (позиционное управление) — ЧПУ, при котором рабочие органы станка перемещаются в заданные точки, причем траектории перемещения не задаются.

Контурное ЧПУ станком (контурное управление) — ЧПУ, при котором рабочие органы станка перемещаются по заданной траектории и с заданной скоростью для получения необходимого контура обработки.

Адаптивное ЧПУ станком (адаптивное управление) — ЧПУ, при котором обеспечивается автоматическое приспособление процесса обработки заготовки к изменяющимся условиям обработки по определенным критериям.

Групповое ЧПУ станками (групповое управление) — ЧПУ группой станков от ЭВМ, имеющей общую память для хранения управляющих программ, распределяемых по запросам от станков.

Ручная подготовка УП — подготовка и контроль УП в основном без применения ЭВМ.

Автоматизированная подготовка УП — подготовка и контроль УП с применением ЭВМ.

Программоноситель — носитель данных, на котором записана УП. В качестве носителя данных могут применяться перфолента, магнитная лента, магнитный диск, компакт-диск (CD) и запоминающие устройства различного типа. Программное обеспечение системы ЧПУ (программное обеспечение) — совокупность программ и документации для реализации целей и задач системы ЧПУ.

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

Программное устройство ЧПУ — устройство ЧПУ, алгоритмы работы которого реализуются с помощью программ, вводимых в его память, и могут быть изменены после изготовления устройства.

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

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

Слово УП (слово) — составная часть кадра УП, содержащая данные о параметре процесса обработки заготовки и (или) другие данные по выполнению управления. Адрес ЧПУ (адрес) — часть слова УП, определяющая назначение следующих за ним данных, содержащихся в этом слове.

Номер кадра УП (номер кадра) — слово в начале кадра, определяющее последовательность кадров в УП.

Формат кадра УП (формат кадра) — условная запись структуры и расположения слов в кадре УП с максимальным числом слов.

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

Абсолютный размер — линейный или угловой размер, задаваемый в УП и указывающий положение точки относительно принятого нуля отсчета.

Размер в приращении — линейный или угловой размер, задаваемый в УП и указывающий положение точки относительно координат точки предыдущего положения рабочего органа станка. 10

Автоматическая работа системы устройства ЧПУ (автоматическая работа) — функционирование СЧПУ (УЧПУ), при котором отработка УП происходит с автоматической сменой кадров УП.

Работа системы ЧПУ с пропуском кадров (пропуск кадра) — автоматическая работа СЧПУ (УЧПУ), при которой не отрабатываются кадры УП, обозначенные символом ПРОПУСК КАДРА.

Ускоренная отработка УП (ускоренная отработка) — автоматическая работа СЧПУ (УЧПУ), при которой предусмотренные в УП скорости подач автоматически заменяются на ускоренную подачу.

Покадровая работа — функционирование СЧПУ (УЧПУ), при котором отработка каждого кадра УП происходит только после воздействия оператора.

Работа системы (устройства) ЧПУ с ручным вводом данных (ручной ввод данных) — функционирование СЧПУ (УЧПУ), при котором набор данных, ограниченный форматом кадра, производится вручную оператором на пульте. Работа системы ЧПУ с ручным управлением (ручное управление) — функционирование СЧПУ (УЧПУ), при котором оператор управляет станком с пульта без использования числовых данных.

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

Ввод УП (ввод) — функционирование УЧПУ, при котором ввод данных в память УЧПУ с программоносителя происходит от ЭВМ верхнего ранга или с пульта оператора.

Вывод УП (вывод) — функционирование УЧПУ, при котором происходит вывод хранимой в памяти УЧПУ управляющей программы на носитель данных. При выводе УП могут выводиться дополнительные данные, используемые при отработке УП и хранящиеся в памяти УЧПУ, например константы и т. п.

Поиск кадра в УП (поиск кадра) — функционирование УЧПУ, при котором на программоносителе или в запоминающем устройстве УЧПУ обнаруживается заданный кадр УП по его номеру или специальному признаку.

Редактирование УП (редактирование) — функционирование УЧПУ, при котором управляющую программу изменяет оператор непосредственно у станка. Контурная скорость — результирующая скорость подачи рабочего органа станка, вектор которой равен геометрической сумме векторов скоростей перемещения этого органа вдоль осей координат станка.

Читайте также:  Как посчитать экономическую эффективность оборудования

Нулевая точка станка (нуль станка) — точка, принятая за начало координат станка. Исходная точка станка (исходная точка) — точка, определенная относительно нулевой точки станка и используемая для начала работы по УП. Фиксированная точка станка (фиксированная точка) — точка, определенная относительно нулевой точки станка и используемая для определения положения рабочего органа станка.

Точка начала обработки — точка, определяющая начало обработки конкретной заготовки.

Нулевая точка детали (нуль детали) — точка на детали, относительно которой заданы ее размеры.

Плавающий нуль — свойство СЧПУ (УЧПУ) помещать начало отсчета перемещения рабочего органа в любое положение относительно нулевой точки станка.

Дискретность задания перемещения — минимальное перемещение или угол поворота рабочего органа станка, которые могут быть заданы в УП.

Дискретность отработки перемещения — минимальное перемещение или угол поворота рабочего органа станка, контролируемые в процессе управления. Коррекция инструмента — изменение с пульта управления запрограммированных координат (координаты) рабочего органа станка.

Коррекция скорости подачи — изменение с пульта оператора запрограммированного значения скорости подачи. Коррекция скорости главного движения — изменение с пульта оператора запрограммированного значения скорости главного движения станка.

Значение коррекции положения инструмента (коррекция на положение инструмента) — расстояние по оси координат станка, на которое следует дополнительно сместить инструмент.

Значение коррекции длины инструмента (коррекция на длину инструмента) — расстояние вдоль оси вращающегося инструмента, на которое следует дополнительно сместить инструмент.

Значение коррекции диаметра фрезы (коррекция на фрезу) — расстояние по нормали к заданному контуру перемещения фрезы, на которое следует дополнительно переместить центр фрезы.

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

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

Датчики обратной связи (ДОС) — устройства, с помощью которых собирается информация обратной связи.

Информация возмущения — информация, источником которой служит окружающая среда (температура, влажность, колебания припуска заготовки, твердость материала, уровень вибрации и др.).

Системы управления разомкнутые (без обратной связи, с разомкнутой цепью, циклические, жесткие, программные) — системы управления, использующие только задающую информацию. В системах отсутствуют контроль за выполнением заданной программы и обратная связь. В разомкнутых системах используется только один поток информации. Задающая информация перерабатывается в форму, удобную для управления приводом, выполняющим тот или иной элементарный цикл технологического процесса. Информация возмущения, имеющая место при выполнении технологического процесса, как и информация обратной связи, в разомкнутых системах управления не используется.

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

Геометрическая информация — информация, описывающая форму, размеры элементов детали и инструмента и их взаимное положение в пространстве. Технологическая информация — информация, описывающая технологические характеристики детали и условия ее изготовления.

Интерполяция — получение (расчет) координат промежуточных точек траектории движения центра инструмента в плоскости или пространстве.

Аппроксимация — процесс замены одной функциональной зависимости другой с определенной степенью точности.

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

Бит — одноразрядная единица двоичной информации.

Байт — единица количества двоичной информации, равная восьми битам.

Бод — единица скорости передачи информации;

Машинное слово — объем информации, равный 1, 2 или 4 байт (8, 16 или 32 бит) в зависимости от разрядности блоков ЭВМ (ПК).

Килобайт — единица количества двоичной информации, равная 1024 (103) байт. Мегабайт — единица количества двоичной информации, равная 1048 576 (106) байт.

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

Код — ряд правил, посредством которых выполняется преобразование данных из одного вида в другой. Применение кода (кодирование) сводится к записи информации в виде комбинации символов.

Геометрический элемент — непрерывный участок расчетной траектории или контура детали, задаваемый одним и тем же законом в одной и той же системе координат.

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

Опорная геометрическая точка — точка расчетной траектории, в которой происходит изменение закона, описывающего траекторию.

Опорная технологическая точка — точка расчетной траектории, в которой происходит изменение условий протекания технологического процесса. Постпроцессор — согласующая программа САП, учитывающая особенности данного станка и формирующая кадр.

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

Рукопись программы — информация, записанная в виде, удобном для составления языковой или управляющей программы.

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

Центр инструмента — неподвижная относительно державки точка инструмента, по которой ведется расчет траектории.

Чувствительность — минимальное рассогласование, на которое может реагировать система.

Шаг программирования — разность между двумя ближайшими программируемыми числовыми величинами.

Эквидистанта — линия, равноотстоящая от линии контура детали (заготовки). Интерполятор системы ЧПУ станком — вычислительный блок системы ЧПУ, задающий последовательность управляющих воздействий для перемещения рабочих органов станка по осям координат в соответствии с функциональной связью между координатами опорных точек, заданных программой управления станком.

Ось координат станка с ЧПУ — направление, совпадающее с перемещением рабочего органа станка по направляющей опоре в соответствии с программой управления станком, связанное с одной единицей привода.

Файл — совокупность данных, объединенных по некоторому общему смысловому признаку или нескольким признакам. Способ хранения информации в виде файла (данных) широко применяется в запоминающих устройствах ЭВМ (ПК). При этом файл отмечают специальными метками, что позволяет легко найти соответствующую информацию (например, на магнитной ленте, диске и др.). Дисплей — устройство визуального отображения алфавитно-цифровой и графической информации. Наиболее распространены дисплеи телевизионного типа.

Интерфейс — совокупность аппаратных и программных средств, обеспечивающих совместимость (взаимодействие) различных функциональных блоков (устройств), образующих измерительную, вычислительную или управляющую систему в соответствии с требуемыми условиями, например видом кода, моментом выдачи (приема) информационных и управляющих сигналов, формой представления информации (аналоговая или цифровая).

Источник

Рабочая программа дисциплины «Программирование для автоматизированного оборудования»
рабочая программа на тему

Митин Дмитрий Иванович

Программа дисциплины «Программирование для автоматизированного оборудования» учитывающая современные требования к знаниям обучающихся

Скачать:

Вложение Размер
op.10.progr_dlya_ao_povysh.doc 246.5 КБ

Предварительный просмотр:

Государственное бюджетное профессиональное образовательное учреждение «Арзамасский приборостроительный колледж имени П.И.Пландина»

«АПК им. П. И. Пландина

« 29» августа 2019 г.

РАБОЧАЯ ПРОГРАММА УЧЕБНОЙ ДИСЦИПЛИНЫ

Программирование для автоматизированного оборудования

по специальности 15.02.08

Рабочая программа учебной дисциплины разработана на основе Федерального государственного образовательного стандарта по специальности среднего профессионального образования 15.02.08 Технология машиностроения, входящей в укрупненную группу специальностей 15.00.00 Машиностроение.

Организация-разработчик: ГБПОУ «Арзамасский приборостроительный колледж имени П.И. Пландина»

Разработчики: Митин Д.И., преподаватель

Утверждена Методическим советом ГБПОУ «Арзамасский приборостроительный колледж имени П.И. Пландина»

Протокол Методического Совета № 1 от « 29 » августа 2017 г.

1. ПАСПОРТ РАБОЧЕЙ ПРОГРАММЫ УЧЕБНОЙ ДИСЦИПЛИНЫ

Программирование для автоматизированного оборудования

1.1. Область применения рабочей программы

Рабочая программа учебной дисциплины является частью основной профессиональной образовательной программы в соответствии с ФГОС по специальности СПО 15.02.08 Технология машиностроения, входящей в укрупненную группу специальностей 15.00.00 Машиностроение.

Рабочая программа учебной дисциплины может быть использована в профессиональной подготовке:

Оператор станков с программным управлением

Станочник широкого профиля

1.2. Место учебной дисциплины в структуре основной профессиональной образовательной программы: дисциплина входит в профессиональный цикл (общепрофессиональные дисциплины ОП.10. Программирование для автоматизированного оборудования).

1.3. Цели и задачи учебной дисциплины – требования к результатам освоения учебной дисциплины.

В результате освоения учебной дисциплины обучающийся должен уметь :

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

В результате освоения учебной дисциплины обучающийся должен знать :

  • методы обработки и внедрения управляющих программ для обработки типовых деталей на автоматизированном оборудовании.

1.4. Рекомендуемое количество часов на освоение рабочей программы учебной дисциплины:

максимальной учебной нагрузки обучающегося 108 часов, в том числе:

обязательной аудиторной учебной нагрузки обучающегося 72 часов;

самостоятельной работы обучающегося 36 часов.

2. СТРУКТУРА И СОДЕРЖАНИЕ УЧЕБНОЙ ДИСЦИПЛИНЫ

2.1. Объем учебной дисциплины и виды учебной работы

Вид учебной работы

Максимальная учебная нагрузка (всего)

Обязательная аудиторная учебная нагрузка (всего)

Источник

Мой путь в пром. автоматизацию. Инженер-программист АСУТП

Итак, не так давно был пост Замкнутый круг — Siemens вокруг! не думал, что оставленный мною комментарий приведет к появлению у меня подписчиков и интересу к вопросу как стать программистом АСУТП.
Опишу вкратце саму специальность, обязанности и как я к этому пришел. Будет много текста.
Что делает любой программист? Правильно — программирует. И на этом можно было бы окончить описание, но не все так просто. Начнем.

АСУТП — автоматизированные системы управления технологическим процессом. Из расшифровки аббревиатуры уже можно понять, что задача инженера по автоматизации — создание программного продукта, который упрощает жизнь в первую очередь оператору механизма, который нужно автоматизировать (чаще происходит наоборот, так как не все хотят учить новое и упираются нововведениям всеми силами).

Обязанности могут быть самые разнообразные. В небольших компаниях инженер-программист может проектировать электрические схемы для автоматизируемого устройства, а затем и писать программу. В более крупных компания только программирование. Работал в компании где было 10 человек, не считая монтажников и в компании, где было свыше 200 сотрудников. Всегда будут командировки — вы будете участвовать в пуско-наладочных работах. Это если из основного. Не удивляйтесь и ситуации когда программист будет с отверткой что-то ковырять в щите управления чем-либо, отсюда следует, что вы обязаны уметь читать и при необходимости изменять электрические схемы, знать технику безопасности и ПУЭ ваша настольная книга. Иногда меня хотели заставить что-то изменить в силовой части подключения, но я этого не делал как бы косо на меня не смотрели электрики/монтажники. А вот объясню почему, на всех фирмах, где я работал у меня не было допуска по электробезопасности, а отсюда следует, что я вообще не должен лезть туда, где есть напряжение. Так что нет допуска — нет и каких-либо изменений схемах шкафа управления.
Часто бывает, что изначальная схема и то, что собрано по факту на объекте отличается. Причины могут быть разные — экономия (купили дешевле оборудование, решили поставить, что на складе нашлось, кто-то откат получил и т.д.). Задача программиста, который приехал на пуско-наладку подружить это все и заставить работать. Иногда это бывает очень непросто. Но про это будет позже, сначала необходима программа, а потом уже запуск объекта.

В общем выполнение работ по автоматизации проходит следующие стадии (упрощенно, на самом деле все немного сложнее):

1. Если участвуют несколько отделов в реализации проекта, то, когда приходит запрос из отдела продаж, каждый отдел предоставляет часы, которые потратит специалист на реализацию своей части. Далее это все суммируется и возвращается в отдел продаж. Они офигевают и ообычно на этом этапе уменьшаются часы, заложенные различными заинтересованными отделами, ибо дорого, и нужно продать. Ненавижу за это «продажников», хотя и понимаю, что это бизнес. Чтобы было понятно, в компании, где было больше 200 сотрудников были: департамент проектирования, департамент разработки ПО, департамент пуско-наладочных работ. И каждое подразделения выдавало кол-во часов на этот проект, необходимое для выполнения их части работ. И как итог выиграли тендер (если повезло, не будем говорить про остальные схемы).
2. На этом этапе обычно пишется ТЗ (технологическое задание) программистом на автоматизацию, хотя должно быть наоборот, заказчик должен предоставить описание того, что он хочет получить. Но у меня было так, как описываю. Дальше это ТЗ долго и нудно согласовывается с заказчиком, вносятся правки, ставятся подписи. Хотя это совсем не гарантия того, что ТЗ останется неизменным. Правки могут прийти, когда до начала пуско-наладочных осталось совсем немного времени, но почти всегда фирма-исполнитель прогибается под заказчика и программист потом в панике вносит изменения, что приводит к тому, что ПО будет не протестировано до конца, что приводит к задержкам при вводе в эксплуатацию и т.д. Но никого это обычно не волнует, хоть спи на объекте, но оно должно работать.
3. Когда есть ТЗ начинается, собственно, и реализация/придумывание того, как же оно все должно работать. Помимо программы для контроллера (ПЛК — программируемый логический контроллер) иногда нужно сделать и визуализацию. Для визуализации, в зависимости от поставленных целей применяется SCADA или HMI. В чем отличия отлично гуглится (статья и так уже огромная, сам не ожидал).
4. Тестирование программы на стенде или в симуляторах. Отлично работающая программа в симуляторе не равно иногда даже работающей на «живом объекте».
5. И самый интересный момент — это пуско-наладка (ПН). Об этом напишу подробнее.

Итак, что должен делать инженер во время ПН. Для удобства разделю на этапы.
1. I/O check проверка правильности подключения всех входов/выходов ПЛК (программируемый логический контроллер). И если что-то неправильно – то исправление. На данном этапе никакого ручного управления, не говоря уже про автоматизацию нет. Просто в контроллере можно жестко активировать выход и посмотреть, тот ли механизм включился. С входами проще, бегаешь вокруг механизма и тыкаешь кнопки, замыкаешь вручную концевые выключатели и смотришь, соответствует ли это тому, что ты заложил в программу. Для тех, кто не в теме, каждый контроллер имеет входа и выхода. Входа используются для сбора данных с механизма (всякого рода датчики, кнопки и т.д.). Выхода же нужны для управления устройством, например включить двигатель, закрыть задвижку и т.д. Это если очень упрощенно и не вдаваясь в подробности.
2. Если предыдущий этап закончился успешно и все собрано правильно (на более-менее больших объектах с первого раза никогда все правильно собрано не будет) – то приступаем к проверке в ручном режиме. Для этого либо со SCADA либо HMI включаем/выключаем узел агрегата и смотрим все ли правильно работает и все ли правильно отображается. Часто бывают ошибки (если используется визуализация) в привязках переменных к объекту на визуализации. Например, запустили один механизм, а на панели/скаде отображается, что включился другой, хотя работает правильный ну и т.д. Эти ошибки сразу же исправляются и процесс проверки продолжается.
3. Когда закончили ручное тестирование – переходим к самому сложному и интересному (вот тут симулятор, если тестировалась программа на нем, и дает прикурить иногда). Автоматический режим. Ну с ним все ясно, перевели все механизмы в автомат и запустили объект.

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

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

Источник

Программирование систем автоматизации завтрашнего дня

В области программирования систем автоматизации на производстве сегодня наблюдаются две тенденции: во-первых, в этой сфере применяются компьютерные информационные технологии (ИТ), во-вторых, при написании прикладных программ с успехом используется модульный принцип. Программа Application Composer, разработанная компанией 3S-Smart Software Solutions, позволяет пользователям идти в ногу со временем и соответствовать обеим тенденциям.
Роланд Вагнер, 3S-Smart Software Solutions GmbH

Оптимизация затрат на проектирование систем автоматизации в производстве, в том числе в машиностроении, а также в мобильных приложениях, автоматизации зданий сегодня является одним из высокоприоритетных вопросов. Программирование прикладных задач составляет значительную часть этих затрат. Неудивительно, что многие ведущие компании, работающие в данной области, всерьез задумываются над тем, какие концепции или парадигмы программирования систем управления им стоит использовать в будущем.
Конкурентная ценность систем все больше достигается именно за счет программного обеспечения. Пользователям постоянно требуется развитие сервисных и коммуникационных функций при одновременном упрощении применения, что вызывает непрерывное наращивание внутренней сложности систем. Это явно показано в исследовании «Требования изготовителей оборудования» немецкого союза машиностроителей (VDMA), крупнейшего объединения промышленных компаний в Европе [1].
Компания 3S-Smart Software Solution GmbH является разработчиком CODESYS, всемирно известного комплекса программирования на языках стандарта МЭК 61131-3. Многолетние собственные исследования и результаты обсуждений с большим числом пользователей явно выявили две тенденции: — внедрение технологий и инструментов из мира компьютерных информационных технологий (ИТ) в автоматизированные системы управления; — концентрация сложных программных частей в виде специализирован­ных прикладных модулей, из которых в дальнейшем строятся программы управления отдельными машинами или производством.
Эти тенденции, их мотивация и способы практического применения в комплексе CODESYS описаны ниже.

Чему мы можем научиться у мира ИТ?
Современные методы и парадигмы программирования ИТ-приложений, в первую очередь объектно ориентированное программирование (ООП), значительно повышают эффективность разработки программ. Естественно, есть смысл применять их в системах автоматизации. Раньше это не удавалось сделать в основном из-за радикализма их введения. «Ветераны» программирования контроллеров категорически не принимали попыток безальтернативного ввода ООП. Кроме того, пользователи были вынуждены в будущих проектах переходить на компьютерные среды разработки, такие как Visual Studio.
Исследование, проведенное в 2011 году, показало: «В разработке программ для систем управления большинство пользователей используют языки стандарта МЭК 61131-3 (98 из 157 опрошенных). Другие языки, такие как C+, UML, C #, Matlab/Simulink, играют очень незначительную роль» [2].
Инновации из мира ИТ должны внедряться поэтапно, не пе­речеркивая наработанный опыт и не разрушая привычный инстру­ментарий.

Зачем в МЭК 61131-3 нужно ООП?
Возможность использования ООП в контексте языков стандарта МЭК 61131-3 впервые была реализована в среде разработки CODESYS V3. Это позволило преодолеть пропасть между ИТ и контроллерным программированием.
Благодаря этому квалифицированные пользователи могут запрограммировать, например, наиболее сложные, «фундаментальные» блоки с помощью объектно ориентированного программирования. Они могут использовать интерфейсы, методы и наследование, динамическое связывание, перегружать методы и определять свойства точно таким же образом, как делают это в языках высокого уровня. Им не придется ради этого покидать среду МЭК 61131-3 – методы и их вызовы могут быть запрограммированы на языках IL, FBD, LD или ST. Созданные же ранее блоки могут вызываться из ООП-кода обычным образом. Пользователи, знакомые только с функциональным программированием, могут пользоваться новыми «фундаментальными» блоками точно так же, как они это привыкли делать без ООП.
По инициативе 3S-Smart Software Solutions концепт ООП был выдвинут на рассмотрение комитета по стандартизации, получил одобрение и был включен в третью редакцию стандарта МЭК 61131-3, выпущенную в начале 2013 года.

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

Рис. UML-диаграмма состояний интегрирована со средой разработки МЭК 61131-3
Но это еще не всё. Из всех 14 различных типов диаграмм особо выделяются диаграммы состояний, как наиболее полезные в автоматизации. Они также были интегрированы со средой программирования CODESYS. Теперь пользователи могут описывать программы и даже генерировать их код автоматически по стандарту МЭК. Специалисты, занятые в АСУ ТП, давно знакомы с такого рода диаграммами, но не имели возможности непосредственно использовать их в прикладном программировании. В среде разработки МЭК 61131-3 UML-диаграммы становятся средством коммуникации или «единым языком», который поможет «преодолеть вавилонское смешение языков между машиностроителями и программистами», как образно выразился доктор Хуттерер из компании Trumpf Maschinen Austria на форуме Benchmark Forum Intelligent Engineering, состоявшемся в Мюнхене в марте 2012 года. Используя UML-диаграммы, специалисты описывают технологические процессы, функции и порядок их вызовов для программистов. Благодаря интеграции UML с CODESYS, отпадает необходимость ручной конвертации проектов, что, естественно, уменьшает количество ошибок.

Рис. Статистический анализ кода для приложений МЭК 61131-3

Вспомогательные инструменты для увеличения производительности программирования
Помимо ООП и UML, есть еще несколько дополнительных инструментов из мира ИТ, которые могут весьма пригодиться в автоматизации.
Очевидно, что разработка масштабного проекта или набора однотипных проектов одним человеком может занять непозволительно много времени. В этих обстоятельствах необходимо работать группой. Как правило, у команды разработчиков возникает потребность синхронизировать свой труд и совместно использовать готовые фрагменты кода. В результате образуется набор проектов и библиотек с множеством вариантов улучшений и доработок. У программиста нередко возникают сложности при поиске исправлений, вызвавших неочевидную проблему. В таких случаях имеет смысл использовать систему контроля версий. В мире ИТ одной из самых распространенных систем такого рода является Apache Subver sion (SVN). Разработчики могли бы хранить программные блоки и библиотеки в SVN, используя механизмы импорта и экспорта. Однако без интеграции системы контроля версий с МЭК 61131-3 ее было бы очень неудобно применять, особенно с графическими языками. Поэтому разработчики CODESYS интегрировали SVN в среду. Управление версиями программных модулей выполняется привычными средствами в среде программирования. Пользователь может сравнить различные версии программных компонентов, про­анализировать отличия и восстановить нужную версию разрабатывае­мого приложения в любое время, с любой глубиной отката, что очень часто бывает необходимо на практике.
Еще одним полезным вспомогательным инструментом является статический анализатор кода CODESYS Static Analysis. Благодаря ему сокращается время разработки путем распознавания и исправления логических ошибок в коде приложения до того, как он будет загружен в контроллер. В анализаторе предусмотрены десятки тестов с настраиваемым набором правил. В числе прочего он проверяет одно­временный доступ к переменным, множественную запись выходных переменных, ищет в проекте не­используемые переменные и пустые программные блоки. Пользователь может настраивать правила тестов для всего проекта. На случай, если ему необходимо намеренно обойти какое-то правило в конкретном фрагменте, предусмотрены специальные исключающие директивы, записываемые в коде приложения.
Четвертым вспомогательным инструментом CODESYS является менеджер тестирования. Без тщательного тестирования не может обойтись ни один значительный проект. Иногда даже в самых тривиальных фрагментах кода может скрываться затаенная ошибка. Блок сравнений способен прекрасно работать на тысяче значений переменной и дать сбой на тысяча первом из-за банальной невнимательности в порядке вычислений и сравнений. Проверить это вручную нереально. Но на работающем объекте будет происходить сбой с непонятной симптоматикой и периодичностью. Менеджер тестирования позволяет написать сценарии тестирования. Работая по сценарию, CODESYS не поленится прогнать выполнение прикладной программы с каждым возможным значением переменной, оценить результаты и сформировать детальный отчет. Также нередко бывает, что «безобидная» доработка программы вносит неожиданную ошибку в уже отлаженный код. Менеджер тестирования позволяет пользователю выполнять полную проверку всего проекта при каждом его исправлении, сколько угодно раз. Ошибки в прикладной программе устраняются до выхода на объект, экономя время и повышая авторитет разработчика.
Представленные выше вспомогательные инструменты не входят в стандартный бесплатный пакет поставки CODESYS. Они выполнены в виде отдельных плагинов. Их можно приобрести и установить через интернет-портал CODESYS Store. Необходимые для этого средства встроены в среду программирования.

Преодоление сложности программирования
Сегодня многие люди, так или иначе связанные с работами по автоматизации, задаются вопросами: «Помогут ли нам новые концепты и стандарты программирования отвечать все возрастающим требованиям рынка?»; «Можем ли мы оценить риски, связанные с заменой нашей философии программирования? Стоят ли перемены этих усилий?»; «Можно ли добиться значительного скачка производительности в программирования ПЛК, не выходя за рамки МЭК 61131-3?».
Все это представляется вполне возможным, особенно в случае тиражирования похожих либо однотипных проектов. Существуют сотни машин и систем, собираемых из достаточно стандартных узлов, механических и электрических устройств. Например, системы освещения и безопасности, системы приточно-вытяжной вентиляции, котельные, системы водоподготовки, деревообрабатывающие, полиграфические, пищевые и многие другие машины. Возникает мысль, что лучше всего иметь один раз подготовленный специалистами высшей квалификации набор гибко настраиваемых программных модулей для всех стандартных узлов подобных систем. Из них можно было бы, как из кубиков, собирать проект системы управления, настраивать необходимые параметры модулей, их связи и автоматически генерировать готовый, заведомо работоспособный код. Если делать это в рамках МЭК 61131-3, то сохраняется возможность легко внести в такой почти готовый код специфические для конкретной установки изменения или дополнения, не предусмотренные разработчиком модулей.
Данная идея вылилась в разработку принципиально нового инструмента программирования, получившего название CODESYS Application Composer.

CODESYS Application Composer
В отличие от других обсуждаемых выше концептов, при использовании Application Composer разработчику не нужно приобретать дополнительных знаний или выходить за рамки привычной среды разработки МЭК 61131-3. Хорошо знакомый инструмент расширяется по принципу модулей, из которых будет «собрано» конечное приложение.

Рис. Собранное дерево модулей с параметрами входов
Понятие «сборки» говорит о том, что для создания приложений уже необязательно быть программистом: построением прикладного проекта способны заниматься технологи, инженеры и даже монтажники. Для этого достаточно иметь общие представления о работе машины.
Типовой модуль состоит из функциональных блоков и реализует функционал различных частей машины/установки. Модулями могут быть, с одной стороны, различные механические компоненты, такие как пневматические цилиндры, теплообменники, клапаны и т. п. С другой стороны, модуль может выполнять и чисто программные функции, такие как архивация событий, формирование аварийного сообщения и т. д. Важный момент – каждый модуль содержит базовые инжиниринговые черты CODESYS: — МЭК 61131-3 код программы; — входы и выходы для связи блоков; — возможность параметризации значений; — графическое представление для операторского управления или обслуживания.
Пользователь создает (собирает) древовидную структуру системы на основе этих модулей, которые полностью описывают работу машины. Модули имеют конкретные интерфейсы с описанием «родителей» и «потомков», и их можно поместить на дерево только в соответствующие места. Например, интерфейс модуля «циркуляционный насос» может требовать модуль плавного пуска либо частотного привода. Неподходящий модуль просто не установится. Модуль за модулем конструктор проекта собирает и настраивает установку целиком. Зная связи в дереве проекта, система подстроит модули друг к другу. Благодаря этому настройка параметров сокращена до действительно необходимого минимума. С помощью графического маппинга пользователь соединяет физические входы/выходы контроллера с соответствующими модулями.

Рис. Маппинг входов/выходов
Если модулям необходим контроль хронологической последовательности их работы, то используется так называемый «модуль программируемых последовательностей». Для более удобного представления информации он оснащен собственным графическим редактором блок-схем по стандарту DIN66001/ISO5807.

МЭК-программа в 0 строк
На основе подготовленного дерева модулей встроенный генератор по команде выдает полноценное МЭК 61131-3‑приложение, включая визуализацию. Оно может быть скомпилировано с помощью CODESYS в исполняемый код и загружено в контроллер. Это значит, что пользователю даже не придется написать ни единой строчки МЭК 61131-3‑кода самому – вся информация будет взята из дерева модулей и библиотек и коррект­но встроена в структуру проекта. Исходный код будет доступен для редактирования, если такая необходимость вдруг возникнет. Приложение автоматически запустится при старте контроллера. Никаких дополнительных действий не требуется.
Если понадобится изменить приложение по требованию заказчика или из-за изменения конфигурации контроллера, то разработчику всего лишь нужно будет внести изменения в параметры требуемых модулей и переназначить входы/выходы.

Доступные и специальные модули
Эффективность использования Application Composer подразумевает доступность разнообразных модулей. 3S-Smart Software Solutions, как разработчик CODESYS, считает необходимым участвовать в развитии универсальных аппаратно-независимых модулей для, например, машин состояний, архивирования данных, коммуникаций, распределенных систем, обработки тревог и уведомлений.

Рис. Задание хронологической последовательности

Источник