Перейти к публикации

Интересный теоретический вопрос


Рекомендованные сообщения

это безусловно простой способ, но не точный +

Любая аппроксимация есть приближенное решение с задаваемой точностью.

PS

apelsin

При поиске в гугле пишите на вякий случай две "П" в термине. Больше результатов будет наверное.

Ссылка на сообщение
Поделиться на других сайтах


А в каких CAM это есть

Ну в Mastercam есть,например.Только для этих целей не стоит покупать программу,стоящую несколько тысяч мёртвых американских президентов.Есть специальные маленькие программы от авторитетных производителей,работающие с NC-кодом.За сущие копейки можно приобрести ту же CIMCO Filter(не реклама!) например,и прогнать через неё программу с аппроксимированными контурами.Нормальный руководитель производства просто приобрёл бы её для программиста,чтобы тот занимался делом на работе,а не изобретал велосипед.Ну,а насчёт точности-что отрезки,что дуги-всё это приближения и на их количество(а значит на точность контура) должен влиять допуск на размер.Не стоит "ловить блох"там,где это не нужно.Какими бы старыми и медленными не были стойки на станках,внешний вид обработки сглаженного контура всегда лучше,чем аппроксимированного.
Ссылка на сообщение
Поделиться на других сайтах

Это вообще-то принципиально в плане моего вопроса...Т.е. разница есть на какой стадии это происходит.

Почему всё-таки вам кажется, что это важно, нужно, необходимо? Если из-за этого

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

, то тоже неизвестно, что будет после ПП.

Ещё одно соображение, которое пришло мне вчера в голову - разные стойки по-разному G02/03 "воспринимают": синумерик через CIP как-то (из-за этой CIP и пришла в голову эта мысль), NUM напрямую через G17, Heidenhain видимо ещё как-то. Глубоко не копал, так как не силён в этом и не нужно, однако вывел для себя, что точно по-разному. То есть ещё один аргумент за дуги после конкретного ПП для конкретной стойки, а не в "обезличенном" CАD/CAMе.

Ссылка на сообщение
Поделиться на других сайтах

То есть ещё один аргумент за дуги после конкретного ПП для конкретной стойки, а не в "обезличенном" CАD/CAMе

Так ПП тем и занимается, что из универсального (формата CAD/CAM) формата получает конкретный формат стойки.

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Т.е. если взглянуть на CL файл этих систем, то там я увижу дуги при обработке сплайна?

Это вообще-то принципиально в плане моего вопроса....

Ну и видимо и в тебис этого нет, раз вы так к этому относитесь.

Есть, есть; вот сподобился закинуть картинку: post-6764-1258639279_thumb.jpg

Но в Tebis эту задачу решает все равно ПП.

Ссылка на сообщение
Поделиться на других сайтах

Но в Tebis эту задачу решает все равно ПП.

По-моему это не здорово. Лучше иметь дуги уже в CLDATA, чем считать в ПП. Это и надёжнее и нагляднее. Наверное и быстрее.
Ссылка на сообщение
Поделиться на других сайтах

В NX при обработке сплайнов три возможных выбора, еще ДО постпроцессирования.

1. Все в линейных перемещениях

2. Дугами и линиями в пределах заданной точности (при этом CLS честно выводит дуги)

3. Сплайн-интерполяция.

См. картинку.

Ссылка на сообщение
Поделиться на других сайтах

По-моему это не здорово. Лучше иметь дуги уже в CLDATA, чем считать в ПП. Это и надёжнее и нагляднее. Наверное и быстрее.

Так и есть. Я просто хотел сказать ,что из дуг в дуги :smile: их все равно, в конечном итоге, должен перебросить ПП. А уж насколько эти дуги в CL (я это CAD/CAM называю) в сравнении с отрезками упрощают/усложняют задачу ПП, не в курсе.
Ссылка на сообщение
Поделиться на других сайтах

насколько эти дуги в CL (я это CAD/CAM называю) в сравнении с отрезками упрощают/усложняют задачу ПП, не в курсе.

Типа

"Ну я-то че полез, я ж читать не умею!" (© анек)

Ссылка на сообщение
Поделиться на других сайтах
  • 12 лет спустя...

Присоединяйтесь к обсуждению

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.




×
×
  • Создать...