Способы проектирования управляющих программ

Процесс проектирования ПО автоматизированных систем условно разбивают на следующие этапы:

1. Разработка проблемных спецификаций (технического задания) (поста­новка задачи; определение требований к вводу-выводу; описание ограни­чений).
2. Проектирование макроструктуры ПО автоматизированных систем (выбор и разработка основных функциональных алгоритмов и структур данных).
3. Выбор языков программирования и операционной системы.
4. Проектирование микроструктуры ПО автоматизированных систем (разработка спецификаций программ).
5. Кодирование (запись программ на языке) и получение носителей.
6. Тестирование и отладка.
7. Корректировка.
8. Оформление документации.
9. Сопровождение на объекте.

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

SINUMERIK 840D: проектирование и отладка управляющих программ

В процессе разработки ПО систем автоматизации допускают следующие типичные ошибки:

1. Недостаточно полно прорабатывают отдельные подсистемы и неточно определяют связи между этими подсистемами. При этом оказываются нару­шенными информационные связи между подсистемами.
2. Не учитывают характеристики используемой вычислительной техни­ки: объемы оперативных и внешних ЗУ, ограничения на время работы от­дельных подсистем программ. В результате система не в состоянии выполнить все возложенные на нее функции.
3. Нечетко определяют цели и функции подсистем.
4. Занижают оценки времени и стоимости разработок ПО программируемых логических контроллеров (ПЛК).
5. Недостаточно автономно определяют подсистемы,
6. Некачественно составляют документацию.

На процесс проектирования ПО большое влияние оказывают различные факторы; от выбранного метода проектирования, размера и вида программ используемою языка до квалифи­кации программистов.

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

Нисходящее проектирование систем автоматизации (проектирование сверху вниз). Известны различные названия этого подхода к проектированию программ: систематическое программирование, иерархическое проектирование программ, взрывное проектиро­вание.

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

ОБУЧЕНИЕ ЧПУ — УРОК 12 — СОЗДАНИЕ УП НА ПК / Программирование станков с ЧПУ и работа в CAD/CAM

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

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

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

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

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

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

Библиотека состоит из четырех разделов:

1. Внутренняя библиотека, содержащая вос­принимаемые машиной исходные программы, пе­ремещаемые модули, объектные модули, опера­торы редактирования связей, тестовые данные.
2. Внешняя библиотека, содержащая текущее состояние листингов всех программ, а также листинги последних фиксированных версий программ.
3. Набор машинных процедур, включающий всю информацию, необходимую для обновления библиотек, выполнения те­стовых пусков, компиляции модулей, редактированию связей и хранению объектной программы.
4. Набор формальных процедур, точно определяющих правила внесения изменений в исходные программы, использования машинных процедур, обновления листингов и файлов внешней библиотеки, образования файлов и замены данных в архивах последних версий программ.

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

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

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

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

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

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

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

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

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

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

Модульное программирование автоматизированных систем. Модульное ПО систем управления технологическими процессами такое, в котором любую часть логической структуры можно изменить, не вызывая изменений в ос­тальных частях.’ Одним из определяющих свойств является размер модуля. Полагают, что модуль должен быть ограничен 50—200 операторами.

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

• легкость составления и отладки (функциональные компоненты программы пишут и отлаживают порознь);
• легкость сопровождения и модификации;
• возможность распределения модулей между программистами различной квалификации в соответствии с уровнем сложности.

Однако широкому распространению принципа модульности систем управления технологическими процессами препятствуют следующие факторы:

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

Источник: ritm.pro

Методы подготовки управляющих программ

1. Разработка чертежа заготовки и операционного чертежа.

2. Техническая проработка операции (состояние операционной карты).

3. Разработка схемы наладки.

4. Построение циклограммы (схемы перемещения инструмента).

5. Определение координат опорных точек (составление операционной расчетно-технологической карты)

6. Составление операционной карты кодирования (буквенно-цифровая запись программы).

7. Запись программы.

8. Проверка программы.

