Постпроцессор к стойкам HEIDENHAIN.

[QQQ 0]

Если кто знает поделитесь информацией :

Существуют ли такие САПР, в которых есть постпроцессор к стойкам HEIDENHAIN (фрезерный станок Micron UMC710 стойка TNC-426) с использованием стандартных станочных циклов :

1-глубокое сверление.

4-прямоугольный карман,

5-круглый карман,

и др.?

[ak762 322]

Базовый пост имеется в Мастеркаме и даже не один.

А по мелочам все равно придется подстраивать.

Если надо я как раз этим и занимаюсь.

[MFS 249]

Наладить пост на Хейденхайн в любом КАМе, поддерживающем вышейказанное не проблема, ИМХО. Вот чтобы КАМ поддерживал фукции 4 и 5 - вот это интересно, эта тема обсуждалась в топике "Хитрый постпроцессор", и, похоже решили , что не фонтан с этим и в Мастере, и вообще

Изменено 7 июля 2003 пользователем MFS

[IBV 112]

Наладить пост на Хейденхайн в любом КАМе, поддерживающем вышейказанное не проблема, ИМХО. Вот чтобы КАМ поддерживал фукции и 5 - вот это интересно, эта тема обсуждалась в топике "Хитрый постпроцессор", и, похоже решили , что не фонтан с этим и в Мастере, и вообще

Не очень корректное заявление, Михаил. Иначе как можно объяснить, что я уже много лет успешно пишу программы для HEIDENHAIN355 используя для этого МастерКАМ?

QQQ

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

Изменено 7 июля 2003 пользователем IBV

[MFS 249]

Не очень корректное заявление, Михаил. Иначе как можно объяснить, что я уже много лет успешно пишу программы для HEIDENHAIN355 используя для этого МастепКАМ?

М.б. я не вполне ясно выразился, да и описАлся маленько - сейчас исправил - имелось в виду, что пункты 4 и 5 - т.е. выборку карманов циклами в КАМе сделать проблематично, да и не особо нужно.

Хотя проги хозяина нашего форума г-на Филиповича что-то такое вроде бы делают. Во всяком случае рекомендую найти вышеуказанный топик и ознакомиться. Он (топик) в этом раздела (НЦ, посты и т.д.)

Изменено 7 июля 2003 пользователем MFS

[GPN 3]

IBV

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

Борис, ты - почти прав!

Маленький подвопрос: а G41/G42 тебе для твоих стоек не нужно выделять?

[IBV 112]

Маленький подвопрос: а G41/G42 тебе для твоих стоек не нужно выделять? 

А причём тут включение коррекции? Коррекцией естественно пользуюсь (и на HEIDENHAIN в том числе). Я имел в виду, что пользоваться встроенными станочными циклами для выборки карманов при работе с CAM-системой не есть логично.

[PVL 0]

Есть постппроцессор для этого станка (система HEIDENHAIN 426 - 530),

поддерживающий этот формат, встроенные циклы сверления и фрезеровки,

циклы смещения и поворота, 5-Axis и пр. Пример на <noindex>http://cadcamcnc.narod.ru</noindex>

[GPN 3]

IBV

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

В этом я согласен с тобой на 100% !

А. если подраумевается, что "станочный цикл" в данном случае эквивалентен "canned cycle" и иже с ним, то займусь самокритикой

[IBV 112]

PVL

Я понимаю, что можно написать постпроцессор, который будет поддерживать встроенные циклы фрезеровки. Правда думаю, что это не очень просто. Но у меня вопрос - а зачем?

Если станочник грамотный, то программу с использованием станочных циклов он напишет и сам. Ему достаточно будет иметь корректный чертёж. Написать несложно и недолго. Можно написать 1 раз параметрический вариант и потом только править переменные. Раньше, когда у нас приличных CAM-систем не было, мы так и делали.

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

[QQQ 0]

ak762 MFS IBV GPN PVL Господа добрый день. Могу выходить в нет только после 00 поэтому постараюсь ответить всем.

MFS Июль 7 2003, 11:43 Прочитал эту дискуссию и считаю ее далеко не законченной, поэтому решил начать новую.

