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

[DJ Astro 55]

При чтении данных из CL-файла пост считает число 0.9999971878 единицей. Из-за этого все дальнейшие вычисления идут неправильно.

Как это исправить? Как увеличить число десятичных знаков, использующихся в вычислениях через FIL? 

[DJ Astro 55]

22 часа назад, DJ Astro сказал:

При чтении данных из CL-файла пост считает число 0.9999971878 единицей. Из-за этого все дальнейшие вычисления идут неправильно.

Как это исправить? Как увеличить число десятичных знаков, использующихся в вычислениях через FIL? 

Разобрался. Смутило то, что в LST параметр, значение которого должно быть 0.9999971878, выводится как равный единице. Но в вычислениях всё же используется точное значение параметра, и вычисления идут правильно. А ошибка работы поста появлялась на этапе проверки логических условий, где параметр с таким значением сравнивается с единицей. 

Вопрос решился с помощью CONTRL/TOLER,IF,t.

[Павел Ишмулкин 0]

                             Добрый день Уважаемый DJ Astro!

Еще раз внимательно перечитал Вашу полемику с Уважаемым товарищем  . И вот какие у меня появились вопросы.

 LxCoder утверждает, что для постпроцессора 3+2 нет необходимости использовать обработчик CAMERA. Вы же утверждаете, что это - просто необходимо. Я поддерживаю Вас, в части касающейся, расчета углов разворота новой системы координат. Или углов Эйлера. Для того чтобы Вам было понятно - это определение  в НН SPATIAL PLANE и CYCLE800 в Sin840D. Недавно узнал, что в FANUC - это G68.2.

Так вот задача "Планеризации" разделяется на две части:

    1. Расчет углов для определения наклонной плоскости;

    2. Расчет машинных углов. То есть углов поворота рабочих органов станка. Коими могут быть головы или столы. Особую сложность представляют углы с нутацией.

Первую часть задачи Вы решили! С помощью Вашего обработчика CAMERA мы рассчитываем углы поворота новой системы координат. И пока во всех случаях углы рассчитываются  корректно. Правда все-таки есть сомнения по поводу устойчивости алгоритма на границе передней и задней полусфер детали. Особо это касается случая с 6 осевой обработкой, или правильнее сказать 1+5. Сначала, доворот по оси В (вдоль Y), а затем расчет поворотной головы с осями А и С.

Но в нашем случае необходимо еще и рассчитать машинные углы. Для определения SPATIAL PLANE нет необходимости в расчете машинных углов, так как высокоуровневая  функция Хайдена - САМА РАССЧИТЫВАЕТ ЭТИ УГЛЫ, аналогично и с CYLCE800 в Sin840D. Но у нас, по непонятной причине изготовитель станка не предоставляет файл с описанием кинематики ($TC_CARR1-17 для Siemens), в связи с чем мы вынуждены подавать в УП ЧПУ конкретно два угла поворота рабочих органов станка, после поворота системы координат, с помощью TRANS -> AROT. Я предполагаю, что у Вас в VERICUT существует корректно настроенный станок с кинематикой, по этой причине Вы не заморачиваетесь с расчетом станочных углов.

... Теперь по поводу неиспользования обработчика , на котором настаивает товарищ LxCoder. Как Вы знаете в  GPOST v6.6 добавлена новая функция расчета углов Эйлера и машинных углов DATA/CAM,1-2-3. Так вот мои "исследования" показали, что корректно, с помощью этой функции, можно определить машинные углы, только по функции DATA/CAM,3 с обработкой FIL на GOTO. То есть с помощью положения точки конца и разложения орта оси инструмента.  Попытка вычислить машинные углы через функцию DATA/CAM,1 (матрица CAMERA) приводят к результатам, когда углы отличаются от корректных на 180, 270 градусов, в различных ситуациях. Мы так и не смогли определить закономерность, когда нужно учитывать эту разность.

