Pro/Engineer почему ошибается постпроцессор

[konst 10]

Уважаемый метр Kamilovich. Согласен перенести дискуссию сюда. Аськи внешней у меня пока к сожалению нет, но я в ближайшее время этим озабочусь и сделаю. А насчет IJK вместо R, так я только так и делаю - центр окружности указывается однозначно, но неправильно, вот такие чудеса.

[konst 10]

Уважаемые господа, для тех, кто не в курсе, краткое содержание обсуждаемого вопроса.

Столкнулсь с таким багом: Proe2001 (да и proe2000i тоже) при расчете эквидистантной траектории с оффсетом на инструмент ошибается в координатах центра дуги при круговой интерполяции, причем лишь иногда. Пробовал играть геометрией детали и настройками постпроцессора, но закономерностей выявить не удалось. При линейной интерполяции по точкам расчет эквидистанты идет отлично, но программа получается невыносимо тяжелой для перфоленты и мозгов древней стойки 2М43. Баг удалось выявить не сразу, пару раз положил стонок на концевики, потом проверил GM код Predatorом и стало ясно где собака порылась. Кто сталкивался с подобным, посоветуйте, можно ли как-нибудь с этим побороться.

[IBV 112]

Скорее всего неправильно выполняется округление чисел. Если я прав, то ошибка небольшая, не более 0,01 мм. Да?

[Гость Kamilovich_]

konst Пришлите мне на e-mail *.ncl.* , *.tap c "багом", а также  uncx01.p0* и uncx01.f0* Вашего станка. В понедельник посмотрю.

e-mai kamilovich@hotbox.ru

[konst 10]

Уважаемый IBV. Тут вы как раз правы, чаще всего ошибка менее 0,005. Но ожидаемое устранение бага путем увеличения точности отработки траектории или (что не всегда возможно при работе с INTRALINK) увеличением точности самой модели к сожалению не происходит - пробовал.

[IBV 112]

Увеличение точности может не помоч, если неправильно организовано округление в постпроцессоре. Подробнее сказать не могу т.к. не работаю с ПроЕ

[konst 10]

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

[IBV 112]

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

    А про округление, чтоб было понятно, такой пример. Число 51.444444444444444444444444445 - это сколько?

[Гость bigBUG]

Число 51.444444444444444444444444445 - это сколько?

что значит сколько? а сколько значаших цифирей после запятой, а докуда округляем? до десятков :)?

[IBV 112]

Вот, вот... Неплохо бы обо всём этом знать.

[Гость UAV1]

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

[SVN 0]

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

А вот это зависит от стойки (математики). :)  У меня есть пара импортных (с громким названием FERRARY) станков, где при несовпадении (погрешность округления) станок отработает полную окружность + необходимый "кусочек". Долго я сидел с постпроцесором к этим станкам, потом плюнул и сделал в посте вывод программ для 4 знаков после запятой, доверив округление самому станку. Проблема отпала. :).

[SVN 0]

  Вообще то я с такими проблемами сталкивался. Были проблемы со станками эрозионной группы, оборудованные стойкой 2М43-55 и со станками итальянскими. Проблема возникает только при включенной G41, G42 или работе с офсетом. Довольно часто эта проблема возникает на станках, где X,Y - абсолюты, а I,J - в относительной системе.

  В случае с итальянскими станками решение было проще - станок оборудован встроненым компом (286 процесор) и имеет отрисовку графики. Поэтому там все видно. Мы просто переключили постпроцесор на создание 4 знаков после запятой, благо станок это позволяет.

  В случае 2М43-55 - дело сложнее. Такие ситуации возникают раз в полгода, при работе с эквидистантной коррекцией. И это было связано с геометрией детали и погрешностью округления до 0.001 мм. Я уж сейчас не помню, как выкрутился из этой ситуации, надо посмотреть и вспомнить. В случае, если  это возникает на станке, где X,Y - абсолюты, а I,J - в относительной системе - можно попробовать переписать постпроцеор. В любом генераторе постов, можно использовать уже готовое значение дельта для I,J или самому вычислять разницу а потом ее выводить в кадр. Результат обычно и состовляет искомую погрешность округления в 0.001мм. Если это не поможет, то дело уже в системе.

