Лечение CAD-модели и распознавание фичеров

[Quaoar 6]

Добрый день участникам форума! Обозначусь: разработчик инженерного ПО на базе OpenCascade, НЕ инженер, программист. Интересует компетентное мнение товарищей инженеров-конструкторов, расчетчиков и иже с ними по концептуальному вопросу. Итак...

 

На протяжении текущего года мы разрабатываем ПО типа CADDoctor / CADfix. Базовая функциональность софта предполагает 4 этапа:

 

- Чтение геометрии (сборки) из файла без истории построения (читай STEP),

- Лечение геометрии от косяков (сшивание граней, заполнение дырок и т.д.),

- Распознавание фичеров и упрощение модели путем их подавления (отверстия и скругления),

- Запись отредактированной геометрии в новый файл (читай STEP).

 

Вся работа идет на точной геометрии (B-Rep), с сеточными моделями почти не работаем (хотя есть идея внедрить реверсный инжиниринг). По совокупности функционала речь идет об аналоге CADfix. К сожалению, конструкторов и расчетчиков в нашей компании как-то негусто (т.е. нет), поэтому "анализ рынка" не проводился (ни отечественного, ни забугорного). Прошу помочь компетентных ребят по следующим вопросам (тире сомнениям):

 

1. Часто ли возникает на практике необходимость покинуть родную САПР, в которой создавалась модель, и обмениваться данными в формате без истории (STEP)?

 

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

 

3. Для каких целей вы это делаете?

 

4. Какие проблемы CAD-моделей вам чаще всего приходится "лечить"?

 

5. Какой софт вы используете для такого лечения?

 

6. Используете ли вы приложения типа CADDoctor или CADfix и почему?

 

7. Есть ли такие проблемы редактирования немой геометрии, которые решаются плохо или совсем не решаются тем софтом, который вы для этого пользуете?

 

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

 

В теории предмет разговора лежит в плоскости "design by features" vs "feature recognition". Т.е. речь идет всегда о ситуации, когда история построения модели недоступна, и что делать с такими моделями. Что делаете с такими моделями вы?

 

Спасибо за экспертные мнения и помощь в этом своеобразном "анализе требований".

[Ветерок 2 108]

Задача может быть и полезная, только не понятно для чего.

Сами по себе модели никому не нужны. Соответственно, и редактировать их просто ради редактирования тоже нет смысла.

Модели нужны только для дальнейшего ИСПОЛЬЗОВАНИЯ В КАКОЙ-ЛИБО CAD-системе. И не сами модели, а РЕЗУЛЬТАТ ИХ ИМПОРТА. Ибо ПРОБЛЕМЫ ИМПОРТА могут быть как ПРИ ИМПОРТЕ, так возникнуть ещё на этапе ЭКСПОРТА исходной геометрии. Поэтому сама модель в нейтральном формате может не содержать никаких проблем, они могут возникать в процессе импорта. Тогда тоже нечего лечить в самой модели.

Я часто передаю и получаю модели в нейтральных форматах. Чаще всего STEP. Проблемы с геометрией встречаются крайне редко.

Работаю в основном в Крео. Там есть свой собственный ИмпортДатаДоктор позволяющий полечить импортированную геометрию - заделать щели, перестроить поверхности, удалить или построить новые. Фасетную геометрию он тоже может редактировать. Но повторюсь - прибегать к его помощи приходится крайне редко. Как правило геометрия корректная.

Отдельная тема - экспорт в продукты Делкам. Они зачастую не понимают напрямую файлы, сделанные не в Делкаме. Но есть выход через "третий софт". Тоже ничего лечить не надо.

 

Ещё раз хочу повторить свою мысль. Важна не сама модель в нейтральном формате, а РЕЗУЛЬТАТ ЕЁ ИМПОРТА. И этот результат импорта одной и той же модели может быть разным в разном софте. И вот если именно в результате импорта появились проблемы, то надо их лечить. Но лечить их надо уже в том софте, в который они импортированы.

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

Но опять же, всё это делается внутри рабочего софта, а не в сторонних приложениях.

[Bonusfrag 104]

такая необходимость есть, когда из CAD нужно передать модель в CAE инструмент.

для CFD FlowVision в таком случае рекомендуется использовать 3DTransvidia  - лечит и правильно и точно выгружает в нужный формат.

Сейчас пилотно поставляется в комплекте с FlowVision.

[zloyuri 289]

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

Изменено 21 августа 2016 пользователем zloyuri