... И наоборот, когда БЕЗ ВКЛЮЧЕНИЯ ОБРАБОТЧИКА CAMERA, функция DATA/CAM,3 (точка+вектор) выдавала ВСЕГДА КОРРЕКТНЫЙ РЕЗУЛЬТАТ. Кроме положений на границе  передней и задней полусфер. Это зона неопределенности, которую необходимо разрешать, принудительно назначая машинные углы из конкретных углов Эйлера. А если включить обработчик CAMERA, то углы обнуляются, что вполне естественно. 

       Так вот вопрос - как Вы справляетесь с проблемой - в одном ПОСТЕ рассчитать и углы Эйлера и машинные углы? Или, может быть, у Вас не стоит проблема в расчете машинных углов.

       А если это сообщение прочтет LxCoder, то хотелось бы услышать и его мнение.

 

[LxCoder 32]

В 18.06.2018 в 09:03, Павел Ишмулкин сказал:

 LxCoder утверждает, что для постпроцессора 3+2 нет необходимости использовать обработчик CAMERA...

...

 Теперь по поводу неиспользования обработчика , на котором настаивает товарищ LxCoder...

Товарищ LxCoder ничего не утверждает и, уж тем более, не навязывает. Делайте как вашей душе угодно, и как Вам понятнее... Нравится изобретать велосипед заново - дело Ваше. Есть косой десяток способов сделать одно и то же.

 

В 18.06.2018 в 09:03, Павел Ишмулкин сказал:

Или, может быть, у Вас не стоит проблема в расчете машинных углов.

Именно. Я половины не понял, что вы понаписали и для чего вам все эти фельдиперсовые функции. Углы можно рассчитать один из другого - абсолютно любые, если понимать, что хочется получить на выходе. В G-Post математический аппарат с большим количеством параметров, настроек - он вполне достаточен (по моему личному мнению) для успешного решения 99% реальных задач. Для 1% скорее всего придется использовать некоторые свои формулы преобразования (например, для станков с не вполне обычной геометрией расположения осей, например, как в DMU 160, где угловая голова расположена под 45 градусов к оси Z...).

[Павел Ишмулкин 0]

Спасибо за ответ, Уважаемый товарищ LxCoder (пока еще не привык обращаться не по имени отчеству, а к нику). С момента публикации последнего поста, мы нашли способ вычисления машинных углов (с нутатором). Из CAMERA забираем два столбца: предпоследний - это разложение орта ОСИ инструмента, а последний - это координаты кончика инструмента. Формируем из этих чисел POINT и VECTOR, вызываем функцию DATA/CAM,3,POINT,VECTOR и получаем искомые машинные углы А и С. Опять же на полюсах, где возникает сингулярность, назначаем значения углов принудительно. То есть для программирования обработки 3+2, мы все углы вычисляем из , CAMERA.

Еще раз спасибо за Ваши ответы, где из намеков мы почерпнули важную информацию!

[LxCoder 32]

В 20.06.2018 в 09:17, Павел Ишмулкин сказал:

Еще раз спасибо за Ваши ответы, где из намеков мы почерпнули важную информацию!

На здоровье. Вот уж не знал, что на что-то важное намекнул :))

[Павел Ишмулкин 0]

А намек был простой, (повторюсь) я из CAMERA забрал вектор оси инструмента... Вы как-то обмолвились, что все углы считаете из GOTO  c вектором и начальной системой координат. Вот я и нашел способ определения машинных углов, используя DATA/CAM,3.

[DJ Astro 55]

В 18.06.2018 в 09:03, Павел Ишмулкин сказал:

   Так вот вопрос - как Вы справляетесь с проблемой - в одном ПОСТЕ рассчитать и углы Эйлера и машинные углы? Или, может быть, у Вас не стоит проблема в расчете машинных углов.

Машинные углы не рассчитываю. За меня это делают циклы PLANE SPATIAL и 800 как в реальных станках, так и в VERICUT :)

 

В 22.06.2018 в 06:16, Павел Ишмулкин сказал:

я из CAMERA забрал вектор оси инструмента... Вы как-то обмолвились, что все углы считаете из GOTO  c вектором и начальной системой координат. Вот я и нашел способ определения машинных углов, используя DATA/CAM,3.