[SVN 0]

Число 51.444444444444444444444444445

Система для NC обработки вычисляет обычно с гарантированой точностью от 4 до 6 знаков после , и любой генератор постов работает только с тем количеством чисел после запятой, которое указали в паспорте + 1. Хотя быть может я и не прав?  Поэтому  - 51.444 :)  

[Гость UAV1]

генератор постов работает только с тем количеством чисел после запятой, которое указали в паспорте + 1.

Нет генератор работает с числами двойной точности (Симатроновский GPP например). Все вычисления ведутся именно с ней, а уж при выводе в  G-код все округляется до заданной точности.

[SVN 0]

Нет генератор работает с числами двойной точности (Симатроновский GPP например). Все вычисления ведутся именно с ней, а уж при выводе в  G-код все округляется до заданной точности.

Я неправильно выразился - подразумевалось, что округление так идет - "генератор постов работает только с тем количеством чисел после запятой, которое указали в паспорте + 1."

[Гость UAV1]

   В последнем NCManagere появилась возможность указывая на участок траектории получать геометрическую информацию - углы с соседним участком, углы с станочными осями, радиус дуги, координаты центра, и т.д. и т.п.  Я раньше как-то и не задумывался, но выяснилось что абсолютно гладких контуров в траектории обработки нет. На железе не заметно конечно.  

[Гость sapr2000]

Тематика данного топика являет собой классическую пробелму постпроцессирования. Расчет перемещений по координатам каждый разработчик постпроцссора(в том числе и универсального) решает по своему. Кто-то все перемещения ведет в абсолюте, кто-то только в перемещениях, остальные используют симбиоз, например - абсолют конечной точки + приращение на отрезке нового перемещения. Все вычисления перемещений внутри постпроцессора ведутся в плавающей арифметике с  сумашедшей точностью(64 разряда). Редкая стойка работает в мм, поэтому любой сколь угодно малый ход по координате надо перевести в импульсы. Т.е. в число, например, с ценой импульса 0.001 или 0.0001. Перевод в импульс особо малого перемещения может привести к его занулению, т.е. это ход в кадр выдавать бессмысленно, он стойкой не отработается. Но следующее перемещение имеет чуть-чуть другую начальную координату!  Возникает разрыв. На разных стойках это проявляется весьма разным образом. Поэтому мы в APTIPP применяем  более изощренные способы  борьбы с проблемой "0.1 импульса". Пишется макро, специализированная для каждой стойки(обычно экс-советской). Описываемые  бяки часто  возникают при эквидистантной коррекции, где смещение инструмента в процессе обработки(задается корректором) может привести к выкидыванию целых участков небольших по размеру кривоинейных перемещений(обычно скругляют ломанный контур).

[Гость bigBUG]

Редкая стойка работает в мм,

Константин, простите, не совсем понял - вы имеете в виду, что в кадрах УП для большинства стоек задаются импульсы, а не линейные единицы? Или это вы уже про работу интерполятора пишите?

[Гость sapr2000]

MFS

Понятно, что технолог проектирует траекторию движения в мм. Но большинство стоек воспринимают перемещение X,Y  в G-коде как число импульсов шагового мотора. Цена импульса (во многом определяет точность изготовления) бывает разная. Перевод мм->импульс делает постпроцессор. Перевод движения по кругу с малым радиусом, с величиной дуги в несколько градусов и эквидистантной коррекцией(в  сторону уменьшения радиуса) может привести к "отбрасыванию" такого элемента т.е. не будет такой крохе в (мм)   соотвествовать элемент в импульсах. Вот одна из причин ошибки GPOST. А если G-код выдается в отностительной с-ме координат, то идет смещение траектории, она "ломается" на крошечные величины.

ИМХО.