[AlexKaz 1 822]

Пишу как студент-прочнист.

 

1. Постоянно. "Родная" САПР - Компас, его расчётные модули, эм, менее предпочтительны по экономическим соображениям.

 

2. Да, когда геометрия чужая, например конструкторская сборка. Свою изначально стараюсь строить без мелких нюансов и деталировки.

 

3. МКЭ, МЖГ, теплотехника (FEM, CFD).

 

4. Тонкостенные трубы с коленами - давненько лечу в SW.

 

5. SolidWorks, ANSYS Workbench Design Modeler, по идее справляется Netgen, но не пользую.

 

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

 

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

 

8. Не могу ответить.

[Ruslan 266]

@@Quaoar,

Мне кажется вы опоздали. Это было актуально достаточно давно.

 

Во первых  Открытие step, лечение, сохранение в step  не имеет ни какого смысла. Кроме случая когда он учитывает особенности конкретной программы. Потому как изначально step корректен, во всяком случае с точки зрения системы из которой он импортировался.

Во вторых в CAD уже есть свои средства лечения и редактирования и распознания.

 

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

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

Из SW передаются записи и состояния отображения в имена.

С ПроЕ есть проблеме при импорте и требования к длине имени и только латинице (без точек и спец символов).

Так что при открытии тоже с именами приходится работать. Так как неудобно я даже писал скрипт обработки из Компаса, SW и Inventora по корректировки имен перед импортом.

Изменено 21 августа 2016 пользователем Ruslan

[Quaoar 6]

Спасибо всем отозвавшимся! Из сказанного делаю такой вывод:

 

По всему видно, что продукты класса CADfix обречены быть "сильно нишевыми" и находиться где-то на обочине магистрального САПРа, где царят всемогущие CAD-системы. Полагаю, что такого рода решения будут более интересны не конструкторам, а программистам, реализующим инженерный софт. А программисту нужна не оболочка с пользовательским интерфейсом, но алгоритмы. Поэтому делать коммерческую утилиту с претензией на внедрение в инженерную цепочку было бы сверх-наивно. Под такое нужен заказчик готовый платить и внедрять, а не идеалистическое R&D, как в нашем случае.

 

Так или иначе, с удовольствием продолжу следить за темой, если кто-то еще пожелает нам помочь с целеполаганием.

[Ветерок 2 108]

помочь с целеполаганием

Ну, если помечать...

А вот такой бы софт, который бы мог:

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

- при необходимости вылечить геометрию

- при необходимости создать новые параметры на основе старых или переименовать старые, или создать новые на основе имени файла

- при необходимости поменять имена файлов (заменить русские буквы латинскими или поменять всё по маске или ещё как)

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

 

На самом деле если передача геометрии через нейтральные форматы уже достаточно успешно решена, то про передачу негеометрической информации, похоже, ещё никто не задумывался. А ведь это тоже немаловажная информация, которая не просто так в модели присутствует. Эта информация особенно важна для PDM-систем. Для них она вообще главная. Выгружать в PDM модели без этой информации почти бессмысленно. Но в нейтральном формате её нет, поэтому приходится для каждой детали всё вводить вручную.

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

[grOOmi 320]

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

 

Ну вы бы хоть букварь почитали. Всё это есть, вопрос как всегда в желании это реализовать.

http://www.spatial.com/blog/3d-interop/emergence-step-ap-242

 

Ну и тему на форуме вам в помощь http://cccp3d.ru/topic/34620-step-format/ 

[niksasa 158]

то про передачу негеометрической информации, похоже, ещё никто не задумывался. А ведь это тоже немаловажная информация, которая не просто так в модели присутствует. Эта информация особенно важна для PDM-систем. Для них она вообще главная. Выгружать в PDM модели без этой информации почти бессмысленно. Но в нейтральном формате её нет, поэтому приходится для каждой детали всё вводить вручную.

Откуда такая дезинформация?

Модель солидворкс 

Модель в инвенторе

Изменено 22 августа 2016 пользователем niksasa

[a_schelyaev 366]

На самом деле если передача геометрии через нейтральные форматы уже достаточно успешно решена, то про передачу негеометрической информации, похоже, ещё никто не задумывался. А ведь это тоже немаловажная информация, которая не просто так в модели присутствует. Эта информация особенно важна для PDM-систем. Для них она вообще главная. Выгружать в PDM модели без этой информации почти бессмысленно. Но в нейтральном формате её нет, поэтому приходится для каждой детали всё вводить вручную.

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

 

