DJ Astro

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

397 posts in this topic

...только если догадается залезть в FIL-файл. А если он туда догадается залезть, то Вам и ID не поможет, т.к. просто можно будет вытереть из FIL-файла проверку на соответствие ID.
 

С этого, кстати, и началось моё постижение G-post'a и FIL'a. :biggrin:  Долго и упорно искал, почему пост не хочет работать на другом компе. Благо, что FIL был не зашифрован, спасибо разработчикам   :worthy: ! Раскопал, и тут понеслось... )))

 

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

 

Из простого остается вариант с получением ID. 

Share this post


Link to post
Share on other sites


Тут ещё один вопрос возник ))) Как работает эта функция - Merging Post ?

Как её понимаю я: 1. Делаем два постпроцессора - один для токарки, другой для фрезерки. Тестируем - все работает на своих операциях. (сделано)

2. Ставим галки Merging post и в первом и во втором постпроцессоре, выбираем их на соответствующих вкладках (т.е. они как-бы друг на друга взаимно ссылаются.) (сделано)

3. В код того постпроцессора, который будем запускать для получения УП (в моем случае - токарный) прописываем примерно такой код:

 

CIMFIL/ON,MODE
XX=POSTF(7,4)
 
IF(XX.EQ.ICODEF(MILL))THEN
             MODE/MILL,50 $$ 50 - Номер фрезерного постпроцессора (UNX01.p50)
ENDIF
CIMFIL/OFF
 
4. Во фрезерный постпроцессор пишем такой код:
 
CIMFIL/ON,MODE
XX=POSTF(7,4)
 
IF(XX.EQ.ICODEF(TURN))THEN
             MODE/TURN,50 $$ 50 - Номер токарного постпроцессора (UNL01.p50)
ENDIF
CIMFIL/OFF
 
5. В CL файл каким нибудь образом запихиваем код
 
MACHINE/UNCL01,50
MACHINE/UNCX01,50
MACHINE/UNCMRG,1
 
6. Запускаем файл на постпроцессирование - получаем УП, обработанную двумя постами.
 
Может я где ошибся, но у меня не получается создать таким образом УП. Подскажите, в чем моя ошибка. 

 

Share this post


Link to post
Share on other sites

 

С этого, кстати, и началось моё постижение G-post'a и FIL'a. :biggrin:  Долго и упорно искал, почему пост не хочет работать на другом компе. Благо, что FIL был не зашифрован, спасибо разработчикам   :worthy: ! Раскопал, и тут понеслось... )))

 

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

 

Из простого остается вариант с получением ID. 

 

Ну тут уж как говорится на каждую ж... с резьбой найдется свой болт. Посты, конечно, шифруются, но есть программы-сканеры, которые отследят любые обращения к файловой системе и реестру от чего угодно и при желании из этого мусора всегда можно найти то, что нужно и вовремя подменять данные... Но стоит ли это все результата? Самый эффективный способ защиты - это сокрытие FIL-кода. Когда в сп..женном посте нельзя даже знак одного значения поменять - этот пост становится бесполезным (или геморройным - постоянно нужно что-то поправлять, а ведь можно разок и забыть, и тогда ... ну всякое может быть). Из удобных остается работа с сетевым ключом, но это опять же только посредством подключаемого внешнего приложения.

Share this post


Link to post
Share on other sites

