Распознавание 2D-элементов

[dd22 13]

Слышал как-то, что для look-ahead стоек линеаризированная прога предпочтительнее. Вы не в курсе - так это?

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

[MFS 248]

Мы даже подводы по дуге из-за этого перестали делать.

Ужас какой. В ductpost поставьте integer 26 = 0 и вам пост все дуги линеаризует.

[Wizard! 7]

Под Heidenhain я разрешил в посте вывод дуг в плоскости XY, в остальных плоскостях их обычно не бывает. Проверял на практике: программы с дугами отрабатываются быстрее, чем линеаризованные. А если использовать коррекцию, то линеаризованные программы проигрывают в производительности совсем сильно.

Качество поверхности при одной и той же точности расчета УП будет выше после программы с дугами. Например, программа расчитана с точностью 0,1 мм. Следы на детали после линеаризованных дуг будут очень грубыми. А если дуги вписаны - получится нормальный результат, хотя координаты, описывающие дугу, "будут не на своем месте" до этой 0,1 мм, т. к. стойка будет интерполировать дугу с точностью гораздо более высокой 0,1 (привода управляются дискретно, но эта дискретность весьма мала). Вы конечно скажете, что используете для расчета гораздо меньший допуск, и проходы после отрезков линеаризованной дуги выглядят весьма прилично. Но программа выросла в объеме от этого. Look Ahead конечно вас выручит, движения станка могут быть плавными, без подтормаживаний. Но по факту медленнее, чем с круговой интерполяцией. Ведь столько коротких кадров требуют обработки наперед. Стойка может не держать заданную подачу. В общем, стойке может быть удобнее "проглотить" один кадр с круговой интерполяцией, чем сотню-другую с линейной. Естественно, на ФОД вывод дуг применим редко. Разве что при черновой обработке 2,5D стратегиями.

Про линеаризованные программы для Look Ahead. Я бы ответил так. Считается, что для Look Ahead предпочтительнее равномерное распределение точек по поверхности, что может быть достигнуто только с линеаризацией дуг. Обсуждалось вот здесь: http://www.fsapr2000.ru/index.php?showtopic=23243

[rw666 74]

согласен, что дуги это хорошо :)

Никто не спорит, это более короткое математическое описание траектории.

Со сплайнами еще короче и правильнее будет. :)

Heidenhein iTNC 530 их поддерживает, Wizard! вы не пробовали?

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

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

А путем их апроксимации с заданной точностью получают уже дуги или сплайны.

Это я о 3D обработке.

Для 2D я уверен, что идет работа в 2-х объектах - линиях и дугах.

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

это 4 000 мм/мин по воску. Отрабатывает четко не сбавляя подачи.

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

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

Ну и конечно в точках резкого изменения вектора скорости УЧПУ сама сбавляет скорость, чтобы не выйти за заданную точность,

которая вводится кадром

21 CYCL DEF 32.0 TOLERANCE

22 CYCL DEF 32.1 T0.01

Что тоже прекрасно, так обеспечение точности отработки ложится на стойку, имеются ввиду учет инерционных сил, действующих на подвижные оси.

:)

Изменено 13 августа 2009 пользователем rw666

[rw666 74]

Слышал как-то, что для look-ahead стоек линеаризированная прога предпочтительнее. Вы не в курсе - так это?

У меня по этому поводу есть предположение, правда мое личное, ну и немного основанное на обрывочной информации от наладчика.

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

у нас на стойке Heidenhein iTNC 530 это выводится кадром

21 CYCL DEF 32.0 TOLERANCE

22 CYCL DEF 32.1 T0.01

Т.е. по-моему функция Look Ahead выполняет апроксимацию с заданной точностью линейных перемещений преобразуя их в некоторую математическую функцию типа сплайнов. Плюс ловит точки резкого изменения вектора скорости, учитывает инерционность осей, для коррекции подачи.

А потом выдавая их на органы движения делает опять же линейную интерполяцию.

По-моему так.

look-ahead это ведь не банальное предчтение кадров в какой-то буфер внутренней памяти с винчестера.

Сейчас это просто неактуально. Если подкачка, то да может именно это и имеется ввиду и то врядли.

Простите, что я написал кучу однотипных ответов в разных ветках форума, но просто много веток затрагивают один и тот же вопрос.

А у меня сейчас есть желание поотвечать :)

Изменено 13 августа 2009 пользователем rw666

[Wizard! 7]

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

это 4 000 мм/мин по воску. Отрабатывает четко не сбавляя подачи.

