РАСШИРЕНИЕ ИНТЕРПРЕТАТОРА ПОСТПРОЦЕССОРА NX CAM

Введение. Настройка постпроцессора является неотъемлемой частью подготовки рабочей среды пользователя CAM - системы. Обусловлено это тем, что поставляемые вместе с CAM – системой стандартные библиотечные постпроцессоры не учитывают особенности конкретного станка, а управляющие программы, получаемые с их помощью, требуют серьезного последующего редактирования, особенно для станков сложной компоновки: 5 – осевых и токарно – фрезерных обрабатывающих центров [1]. Соответственно, правильная настройка постпроцессора и дополнение его всем необходимым функционалом является важной задачей, как для увеличения технико– экономических показателей при проведении технологической подготовки производства в целом, так и производительности отдельно взятого инженера-технолога.

Постпроцессор. В каждой CAM – системе используются свои уникальные постпроцессоры. Для них отличаются, как языки, на которых они реализованы, так и функционал, предоставляемый разработчикам постпроцессоров. В общем случае постпроцессоры бывают двух видов: внешние и встроенные (рис. 1).

Внешние постпроцессоры не привязаны к CAM – системе и работают с файлом CLData (Cutter Location Data). Данный файл содержит управляющую траекторию и является реализацией стандарта ISO-4343 1978. Данный формат реализуется почти всеми CAM – системами. А сам файл CLData является входным для внешних постпроцессоров [2, c. 10-20]. Учитывая все вышеперечисленное, реализация внешнего постпроцессора возможна на любом языке программирования и заложенные в него алгоритмы и функционал не зависят от CAM – системы, то есть разработанный однажды внешний постпроцессор, можно использовать с различными CAM – системами. Это является его главным достоинством. Но в то же время внешнему постпроцессору доступна только информация, заложенная в CLData файл, где отсутствуют многие параметры, как CAM – системы, так и разрабатываемых операций обработки. Например: тип и материал инструмента, количество режущих кромок, тип движения (подвод, врезание, резание, отвод) и т.д., то есть у внешнего постпроцессора отсутствует обратная связь с ядром CAM – системы.

Рисунок 1. Схема работы различных типов постпроцессоров.

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

1. Привязка к CAM – системе, то есть встроенный постпроцессор невозможно использовать в CAM – системах других производителей.
2. Реализация алгоритмов работы постпроцессора на внутреннем языке, заложенным разработчиком. Это могут быть, как языки высокого уровня, так и интерпретируемые скриптовые языки, а также различные реализации синтаксических анализаторов (parser).
3. Сильная ограниченность функционала внутреннего языка, то есть невозможность разработки собственных функций, методов и работа только с библиотекой, заложенной разработчиками.

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

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

Многие разработчики CAM – систем пытаясь объединить достоинства встроенного и внешнего постпроцессора, убирают основные ограничения, накладываемого интерпретатором за счет пользовательского расширения его функционала. Рассмотрим, как реализован данный механизм в одной из самых широко используемых CAM – систем современности NX CAM.

Снятие ограничений встроенного интерпретатора здесь реализуется за счет использования средств API (application programming interface) NXOpen (рис. 2).

Рисунок 2. Схема расширения интерпретатора через интерфейс NXOpen

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

Разработка новой команды постпроцессора. В качестве примера создадим и зарегистрируем для постпроцессора новую команду, отсутствующую в стандартном функционале. Новая команда будет выводить на экран текстовые сообщения оператору. Все стандартные команды встроенного постпроцессора в NX CAM начинаются с приставки MOM, поэтому, для поддержания единой стилистики в наименовании, вновь создаваемую команду также будем начинать с данной аббревиатуры, а список принимаемых параметров зададим следующим: MOM_message «Title» «MsgText». Здесь MOM_message – наименование команды, «Title» – заголовок сообщения, «MsgText» – текст выводимого на экран сообщения. Приставка MOM в названии команды расшифровывается как «Manufacturing Operations Management» (управление производственным процессом (операциями)). Manufacturing Operations Management – это методология, позволяющая повысить автоматизацию и прозрачность производственных процессов на предприятии, а также обеспечить тесное взаимодействие между инженерными службами предприятия и его производственными подразделениями.

Реализацию нового функционала проведем на языке C# с использованием интегрированной среды разработки Visual Studio 2013.

