Главная страница

 For english reader

 Новости (01/01/2002)

 САПР-ЧПУ/2000

 APTIPP для CAD/CAM

 Верификатор УП

 Постпроцессоры

 Прайс-лист

 Ответы на вопросы

 Небольшие секреты

 Демоверсия

 Рассылка новостей

 Форум о САПР

 Гостевая книга

 Об "Евразии Лтд"

 CAD/CAM портал

 Наша библиотека

 О вебмастере









Наша библиотека

Филиппович К.В.
"Идеология постпроцессирования в современных CAD/CAM-системах"
Россия, ООО Евразия Лимитед, 2000

Итак, что же такое постпроцессор?

         Даже студент технологического факультета ответит с первого раза - это модуль, преобразующий файл траектории движения инструмента и технологических команд, рассчитанный процессором CAM- или CAD/CAM-системы, в файл управляющей программы в строгом соответствии с требованиями методики ручного программирования конкретного комплекса "станок-система с ЧПУ". Постпроцессор выполняет немалое количество функций, например:
-кодирует линейные перемещения сообразно цене импульса;
-выполняет линейную или круговую интерполяцию перемещений по дуге окружности, а также кодирует их в импульсах;
-рассчитывает динамику перемещений, отслеживая и, если нужно, уменьшая слишком большую подачу на малом перемещении("станок не успеет разогнаться");
-автоматически выдает в кадр вектора или функции коррекции на радиус инструмента;
-строит текущий кадр по шаблону, автоматически нумеруя кадры под адресом N;
-превращает подачи, назначенные технологом, в конкретный набор символов с адресом F и выдает в нужное место кадра.
-оформляет как начало, так и конец УП, а также структуру кадра.
         На самом деле число функций, выполняемых среднестатистическим постпроцессором больше, значительно больше! Как, например, научить постпроцессор выдавать в кадр перемещения только по тем координатам, движения по которым имело место? Или как определить выпуклость/вогнутость контура детали для правильного расчета вектора корpекции? Скажем в заключении, что разработка добротного постпроцессора с нуля(т.е. без средств автоматизации постпроцессирования) займет у программиста средней квалификации не менее 6 месяцев.

2. Индивидуальный постпроцессор(сначала был дух...)

         Исторически сложилось так. Для каждого комплекса "станок-система с ЧПУ" специально обученный программист разрабатывал индивидуальный постпроцессор. Далее происходил длительный процесс доводки постпроцессора, путем активных консультаций с технологом-расчетчиком управляющих программ, а также опытными прогонами управляющих программ (рассчитанных при помощи постпроцессора) на станке с ЧПУ. Наконец, постпроцессор "сдавался" в опытную эксплуатацию Заказчику. Затем наступал процесс исправления ошибок и неучтенных при разработке особенностей программирования стойки и даже (!) технологии изготовления деталей, принятых на данном предприятии. В итоге - рождался таки постпроцессор, индивидуальный для данного станка, стойки ЧПУ и нередко - технологии обработки. Стоимость разработки индивидуального постпроцессора была отчаянно высока - от 500 до 1500$. Исправить ошибки и сделать нововведения в постпроцессоре мог сделать только программист, разработавший данный постпроцессор. Через индивидуальное постпроцессирование, как исторически первый и естественный способ разработки постпроцессоров, прошли все фирмы, как отечественные, так и зарубежные, примерно в 1960-1970 годах прошлого столетия. Удивительно, но ранние версии русских CAD/CAM-систем, появившихся на свет всего каких-то десять лет назад, также не обошли стороной метод индивидуального постпроцессирования.
         Далее путь эволюции постпроцессирования развивался так. С одной стороны в 80-х годах прошлого века наблюдался всемирный бум автоматизации машиностроения, с другой - как грибы плодились новые станки с непременно новой системой ЧПУ, с третьей стороны возник небывалый спрос на САПР для таких станков со стороны заводов и компаний . В этих условиях программисты, разработчики-постпроцессоров, просто не успевали писать и отлаживать новые постпроцессоры. Эти объективные причины подтолкнули разработчиков постпроцессоров к идее автоматизации собственного труда - т.е. средств автоматизации разработки постпроцессоров.

