G-POST, много вопросов. Хочется понять логику работы.

[Ivav 0]

попытка исправить ошибку по REPLAC

Постпроцессор отрабатывает весь код до конца. Но теперь не выводятся DR+ и DR- в круговых интерполяциях.

[Ivav 0]

Получается вот что. В FIL файле есть макрос под названием HEID, если в нем закоментить TT=TEXT/'C';REPLAC/L2TXT,TT,1,1 то постпроцессор отрабатывается полностью, но не выводятся DR+ DR-.

 

HEID = MACRO/
$$ Macro to Process Heidenhain motion
$$ Input is BUF from the auxiliary file
$$ Check if I was programmed (this means that this is a
$$ circle
II=TEXT/'I'
IPOS=INDXF(BUF,II)
IF(IPOS.NE.0) THEN
  $$ Remove everything after I
  BUF=TEXT/RANGE,BUF,1,IPOS-1
  $$ Last I and J values outputed
  IVAL=POSTF(1,3,(355+I))
  JVAL=POSTF(1,3,(355+J))
  $$ Output Center positioning
  POSTN/OUT,U,0,X,IVAL,Y,JVAL
ENDIF 
$$ Check if CIRCLE
L2TXT=TEXT/'L2';
OKL2=INDXF(BUF,L2TXT)
IF (OKL2.NE.0) THEN
  $$ Replace L2 by C and add DR- at the end
  $$ of the block
  TT=TEXT/'C';REPLAC/L2TXT,TT
 
  STR=TEXT/BUF,' DR-'
  ELSE
  L3TXT=TEXT/'L3';
  OKL3=INDXF(BUF,L3TXT)
  IF (OKL3.NE.0) THEN
    $$ Replace L3 by C and add DR+ at the end
    $$ of the block
    TT=TEXT/'C';REPLAC/L3TXT,TT
   
    STR=TEXT/BUF,'DR+'
   
  ELSE
    $$ Linear motion, add M90 at the end of
    $$ the block
    STR=TEXT/BUF,' '
  ENDIF
ENDIF
$$ Issue the motion
INSERT/' ',STR,'$'

Если уберем в коде макроса 1,1 ( получим TT=TEXT/'C';REPLAC/L3TXT,TT), то мы получим что постпроцессор отработает блок HEID по одному разу, т.е DR+ DR- выведется в g коде по одному разу.

 

............куча кода без DR

162  L X30.46
163 CC X0 Y-.053
164  C X30.466 Y-1.5  DR- <<<< первый DR
165  L X31.497 Y-1.5
166  L Y-2.5
167  L X52.5

...........куча кода без DR

415  L X17.988 Y-4.373
416 CC X14.771 Y-9.437
417  C X9.707 Y-6.22 DR+<<<<< второй DR
418 CC X0 Y-.053
419  C X9.707 Y-6.22

.....куча кода без DR

 

Как заставить макрос HEID обрабатывать каждую строку ??

[DJ Astro 62]

Лучше всего избавиться от REPLAC в этом макросе. А дополнительно ввести проверку - какое направление круговой интерполяции, CW или CCW. И в зависимости от того, чему равна переменная INTCOM538 после обработки дуги постом (2 - CW, 3 - CCW) далее добавлять в кадр DR- или DR+.

 

Вроде бы работает, проверьте...

 

HH3.zip

[Force@ 0]

Добрый день!

Подскажите, пожалуйста! На многогранной детали расположены одинаковые отверстия, создаю сверление, затем круговой массив обработки, в creo обработка выводится нормально. Проблема возникает при обработке постпроцессором, правильно выводит углы в цикле PLANE SPATIAL только на первом отверстии, на последующих углы поворота не меняются. Причину нашел. Пост обрабатывает вектора через CAMERA по примеру DJ Astro. Проблема в том, что при обработке именно массивом в CL Data команда CSYS выводит одни и те же вектора, несмотря на поворот.

 

Если сделать без массива, создавая отдельный цикл сверления на каждый поворот, все работает правильно. Можно ли как то решить проблему именно при создании массива обработки?

[DJ Astro 62]

Попробуйте создавать массив не через "Массив", а через "Подпрограммы". И в окне с настройками в разделе "Стиль вывода CL" поставьте галочку "Копировать положение резца". 

Попробовал так сделать - всё получилось. Каждый новый элемент массива выводится с новой матрицей поворота.

 

 

 

 

[Force@ 0]

Спасибо за помощь! Как всегда выручаете. Подпрограммами раньше пользоваться не приходилось

[LxCoder 36]

Добрый день!

Подскажите, пожалуйста! На многогранной детали расположены одинаковые отверстия, создаю сверление, затем круговой массив обработки, в creo обработка выводится нормально. ... Проблема в том, что при обработке именно массивом в CL Data команда CSYS выводит одни и те же вектора, несмотря на поворот.

 

Ну ребят, ну это бред.

Creo2 выводит в массиве каждый его элемент как отдельный сиквенс.

Иная ситуация в более ранних версиях ProE, например, в WF3. Но и там ну никак не сохраняются значения вектора инструмента, если подразумевается поворот. Просто он выводится для каждого положения резца, например: 

GOTO / 90.9298528148, -52.4983750000, -6.4849908428,  $

0.8660254038, -0.5000000000, 0.0000000000

RAPID 

GOTO / 0.0000000000, -104.9967500000, -6.4849908428,  $

0.0000000000, -1.0000000000, 0.0000000000 

 - здесь очевидно разные расположения резца (об этом говорят последние 3 числа в кадрах позиционирования)

 

Так что не нужно городить этот огород с "подпрограммами" - они как бы вообще не для этого предназначены. Просто или вы сами что-то неправильно определяете в массиве (что вряд ли), либо просто используете кривенький пост (что вероятнее всего).

Для надежности возьмите любой стандартный 5-ти осевой пост (например, SHODA или CINCINATTI - они есть в стандартной библиотеке постов) и прогоните УП. Я уверен, что в нем вы повороты увидите (если конечно в ProE все сделали правильно...)

[DJ Astro 62]

LxCoder, возможно Force@ неточно описал вопрос.
Всё правильно - если делать массив сиквенса, то каждый элемент массива выводится как отдельный сиквенс. Только система координат каждого сиквенса не изменяется в соответствии с преобразованиями, заданными в массиве, а остаётся постоянной во всех сиквенсах. Преобразовываются только вектора точек в каждом сиквенсе из массива.
CL получается таким:

CSYS / 1.000, 0.000, 0.000, 0.000, $
            0.000, 1.000, 0.000, 0.000, $
            0.000, 0,000, 1.000, 0.000
GOTO / 90.9298528148, -52.4983750000, -6.4849908428, $
0.8660254038, -0.5000000000, 0.0000000000
RAPID
$$END
CSYS / 1.000, 0.000, 0.000, 0.000, $
            0.000, 1.000, 0.000, 0.000, $
            0.000, 0,000, 1.000, 0.000
GOTO / 0.0000000000, -104.9967500000, -6.4849908428, $
0.0000000000, -1.0000000000, 0.0000000000

В итоге эти переходы из массива невозможно вывести как 3+2, т.к. углы для PLANE SPATIAL вычисляются из CSYS, а CSYS от перехода к переходу не меняется. Из ijk точек их тоже не вычислишь.

Если же использовать подпрограммы, то новая ориентация элемента массива отражается в CSYS, а ijk каждой точки =0,0,1. Тогда всё хорошо преобразуется в 3+2.



LxCoder, подскажите, пожалуйста, а для чего тогда используются "подпрограммы"?

[LxCoder 36]

...

В итоге эти переходы из массива невозможно вывести как 3+2, т.к. углы для PLANE SPATIAL вычисляются из CSYS, а CSYS от перехода к переходу не меняется. Из ijk точек их тоже не вычислишь.

Нормальный постпроцессор не работает через CSYS. В G-Post достаточно математического аппарата, чтобы все вычислить по одному вектору инструмента и начальному положению СК (и скажу по секрету, даже не прибегая к трехмерным преобразованиям). Все работает. Ищите (или делайте сами) нормальные посты.

 

"Подпрограммы" нужны для оформления подпрограмм, например, когда не один сиквенс, а группа сиквенсов в определенной последовательности используется несколько раз в обработке. Тогда через определение подпрограмм в ProE можно обозначить эту группу сиквенсов для вывода в отдельную программу с отдельным номером чаще всего в относительных координатах (в приращениях), хотя тут возможны варианты... И тогда нормальный постпроцессор распознает начало подпрограммы и оформит ее как отдельную и в этом же файле создаст вам и основную программу с вызовами подпрограмм (в Фануке например через G65 PXXXX и т.п.). Таким образом сокращается объем файла УП и появляется возможность одновременно поправить на станке  все повторяющиеся элементы. 

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

 

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

[Bastion 20]

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

Будьте добры, выложите.  

[LxCoder 36]

Будьте добры, выложите.  

https://cloud.mail.ru/public/BVfH/91GXtQHue

Особенно это оправдано на станках с маленьким объемом оперативной памяти, в многоместных приспособлениях и т.п. В примере лежит пример обработки в Creo2 и tap файл после нормально настроенного на обработку команд DEFSUB, CALSUB и ENDSUB постпроцессора. Никаких ручных вводов - все выдается автоматом в один файл. Вот для этого нужны подпрограммы. Ради смеха попробуйте отмассивить ту же обработку и получить размер УП на порядок больше.

[DJ Astro 62]

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

Хорошо,  с подпрограммами всё ясно. Я думал, что под "подпрограммами" в ProE скрыто что-то другое, чего я не знаю. А так, что такое подпрограммы и как "оно" работает применительно к УЧПУ - здесь всё понятно, вопросов нет. :)