IBV Июль 7 2003, 12:00 При написании программ для 2.5D ты наверное используешь круговую интерполяцию, а мог бы по логике вещей использовать интерполяцию отрезками прямых, какая разница CADу, да и тебе тоже как будет выглядеть исходная программа? Кстати ты не сталкивался с лимитом в 1000 кадров в одной программе и 3500 кадров для всех программ для HEIDENHAIN355 ? Или у тебя блочная передача данных? Посмотри циклы 14, 6, 16 и я задам тебе вопрос зачем тебе на этой стойке вообще CAD для 2.5D или точнее такой ли CAD нужен для этой стойки?

MFS Июль 7 2003, 12:06 ; PVL Июль 7 2003, 16:09 Просмотрел пример программы да прогресс налицо но честно говоря не очень впечатляет.

CYCL DEF 19.0 BEARBEITUNGSEBENE - поворот "головы" в 5 координатном станке , а как по другому управлять этой координатой? Честно говоря не знаю.

CYCL DEF 7.0 NULLPUNKT - перенос системы координат это все равно, что вызвать функцию G92 в DIN-ISO

IBV Июль 7 2003, 16:34 Самый простой ответ на вопрос зачем это уменьшение объема программы.

Спасибо всем за помощь. Для тех кто хочет поговорить лично : oleg-sh@yandex.ru

[IBV 112]

Самый простой ответ на вопрос зачем это уменьшение объема программы.

QQQ

Олег, видимо задачи у нас разные, поэтому и подходы сильно отличаются. Я занимаюсь инструменталкой и меня такие меры по сокращению программы всё равно не спасут - программы бывают по 10 и более мегабайт. Вы правы, у меня программа подкачивается с компа. Кстати, переделка HEIDENHAIN для работы с подкачкой не такое уж дорогое удовольствие (менее 1000$), а проблему решает кардинально. Очень рекомендую.

[PVL 0]

Я думаю, что истина где то посредине.

Просто при написании постпроцессора, одно из условий

было обязательная поддержка циклов сверления и фрезерования.

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

CAM системы, нет особого смысла в получении программы обработки

с поддержкой циклов. Но в ответ услышал:

"Зачем ездить на Запорожце, если можно на Мерседесе".

И я не нашел аргументов против этого. Да, написать постпроцессор

в кодах ISO и без поддержки циклов былобы гораздно проще и быстрее,

поначалу я не был даже уверен, что это возможно, ведь это проблема не только

постпроцессора, но и проблема возможности CAM системы выдавать

определенный формат, без изменения идеологии работы с этой системой.

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

Если такой станок используется для обработки СФО, программы

на которые как правило состоят из координат X,Y,Z , большие по объему

и не пишуться на станке, то вполне достаточно формата ISO.

Если же это корпусные детали из самых различных областей, где

куча разных отвертий, карманов, пазов и т.п, где в принципе

достаточно обработки по 2,5 координатам и 4, 5-оси для позиционирования

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

и простота редактирования программы. Для станочника это важно.

А как правило, на таких станках и ребята работают, для которых просто

нажатие кнопки ПУСК недостаточно.

[IBV 112]

"Зачем ездить на Запорожце, если можно на Мерседесе".

Не знаю... По-моему в данном случае в роли Мерседеса может выступать только CAM-система. Аргументирую - сколько стратегий выборки кармана в CAM-системе и сколько во встоенных циклах ЧПУ? Мне думается, что просто программы нужно писать правильно, тогда их станочнику и редактировать не придётся.

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

[IBV 112]

QQQ

Посмотри циклы 14, 6, 16 и я задам тебе вопрос зачем тебе на этой стойке вообще CAD для 2.5D или точнее такой ли CAD нужен для этой стойки?

Ответ на этот вопрос сильно зависит в каком виде вы получаете задание на разработку программы. Я получаю твердотельную модель. Это означает, что мне не нужно вводить геомертию ручками. Поэтому даже при 2,5D-обработке у меня получится быстрее и надёжнее писать программу, ориентируясь на возможности CAM-системы, а не на возможности встроенных циклов станка.

[sapr2000 68]