Нет, я наверное, когда говорил про токарно-фрезерные постпроцессоры не совсем правильно выразился. Я имел ввиду замерженные "Merge" посты, которые собраны из двух разнотипных (токарно-фрезерного Live Tool и фрезерного Mill 5Axis Rotary Table, например - для станков у которых есть поворотный фрезерный шпиндель с токарной функцией и револьверная головка, наподобие https://youtu.be/HnV7Nrtie1Y?list=FL_Zy7mmeO5XjaewSveiOogA) . Вот они под Виндой 10 точно работать отказываются... 

 

При прогоне через пост выскакивает ошибка - ERROR OPENING PUNCH FILE - POST NAME AND NUMBER = UNCX01  97

 MERGE TERMINATED
 
Уж не из-за 8-й ли винды, или вы другую ошибку имели ввиду?  

Share this post


Link to post
Share on other sites

Ну тут уж как говорится на каждую ж... с резьбой найдется свой болт. Посты, конечно, шифруются, но есть программы-сканеры, которые отследят любые обращения к файловой системе и реестру от чего угодно и при желании из этого мусора всегда можно найти то, что нужно и вовремя подменять данные... Но стоит ли это все результата? Самый эффективный способ защиты - это сокрытие FIL-кода. Когда в сп..женном посте нельзя даже знак одного значения поменять - этот пост становится бесполезным (или геморройным - постоянно нужно что-то поправлять, а ведь можно разок и забыть, и тогда ... ну всякое может быть). Из удобных остается работа с сетевым ключом, но это опять же только посредством подключаемого внешнего приложения.

 

Вот про это я и говорил: все посты давно уже написаны, а всякие ретейлеры и прочие лишь чутка поправляют.... Зато денег просят как за написание КРЕО !

Share this post


Link to post
Share on other sites

Вот про это я и говорил: все посты давно уже написаны, а всякие ретейлеры и прочие лишь чутка поправляют.... Зато денег просят как за написание КРЕО !

К слову сказать, я занимаюсь тем же самым, и если бы все посты были написаны - мы все бы давно остались без работы... Ну а сколько просить денег - это личное дело каждого. Есть спрос - есть предложение. Если каждый бы смог написать свой пост под любой станок - продать было бы его оч. сложно даже за копейку.

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

 

При прогоне через пост выскакивает ошибка - ERROR OPENING PUNCH FILE - POST NAME AND NUMBER = UNCX01  97

 MERGE TERMINATED
 
Уж не из-за 8-й ли винды, или вы другую ошибку имели ввиду?  

 

Нет, рабочий пост просто ничего не выдает в tap... Никаких ошибок быть не должно.

 

 Pro/NC-GPOST Mill, Version  6.4 P-10.0, Copyright© 2011                      
  Build number=0083                                                              
  Date=02-11-2016 Time=08:49:39                                                  
  Input  File=op010.ncl.18                                                       
                                                                                 
  Option File=uncx01.p16                                                         
  Filter File=uncx01.f16                                                         
                                                                                 
         *** Tape length     35.03  Cycle time      4.57  Warnings     0 ***     
  Date=02-11-2016 Time=08:49:44                                                  
  Pro/NC-GPOST Lathe, Version  6.4 P-10.0, Copyright© 2011                     
  Build number=0083                                                              
  Date=02-11-2016 Time=08:49:45                                                  
  Input  File=op010.ncl.18                                                       
                                                                                 
  Option File=uncl01.p16                                                         
  Filter File=uncl01.f16                                                         
                                                                                 
         *** Tape length      6.94  Cycle time     18.31  Warnings     0 ***     
  Date=02-11-2016 Time=08:49:45                                                  
  Pro/NC-GPOST Merge, Version  6.4 P-10.0, Copyright© 2011                     
  Build number=0083                                                              
  Date=02-11-2016 Time=08:49:45                                                  
  Input  File=op010.ncl.18                                                       
  Post   Name=uncmrg.p01 
 
 
В tap файле 0 байт. Зато есть какой-то файл "fort.24" (причем независимо какую УП прогоняешь - он называется именно так) в котором фактически содержится "тело" УП (без символов перемотки в начале и в конце). Вот так это выглядит под Win 10.
Под Win7 все абсолютно нормально. Файл tap формируется как положено.
 
А у вас по-ходу постпроцессор не находит другого поста с именем uncx01.p97 (s97, f97)... Может быть указать путь поточнее в окошке "Merging post"?

Share this post


Link to post
Share on other sites

Спасибо,буду разбираться

Share this post


Link to post
Share on other sites
К слову сказать, я занимаюсь тем же самым, и если бы все посты были написаны - мы все бы давно остались без работы...

 

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

1) подобрать уже из готового что есть

2) если что-нить не устраивает - подправить. 

 

В принципе, что G-код что H-код - одинаковы от станка к станку соответственно,  и лишь некоторые циклы их различают.

Share this post


Link to post
Share on other sites

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