Я работаю на подаче до 8000 мм/мин, разница ощутима. Ну плюс ведь все от траектории зависит.

У меня по этому поводу есть предположение, правда мое личное, ну и немного основанное на обрывочной информации от наладчика.

Так и есть, цикл 32 - это максимально отклонение реальной траектории от запрограммированной. Резкие переломы траектории сглаживаются дугами или сплайнами в пределах этого допуска, и это часть функции Look Ahead.

Однако вещь эта должна работать что для прямых, что для дуг, насколько мне понятно. Правда, по идее дуга - это уже плавное движение... Может быть, фактически имеет смысл только для прямых...

Heidenhein iTNC 530 их поддерживает, Wizard! вы не пробовали?

Сплайны не пробовал. Руки не доходят. Видимо, сильно не прижимает их использовать ).

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

Так и есть, САМ вычисляет все с помощью отрезков, а затем уже вписывает дуги. Но, как я уже говорил, дело тут в особенностях обработки информации и управления стойки.

21 CYCL DEF 32.0 TOLERANCE

22 CYCL DEF 32.1 T0.01

Кстати, а кроме этих двух параметров цикла 32 другие использовать не пробовали? Мне в остальных параметрах не все понятно. В документации описано скудно, спрашивал у сотрудников московского представительства Heidenhain - затрудняются ответить.

[rw666 74]

Кстати, а кроме этих двух параметров цикла 32 другие использовать не пробовали? Мне в остальных параметрах не все понятно. В документации описано скудно, спрашивал у сотрудников московского представительства Heidenhain - затрудняются ответить.

1) Если честно, только сейчас от вас и узнал, что в 32 цикле есть еще какие-то параметры.

Даже не подозревал такого. Никогда не водил его со стойки (там ведь подсказывает).

Попробую почитать мат. часть.

2) U.S. Опять же, повторю свое сообщение из ветки про стойки Heidenhein.

Т.к. чувствую, что вроде бы оно и здесь будет актуально.

Раз уж разговор зашел о скорости подач и плавности отработки.

S. У нас в инструментальном производстве 5-ти осевой Fehlmann Picomax 60M со стойкой Heidenhein iTNC 530.

Могу сказать только хорошее: как про станок, так и про стойку. Все просто замечательное, умеют люди делать.

Делаем ФОД просто прекрасно, никаких проблем.

Есть спец опции стойки для различных задач: точность, качество поверхности, скорость.

CYCL DEF 327 HSC-SETUP ~

Q273=+2

Мы в основном используем преднастройку - поверхность.

При ней движение мягкие, плавные, без ударов в точках резкого изменения вектора скорости.

Цикл как-то оптимизирует особым боразом управление приводами (так нам объяснили).

А может банально притормаживает в точке разворота.

Если этот цикл не включать (значение 0 ), то станок будет "бить" каждую точку траектории.

Т.е. жестко ее отрабатывать. А при включенном цикле на "поверхность" происходит сглаживание.

Получается какое-то дополнение к 32 циклу.

В общем нарадоваться не можем.

Не стойка, а песня. :)

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

Т.е. не у всех у кого есть эта стойка.

Изменено 14 августа 2009 пользователем rw666

[Wizard! 7]

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

Т.е. не у всех у кого есть эта стойка.

Так точно, такого цикла у нас нет. Кстати, в самом 32 цикле есть подобные преднастройки.

[Andrew_P 14]

Слышал как-то, что для look-ahead стоек линеаризированная прога предпочтительнее. Вы не в курсе - так это?

Это является важным условием для траектории, которую станок отрабатывает с функцией look-ahead. Причем Делкам специально для этой функции стоек разработал алгоритм размещения точек как "Переразместить" плюс "Ограничить расстояние между точками". С этими параметрами траектории и функцией станка look-ahead станок ровнее (по подачах) и !самое важное! - быстрее обрабатывает деталь в отличии от обычной траектории. Это касается и непрерывного 5-ти осевого фрезерования.

[Wizard! 7]

Нужную ссылку уже привел )

!самое важное! - быстрее обрабатывает деталь в отличии от обычной траектории

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

[maxcrug 0]

Как много ответов.

Лабы выкладываю, пока только те, какие накидал.

На студентах не испытаны!

Когда допишу недостающие и оформлю до конца - не знаю.

Осталось две:

- 2,5D обработка (еще думаю, что дать);

- обработка по поверхностям (даже не думал).

labi.zip

Изменено 17 августа 2009 пользователем maxcrug