Анализ программ

[Гость UAV1]

 Задавался ли кто-нибудь вопросом о анализе программы на предмет ее эффективности(оптимальности). Имеется ввиду следущее. Я получил в CAM G-код. Далее мне нужно его проанализировать на предмет скажем, нет ли там нарушения динамики станка(смена направления на большой подаче). произошла ли смена инструмента через заданное время, и т.д. Вопрос такой, актуальна ли такая задача, и какие  важные моменты(критерии) можно было бы выявлять в программе. Мне еще в голову приходит менять подачу в зависимости от объема снимаемого материала. Предлагаю пофантазировать на эту тему предполагая, что информацию о программе можно получить любую.

[Гость lexcam_]

Я, например,анализирую до того, как писать G-код. Интересуют в основном два момента - визуализация(что реально получится) и время выполнения.Если время не устраивает - тогда "в голову приходит менять подачу" или "объем снимаемого материала" :) Я не думаю о том - произошла ли смена инструмента и т.д. потому что я об этом думал, когда писал и прогонял постпроцессор.И я на 100% уверен, что сбоев не будет.

[Гость sapr2000]

Я думаю, анализаторов "качества" G-кодов в чистом виде нет. Многие из функций, о которых говорил UAV присутствуют в программах графической верификации. Анализ и оптимизация величин подач и оборотов шпинделя, столкновения инструмента с деталью на быстрых ходах и прочее реализованы в той или иной степени, как приложения к задаче визуализации G-кода. Более подробно можно изучить данный вопрос на сайтах производителей программ. Если не знаете(где?), то даю линк на небольшой и далеко не полный обзор в этой области  <noindex>http://sapr2000.ru/link1.html</noindex>.

[IBV 112]

Ну по-моему контроль за нарушением динамики станка - это задача постпроцессора. И вообще серьёзно заниматься анализом G-кодов есть смысл (мне так кажется) заниматься только на стадии отладки постпроцессора. Иначе не останется время для работы. Если говорить о каком-то анализе, то конечно LexCAM прав - этим нужно заниматься до вывода G-кодов. Т.е. функции анализа (оптимизации обработки) должны быть в CAM-системе. Например, нужно сделать черновую обработку. Можно снимать по 2 мм на подаче 1000 мм/мин или по 10 мм на значительно меньшей подаче. Как быстрее на глаз сказать трудно, а чтоб САМ-система дала точный ответ ей все равно придется просчитать обработку в двух вариантах. Вот и весь анализ.

[Гость sapr2000]

Quote: from sapr2000 on 11:46 - 18 Янв., 2002

Ну по-моему контроль за нарушением динамики станка - это задача постпроцессора..

Соглашусь. Постпроцессор просто обязан занижать подачу, если, например, на данном перемешении и минимальном времени отработки кадра такая подача не "успеет" отработаться приводом станка. Обычно это возникает на мелких участках траектории в несколько импульсов(напр.скругления).

Далее, как найти грань, которая разделяет врезание от столкновения? Только ли наличие быстрохода на таком перемещении, только ли плавое врезание? Ведь многие САМы не имеют по-переходной технологии, где такие вопросы решаются по умолчанию?

Quote: from sapr2000 on 11:46 - 18 Янв., 2002

LexCAM прав - этим нужно заниматься до вывода G-кодов.

Согласен. Любая приличная САМ-система должна обеспечить технолога максимальным кол-вом инструментов для инспекции траектории движения и техн.команд еще до постпроцессирования.

С другой стороны, Борис, ты хорошо знаешь  и другой подход - графическая верификацмя G-кодов. Это попытка на только рисовать, но и оптимизировать, и находить ошибки.

[IBV 112]

Про верификацию я понятное дело слышал, вещь хорошая и нужная. Но думаю, что пользоваться ей нужно, когда:

  - отлаживаешь постпроцессор

  - в G-коды "вкралась" ошибка и непонятно её происхождение

  - есть большие сомнения в правильности G-кодов

  - деталь сложная и дорогая, ошибка обойдется слишком дорого

  - при использовании старой или чужой программы

  Каждую программу верифицировать - так тоже времени не напасёшься. А анализ и оптимизация все же думаю должны делаться в САМ-системе.

[Гость sapr2000]

Мы, кажется, немного удалились от темы. Вопрос стоял об анализе оптимальности УП. А мы кинулись в споры о том, в чем разница и зачем нужны верификаторы G-кодов и CL-файлов. :confused:

Мне помнится статья о оптимизации подач в EgeCAM. Я сам отношусь к этому процессу немного скептически, но если сабдж будет "обучаемым", а не слепо исполнять алгоритмы разработчиков, то тогда можно и подумать об его использовании. Иной раз подачи и обороты ставяться только исходя из опыта или результатов  пробного изготовления. А тут вмешивается сабдж и говорит - занизил подачу неправильно!

[Гость UAV1]

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

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

1. Понижать подачу если длина перемещения < Х.

2. Включать торможение (G9) если угол между перемещениями > X или след движение G00.