Автоматизация подготовки управляющих программ

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

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

САП классифицируется: по назначению, области использования, параметрам используемых ПК. По назначению различают:

— универсальные САП – предназначенные для станков определенных групп при изготовлении разных по форме деталей;

— специализированные – для автоматизированных участков для деталей отдельных классов;

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

По области использования в зависимости от типа деталей и оборудования различают САП:

— для обработки плоскостей параллельных осям координат (фрезерные станки);

— для обработки сложно-контурных поверхностей на фрезерных станках;

— сложно-профильных деталей на токарных станках;

— для сверлильных станков с позиционной системой управления;

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

Методики и способы подготовки управляющих программ для станков,

Оснащенных устройствами ЧПУ типа CNC

1. Использование подпрограмм различного типа: стандартных на типовые детали и составленных в процессе программирования для каждой конкретной детали.

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

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

4. Оперативное программирование. Программа предварительно не составляется, а координаты опорных точек, циклограмма перемещения инструмента, режимы резания вводятся с пульта управления устройством ЧПУ с оперативного эскиза. Для станков с УЧПУ оперативного программирования характерно: упрощенная схема ввода программы, использование большого количества постоянных циклов ориентированных, на данный станок, простая схема редактирования и ввода коррекции программы.

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

Программирование обработки символьно-графическим способом включает следующие этапы:

— формирование геометрических параметров заготовки и детали;

— конкретизация технических требований;

— выбор схемы обработки и инструмента;

— определение режимов обработки;

— разработка схемы наладки;

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

В настоящее время находят широкое применение различные системы автоматизированного программирования (Delcam, Гемма и др).

Дата добавления: 2019-02-13 ; просмотров: 644 ; Мы поможем в написании вашей работы!

Поделиться с друзьями:

Источник: studopedia.net

2.3.2. Параметрический метод проектирования управляющих программ

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

Предположим, мы имеем два реальных размера ии некоторый параметр c, такой что:

(4),

Размерам исоответствуют программные размерыи. С учетом (1), верно утверждение:

(5),

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

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

Задача решается через применение языка программного обеспечения Mscript. Данное приложение используется для создания маркируемых моделей и задания режимов и схемы обработки. Язык является Basic-подобным. В нем есть операторы примитивов и булевы операции над ними, также возможны параметры и математические операции над ними.

Данные функции можно использовать для создания моделей маркируемых изделий или вырезаемых. При этом между примитивами в явном виде привязки создать нельзя, создание привязок рассмотрено в [3].

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

1. Пересчитать размеры детали в середину допуска, они и будут параметрами.
2. Выбрать размер с наименьшим отношением допуска к номинальному размеру (R).
3. Выразить все параметры (остальные размеры детали) в долях от выбранного размера с учетом пересчета в середину допуска.
4. Записать в начале программы параметры, присвоить значение, выраженное через основной параметр формулой. Основному параметру присвоить номинальное значение.
5. С помощью параметров, примитивов и булевых операций над ними по чертежу или эскизу, учитывая базы для каждого размера, задать параметрическую модель изделия.

Рисунок 2.5. Прокладка. Пятый пункт требует пояснения. Рассмотрим прокладку, изображенную на рисунке 2.5. За начало координат примем точку пересечения осей симметрии габаритного прямоугольника с длинами сторон a и b. Если в начале программы были перечислены все размеры, то расположение левого нижнего угла габаритного прямоугольника (примитив прямоугольника требует задавать его расположение из левого нижнего угла) определяется формулами . Тогда расположение центров отверстий на осиX определяется по формулам для левого и для правого соответственно. В данном случаеопределяет базу. Если будет изменен размер, то произойдет автоматический пересчет расположения и размеров примитивов, и мы получим гарантированное положение отверстий относительно базы, поскольку в программе их положение так же зависит и от размера габарита. Таким образом, будет сохраняться постоянная привязка центров отверстий к габаритному прямоугольнику. Сами эти формулы и параметры должны быть указаны в операторах программы.

Источник: studfile.net