Функцию DATA/CAM не использовал. В мануале G-POST, кстати, описана разница между DATA/CAM,1 и DATA/CAM,3 (почему у Вас и получались результаты, когда углы отличаются от корректных на 180, 270 градусов, в различных ситуациях).
Вектор оси инструмента всё равно откуда брать - из CAMERA или из GOTO, при 3+2 они одинаковы. По сути функция DATA/CAM,3 - это то же самое, что и POSTF(13) для кадра GOTO/X,Y,Z,I,J,K. Просто раньше нужно было писать конструкцию из нескольких строк и функций, чтобы прогнать GOTO через пост "в режиме симуляции" (без вывода кадра с координатами в программу) для вычисления углов поворотных осей с учётом кинематики станка. А теперь разработчики свели это всё в одну однострочную команду.

 

[Павел Ишмулкин 0]

Все так! (Ответ DJ Astro)

... Постепенно становимся умнее.

[fenics555 210]

Уважаемые Господа! При 4-х осевой обработке при сверлении нескольких подрят отверстий цикл сверления каждый раз отменяется, поворачивается ось, а потом заново этот цикл описывается:

N6S1200M3
N7G1G43X62.Y0.Z60.H1M8F7000.A40.
N8G81G98X62.Y0.Z46.5R49.F40.A40.
N9G80
N10G1Z60.F7000.
N11X55.A0.
N12G81G98X55.Y0.Z46.5R49.F40.A0.
N13G80
N14G1Z60.F7000.
N15X62.A-90.
N16G81G98X62.Y0.Z46.5R49.F40.A-90.
N17G80

 

Можно как-либо избежать этого? 

 

N10G1Z60.F7000.
N11X55.A0.
N12G81G98X55.Y0.Z46.5R49.F40.A0.
N13X62.Y0.A-90.
N17G80

 

И может кто подскажет как сделать?

В 29.11.2016 в 10:50, fenics555 сказал:

При жестком нарезании резьбы метчиком в строке оборотов необходимо вставить М29, но я тоже так и не нашел где это.
Может кто подскажет что можно сделать?

[DJ Astro 55]

В NCL всё так же и выводится - для каждого отверстия отдельный цикл, между циклами просто перемещения по координатам. Чтобы посту дать понять, что это один и тот же цикл - придётся повозиться...

Просканить вперёд весь шаг обработки в поисках циклов, сохранить все точки из "скобок" CYCLE / DRILL ........... CYCLE / OFF. Вывести первый цикл и дальше в него добавить сохранённые точки. Добавить проверку на одинаковость всех циклов в шаге. 

 

С М29 так же. В CIMFIL/ON, SPINDL cканировать шаг обработки вперёд в поисках цикла нарезания резьбы. Если есть - добавить в вывод оборотов М29.

[fenics555 210]

1 час назад, DJ Astro сказал:

В NCL всё так же и выводится - для каждого отверстия отдельный цикл, между циклами просто перемещения по координатам. Чтобы посту дать понять, что это один и тот же цикл - придётся повозиться...

Просканить вперёд весь шаг обработки в поисках циклов, сохранить все точки из "скобок" CYCLE / DRILL ........... CYCLE / OFF. Вывести первый цикл и дальше в него добавить сохранённые точки. Добавить проверку на одинаковость всех циклов в шаге. 

Честно говоря я вообще не разбирался с FIL, нет ни желания ни возможности. По крайней мере пока.

1 час назад, DJ Astro сказал:

С М29 так же. В CIMFIL/ON, SPINDL cканировать шаг обработки вперёд в поисках цикла нарезания резьбы. Если есть - добавить в вывод оборотов М29.

Тут, я думаю, вообще 3 строчки... Будем ждать доброго человека, который откликнется.

Еще такой вопрос: 

есть станок, у которого 4-ая ось не разжимается в автоматическом режиме. В G-post есть управление зажатием/разжатием осей, но при выводе УП идет разжатие-поворот-зажатие и т.д., т.е. непрерывного фрезерования не получается. В самом посте уже все галки перетыкал, разницы никакой. Как с этим бороться?

[LxCoder 32]

В 28.06.2018 в 12:25, DJ Astro сказал:

В NCL всё так же и выводится - для каждого отверстия отдельный цикл, между циклами просто перемещения по координатам. Чтобы посту дать понять, что это один и тот же цикл - придётся повозиться...