В данной постановке задачи кроется парадокс. Передача данных из ПДМ в ПДМ возможна только если у вас есть четкое описание модели данных в обеих системах. А это и есть 99,99% информации, т.к. если все это определено, то перенос данных будет реализован силами программистов IT отдела.

[Quaoar 6]

Объясню немного, почему постановка задачи именно такая, как описано в первом посте. Наша контора время от времени получает вопросы от потенциальных заказчиков следующего рода. Есть STEP-файл. В его геометрии некоторые фичеры, такие как скругления, надо либо удалить, либо изменить их радиус. То же самое только с предварительной сшивкой граней и удалением цилиндрических отверстий просил другой заказчик. Насколько мне теперь ясно, в CAD-системах все указанное делается без проблем. Указанные же клиенты хотели вендор-независимое решение, то есть, грубо говоря, некоторую библиотеку (C++), способную выполнять манипуляции по дефичирингу и которую можно интегрировать в некий софт (до которого нам нет дела). Построить такое решение возможно, используя не CAD-систему, а геометрическое ядро, например, OpenCascade. Вопрос, который нас интересует, состоит в том, насколько такое решение востребовано вообще? Каков его рынок? Мы использовали гугл (такая вот бизнес-аналитика) и нашли там CADfix, CADDoctor, Gpure и теперь вот 3DTransVidia, и, частично, MSC Apex. Такое ощущение, что софт, связанный с редактированием немых моделей, имеет ненулевую аудиторию. В поисках этой аудитории я дошел до вашего форума, но, по всей видимости, спрашивать нужно не у инженеров, а у программистов, реализующих инженерный софт. Примерно у тех же людей, я имею в виду, которые лицензируют ACIS, Parasolid, SMLib и проч.

[Ветерок 2 108]

Такое ощущение, что софт, связанный с редактированием немых моделей, имеет ненулевую аудиторию.

Сами по себе модели никому не нужны. Соответственно, и редактировать их просто ради редактирования тоже нет смысла.

 

Откуда такая дезинформация?

Что сказать-то хотел? Скажи.

Я не понимаю без пояснений что на твоих картинках.

 

Передача данных из ПДМ в ПДМ возможна

Я немного про другое. Даже совсем про другое. Про первоначальную выгрузку данных в PDM, если эти данные получены из нейтральных форматов (например, из Компаса).

Изменено 22 августа 2016 пользователем Ветерок

[Ветерок 2 108]

Ну вы бы хоть букварь почитали. Всё это есть, вопрос как всегда в желании это реализовать.

В ЧЬЕМ желании? Какой софт поддерживает этот AP 242? Я такого не знаю.

[Maik812 290]

Из SW передаются записи и состояния отображения в имена. С ПроЕ есть проблеме при импорте и требования к длине имени и только латинице (без точек и спец символов). Так что при открытии тоже с именами приходится работать. Так как неудобно я даже писал скрипт обработки из Компаса, SW и Inventora по корректировки имен перед импортом.

Элементарно решается  Total commander с плагинами Компасом 16 и Solidworks 2014 , данные не геометрические заносятся в потоки ntfs, а геометрия само содержимое 0 поток. Его переписываем , а остальные данные остаются и переносятся в фаил Компаса или Солида этими же плагином. А сама геометрия конвертируется любой программой кокой нравится..

Что касается перекодировки имени в латиницу то там второй плагин подключается Translit.

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

Вместо того чтоб читать внимательно мои посты, ты их обсираешь... Как это делать раза 3 писал! и делает  Total commander это пакетно выбором всех файлов!

Изменено 22 августа 2016 пользователем Maik812

[Ruslan 266]

@@Maik812,

Во первых вы ошиблись веткой. Предложение услуг и продажа это другие ветки.

Во вторых создается впечатление что вы не конструктор. У вас несколько абстрактные представления о необходимых данных. И вообще отличиях в каждой программе. Большинство данных не доступно стандартными свойствами ОС.И они не являются свойствами файлов. И не у всех они прописаны в шапках файлов.

В третьих хватит позорить и вызывать негатив в отношении хорошего менеджера файлов. Надеюсь совести купить хватило?

Изменено 22 августа 2016 пользователем Ruslan

[zloyuri 289]

@@Maik812,

.

Во вторых создается впечатление что вы не конструктор. 

Тут что, отстрел "неконструкторов"

[streamdown 1 565]

данные не геометрические заносятся в потоки ntfs

 ))))