Для реализации интерфейса к проекту необходимо подключить соответствующие библиотеки интерфейса NXOpen, которые можно найти в каталоге по адресу: <Корневой каталог NX>\NXBIN\managed. Здесь необходимо подключить следующие библиотеки:

• NXOpen – для получения доступа к текущему сеансу работы NX;
• NXOpen.UI – для получения доступа к интерфейсу и механизмам текстовых сообщений;
• NXOpen.UF – для получения доступа к текущему сеансу работы интерпретатора постпроцессора;

После чего ссылки на компоненты NXOpen проекта Visual Studio будут выглядеть следующим образом (рис.3).

Рисунок 3. Ссылки на компоненты NXOpen проекта Visual Studio

Далее представлен исходный текст полученной программы на языке C#.

public static void Main(string[] args)

        {

            IntPtr param = new IntPtr(0);

            IntPtr mom_id;

            NXOpen.UF.UFSession ufSession =  

            NXOpen.UF.UFSession.GetUFSession();

            UFMom mom = ufSession.Mom;

            mom.AskMom(param, out mom_id);

            UFMom.CommandFunc cfunc =

            new UFMom.CommandFunc(message);

            mom.ExtendXlator(mom_id, "MOM_message", cfunc);

        }

  static int message(IntPtr ptr1, IntPtr ptr2, int num, string[] str)

        {

            NXOpen.UI ui = NXOpen.UI.GetUI();

            NXMessageBox msg=ui.NXMessageBox;

            msg.Show(str[1],NXMessageBox.DialogType.Information,str[2]);

            return 0;

        }

    public static int GetUnloadOption(string dummy)

        {

            return (int)NXOpen.Session.LibraryUnloadOption.Explicitly;

         }

Здесь Main главная точка входа программы, в котором происходит расширение синтаксиса интерпретатора. Алгоритм работы данного метода следующий. Во-первых, посредством объекта ufSession типа NXOpen.UF.UFSession, хранящая экземпляр текущего сеанса работы NX, осуществляется вызов объекта mom типа UFMom, которая хранит в себе экземпляр интерпретатора постпроцессора. Далее происходит вызов текущего сеанса работы интерпретатора посредством метода mom.AskMom. Создается делегат cfunc типа UFMom.CommandFunc с указателем на пользовательскую функцию message и посредством метода mom.ExtendXlator происходит расширение интерпретатора. Как видно из сигнатуры данного метода в качестве первого параметра передается указатель на текущий сеанс работы интерпретатора mom_id, далее название новой команды MOM_message и делегат на пользовательский метод cfunc.

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

Сигнатура пользовательской функции следующая: int UserFunc (IntPtr ptr1, IntPtr ptr2, int num, string[] str), где int – тип возвращаемого значения (всегда int), UserFunc – имя пользовательской функции (может иметь любое значение). Типы входных переменных также неизменны. Первые два параметра ptr1 и ptr2 – указатели на тип Int, параметр num – содержит номер вызываемой сессии, массив строк string[] – содержит параметры переданные постпроцессором пользовательской функции.

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

Для этого в событие начала программы введем вызов функции регистрации новой команды, которая имеет следующую сигнатуру: MOM_run_user_function <shared_library_name> <entry_point_name>, где <shared_library_name> - полный путь к разработанному исполняемому файлу или динамической библиотеки пользователя, <entry_point_name> - главная точка входа. Для разработанного примера данная команда в исходном тексте постпроцессора будет иметь следующий вид:

Рисунок 4. Начальный вызов механизма регистрации

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

Используем вновь разработанную команду в событие конца программы. В исходном тексте постпроцессора она будет иметь следующий вид:

Рисунок 5. Вызов разработанной команды

Результатом работы команды будет сообщение, выводимое оператору (рис.6).

Рисунок 6. Результат работы команды

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

Список литературы:

1. Урманов М.Д. Особенности разработки постпроцессора для работы в модуле NX CAM [Электронный ресурс] //Материалы VIII Международной студенческой электронной научной конференции «Студенческий научный форум» - URL: http://www.scienceforum.ru/2016/2155/18735 (дата обращения: 31.07.2017)
2. Мальцев А. Генератор постпроцессоров в CAD/CAM ADEM [Электронный ресурс] / Мальцев А., Сальников А.  // САПР и графика. – 2000 – N8 – С.10-20. – URL: http://sapr.ru/article/7791 (дата обращения: 18.01.2018).