Просканить вперёд весь шаг обработки в поисках циклов, сохранить все точки из "скобок" CYCLE / DRILL ........... CYCLE / OFF. Вывести первый цикл и дальше в него добавить сохранённые точки. Добавить проверку на одинаковость всех циклов в шаге. 

 

С М29 так же. В CIMFIL/ON, SPINDL cканировать шаг обработки вперёд в поисках цикла нарезания резьбы. Если есть - добавить в вывод оборотов М29.

1. В NCL сделано все очень даже правильно, а именно для того, чтобы пользователь мог воткнуть процедуру пересчета смещения СК, если деталь оказывается не на оси вращения стола, и если УЧПУ не обладает функцией автоматического слежения (как у Фануков, например)... Для этого отменяется предыдущий цикл и выводится новый вектор инструмента. Поэтому особенного смысла в этой манипуляции (кроме незначительного сокращения объема программы как бы и нет. Помимо этого появляется возможность не сделать нормальную деталь (опять же, если наладчик не удосужился ее выставить ровно по оси вращения))

 

С М29 можно не сканить CIMFIL/ON,SPINDLE... Достаточно воткнуть что-то типа:

CIMFIL/AT,CYCLE,TAP 

      DMY=POSTF(20)
      SPD=POSTF(1,2,10)
      POSTN/OUT,M,29,S,SPD $$ ну или что-то другое...
      DMY=POSTF(21)

      DMY=POSTF(13)

CIMFIL/OFF

 

 

[fenics555 210]

20 часов назад, LxCoder сказал:

Поэтому особенного смысла в этой манипуляции (кроме незначительного сокращения объема программы как бы и нет.

А зачем вообще тогда циклы? Наверно оператору куда удобнее править режимы/глубины в одном кадре, не правда ли?

 

 

[LxCoder 32]

37 минут назад, fenics555 сказал:

А зачем вообще тогда циклы? Наверно оператору куда удобнее править режимы/глубины в одном кадре, не правда ли?

 

 

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

[fenics555 210]

15 часов назад, LxCoder сказал:

Так что здесь каждому решать, что же лучше - универсальность или краткость.

Мне все же кажется, что тут программный косяк! Именно в последовательности (считай в ГОТО) должно определяться группировать сверления по глубинам для вывода нормальных циклов, или по кратчайшему пути для 4-5 осевой обработке,а дальше,при любых вариантах, коль встречаются одинаковые условия сверления - собирать их в один цикл в ГОТО. 

А не в Гпосте простыни писать!

 

15 часов назад, LxCoder сказал:

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

У нас на это влияет массовость: на 10 деталей и так сойдет, а на 400 приходится ручками...

[LxCoder 32]

5 часов назад, fenics555 сказал:

Мне все же кажется, что тут программный косяк! Именно в последовательности (считай в ГОТО) должно определяться группировать сверления по глубинам для вывода нормальных циклов, или по кратчайшему пути для 4-5 осевой обработке,а дальше,при любых вариантах, коль встречаются одинаковые условия сверления - собирать их в один цикл в ГОТО. 

А не в Гпосте простыни писать!

    Вы прочитайте свой начальный пост, в котором вы задаете вопрос. Там весьма конкретно написано про 4-х осевое сверление. И Крео здесь делает все как нужно - я уже объяснил для чего так. Если хотите объединить точки сверления при 5-осевом (4-х осевом - неважно) - это должен делать пост, как говорится "под вашу ответственность". Крео дает избыточные данные для этого - не беда - отслеживайте, отсекайте, сортируйте. Но они от своей ж.. проблему отвели. Вот если бы этих данных не было, а были бы, например, отверстия, выполненные на одинаковой глубине, к примеру с использованием команд "ROTATE/BAXIS, ..." , "ROTATE/CAXIS, ... " или AAXIS - было бы все несколько иначе. Но логика системы выстроена через управление вектором оси инструмента - и это правильная логика, универсальная, не связанная с конфигурацией и кинематикой конечного оборудования.

    Если вы делаете простое 3-х осевое сверление, то в этом случае Крео не всегда разбивает на разные группы отверстия, различающихся по глубине сверления. И тогда некачественные посты выводят все в один цикл. И, соответственно, сверлят отверстия на одинаковую глубину вместо разных. Хотя и этого можно избежать, сгруппировав отверстия вручную через PICK_ORDER. Но ведь и не всегда заметишь, пока деталь не сделаешь:)