3. Обобщенный постпроцессор(жив еще, курилка...)

         Для начала программисты стали обобщать информацию об использовании одной и той же системы с ЧПУ вместе со станками различных производителей, но одного принципа обработки(например, токарное). Выяснилось, что управляющие программы для таких станков, "вооруженных" однотипной системой с ЧПУ, различались в лучшем случае незначительными вариациями в оформлении структуры кадра, значностью перемещений, оформлением начала и конца программы.
         Поэтому вскоре родилась идея обобщить алгоритмы разработки постпроцессоров на однотипное оборудование разных фирм, но имеющее одну и туже систему с ЧПУ. Идея использования обобщенных постпроцессоров была поистине революционной. Ведь разработка постпроцессора для новой модификации станка с системой ЧПУ, для которой уже имелся обобщенный постпроцессор, требовала от программиста всего лишь небольшой модификации узкого набора программ для учета ососбенностей нового оборудования.
         Это сокращало в разы сроки, стоимость и трудоемкость разработки нового постпроцессора; способствовало снижению издержек фирм-разработчиков постпроцессоров и их заказчиков, оказало сильное воздействие на конкурентную борьбу между производителями CAM-систем в мире. Выигрывал тот, кто дешевле и быстрее обеспечивал клиента готовым постпроцессором. Кроме того, некоторые фирмы продавали именно "обобщенные постпроцессоры" на 5-10 станков с одной системой с ЧПУ по цене одного индивидуального, что было выгодно их клиентам и чрезвычайно невыгодно фирмам-конкурентам, еще не освоившим эту технологию.

4. Обобщенный постпроцессор. Возрождение идеи ?

         Как не парадоксально, но небольшое число современных CAM-систем до сих пор используют в своем составе обобщенные постпроцессоры. Однако постепенно устаревающая технология неожиданно получила оживляющий импульс - в таких системах теперь используются автоматические корректоры кадров управляющих программ. Суть "ноу-хау" - дать возможность разработчику или пользователю описать на специальном макроязыке изменения, которые затем автоматически и последовательно выполняются постпроцессором над каждым кадром во время формирования управляющей программы(УП).
         Таким образом, можно, например, вставить в кадр новый адрес и значение (например, некую функцию G99), удалить неверный или ошибочно сформированный адрес и значение(например, N0100) или заменить адрес со значением (например, F9000 на G00). Безусловно, макроязык, на котором программируются такие операции, более сложен и зависит от фантазии разработчика. Например, в ряде языков есть и более крупные модификаторы типа "удалить весь кадр" или "вставить новый кадр".
         Автоматические корректоры позволяют "законсервировать" обобщенный постпроцессор. А огрехи его настройки на язык нового комплекса "станок-система с ЧПУ" попытаться исправить при помощи составления макропроцедур. Этот метод, впервые примененный в системе PEPS, дал свои плоды - макроязык коррекции кадров УП применяется теперь весьма широко и не только в обобщенных постпроцессорах.
         А недостатки такого метода постпроцессирования видны на лицо. Да, используя макроязык, можно менять неверные адреса перемещений. Да - можно менять структуру кадра. Можно, наконец, вставить даже последовательность техкоманд. Но поскольку макропроцедура может изменять только один(текущий) или два(текущий и последующий) кадры, сформированные постпроцессором, то более сложные режимы выдачи техкоманд в виде цепочек символов, выдаваемых в совокупность кадров(да еще с предыдущим и последующим перемещением), реализовать на макроязыке можно, но весьма не просто.
          Кроме того, если макроязыком допускается корректировка только символьной строки сформированного кадра, то нельзя при помощи макро изменить величины перемещений, тип расчета интерполяции кривых, способ расчета перемещения(абсолют или приращения). Ибо в символьном кадре УП перемещения инструмента переведены в импульсы. Упорное непонимание глубины этой проблемы, приведет корректировщиков перемещений в сформированных символьных кадрах к искажению траектории движения резца или фрезы.
         Подводя итог, можно констатировать, что автоматические корректоры УП в обобщенных постпроцессорах позволяют поочередно исправить кадры сформированной программы, а в ряде реализаций - не допускают изменений значений адресов, если это касается перемещений по линейным и круговым элементам траектории. Таким образом, обобщенное постпроцессирование с макроязыком автоматической коррекции, безусловно, имеет право на жизнь, хотя и не лишено ограничений и недостатков при очевидной простоте реализации. Поскольку технология подразумевает овладевание макроязыком и диаграммой работы постпроцессора, то весьма трудно предположить ее полную прозрачность для рядового технолога. А следовательно, по-прежнему, этот метод правильнее позиционировать как инструмент разработчика, а не пользователя(хотя это и рекламируется в ряде CAM-систем).

