Ошибка в стандартном постпроцессоре на 5 осей для хайдена

[Ashmonin 6]

Появилось немного свободного времени и я решил подучить 5 осевую обработку. Начал пробовать выводить траектории через стандартный хайденовский пост sim08_mill_5ax_tnc_mm ну и соответственно прогоняя траекторию через встроеный симулятор NX. Все отлично работает кроме операции hole mill. Ну не хочет она постпроцессироваться так как нужно - не выводит преобразование системы координат. Копался около двух часов - обнаружил проблему в посте. В коммандах пользователя есть процедура PB_CMD_detect_tool_path_type в ней идет разбор какие операции выводить через преобразование системы координат а какие являются чисто 5 осевыми. Ищем строку

string match "Hole Milling" $mom_operation_type]

и меняем на

string match "Cylinder Milling" $mom_operation_type]

И почему её так обозвали эту "святую дырку"? А самое главное что этот пост является "родным" для кинематики станка в NX, а получалось что он не работал - что есть странно для меня.

Надеюсь эта информация будет полезна начинающим.

Кто нибудь использовал этот пост для боевых программ?

Много ли пришлось переделывать?

Что такое "обработка превышения предела оси"? - что за обработчим мона запихнуть?

[ben_laden 39]

Что такое "обработка превышения предела оси"?

Предполагаю, что это касается в основном поворотных осей. В САПРе вы задаете поворот, как вам угодно, а пост его выводит под нужный вам тип оборудования с учетом его кинематических особенностей. Напр., вы у вас есть 2 поворота А+90 и А-90 и УП вы выводите для станка с кинематической схемой ВС, причем пределы поворота по оси В от -10 до +95. В первом случае пост выдаст В+90 С+90, а во втором напишет "предел поворота по оси В" и выдаст В+90 С-90.

[Ashmonin 6]

Предполагаю, что это касается в основном поворотных осей. В САПРе вы задаете поворот, как вам угодно, а пост его выводит под нужный вам тип оборудования с учетом его кинематических особенностей. Напр., вы у вас есть 2 поворота А+90 и А-90 и УП вы выводите для станка с кинематической схемой ВС, причем пределы поворота по оси В от -10 до +95. В первом случае пост выдаст В+90 С+90, а во втором напишет "предел поворота по оси В" и выдаст В+90 С-90.

И как же такое реализовать?

[ben_laden 39]

И как же такое реализовать?

Sorry, но понятия не имею

Вы спросили

Что такое "обработка превышения предела оси"?

и я вам ответил свое видение этого.

Я использую посты под WF5.0, созданные в G-Post, которые нашей компании делала другая компания за деньги. Пройти нормальный курс обучения, включая модуль по G-Post, не могу из-за скупердяйства руководства

[Ashmonin 6]

Sorry, но понятия не имею

Вы спросили

и я вам ответил свое видение этого.

Я использую посты под WF5.0, созданные в G-Post, которые нашей компании делала другая компания за деньги. Пройти нормальный курс обучения, включая модуль по G-Post, не могу из-за скупердяйства руководства

Спасибо за ответ

[Ashmonin 6]

Продолжаю ковырять стандартный пост на 5 осей для хайдена. Просто так, чисто для себя...интересно ж.

Постпроцессор выдаёт вполне рабочий код, который я проверяю в верикуте(спасибо ОГРОМНОЕ участнику форума за помощь со стойкой hei530 в верикуте).

Всё работает: и 3+2 и непрерывная 5осевая. Сверлить не пробовал - но это потом всё...

Единственное что мне не нравится в постпроцессоре так это постоянный "отскок" по Z и "обнуление" поворотных осей в конце операции(3+2)

58 L ZQ503 R0 FMAX M91

59 L A+0.0 C+0.0 FMAX

Если у меня несколько операций на одном повороте - всё равно идет "отскок" и "обнуление", что не есть хорошо и как минимум не красиво. Вот задумал пост "доковырять".