1) подобрать уже из готового что есть

2) если что-нить не устраивает - подправить. 

 

В принципе, что G-код что H-код - одинаковы от станка к станку соответственно,  и лишь некоторые циклы их различают.

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

 

И еще: для полноты картины между первым и вторым пунктами я бы вставил еще несколько:

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

 б) приехать на предприятие-заказчик и отработать на новом станке тестовую деталь с представителями самого заказчика

 в) выслушать все пожелания, на месте отсеять то, что невозможно по умолчанию (доказать), реализовать то, что еще нужно, подогнать его под форму работы на конкретном предприятии

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

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

 е) передать пост в тестовое пользование 

И только потом п.2)

 

Вот как-то так...

Share this post


Link to post
Share on other sites

Только у меня в Creo 3 М040 не работает функция TEXT/MAIN ? Кто может проверить у себя? 

Share this post


Link to post
Share on other sites

У меня в WF4 не работает.

1 person likes this

Share this post


Link to post
Share on other sites

Странно, что функция, описанная в мануале, не работает. Так и не смог отправить пост на выполнение FINI функцией POSTF(9,14000) после неудачной проверки "лицензии". Пишет ошибку на этой строке и всё. Удалось только через поиск FINI с помощью POSTF(30,...).

Share this post


Link to post
Share on other sites

ID: 173   Posted (edited)

действительно, странно.

Edited by Bastion

Share this post


Link to post
Share on other sites
Я использую   

DMU=POSTF(10,2,14000)

DMU=POSTF(13)

А для привязки рекомендую использовать как один из вариантов POSTF(27) и криптовать FIL секцию - пока еще никто не взломал :-)

Share this post


Link to post
Share on other sites

Здравствуйте!
Помогите пожалуйста разобраться. Постпроцессор выводит программу на языке haidenhain. Но при больших объемах обработки обрабатывает CL не корректно, т.е примерно до 4000-5000 все линейные, круговые перемещения обрабатываются нормально, а в остальном получается полная "каша". Также не полностью выводится подача и обороты.
Должно быть ..... F750 , а получается ......F75.

 

........

5969  L X+9.526 M90
5970 CC X+0 Y+21
5971  C X+7.861 Y+13.306  DR-
5972 CC X+0 Y-0.053
5973  C X+13.535 Y+7.5  DR-
5974  L X+59 Y+7.5 M90
5975 CC X+59 Y+0
5976  C X+65.5 Y+3.742  DR-
5977  L X+66.5 Y+3.742 M90
5978  L Y+16.5 M90
5979  L X+8.93 M90
5980 CC X+0 Y+21
5981  C X+6.121 Y+13.092  DR-
5982 CC X+0 Y-0.053
5983  C X+12.935 Y+6.5  DR-
5984  L X+59 Y+6.5 M90
5985 CC X+59 Y+0
5986  C X+60.413 Y-6.345  DR-
5987  L X+60.196 Y-5.368 M90
5988 CC X+59 Y+0
5989  C X+59 Y-5.5  DR-
5990  L X+12.352 Y-5.5 M90
5991 CC X+0 Y-0.053
5992  C X+4.011 Y-12.943  DR-
5993 CC X+0 Y-21
5994  C X+8.292 Y-17.5  DR-
5995  L X+67.5 Y-17.5 M90
5996  L Y+17.5 M90
5997  L X+8.292 M90
5998 CC X+0 Y+21
5999  C X+3.878 Y+12.878  DR-
600 CC X+0 Y-0.053
601  C X+12.305 Y+5.5  DR-
602  L X+59 Y+5.5 M90
603 CC X+59 Y+0
604  X+59.978 Y-4.392
605 2 X+59 Y-4.5 I+59 J+0
606  X+11.682
607 2 X-3.714 Y-11.988 I+0 J-0.053
608  X-4.011 Y-12.943
609 2 X-5.777 Y-12.254 I+0 J-0.053
6010  X-6.205 Y-13.158
6011 2 X-7.415 Y-12.513 I+0 J-0.053
6012  X-7.926 Y-13.373
6013 2 X-8.865 Y-12.767 I+0 J-0.053
6014  X-9.437 Y-13.588
6015 2 X-11.5 Y-11.885 I+0 J-0.053
6016  Y-14.5
6017  X-10.087
6018 2 X-9.437 Y-13.588 I+0 J-21
6019  X-8.865 Y-12.767
6020 2 X-12.5 Y-9.218 I+0 J-0.053
6021  Y-15.5
6022  X-9.526
6023 2 X-7.926 Y-13.373 I+0 J-21
6024  X-7.415 Y-12.513
6025 2 X-12.975 Y-6.526 I+0 J-0.053
6026  X-13.5
6027  Y-16.5
6028  X-8.93
6029 2 X-6.205 Y-13.158 I+0 J-21
6030  X-5.777 Y-12.254
6031 2 X-12.34 Y-5.526 I+0 J-0.053
6032  X-14.5
6033  Y-17.5
6034  X-8.292
6035 2 X-4.011 Y-12.943 I+0 J-21
6036  X-3.714 Y-11.988
6037 2 X-11.672 Y-4.526 I+0 J-0.053

