Powermill: Учёт цикла разгон-торможение

[Сергей Ксуров 0]

Не секрет, что любой современный станок с ЧПУ отрабатывает перемещение из точки А в Б следующим образом: станок набирает скорость, затем, рядом с точкой Б, тормозит, в точке Б - неподвижен. Подобным образом станок отрабатывает все кадры программы.

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

Сталкивался ли кто с учётом времени на разгон-торможение?

[MFS 248]

Подобным образом станок отрабатывает все кадры программы.

Это если только включена остановка в конце кадра (G09, емнип). Имеет смысл ставить только на перебегах (которые на рапиде выполняются), на контурной, а тем паче 3Д станок с этим параметром дергается как эпилептик.

По умолчанию уголпробегается на рабочей, срезая траекторию на величину допустимого рассогласования. Если он там что-то где-то тормозит, то это уже Look ahead и просчитать это дело задача более чем серьезная и сильно, знаете ли будет зависеть от реализации предпросмотра на каждой конкретной стойке.

А еще сейчас придет MIF и что-нибудь интересное добавит :).

[Сергей Ксуров 0]

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

[andrey-rr 0]

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

[MFS 248]

Статистику человек хочет рисовать корректную.

Выяснять параметры лукэхэда (кривую разгона-торможения) и писать свою утилитку. Хотя вызнать реальные параметры, это, имхо практически нереально :(.

[Сергей Ксуров 0]

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

[MFS 248]

Может, каким-то образом можно зашить в милл параметры конкретного станка?

Насколько знаю - нет.

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

[UAV 19]

Может, каким-то образом можно зашить в милл параметры конкретного станка

<{POST_SNAPBACK}>

А в постпроцессоре нет что ли возможности считать самому время работы в каждом кадре и естественно суммировать его? Тогда можно было бы, учесть конкретику станка, введя поправки к расчетному времени.

[MFS 248]

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

Гы. Интересная мысль. Но работать будет по черепашьи.

[UAV 19]

Но работать будет по черепашьи.

<{POST_SNAPBACK}>

Ну и плеввать на медленность. Уж тут-то быстрота непринципиальна (не смену же считать будет вместо пары секунд)

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

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

[MFS 248]

можно порешать в симуляторе или в своей утилитке.

Вот это как-то ближе к правде, имхо.

[UAV 19]

Вот это как-то ближе к правде, имхо.

<{POST_SNAPBACK}>

Если бы это надо было только мне, я бы, точно в постпроцессоре бы делал это, если генератор такое позволяет (про PM просто не знаю). Там все известно (длина, подача), не надо городить огород с чтением, интерпритацией программы и т.п.

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

[IBV 112]

Писал я когда-то программку для подсчёта машинного времени. Работала она непосредственно с УП (ISO коды). Программка была простая, как грабли. И такой же она останется даже если разгоны-торможения учитывать. Но!!! Придётся провести офигительную работу по набору статистики как эти самые разгоны-торможения в реальной жизни работают.

Работала она, кстати, обалденно быстро. Т.е. это я к тому, что с симуляторами и постпроцессорами в данном случае лучше задачку не смешивать. Получится сложнее и медленнее.

[MFS 248]

Придётся провести офигительную работу по набору статистики как эти самые разгоны-торможения в реальной жизни работают.

По хорошему кривые ускорения можно с доки на стойку срисовать.

Т.е. это я к тому, что с симуляторами и постпроцессорами в данном случае лучше задачку не смешивать. Получится сложнее и медленнее.

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

[UAV 19]

Т.е. это я к тому, что с симуляторами и постпроцессорами в данном случае лучше задачку не смешивать. Получится сложнее и медленнее.

<{POST_SNAPBACK}>

Не соглашусь, в плане постпроцессора. Какая бы простая программа не была, все равно нужно в ней провести некоторую дополнительную работу по интерпритации G-кода. Это время. И чем хитрее G-код (не только G1 G0), тем сложнее (время программирования), становится эта работа. В генераторе постпроцессоров же, за меня это уже сделано - вставляй только формулы расчета времени. Реально, особого замедления не будет, не так уж и много вычислений добавится к основным.

[IBV 112]

UAV

Если делать глобально , то "ДА". Если для себя (1...2 станка), то нет. Всё специализированное работает много быстрее, чем универсальное.

[UAV 19]

Всё специализированное работает много быстрее, чем универсальное.

<{POST_SNAPBACK}>

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

[andrey-rr 0]

Ну и замутили вы тут с симуляторами и постпроцессорами. Объясните для чего все это? Если время расходится в 2 раза, это уже не PM виноват. Да и замучаетесь всю статистику собирать. Объясните пожалста, товарищ, какой у вас хоть станок, который так сильно то тормозит, то разгоняется.

[Himik 2]

на мой взгляд эту проблему можно решить следующим образом:

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

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

[bf109 8]

Я решаю эту проблему в Mastercam с помщью функции Highfeed.Заранее создаётся библиотека цехового оборудования,в неё заносятся,подобранные опытным путём,параметры динамики каждого станка.Расчитанная дата программы прогоняется через Highfeed,отображается коэффициент редукции реального времени обработки на станке от первичного,расчитанного без учёта разгонов и торможений и собственно реальное время обработки.Минута в минуту с компом ,конечно, не получается,5-7 % разброс,но это нормально.Другое дело,что под одни настройки динамики годятся все стратегии под 2,5 оси,а если стратегии 3-х осевые,в настройку динамики нужно вносить фиксированную поправку для отражения реального машинного времени,и для каждого станка она своя.Каждая дополнительная ось в программе заставляет вносить фиксированную опытным путём поправку в Highfeed.Но плюс здесь в том, что разработанные предварительно стратегии можно объединить в группы по типам,а затем прогонять покетным методом.