3. Сменить инструмент если время его работы > X или остановить обработку или пауза.

4. Подачу  увеличить если обьем снимаемый инстр < X уменьшить если >X

5. Менять велечину подачи в зависимость от встречное/попутное фрезерование

 

[Гость sapr2000]

И все же... этот список проблем нужен вам для разработки постпроцессоров или программы анализа?

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

Более того, мне кажется, что величина подачи, пришедшая в постпроцессор с тем или иным перемещением, должна подвергаться модификации весьма осторожно. Многи мои клиенты впадают "в транс", если выдят занижение подачи на том или ином участке траектории. Приходится анализировать каждый случай и объяснять, почему это произошло. Например, F5000 при движении по трем координатам мной не трактуется как быстрый ход, если в паспорте(постпроцессоре) кол-во координат БХ равно =2. Подача F200 занижается до минимально возможной на перемещении 5 мм, если минимальное время отработки кадра равно 0.1сек. и т п.

Иными словами, оптимизация динамики привода - это четкий свод правил, которые могут быть настроены пользователями того или иного постпроцессора. Если эти правила недоступны для изменения технологом, то это есть плохо. Это недостатки присущи индивидуальным постпроцессорам. Более того, сложные макроязыки, встроенные в универсальные постпроцессоры современных САПР, не дают возможность быстро  изменить алгоритмы(в том числе расчета динамики) самому технологу. Для этого он вынужден прибегать к помощи специально выделенного программиста. Это тоже, согласитеь, неудобно.

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

[Гость UAV1]

2Администратор

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

[Гость AVD]

Очень много полезной информации.

Я понял, что существующие проблемы надо решать постепенно. Часть в САМ системе, часть в постпроцессоре и часть в верификаторе. Доля которая прийдется на эти части зависит от используемых систем.

Большая часть, на мой взляд, лежит на САМ'е, далее на постпроцессоре...

[doob 14]

Согласен с AVD - проблему нужно решать по частям последовательно.

А всписок проблемных параметров для UAV могу добавить еще один.

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

[Гость UAV1]

doob

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

[doob 14]

2UAV

Совершенно верно! Анализировать угол нормали с осью Z! Если добавить к этой информации размеры фрезы, то для заданных оборотов можно определить скорость резания в точке касания фрезы. Или наоборот, задаваясь скоростью резания можно определить нужные обороты.

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

И еще, такое изменение оборотов приемлемо только для чистовой обработки, выражаясь количественно - если снимаемый слой не превышает приблизительно 30% от радиуса фрезы.

[Гость bigBUG]

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

[IBV 112]

  На токарных станках давно реализован алгоритм изменения скорости вращения от скорости резания в процессе обработки. Правда там методика расчета на два порядка проще. Для фрезерной обработки применить очень проблематично. Это не проще 3D-коррекции и "завязано" не только на возможности САМ-системы, но и станка.

 

[Гость bigBUG]

Напомните мне, пожалуйста, типичную подачу на оборот при токарке.

[IBV 112]

Михаил, а причем здесь подача? Там связь совсем другая - от заданной скорости резения (м/мин) и известного обрабатываемого диаметра (координата "Х" в УП) вычисляются обороты шпинделя. Вот и все. Подробностей не помню т.к. токаркой лет 300 не занимался, но при обработке торцев деталей большого диаметра народ у нас этой функцией пользоваться очень любил.

[Гость bigBUG]

Про подачу на оборот - это я к тому, что если её значение сравнительно невелико (как при токарке), то можно успеть разогнать/затормозить шпидель до нужной величины, если она к тому же плавно меняется.

Попробуем прикинуть для фрезерования.

Берём достаточно типовые параметры чистовой обработки по сырой стали:

Фреза - 4-х зубая шаровая SGS 14BM, из рекомендаций производителя берем

Fz=0.04 , то на оборот 0,16 при этом n=6000-8000 мин**-1.

Тогда линейная подача

Vf (она же F) =Fz x n x Z

То есть для приведенного примера -

Vf ( F ) = 0.04 x 8000 x 4 = 1280

То есть за 1 секунду проезжаем при скорости 1280 мм/мин ~21 мм.

Что все это значит?

Все это значит, что если мы обрабатываем поверхность с более-менее выраженным рельефом, то (при наличии n-оптимизированной УП) необходимо постоянное изменение скорости вращения шпинделя. По моим наблюдениям даже легкий шпиндель гравировального типа разгоняется-тормозится в диапазоне 0,5 полного где-то 3-5 секунд. За это время он уезжает в нашем примере на 60-105 мм (что ни к черту). То есть нужно либо еще и прогнозирование какое-то придумывать в этом оптимизаторе, либо искать принципиально новые шпинделя (при этом плюнув на износ механики ;)). Словом сдаётся мне, что не сильно хорошая это идея - n-оптимизация.

(Отредактировал(а) MFS - 17:40 - 26 Фев., 2002)

[Гость UAV1]

В дополнение к списку проблемных параметров.

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