Кстати, результат "подпрограммирования" с параметром "Копировать положение резца" ничем не отличается от "массивирования"..... он без DEFSUB'ов, CALSUB'ов... 

Тут у кого-то на форуме в подписи такая фраза: "Инженера устраивает любое техническое решение, приводящее к положительному результату."

Если результат с подпрограммами легко привел к нужному положительному результату - то почему бы им не пользоваться?

 

 

Хотелось бы всё-таки разобраться с этим вопросом:

Нормальный постпроцессор не работает через CSYS. В G-Post достаточно математического аппарата, чтобы все вычислить по одному вектору инструмента и начальному положению СК (и скажу по секрету, даже не прибегая к трехмерным преобразованиям). Все работает. Ищите (или делайте сами) нормальные посты.

Почему пост, работающий через CSYS вдруг считается "ненормальным", если даже в самом G-POST'e на вкладке Planar Machining предлагается на выбор "ненормальный" вариант работы - через CSYS ?

LxCoder, Вы можете немного пояснить, чисто с математичекой точки зрения - как можно вычислить повороты системы координат только по положению оси Z (вектора инструмента)? Куда в этом случае будут направлены X, Y?

[Metan 12]

 

$$ экспериментальная процедура, по идее должна распознавать

$$ когда поворот по циклу 19 а когда М128