.........

 

H.rar

Share this post


Link to post
Share on other sites

Здравствуйте!

Помогите пожалуйста разобраться. Постпроцессор выводит программу на языке haidenhain. Но при больших объемах обработки обрабатывает CL не корректно, т.е примерно до 4000-5000 все линейные, круговые перемещения обрабатываются нормально, а в остальном получается полная "каша". Также не полностью выводится подача и обороты.

Должно быть ..... F750 , а получается ......F75.

Ivav, попробуйте с этим постом. Немного поправил подачи. Пост сильно глубоко не проверял.

HH.zip

Share this post


Link to post
Share on other sites

Ivav, попробуйте с этим постом. Немного поправил подачи. Пост сильно глубоко не проверял.

Спасибо подачи поменялись. Но программа по прежнему генерируется на треть. В lst файле выводится такая ошибка

***Error** REPLAC/TABLE FULL, REPLAC/OFF NEEDED

  -233 ** Error **  108 STATEMENT ENDS INCORRECTLY        

        ** MACRO HEID   CALLED FROM ISN -314

  -234  STR           TEXT  24 CHAR.:L2 X+60.196 Y-5.368  DR-

  -236  L3TXT         TEXT   2 CHAR.:L3     

  -237  OKL3          SCALAR         .00000

  -241  TT            TEXT   1 CHAR.:C      

  -241 ***Error** REPLAC/TABLE FULL, REPLAC/OFF NEEDED

  -241 ** Error **  108 STATEMENT ENDS INCORRECTLY        

 

Share this post


Link to post
Share on other sites

Спасибо подачи поменялись. Но программа по прежнему генерируется на треть. В lst файле выводится такая ошибка

а можете дать исходный ncl в котором появляется такая ошибка?

Share this post


Link to post
Share on other sites

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

 

 

HH2.zip

Share this post


Link to post
Share on other sites

а можете дать исходный ncl в котором появляется такая ошибка?

POST.rar

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

 

HH3.zip

Share this post


Link to post
Share on other sites

Добрый день!

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

6c7ebb4a7a0e02dbe998f571f0b47edd.jpg

 

07f0862c39f6c1f930d7a248fe7d5210.jpg

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Добрый день!

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

...

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

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

 

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

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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

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

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

1 person likes this

Share this post


Link to post
Share on other sites

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

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

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

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

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

 

 

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

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

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

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

Share this post


Link to post
Share on other sites

 

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

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

1 person likes this

Share this post


Link to post
Share on other sites

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

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

 

 

 

 

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

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

1 person likes this

Share this post


Link to post
Share on other sites

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

 

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

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

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

1 person likes this

Share this post


Link to post
Share on other sites

 

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

 

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

3 people like this

Share this post


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

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

 

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

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

Share this post


Link to post
Share on other sites

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

1 person likes this

Share this post


Link to post
Share on other sites
оптимизация программы в части минимизации отводов и перепозиционирований

 

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

 

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

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

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

 

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

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

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

 

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

1 person likes this

Share this post


Link to post
Share on other sites

Но ведь значения для 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-шным.

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.