Есть задумки как это реализовать:

* делать проверку в начале операции на изменение локальной СК

обрезает функционал NX так как можно делать операции без локальных СК с помощью функционала "задать вектор" и "нормально первой грани"

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

* делать проверку на изменение параметров(SPA,SPB,SPC) в цикле PLANE SPATIAL SPA+70. SPB+0.0 SPC+60. TURN FMAX SEQ+

если изменение не происходит то никаких "отскоков" и "обнулений" - это решение более "правильное" на мой взгляд (только не нада умничать и флудить, что правильное решение купит пост)

*ваша мысль реализации

Товарисчи! у кого есть такой опыт? кто как это реализовывал? может я слишком уж загоняюсь и фиг бы с ними с отскоками? может многие так и работают?

[avd 73]

Продолжаю ковырять стандартный пост на 5 осей для хайдена. Просто так, чисто для себя...интересно ж.

Постпроцессор выдаёт вполне рабочий код, который я проверяю в верикуте(спасибо ОГРОМНОЕ участнику форума за помощь со стойкой hei530 в верикуте).

Всё работает: и 3+2 и непрерывная 5осевая. Сверлить не пробовал - но это потом всё...

Единственное что мне не нравится в постпроцессоре так это постоянный "отскок" по Z и "обнуление" поворотных осей в конце операции(3+2)

58 L ZQ503 R0 FMAX M91

59 L A+0.0 C+0.0 FMAX

Если у меня несколько операций на одном повороте - всё равно идет "отскок" и "обнуление", что не есть хорошо и как минимум не красиво. Вот задумал пост "доковырять".

Есть задумки как это реализовать:

* делать проверку в начале операции на изменение локальной СК

обрезает функционал NX так как можно делать операции без локальных СК с помощью функционала "задать вектор" и "нормально первой грани"

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

* делать проверку на изменение параметров(SPA,SPB,SPC) в цикле PLANE SPATIAL SPA+70. SPB+0.0 SPC+60. TURN FMAX SEQ+

если изменение не происходит то никаких "отскоков" и "обнулений" - это решение более "правильное" на мой взгляд (только не нада умничать и флудить, что правильное решение купит пост)

*ваша мысль реализации

Товарисчи! у кого есть такой опыт? кто как это реализовывал? может я слишком уж загоняюсь и фиг бы с ними с отскоками? может многие так и работают?

Дешевле будет не переделывать

[Ashmonin 6]

Дешевле будет не переделывать

в смысле? я занимаюсь этим для себя. У меня на работе одна 3х осёвка, просто интересно, да и для себя полезно я считаю. У вас что же постоянно после каждой операции идет отскок и обнуление? я думаю нет

[avd 73]

в смысле? я занимаюсь этим для себя. У меня на работе одна 3х осёвка, просто интересно, да и для себя полезно я считаю. У вас что же постоянно после каждой операции идет отскок и обнуление? я думаю нет

Я про свой опыт говорю. Лучше пусть отскакивать будет - надежней и спокойней ИМХО.

[Ashmonin 6]

Я про свой опыт говорю. Лучше пусть отскакивать будет - надежней и спокойней ИМХО.

У меня были корпусные детали, про одну из них можно почитать на шмонин.рф я её делал на 3х осях, а если её запихнуть на 5 осей??? там туча операций на каждом повороте!!!

За опыт - спасибо!!! Ну как минимум попробую даже для того чтоб моск не затух

[avd 73]

У меня были корпусные детали, про одну из них можно почитать на шмонин.рф я её делал на 3х осях, а если её запихнуть на 5 осей??? там туча операций на каждом повороте!!!

За опыт - спасибо!!! Ну как минимум попробую даже для того чтоб моск не затух

Если станок не 3-9 метров в длину, то считаю не критичные отскоки в безопасную точку и обнуление осей

[Ashmonin 6]