$$ и выводить соответствующие строки

$$ пока не доработана :(

CIMFIL/ON,CAMERA

XXXXXX=text/'************** CAMERA ***************'

DMY=POSTF(13)

$$JUMPTO/ESCCAM

$$ процедура отслеживающая смещение нуля или векторов

CHIF_X=POSTF(7,7);CHIF_Y=POSTF(7,11);CHIF_Z=POSTF(7,15)

VEC_I=POSTF(7,6);VEC_J=POSTF(7,10);VEC_K=POSTF(7,14)

CHIF1=POINT/CHIF_X,CHIF_Y,CHIF_Z;VEC1=POINT/VEC_I,VEC_J,VEC_K

AN1=ANGLF(CHIF1,NUL);VEC2=ANGLF(VEC1,VEC_N)

IF (AN1.NE.0) THEN

   CHIF=1

$$ выставляем флаг если найдено смещение

ELSE

   CHIF=0

ENDIF

IF (VEC2.NE.0) THEN

   VEC=1

$$ выставляем флаг если наден наклон

ELSE

   VEC=0

ENDIF

$$JUMPTO/ESCCAM

IF (CHIF.EQ.0.AND.VEC.EQ.0) JUMPTO/ESCCAM

IF (CHIF.EQ.1.AND.VEC.EQ.0) DOIT=+10 $$ только сдвиг

IF (CHIF.EQ.1.AND.VEC.EQ.1) DOIT=+20 $$ сдвиг и поворот

IF (CHIF.EQ.0.AND.VEC.EQ.1) DOIT=+30 $$ только поворот

$$ *************************

$$  REZ_A=VECTOR/VEC_I,VEC_J,0

$$  REZ_B=ANGLF(REZ_A)

$$  ANGL_C=90-REZ_B

$$ **************************

$$  I2=VECTOR/VEC_I,0,0

$$  J2=VECTOR/0,VEC_J,0

$$  K2=VECTOR/0,0,VEC_K

$$  D2=DOTF(I2,J2)

$$  REZ2=VECTOR/D2,VEC_K,0

$$  ANGL_A=ANGLF(REZ2)

$$  DMY=POSTF(21)

ESCCAM)CONTIN

