Для чего Вы используете симулятор ЧПУ станка? Нужно ли видеть симуляцию?

[Akson 0]

Продолжая серию простых/очевидных/глупых(нужное подчеркнуть) вопросов, я хотел бы спросить, для чего Вы используете симуляторы (всякие верикаты, нцменеджеры и подобные)?

Дабы не получать ответ: "для симуляции", я уточню.

Делаю я исследование (аспирант я) на тему автоматической генерации УП для 5-осевых станков (я знаю, что не сделаю универсальную, но это уже другая история) и использования GPU для расчетов. Частью этой системы будет симулятор процесса фрезерования, который мне нужен для выбора траектории, но есть идея сделать из него собственно симулятор с некоторыми интересными особенностями и написать об этом в предложении проекта, который мне скоро надо будет представлять. С одной стороны, хочется добавить несколько фраз о том, какой полезный он будет и какая ценная моя работа. С другой же стороны, может действительно получиться что-то интересное именно из-за того, что я планирую все считать на GPU. Особенностью GPU является то, что мне гораздо проще рассчитать результат выполнения 100тыс кадров сразу, чем последовательно каждый из них. Поэтоу есть вопрос, а надо ли Вам видеть весь процесс симуляции, или интересно найти только те участки, где возникают столкновения и зарезы? Просто симулировать можно и на CPU как обычно и я не вижу особого смысла пытаться сделать непрерывную симуляцию со скоростью 1000FPS. Но я могу разбить всю программу на части и симулировать одновременно каждую часть, тогда это будет быстро.

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

Что Вы думаете по этому поводу? Нужно ли еще какие-то данные получить от симулятора?

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

[CyberPunk 3]

Симулятор использую для:

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

2. Анализа оптимальности траектории. (Наличие лишних ходов, переходов)

3. Анализа результирующей модели. (Недорезы, чистота поверхности)

Поэтоу есть вопрос, а надо ли Вам видеть весь процесс симуляции

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

[volodja 77]

Основная причина использования симуляторов это 1) выявление зарезов/столкновений на стадии программирования и 2) быстрая оптимизация траектории. Таким образом экономится машинное время и исключаются/снижается вероятность брака/поломок. Проверяться должен конечный G-код после постпроцессора, а не САМ-траектории из САПР.

В визуализации как таковой ПРАКТИЧЕСКОГО смысла немного, больше для красоты конечно. Но иногда требуется и бывает полезна.

[CyberPunk 3]

Основная причина использования симуляторов это 1) выявление зарезов/столкновений на стадии программирования и 2) быстрая оптимизация траектории. Таким образом экономится машинное время и исключаются/снижается вероятность брака/поломок. Проверяться должен конечный G-код после постпроцессора, а не САМ-траектории из САПР.

В визуализации как таковой ПРАКТИЧЕСКОГО смысла немного, больше для красоты конечно. Но иногда требуется и бывает полезна.

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

[belov_sw 0]

Поэтоу есть вопрос, а надо ли Вам видеть весь процесс симуляции, или интересно найти только те участки, где возникают столкновения и зарезы?

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

[volodja 77]

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

Вы видимо не поняли смысл моего высказывания "визуализации как таковой" в свете вопроса топикстартера "...а надо ли Вам видеть весь процесс симуляции, или интересно найти только те участки, где возникают столкновения и зарезы? Просто симулировать можно и на CPU как обычно и я не вижу особого смысла пытаться сделать непрерывную симуляцию со скоростью 1000FPS". То есть надо ли постоянное высокоточное создание STL-тел или достаточно упрощённого (до известных пределов) воспроизведения "визуализации как таковой".

Ведь вообще-то именно конечный результат и есть сама траектория, которая оптимизируется в конечном состоянии (не в процессе): в Tebis например, с помощью макросов или виртуальных команд станка.

[Akson 0]

Спасибо за ответы. Если я правильно понимаю, обычно то визуализация нужна, но интересно увидеть именно проблемные места. Примерно так я и думал.

К проблемным же местам относятся:

- столкновения чего-либо с чем-либо

- большой съем, т.е. если при подходе фреза задевает материал, который вроде и надо убрать, но на данном этапе убирать не планировалось

- зарезы

- недорезы

- неправильный подход - Вот тут я не совсем понимаю, что Вы имеете в виду. Что такое неправильный подход? Как его можно описать и определить?

Забыл ли я что-то еще?

Но я не совсем понял про оптимизацию, что такое лишний ход и почему он появляется? можно ли его как-то описать с математической точки зрения?

Изменено 2 августа 2011 пользователем Akson

[volodja 77]

Спасибо за ответы. Если я правильно понимаю, обычно то визуализация нужна, но интересно увидеть именно проблемные места. Примерно так я и думал.

К проблемным же местам относятся:

- столкновения чего-либо с чем-либо

- большой съем, т.е. если при подходе фреза задевает материал, который вроде и надо убрать, но на данном этапе убирать не планировалось

- зарезы