5. Универсальные постпроцессоры(на сем стоим...)

         Почти одновременно с появлением методологии обобщенного постпроцессирования, программисты-разработчики постпроцессоров пришли к осознанию совершенно другой идеи. Зададимся вопросом - что делают два совершенно разных постпроцессора(причем неважно, индивидуальных или обобщенных)? Они последовательно читают записи из файла траектории движения инструмента и техкоманд (далее CLDATA-файл) и выполняют преобразование этих записей в один или несколько кадров управляющей программы по некоторым правилам, отличным для разных станков и систем ЧПУ.
         А что, если сопоставить каждой записи CLDATA-файла алгоритм ее превращения в кадр управляющей программы и сохранить эти правила отдельно для каждого станка-системы ЧПУ в виде файла. Тогда можно создать один универсальный постпроцессор как машину, транслирующую каждую запись CLDATA-файла в кадр(ы) управляющей программы по правилам, которые можно подгружать из внешних файлов!!!
         Такой метод получил название "универсальный постпроцессор". Программист описывал алгоритмы обработки каждой записи Cldata-файла применительно к методике ручного программирования конкретного комплекса "станок-система с ЧПУ" и сохранял эти правила(алгоритмы) в виде текстовых файлов-постпроцессоров. А технолог лишь выбирал - при помощи какого файла-описателя алгоритмов, преобразовать свой Cldata-файл в файл управляющей программы.
         Эта блестящая идея, заимствованная из методов построения трансляторов с настраиваемой лексикой и семантикой, получила широчайшее развитие на рубеже 90 годов прошлого века. Подавляющее большинство CAD/CAM-систем используют сегодня именно такой метод для решения проблем постпроцессирования.

6. Преимущества универсального постпроцессирования

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

7. Недостатки универсального постпроцессирования

1. По-прежнему постпроцессоры разрабатываются и отлаживаются Разработчиком. Лишь 10-15% предприятий позволяют себе содержание квалифицированных программистов, знакомых с технологией машиностроения и обработки на станках с ЧПУ и способных самостоятельно описать, отладить или модифицировать алгоритмы для генераторов постпроцессоров. Таким образом, среднестатический генератор постпроцессоров пока остается в массе скорее плохо отчуждаемым продуктом, чем инструментом технолога.
2. Реализации универсальных постпроцессоров многообразны. Но, как правило, интерпретатор алгоритмов оперирует с одной записью CLDATA-файла. Выдача техкоманд составного вида, например,одновременно с предыдущим перемещением, текущим и последующим перемещением, ставит пользователя в тупик. Выходы, конечно, есть. Но они очевидны только для разработчиков таких генераторов и вряд ли прозрачны для конечного пользователя.
3. Универсальные постпроцессоры весьма непросто настроить на морально устаревшее российское оборудование. Особенно со сложной системой требований к расчету режима разгона-торможения(например, СФП-3 с системой ИЛ4). Автору статьи известны несколько предприятий, где это оборудование числом более 200 станков успешно применяется до сих пор. Попутно заметим, что на текущем этапе 90% заводов не могут позволить себе обновить станочный парк(цена зарубежного станка составляет примерно 250-500 тысяч долларов).