XXXXXX=text/'************** CAMERA out ***************'

$$  DMY=POSTF(13)

CIMFIL/OFF

 

не закончено и на практике не проверено, но может кому пригодится сама идея, изначально предназначена для стоек хайден с осями поворота АС

суть в том что fill на самом деле обрабатывает не сам файл .ncl но его производную файл .acl

поскольку в файле .ncl происходит заремаривание

$$-> CSYS / 1.0000000000, 0.0000000000, 0.0000000000, 0.0000000000,  $
            0.0000000000, 1.0000000000, 0.0000000000, 0.0000000000,  $
            0.0000000000, 0.0000000000, 1.0000000000, 0.0000000000

но в файле .acl эта ремарка снята

    CAMERA/ 1.0000000000, 0.0000000000, 0.0000000000, 0.0000000000,  $
            0.0000000000, 1.0000000000, 0.0000000000, 0.0000000000,  $
            0.0000000000, 0.0000000000, 1.0000000000, 0.0000000000

поэтому пишем обработку процедуры и вычисление углов через вектора, это родная функция G-post

смещение и (или) поворот осей так можно отследить

но вот до вывода в сам код станка я не добрался )) сменил должность, этой идеи уже лет 8 наверное, очень удивлен что тема до сих пол актуальна

если не знаете (сомневаетесь) какие на самом деле данные содержатся в тексте (процедуре, служебном слове)

и как к ним обращатся

то могу посоветовать простой макрос

ALLWAR=MACRO/
  COLWAR=POSTF(5)
  DO/CY5,WARR=4,COLWAR,1
  P3=POSTF(7,WARR)
  CY5)CONTIN     
TERMAC

поместите его в разделе макросов

вызывается (запускается)   CALL/ALLWAR

из тела соответствующей процедуры которую хотите исследовать

например:

CIMFIL/ON,MACHIN
  DMY=POSTF(20)
  CALL/ALLWAR
  DMY=POSTF(13)
CIMFIL/OFF

результат смотрите в файле с расширением .lst

[LxCoder 36]

Если результат с подпрограммами легко привел к нужному положительному результату - то почему бы им не пользоваться?

Легко - это когда нажал в контекстном меню "Массив" и пришел к положительному результату. Про ваш метод массивирования через "подпрограммы" я бы наверное и не узнал бы никогда, если бы не форум (спасибо, кстати). Он не очевиден, к нему можно прийти, только если не получилось что-то сделать стандартным способом. А в остальном - да, кто как хочет, так и ...

 

 

 

 

Хотелось бы всё-таки разобраться с этим вопросом:

Почему пост, работающий через CSYS вдруг считается "ненормальным", если даже в самом G-POST'e на вкладке Planar Machining предлагается на выбор "ненормальный" вариант работы - через CSYS ?

LxCoder, Вы можете немного пояснить, чисто с математичекой точки зрения - как можно вычислить повороты системы координат только по положению оси Z (вектора инструмента)? Куда в этом случае будут направлены X, Y?

 