- недорезы

- неправильный подход - Вот тут я не совсем понимаю, что Вы имеете в виду. Что такое неправильный подход? Как его можно описать и определить?

Забыл ли я что-то еще?

Но я не совсем понял про оптимизацию, что такое лишний ход и почему он появляется? можно ли его как-то описать с математической точки зрения?

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

Далеко не все системы отслеживают актуальное состояние заготовки. Большинство создают переходы между траекториями основываясь на её изначальной геометрии, что почти всегда неоптимально и вызывает лишние/удлинённые переходы.

[Wizard! 7]

- неправильный подход - Вот тут я не совсем понимаю, что Вы имеете в виду. Что такое неправильный подход? Как его можно описать и определить?

Как правило, под "неправильным" имеется в виду подвод фрезы, при котором она врезается в заготовку вертикально. Это связано с тем, что обычно фрезы имеют нережущую центральную часть на торце. Аналогичный случай может иметь место и при наклонном врезании.

[UAV 19]

Как правило, под "неправильным" имеется в виду подвод фрезы, при котором она врезается в заготовку вертикально.

Я думаю что это не как правило (многие фрезы могут) т.е - когда величина вертикального погружения больше чем может эта фреза, то ошибка.

Я бы неправильным еще назвал:

- подход когда его длины не хватает, если включается коррекция контурная (он меньше величины в корректоре)

- включение коррекции на дуге.

[Akson 0]

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

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

[Ug_user 638]

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

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

Не торопись...

[NickyWizard 18]

Продолжая серию простых/очевидных/глупых(нужное подчеркнуть) вопросов, я хотел бы спросить, для чего Вы используете симуляторы (всякие верикаты, нцменеджеры и подобные)?

Дабы не получать ответ: "для симуляции", я уточню.

Делаю я исследование (аспирант я) на тему автоматической генерации УП для 5-осевых станков (я знаю, что не сделаю универсальную, но это уже другая история) и использования GPU для расчетов. Частью этой системы будет симулятор процесса фрезерования, который мне нужен для выбора траектории, но есть идея сделать из него собственно симулятор с некоторыми интересными особенностями и написать об этом в предложении проекта, который мне скоро надо будет представлять. С одной стороны, хочется добавить несколько фраз о том, какой полезный он будет и какая ценная моя работа. С другой же стороны, может действительно получиться что-то интересное именно из-за того, что я планирую все считать на GPU. Особенностью GPU является то, что мне гораздо проще рассчитать результат выполнения 100тыс кадров сразу, чем последовательно каждый из них. Поэтоу есть вопрос, а надо ли Вам видеть весь процесс симуляции, или интересно найти только те участки, где возникают столкновения и зарезы? Просто симулировать можно и на CPU как обычно и я не вижу особого смысла пытаться сделать непрерывную симуляцию со скоростью 1000FPS. Но я могу разбить всю программу на части и симулировать одновременно каждую часть, тогда это будет быстро.

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

Что Вы думаете по этому поводу? Нужно ли еще какие-то данные получить от симулятора?

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

Простите за темень, но что це такэ GPU?

Теперь из моего скромного опыта работы с Верикатом.

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

Во-вторых - зарезы-недорезы, об этом тоже много сказано.

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

Ну и наконец о нужности-ненужности видеть обработку.

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

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

Но несмотря на сказанное мною, идея быстрой симуляции очень даже кошерна!!! Например при отлаженном посте (на предмет заходов человечьих, а вертикальный зарез и в САМе углядеть вполне можно.., на предмет лимитов по углу отлаженных) для 3+2 обработок действительно на траекторию и глядеть нечего.

А за сим предлагаю топикстартеру озадачиться гибридным вариантом. Хотя, возвращаясь к началу моего поста, я не знаю, что такое GPU, и, вероятно эта страшная аббревиатура не предполагает смешенья жанров :)

[Akson 0]

Простите за темень, но что це такэ GPU?

Теперь из моего скромного опыта работы с Верикатом.

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

Во-вторых - зарезы-недорезы, об этом тоже много сказано.

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

Ну и наконец о нужности-ненужности видеть обработку.

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

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

Но несмотря на сказанное мною, идея быстрой симуляции очень даже кошерна!!! Например при отлаженном посте (на предмет заходов человечьих, а вертикальный зарез и в САМе углядеть вполне можно.., на предмет лимитов по углу отлаженных) для 3+2 обработок действительно на траекторию и глядеть нечего.

А за сим предлагаю топикстартеру озадачиться гибридным вариантом. Хотя, возвращаясь к началу моего поста, я не знаю, что такое GPU, и, вероятно эта страшная аббревиатура не предполагает смешенья жанров :)

Спасибо большое за подробное описание!

А GPU - это видеокарты. Их теперь можно использовать для общих расчетов. В теории, можно получить в несколько десятков раз большую скорость, чем обычные процессоры, но много надо мучиться, чтобы такое получить.

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

Изменено 6 августа 2011 пользователем Akson