https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D1%8C%D1%82%D0%B5%D1%80%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B8_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85

Тупо загуглил. Потерять "поток ntfs" легко, потерять модельные данные - ооочень сложно. Опять какие то плагины. Какой-то 

 

кокой нравится

Геометрия конвертируется кокаиновым кустом чтоль?

 

 

Большинство данных не доступно стандартными свойствами ОС

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

 

 

 

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

много писать придётся. Фактически всю математику, если конечно "клиенты" не остановятся только на скруглениях. Я, конечно, желаю вам всяческих успехов в начинаниях и продолжениях, но почему б клиентам не использовать на том же ядре (раз понравилось) ЭТО

 

 

Построить такое решение возможно, используя не CAD-систему, а геометрическое ядро

дык оболочка для ядра - это и будет CAD система

 

------------------------------

"Чтение геометрии (сборки) из файла без истории построения (читай STEP)"

Лучше б как раз наоборот, из уже готовых CAD форматов лепить конвертер.

 

- Лечение геометрии от косяков (сшивание граней, заполнение дырок и т.д.)

Выше написали, геометрия при импорте с точки зрения CAD как бы не требет какого-то лечения.

 

- Распознавание фичеров и упрощение модели путем их подавления (отверстия и скругления)

А распознаваться они во что будут? В фичеры?    "Подавление" на ура делается и в родных CAD системах, с много меньшими программисто-часми по затратам.

 

- Запись отредактированной геометрии в новый файл (читай STEP)

Если это и есть конечная цель, то я бы пошёл по пути аддонов в CAD средах, а не самописном CAD. Вроде таких уже в интернетах полно)))

Изменено 22 августа 2016 пользователем streamdown

[Quaoar 6]

Мужики, вот из ленты Spatial: "CGM Core Modeler now supports expanded feature recognition to enable logo, slot and pocket recognition, allowing customers to use feature recognition on parts and models to identify entities in order to focus on or remove them for downstream operations". [http://www.spatial.com/blog/3d-software-development-kits/spatial-enables-industry-innovation-release-2017-10]

 

Вопрос: для чего это нужно?

 

А про это в основном и речь: есть некая программная компонента (ядро, библиотека), способная распознавать фичеры на геометрии. Я не уверен, что в случае со Spatial речь идет о распознавании вообще всех фичеров, поэтому говорить о восстановлении полного дерева построения нельзя.

 

дык оболочка для ядра - это и будет CAD система

 

CADfix, CADDoctor и т.д. -- не CAD-системы. Они позволяют работать с уже созданной геометрией, но не моделировать.

 

Лучше б как раз наоборот, из уже готовых CAD форматов лепить конвертер.

 

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

 

А распознаваться они во что будут? В фичеры?

 

В "абстрактный фичер", не привязанный ни к какой CAD-системе, что позволит быть вендор-независимыми. Типа "цилиндрическое отверстие радиуса r и глубины h".

Какой софт поддерживает этот AP 242

 

Когда Вы говорите о негеометрических данных и "параметрах" модели, Вы имеете в виду протокол STEP AP242 или что-то еще? Речь о PMI или вопрос передачи данных ставится шире?

Выше написали, геометрия при импорте с точки зрения CAD как бы не требет какого-то лечения.

 

Ребята из ТЕСИСа с Вами не согласны: https://tesis.com.ru/infocenter/downloads/3dtransvidia/3dtv_sapr0614.pdf

Если это и есть конечная цель, то я бы пошёл по пути аддонов в CAD средах, а не самописном CAD

 

Упаси Бог делать очередной самописный CAD. Наша ниша -- алгоритмы и лицензируемые компоненты, которые могут быть переиспользованы с кадах. Мы делаем геометрическое ядро.

Я, конечно, желаю вам всяческих успехов в начинаниях и продолжениях, но почему б клиентам не использовать на том же ядре (раз понравилось) ЭТО

 

Я не знаток FreeCAD, но не уверен, что он имеет средства feature recognition. Надо будет поизучать.

[Ruslan 266]

Вопрос: для чего это нужно?

Нужно это для более удобного прямого редактирования импортированной модели.

 

Я не уверен, что в случае со Spatial речь идет о распознавании вообще всех фичеров, поэтому говорить о восстановлении полного дерева построения нельзя.

Естественно. Просто к базовым примитивам добавили еще. Тут речь идет скорее не о распознание фичеров, а о геометрических фигурах и конструкторских примитивов.