Помогите разобраться со скоростью обработки при 5 осях

[Akson 0]

Собственно дело вот в чем, для 3х осей скорость подачи, скорость относительно поверхности и обороты в минуту штуки достаточно простые и очевидные, но с 5 осями я не до конца понимаю как все это работает. Точнее для линейных все логично, но как это происходит с вращающимися осями? Еще есть недопонимание inverse feed rate, как там все считается? Еще есть ли разница с и без RTMP? А еще была обнаружена проблема: при некоторых командах перемещение по осям A и C происходило оооочень медленно, т.е. идет обработка, все хорошо, но в какой-то момент выполнение очередного шага требует 10 минут, хотя там совсем небольшое линейное перемещение. Не могу показать сейчас программу, но если это какая-то стандартная проблема, буду очень признателен за помощь.

Наверное несколько сумбурные вопросы, но идея такая: как все это работает в 5 осях с RTMP?

Заранее большое спасибо за помощь!

PS: У Гугла спрашивал, вразумительного ответа не получил. Возможно спрашивал плохо. Если пошлете меня в нужном направлении, заранее спасибо!

[volodja 77]

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

Что касается замедления, проблема 1) в количестве NC-точек в этом месте программы и 2) в скорости работы стойки. Повлиять можно несколькими способами:

1) изменить параметр распределения NC-точек в созданной операции (если этот параметр есть, зависит от САПР).

2) на большинстве знакомых мне стоек есть параметр "фильтрации" таких точек или параметр "сглаживания" траектории. К примеру это 32ой цикл на Heidenhain, пара параметров (RADMAX, tolerance) на Roeders, на Sinumerik 840D не помню; кажется М120, но не уверен. До известного предела помогает.

3) если стойка совсем старая, она может читать одну точку УП за другой, а не все сразу. У Sinumerik 840D для этого есть команда G642, у других не знаю, но думаю здесь спецы подскажут.

[Akson 0]

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

Что касается замедления, проблема 1) в количестве NC-точек в этом месте программы и 2) в скорости работы стойки. Повлиять можно несколькими способами:

1) изменить параметр распределения NC-точек в созданной операции (если этот параметр есть, зависит от САПР).

2) на большинстве знакомых мне стоек есть параметр "фильтрации" таких точек или параметр "сглаживания" траектории. К примеру это 32ой цикл на Heidenhain, пара параметров (RADMAX, tolerance) на Roeders, на Sinumerik 840D не помню; кажется М120, но не уверен. До известного предела помогает.

3) если стойка совсем старая, она может читать одну точку УП за другой, а не все сразу. У Sinumerik 840D для этого есть команда G642, у других не знаю, но думаю здесь спецы подскажут.

Спасибо большое за быстрый ответ!

Про RTMP->RTCP правда, описался.

На счет точек имеется в виду какие-то внутренние точки, которые использует стойка?

Потому что в программе это просто 2 соседние строки/точки.

Примерно так:

N1000 X1 Y1 Z1 A1 C1

N1001 X2 Y2 Z2 A2 C2

И вот между ними переход длился 10 минут, хотя до этого и после этого никаких проблем нет. Станок Okuma MU500VA с родной стойкой окумовской, вроде у него все должно быть хорошо с производительностью.

[volodja 77]

На счет точек имеется в виду какие-то внутренние точки, которые использует стойка?

Потому что в программе это просто 2 соседние строки/точки.

Примерно так:

N1000 X1 Y1 Z1 A1 C1

N1001 X2 Y2 Z2 A2 C2

И вот между ними переход длился 10 минут, хотя до этого и после этого никаких проблем нет. Станок Okuma MU500VA с родной стойкой окумовской, вроде у него все должно быть хорошо с производительностью.

Нет, точки из NC-программы, которые ПП переводит в G-кодовый/текстовый формат. Я имел ввиду, как между ними стойка строит траекторию. Равномерно ли расположены точки/координаты в УП? Там, где переход длится долго - близко ли друг от друга расположены эти точки/есть ли там их "сгущение"? Траекторию внимательнее проверьте, для пяти осей важно наличие ОДНОЗНАЧНОЙ нормали в каждой точке геометрии. Геометрию посмотрите, может там чего не в порядке. Как себя фреза в САМе ведёт - также как на станке или равномерно проходит?

Скажем так: есть стойки, которым (из-за заложенного алгоритма/логики) необходимо равномерное распределение точек через, скажем, 0.1мм; объём УП не имеет значения. В основном это современные стойки/станки, "поддерживающие" HSC-технологию.

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

Чёткой границы конечно нет и параметрами стойки можно поиграть, но примерно так выглядит сегодняшняя ситуация.

[Akson 0]

Нет, точки из NC-программы, которые ПП переводит в G-кодовый/текстовый формат. Я имел ввиду, как между ними стойка строит траекторию. Равномерно ли расположены точки/координаты в УП? Там, где переход длится долго - близко ли друг от друга расположены эти точки/есть ли там их "сгущение"? Траекторию внимательнее проверьте, для пяти осей важно наличие ОДНОЗНАЧНОЙ нормали в каждой точке геометрии. Геометрию посмотрите, может там чего не в порядке. Как себя фреза в САМе ведёт - также как на станке или равномерно проходит?

Скажем так: есть стойки, которым (из-за заложенного алгоритма/логики) необходимо равномерное распределение точек через, скажем, 0.1мм; объём УП не имеет значения. В основном это современные стойки/станки, "поддерживающие" HSC-технологию.

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

Чёткой границы конечно нет и параметрами стойки можно поиграть, но примерно так выглядит сегодняшняя ситуация.

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

[Wizard! 7]

Еще есть ли разница с и без RTMP?

Если есть RTCP, то скорость подачи на вершине инструмента будет такой (а на практике не всегда, например, как у Вас), как задано в программе.

Если нет, то читать <noindex>здесь</noindex>.

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

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

[Akson 0]

Если есть RTCP, то скорость подачи на вершине инструмента будет такой (а на практике не всегда, например, как у Вас), как задано в программе.

Если нет, то читать <noindex>здесь</noindex>.

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

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

Спасибо за ссылку, прочитал эту ветку, вроде стало понятно как оно должно работать теоретически:).

Т.е. получается, что станок линейно интерполирует все оси вместе и можно о них думать как о простом линейном перемещении в 5тимерном пространстве, а feed rate задается как раз для этого самого перемещения, где уже смешались градусы и миллиметры. Но если какая-то ось не успевает, то она двигается на предельной скорости, а остальные двигаются медленнее. Правильно я понимаю?

А с RTCP тогда как? Там для расчетов используется перемещение в системе координат модели, но учитываются максимальные скорости в системе координат станка?

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

[Wizard! 7]

Т.е. получается, что станок линейно интерполирует все оси вместе и можно о них думать как о простом линейном перемещении в 5тимерном пространстве, а feed rate задается как раз для этого самого перемещения, где уже смешались градусы и миллиметры.

Только в том смысле, что система ЧПУ таким образом интерпретирует подачу, заданную в кадре. А задача постпроцессора - под эту интерпретацию подстроиться и вывести в кадр такое значение подачи ("код подачи", как это называется по ссылке), чтобы после интерпретации системой ЧПУ получить необходимую минутную подачу.

Но если какая-то ось не успевает, то она двигается на предельной скорости, а остальные двигаются медленнее. Правильно я понимаю?

Да, подача других осей пропорционально уменьшается.

А с RTCP тогда как? Там для расчетов используется перемещение в системе координат модели, но учитываются максимальные скорости в системе координат станка?

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

Хотя причины торможений похоже где-то глубже.

Видимо, так.