Перейти к публикации

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


DJ Astro

Рекомендованные сообщения

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

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

Ссылка на сообщение
Поделиться на других сайтах


Получается вот что. В 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 обрабатывать каждую строку ??

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

HH3.zip

Ссылка на сообщение
Поделиться на других сайтах
  • 1 месяц спустя...

Добрый день!

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

6c7ebb4a7a0e02dbe998f571f0b47edd.jpg

 

07f0862c39f6c1f930d7a248fe7d5210.jpg

 

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Добрый день!

Подскажите, пожалуйста! На многогранной детали расположены одинаковые отверстия, создаю сверление, затем круговой массив обработки, в 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 все сделали правильно...)

Ссылка на сообщение
Поделиться на других сайтах

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, подскажите, пожалуйста, а для чего тогда используются "подпрограммы"?

Ссылка на сообщение
Поделиться на других сайтах

...

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

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

 

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

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

 

 

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

$$ когда поворот по циклу 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

Ссылка на сообщение
Поделиться на других сайтах

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

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

 

 

 

 

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

Почему пост, работающий через 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 самому вычислить мне углы и только лишь рассовываю их куда нужно. Таким образом я избавился если не от всех, то по крайней мере от большой части проблем вычисления углов и поворотов. Зачем изобретать велосипед самому?

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

 

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

 

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

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

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

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

Но в моём случае не 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 градусов, чтобы позволить доработать сферу до конца...

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

 

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

 

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

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

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

 

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

fa17edc94d0649c90d6ea6e4aca642b2.jpg

 

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

f9990878115139bf56995a76f59b8a58.jpg

 

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

72704c84f3a2191b39134a4b48452b08.jpg

 

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

 

d73d52da9ec5d523c4d49c0ac11cee10.jpg

 

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

 

 

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

 

 

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

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

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




  • Сообщения

    • Eng.Destructor
      Сделал так: Добавил новый формат fs2 25 0 4 0 3t #No decimal, absolute, 3 поменял  result = newfs (25, thddepth$) # изменил 16 на 25 result = newfs (25, thdfirst$) # изменил 16 на 25 result = newfs (25, thdlast$) # изменил 16 на 25 result = newfs (25, thdfinish$) # изменил 16 на 25 Спасибо за наводку
    • arsenev
    • teqn1c
      Есть динозавр stratos plus на io mb -  В нем всего 256 КБ памяти  есть ли возможность через режим rtm подгружать программу с ПК через rs 232 ? В шкафу ещё есть разъем под карту но с нее получается только считать и опять таки сохранить на память станка. Соединение ПК-станок настроил ,есть возможность отправлять на него через альфакам программы ,но они сохраняются в память станка. В альфакам есть непрерывная отправка - она отправляет - но в режиме rtm ничего не происходит 
    • Metal_Cutter
      @arsenev В FC такого нет.
    • Bot
      HCL CAMWorks 2024, новая версия программного обеспечения CAM, полностью интегрированного с SOLIDWORKS и Solid Edge включает в себя передовые технологии, позволяющие сократить время программирования, уменьшить время цикла обработки и увеличить срок службы инструмента. Смотреть полностью
    • Александр1979
      Руководство для дусь взял здесь: https://www.cnczone.com/forums/daewoo-doosan/413426-every-doosan-service-manual-currently-auto-updated.html
    • ss_162
      Может есть у кого оригинальные резцы на продажу? Нужен резец SFCC 50 - это маркировка D`Andrea, или Искаровский, он такой же, только маркировка у него другая.
    • Aveovar
      Подскажи, как ты сделал несколько экранов с разных ракурсов
    • Kaktusito
      Всем доброго времени суток! Только начал заниматься редактированием постпроцессоров и сразу же столкнулся с проблемой. Суть в том что я нашел по форумам постпроцессоры с SolidCAM 2015 года, ибо у меня в версии 2022 года их почти нет, а мне нужен был более менее адекватный пост под токарку.  Закинул все файлы Gpptool 2015 года в свою папку, выбрал подходящий мне станок и начал генерировать УП.  Как вы поняли ничего мне не сгенерировало. Пишет ошибку "please change the name "Bore" in the VMID. This name is reserved for use in the GPP"  Сделал то что просит ошибка и был уверен что это не поможет, так оно и вышло. По итогу начало долбить другие ошибки. Очень еще не понятно с файлами которые я кидал в папку Gpptool потому что вместо стандартных двух у меня их аж 4 штуки.: gpp с циклами, gpp обычный, PRP и vmid. Хотя я знаю что в версиях вроде после 2017 уже идет по 2 файла. Что я только не пробовал кидал только 2 файла, кидал все 4, кидал содержимое файла с циклами в основной gpp, шёл по пути ошибок и исправлял что меня просили. В общем ничего не помогает  От безисходности пишу сюда, вы моя последняя надежда понять что происходит и почему ничего не работает. Заранее благодарю за ответы!
    • Krusnik
×
×
  • Создать...