[Павел Ишмулкин 0]

... Может плохо искал, но в ветке VERICUTне нашел ничего похожего на свою проблему. Но в этой ветке я уже почерпнул много чего для себя, поэтому вопрос к DJ Astro!

Столкнулся с проблемой симуляции в VERICUT станка РАМА, у которого помимо оси Z существует еще ось V, которая двигает поворотный стол, навстречу оси Z, которая "вылазит" ползуном из колонны. Опуская то, что в самой Z еще присутствует ось W - удлинение шпинделя...) вопрос:

       В общем, без применения перемещения по V, все работает как надо, перемещаю G54 по XYZ (TRANS/ATRANS), поворачиваю вокруг ABC (ROT/AROT), поворачиваю стол по В, поворачиваю головы по АС -  Все на месте, все отрабатывает как надо,... но как только необходимо отодвинуть или пододвинуть стол, (команда V1000/V-1000), то все "съезжает" по Z, на величину этого смещения. Попытка, после смещения добавить TRANS V-1000, приводит к тому, что  "Нуль приводной точки" смещается из "своего" места, а обработка так и остается удаленной на смещение V1000.... Как-то давно в примерах VERICUT (display_dpz_wz_machine.vcproject), нашел похожую ситуацию, правда для FANUC. Там ось W "вытягивалась" из шпинделя, а компенсация выполнялась смещение системы координат по G52 Zппп. Попробовал у себя, вроде результат получил, НО:

     1. В реальной УП такой компенсации нет;

     2. Нет уверенности, что такая компенсация отработает, когда ось Z системы координат будет развернута, относительно машинной СК;

     Отсюда вопрос? Есть ли в VERICUT возможность компенсировать перемещения оси V ?????????

[LxCoder 32]

3 часа назад, Павел Ишмулкин сказал:

... Может плохо искал, но в ветке VERICUTне нашел ничего похожего на свою проблему. Но в этой ветке я уже почерпнул много чего для себя, поэтому вопрос к DJ Astro!

Столкнулся с проблемой симуляции в VERICUT станка РАМА, у которого помимо оси Z существует еще ось V, которая двигает поворотный стол, навстречу оси Z, которая "вылазит" ползуном из колонны. Опуская то, что в самой Z еще присутствует ось W - удлинение шпинделя...) вопрос:

       В общем, без применения перемещения по V, все работает как надо, перемещаю G54 по XYZ (TRANS/ATRANS), поворачиваю вокруг ABC (ROT/AROT), поворачиваю стол по В, поворачиваю головы по АС -  Все на месте, все отрабатывает как надо,... но как только необходимо отодвинуть или пододвинуть стол, (команда V1000/V-1000), то все "съезжает" по Z, на величину этого смещения. Попытка, после смещения добавить TRANS V-1000, приводит к тому, что  "Нуль приводной точки" смещается из "своего" места, а обработка так и остается удаленной на смещение V1000.... Как-то давно в примерах VERICUT (display_dpz_wz_machine.vcproject), нашел похожую ситуацию, правда для FANUC. Там ось W "вытягивалась" из шпинделя, а компенсация выполнялась смещение системы координат по G52 Zппп. Попробовал у себя, вроде результат получил, НО:

     1. В реальной УП такой компенсации нет;

     2. Нет уверенности, что такая компенсация отработает, когда ось Z системы координат будет развернута, относительно машинной СК;

     Отсюда вопрос? Есть ли в VERICUT возможность компенсировать перемещения оси V ?????????

Павел, лично мне кажется, что этот вопрос для ветки Vericut... Переадресуйте вопрос туда, там точно есть люди, которые Вам помогут.

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

Кроме того, вы описываете, как для симуляции станка в Vericut с контролом FANUC использовалась компенсация смещения через команду G52. У вас (судя по командам. которые вы приводите выше) стойка Sinumerik. Аналог G52 на Sinumerik - это TRANS/ATRANS - чем они Вас не устраивают?

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

 

[DJ Astro 55]

Павел, выкладывайте проект Вериката, так будет проще разбираться с вопросом. И попросите Модератора перенести тему в соответствующий раздел.