8. Инвариантное постпроцессирование.

         Метод "Инвариантное Постпроцессирование(ИП)", рожденный в Роcсии первой половине 70 годов, стоит обособленно в ряду других, ранее рассмотренных нами методов постпроцессирования. Основная идея метода заключается в его названии, т.е. Инвариантности постпроцессора от особенностей станка и языка программирования системы ЧПУ. Иными словами Инвариантный Постпроцессор может быть настроен на генерацию программ для любых типов станков и любых систем с ЧПУ. Вы скажете - хм, так это умеет и универсальный постпроцессор! Но не тут то было. Вторая идея описываемого метода состоит в том, что настройка Инвариантного Постпроцессора на конкретный комплекс "станок-система ЧПУ" состоит не в написании алгоритмов трансляции "CLDATA->кадр УП", а в заполнении анкеты(паспорта), в которой всего лишь перечисляются параметры станка и системы с ЧПУ. И наконец, последней, но весьма важной идеей рассматриваемого метода является полная отчуждаемость от Разработчика, иными словами, изначально Инвариантный Постпроцессор является инструментом технолога, а не программиста!
         Метод Инвариантного Постпроцессирования практически воплощен в линейке совместимых систем САП-ЕС, САП-СМ, САПР-ЧПУ и за 25 лет своего существования доказал как правильность идеи, так и блестящие результаты его применения. Это один их немногих Постпроцессоров, который технолог средней квалификации сможет самостоятельно настроить на любой новый комплекс "станок-система ЧПУ" без консультации с разработчиком или услуг программиста.

9. Преимущества Инвариантного Постпроцессирования

1. Покупая Инвариантный Постпроцессор один раз, технолог получает инструмент, при помощи которого он сможет действительно самостоятельно настроить свою CAM-систему на любое оборудование с ЧПУ;
2. Инвариантный Постпроцессор можно настроить как на любые современные, так и на морально устаревшие системы с ЧПУ;
3. Инвариантный Постпроцессор поддерживает все возможности современного оборудования с ЧПУ - подпрограммы, автоциклы, обеспечивает автоматическую сборку УП и подпрограмм, написанных технологом.
4. Инвариантный Постпроцессор позволяет технологу описать сколь угодно сложные методы выдачи техкоманд, новые типы интерполяции, расчета динамики перемещений или коррекции и многое другое, поскольку включает макроязык, позволяющий технологу самостоятельно расширять возможности Инвариантного Постпроцессора.
5. Инвариантный Постпроцессор это продукт, действительно отчуждаемый от Разработчика, это инструмент Технолога.

Чей метод лучше?

         На мой взгляд, каждый из четырех рассмотренных нами методов имеет право на жизнью. Однако -
Индивидуальное постпроцессирование оправдано только при создании постпроцессора для уникального оборудования. Например, для 5 координатного фрезерного оборудования. Таких станков на производстве - считанные единицы. Расчет перемещений сугубо индивидуален для каждого комплекса "станок-система с ЧПУ". Если же говорить об индивидуальном постпроцессировании на 3-х координатное фрезерное или токарное оборудование, то здесь этот метод давно морально устарел.
Обобщенное постпроцессирование пожалуй, самый тупиковый метод. Сочетает все недостатки - неотчуждаемый от разработчика, требующий программирования при настройке на новое оборудование, замкнутый только на группу оборудования или систем с ЧПУ. Системы, имеющие в своем составе обобщенные постпроцессоры, еще продаются в Роcсии, но мне кажется, что трезвомыслящий технолог вряд ли должен отдать им предпочтение.
Универсальные постпроцессоры пожалуй, наиболее предпочтительны. При известном умении и опыте программисты на заводах смогут адаптировать их на заводское оборудование. Не смогут - закажут разработчику, правда, заплатив приличную сумму. Поэтому этот метод является весьма выгоден разработчику - можно быстро разрабатывать постпроцессоры для заводов и взимать с них за это дополнительные суммы. На сегодня этот метод исторически наиболее распространен.
Инвариантный постпроцессор - мечта грамотного технолога. Легкая и быстрая настройка на новое оборудование, выполняемая самим технологом и не требующая дополнительных оплат разработчику. Идеальный метод. Но, увы - имеется в чистом виде только в одной российской системе САПР-ЧПУ/2000. Воплощения метода в других системах исказили его почти до неузнаваемости и по сути выродили метод до универсального постпроцессирования.