Прочитал я ваш спор, уважаемые коллеги. Думается каждый из вас по своему прав. IBV в силу специфики производственного процесса и возможностей его САМ-системы, а также прямой передачи УП на станок, "глубоко фиолетово" наличие в системе с ЧПУ каких-либо изысков. Фрезерование карманов или прочих "углублений" он "поручает" Мастеркаму и за сим счастлив и доволен. Позиция его оппонента мне тоже хорошо знакома, за свою жисть я познакомился с технологами, предпочитаюшими использовать на 100% возможности стойки. Во-первых это правильно, во-вторых, ведет у существенному уменьшению кадров УП, в третьих ...ну тут у каждого свои аргументы. Я ни хочу искать здесь истину. Это собсно и не требуется. Каждый юзает систему с ЧПУ по своему и видимо доволен.

Хотца ответить на поставленный вопрос.

НУ есть такая возможность в нашем САПР-ЧПУ. Мы действительно допускаем использование любых станочных подпрограмм, автоциклов и станочных подпрограмм, написанных самим технологом. В том числе и для вашей стойки. Стойка нам хорошо известна. Постпроцессор на нее написан и отлажен и крутиться где-то на машзаводе в Ростове на Дону. Мало того, попутно мы решали задачу графической верификации таких программ, обеспечивая графическое моделирование выполнения стойкой станочных подпрограмм с конкретными параметрами. Жаль что мои попытки, заставить технолога - чиркнуть об выполненной работе статейку, пока не увенчались успехом. А было бы любопытно и показательно. С той точки зрения, что постпроцессоры в САПР-ЧПУ пишет технолог, не имеющий ни какого понятия о языках программирования. Он же пишет и макропроцедуры иммитации работы станочных подпрограмм.

Появились вопросы -задавайте.

[GPN 3]

sapr2000

Появились вопросы -задавайте.

А я моя псина по кликухе numericon850 под колёса вашего верификатора никогда не попадала?

Очень хоца проверять живой код без особенных изысков (т.е. по крупному G0,1,2,3)

Проблемы две.

Проблема №1 : движется, собака, хитрокриволинейно (или криволинейнохитро ?)

N805 G4 I-20.09 J-35.8 R10.3 C180.

N806 G2 C130.87

где

G4 - "служебный" код (ввод потребной инфы и т.п.)

N805 G4 I-20.09 J-35.8 R10.3 C180. - описывает начальную точку движения, в которой инструмент уже находится

соответственно N806 G2 C130.87 описывает точку назначения

Проблема №2 : нужно найти "готовый на всё" софт, а не "готовых на всё" программеров, ибо легче вытянуть бегемота из болота, чем денюжку из моего хозяина, коего слово customizing бросает в дрожь , и формулы "money - it's a gas" не разделяющего

[QQQ 0]

IBV Июль 8 2003, 9:47; IBV Июль 8 2003, 12:48

Да пока что у нас есть MICRONы 145, 155, 355, 426 но нет блочной передачи данных. У нас не инструментальное производство но продукция в основном единичная и в 2,5D. Чертежи приходят в бумажном виде иногда можно выпросить файл в АВТОКАДе. Объемные модели в том же АВТОКАДе начали рисовать только недавно но это великий подвиг, о твердотельных математических моделях пока нет разговоров, а хотелось бы. Как у вас начинался этот процесс? Интересно все: как организовать, какой софт нужен (или рекомендуешь), железо для его поддержки, какая структура производства под весе это. Для меня это не праздные вопросы так как я недавно начал процесс по по переходу на более высокий уровень, чем у нас есть. Пиши. Извини что на ты - издержки воспитания сети.

PVL Июль 8 2003, 12:15

Спасибо за письмо. Это уже интересней. Даже встретились незнакомые циклы. Твое мнение: нужен ли САПР, который поддерживает только встроенные функции станка, хотя бы % на 70? Будет ли он иметь хоть какую то нишу? Или это все от нашей бедности?

[QQQ 0]

sapr2000 Июль 8 2003, 14:55

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

[IBV 112]

QQQ

1. Позволю себе ответить за sapr2000 - более подробная инфа здесь ]]>http://www.sapr2000.ru/]]>

2. Поскольку твои вопросы ко мне выходят за рамки топика, отвечу на e-mail. Адресок пришли, мой адрес:

boris@skantooling.eunet.lv

Изменено 9 июля 2003 пользователем IBV