"Нормальным", по моему сугубо личному мнению, считается пост, который при использовании стандартных методов работы не требует никаких дополнительных телодвижений. Помимо вашей описаной проблемы с невыводом CSYS есть ведь и другие, подобного рода проблемы, например, с невыводом определения цикла сверления (да любого другого осевого цикла), если, например сверление происходит на разную глубину, или на разной высоте (я не помню про такую проблему в Creo, но в WF3 она точно была). В результате нее постпроцессор, находя команду CYCLE/... формировал по ней определение цикла, а дальше выводил просто координаты. А в них может измениться координата по Z. Тогда, люди предпринимали следующее - разбивали один сиквенс сверления на несколько, заставляя тем самым ПроЕ выводить определение цикла на каждую высоту... Понятно, что такой пост не является "нормальным" и требует доработки.

То же самое и с Вашей ситуацией.

 

Про математику: я не сказал, что только по вектору инструмента выбирается расположение осей. А по вектору и начальному положению CSYS. Ориентация осей выбирается G-Post'ом исходя из геометрии станка и в пределах тех лимитов по поворотным осям, которые определены вами на вкладке Axis/Use automatic repositioning. Вот там действительно непростой алгоритм, потому что он не только "укладывает" расположение СК в эти пределы, но и делает это с минимальными поворотами по осям (а они, как вы знаете, на разных станках могут быть разные и направлены быть по разному). Поэтому в моих постах секции CIMFIL/ON,CAMERA нет. Я предоставляю G-Post самому вычислить мне углы и только лишь рассовываю их куда нужно. Таким образом я избавился если не от всех, то по крайней мере от большой части проблем вычисления углов и поворотов. Зачем изобретать велосипед самому?

[Metan 12]

или я потерял нить разговора или мы (уважаемые коллеги) начинаем повторятся )

 

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

повторюсь что имеем как минимум два широко используемые метода, это 2+3 и полное 5х

только вот в базе, G-post не имеет возможности их различать поскольку это вопрос технологии но не програмирования

[GARRY 10]

 

только вот в базе, G-post не имеет возможности их различать поскольку это вопрос технологии но не програмирования

 

По этой причине 13 лет назад мне пришлось писать процедуру анализа типа обработки для постпроцессора DMU50eV с Heidenhain. При 4-5 осевой выводить M128 и соответствующий расчет координат, при 3-осевой вывод цикла 19 и при смене типа обработки соответственно делать отмену (M129 или вывод 19 цикла в нули). С тех пор во всех 5х постпроцессорах этот макрос использую (например для зажима осей для 3+2 и разблокировке для 5х или Haas UMC750 с разными кодами для 3х и 5х). 

[DJ Astro 62]

Ориентация осей выбирается G-Post'ом исходя из геометрии станка и в пределах тех лимитов по поворотным осям, которые определены вами на вкладке Axis/Use automatic repositioning.

Но в моём случае не G-Post выбирает углы и оси, а станок сам "решает" какую ось и на сколько повернуть, т.к. я организую 3+2 обработку через PLANE SPATIAL. А углы, задаваемые в этом цикле, вообще не связаны с кинематикой станка и могут лежать далеко за пределами лимитов поворотных осей. Стандартным математическим аппаратом G-Post'a я не смог реализовать эту функцию (если кто-то знает - подскажите, пожалуйста, как?). Даже не смотря на владку Planar Machining, которая, если я не ошибаюсь, не так давно появилась в G-Post'е. 

 

Есть ещё один вопрос:

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

[LxCoder 36]

Но в моём случае не G-Post выбирает углы и оси, а станок сам "решает" какую ось и на сколько повернуть, т.к. я организую 3+2 обработку через PLANE SPATIAL.

 

Но ведь значения для PLANE SPATIAL по углам SPA SPB SPC вы какие-то все равно размещаете, ведь так? Они-то откуда берутся - вы их сами вычисляете и в УП вставляете потом? Или все таки G-Post? :)

 

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

 