Если станок не 3-9 метров в длину, то считаю не критичные отскоки в безопасную точку и обнуление осей

а как у Вас?

[avd 73]

а как у Вас?

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

[Ashmonin 6]

при изменениях осей происходит отскок в самую безопасную точку, поворот потом работаем дальше.

дык и я так хачу сделать))

[avd 73]

дык и я так хачу сделать))

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

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

Мысль вообще ваша верна, хотя посты 5-ти осевые я не делал сам в основном как пользователь и заказчик.

На мой взгляд надо проверять углы поворотов и принимать решение.... все просто

[Ashmonin 6]

Про локальные системы координат надо смотреть иногда они не нужны и вредны (конфигурация стол-стол, т.е. при повороте ось инструмента и ось Z всегда одинаковы), иногда они не обходимы и полезны (когда есть хоть одна голова, т.е. при повороте оси инструмента и ось Z разные).

три раза прочитал не понял про полезность и вредность ЛСК. Я по неопытности смотрю на ЛСК с точки зрения читабельности УП.

На мой взгляд надо проверять углы поворотов и принимать решение.... все просто

так то да. Я про это и писал выше...не все так просто оказалось. Сейчас пухнет голова. Но рожу чего нибудь через недельку мучений))

три раза прочитал не понял про полезность и вредность ЛСК. Я по неопытности смотрю на ЛСК с точки зрения читабельности УП.

возможно понял - это для возможности использовать циклы и коррекцию? если "да" то по Вашему в конфигурации стол-стол PLANE вообще не нужна? пересчеты всякие понадобится делать...

[avd 73]

возможно понял - это для возможности использовать циклы и коррекцию? если "да" то по Вашему в конфигурации стол-стол PLANE вообще не нужна? пересчеты всякие понадобится делать...

Каша манная обыкновенная)))))

PLANE нужна чтобы компенсировать повороты поворотных осей, потому что при повороте оси С система координат остается на месте, а PLANE ее переносит вместе с поворотом.

Локальные СК мне нужны были именно для коррекции и циклов сверления. Здесь надо конкретику приводить, а разговор не о том.

Резюмирую для станков типа Hermle, Variaxis и подобных, у которых есть два стола, локальные системы координат не нужны!

[Ashmonin 6]

Каша манная обыкновенная)))))

PLANE нужна чтобы компенсировать повороты поворотных осей, потому что при повороте оси С система координат остается на месте, а PLANE ее переносит вместе с поворотом.

Локальные СК мне нужны были именно для коррекции и циклов сверления. Здесь надо конкретику приводить, а разговор не о том.

Резюмирую для станков типа Hermle, Variaxis и подобных, у которых есть два стола, локальные системы координат не нужны!

я не пойму что плохого в том что я перенесу систему координат с помощью CYCLE DEF7.0 у станка с двумя столами?

может о разных вещах говорим?

[avd 73]

я не пойму что плохого в том что я перенесу систему координат с помощью CYCLE DEF7.0 у станка с двумя столами?

может о разных вещах говорим?

Да мы друг друга понимаем. В нашем постпроцессоре мы не используем локальные системы координат, соответственно цикл 7 не используется. Хотя при ручном программировании мы конечно его используем и другие замечательные циклы тоже.

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

[Ashmonin 6]

Да мы друг друга понимаем. В нашем постпроцессоре мы не используем локальные системы координат, соответственно цикл 7 не используется. Хотя при ручном программировании мы конечно его используем и другие замечательные циклы тоже.

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

да и пост легче делать в случае отсутствия ЛСК...но ведь жуть как хочется позаморачиваться .

Пост ужо почти слепил...осталось добить чтоб при сохранении углов осей из операции в операцию в случае использования или смены ЛСК(с такими же углами но другой координатой)пост делал plane reset stay потом переопределял sycle def 7 и включение plane spatial думаю если не осилю или надоест буду делать без ЛСК.