Могут. А смысл? Чтобы окончательно запутаться самому при попытке понять что же такое должен делать инструмент и самое главное - в какой ориентации? На мой взгляд - значения, выводимые в SPATIAL должны соответствовать реальным значениям поворотных осей: повернулась голова на 40 градусов вокруг оси Y - значит в SPB+40. Повернулся стол вокруг оси Z на 90 - в SPC+90. Если вокруг оси Х вообще ни один орган не ворочается так и в SPA+0 всегда. Зачем усложнять себе жизнь? Все эти вычисления прекрасно делает сам G-Post.

 

Как может быть организована оптимизация программы в части минимизации отводов и перепозиционирований при достижении лимитов по осям вращений? Станок может приехать в позицию двумя путями - "коротким" и "длинным". Если в стартовую точку обработки приехать "коротким" путём - где-то в середине траектории произойдёт перепозиционирование.

 

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

[Metan 12]

оптимизация программы в части минимизации отводов и перепозиционирований

 

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

 

в данном случае вы пытаетесь высокоуровневую интелектуальную систему (G-post)

научится давать инструкции для другой высокоуровневоой интелекуальной системы (хайден)

это было бы гениально если бы не было так абсурдно )

 

тут придется выбирать

или простая программа с максимальным задествованием возможностей стойки станка (что то придется ручками прописывать)

или максимально технологически продуманная программа состоящая только из прямых инструкций

 

лично я оба метода применяю, в зависимости от ситуации

[DJ Astro 62]

Но ведь значения для PLANE SPATIAL по углам SPA SPB SPC вы какие-то все равно размещаете, ведь так? Они-то откуда берутся - вы их сами вычисляете и в УП вставляете потом? Или все таки G-Post? :)

 

Нет, не G-Post, а я их сам вычисляю. Как? Я показывал решение тут.

 

На мой взгляд - значения, выводимые в SPATIAL должны соответствовать реальным значениям поворотных осей: повернулась голова на 40 градусов вокруг оси Y - значит в SPB+40. Повернулся стол вокруг оси Z на 90 - в SPC+90. Если вокруг оси Х вообще ни один орган не ворочается так и в SPA+0 всегда. Зачем усложнять себе жизнь? Все эти вычисления прекрасно делает сам G-Post.  

 

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

 

Вот так установлена главная система координат:

 

Предположим, я хочу написать программу для обработки на плоскости ZX (так, чтобы ось X была параллельна столу и совпадала с X главной системы координат, Y была направлена вверх, а Z – в отрицательную сторону главной Y  -  я так хочу, мне так удобно). Для этого мне нужно просто повернуть СК вокруг X на угол +90, что равносильно команде PLANE SPATIAL SPA+90 SPB+0 SPC+0. Система координат повернется вот так:

 

при этом оси станка повернутся так  ----  B90 C-90 (такие углы нам и высчитает G-Post с учетом кинематики нашего станка. Естественно, он же не может вычислить и выдать нам угол А, потому что в станке такой оси нет).

 

Теперь, если эти углы, вычисленные нам G-Post’ом подставить в PLANE SPATIAL SPA+0 SPB+90 SPC-90, то система координат повернётся вот так (что не соответствует моему замыслу).

 

 

Т.е. задавая в Pro/E локальную СК для 3+2 обработки я ожидаю, что после поста в программе координаты перемещений будут выводится в такой же СК (что логично и легко для понимания при отладке, поиске ошибок и т.д.). А по факту получается, что если эти углы позволять рассчитывать G-Post’у на основании кинематики станка, то в станке потом система координат может быть повернута как угодно и не совпадать с той СК, которую задавали в проекте обработки. Хотя и координаты все будут пересчитаны правильно и обработка будет в порядке.

 

 

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

 

 

Я согласен, есть вещи, которые невозможно сделать без разворотов. Но на совсем простых вещах можно обойтись и без этого. Рядом есть пост под NX, разработанный сторонней организацией. Так вот он, перед тем как сделать фаску в отверстии наклоненным инструментом, предварительно выворачивает оси станка во второе возможное положение и проходит всю фаску без отрыва. Но и считает этот пост одинаковую траекторию гораздо дольше в сравнении с моим pro/e-шным.

Вот мне и стало интересно, как оно может быть устроено.