Как стать автором
Обновить

Оптимизация работы конструкторского отдела производственного предприятия

Время на прочтение3 мин
Количество просмотров6.3K
Всего голосов 6: ↑4 и ↓2+3
Комментарии19

Комментарии 19

Каким образом производится присвоение и проверка актуальности децимальных номеров?

Добрый день!  Присвоение децимальных номеров выполняется вручную пользователем. В SOLIDWORKS PDM пакета Professional есть встроенный генератор серийных номеров, однако он не позволяет реализовать достаточно своеобразную логику присвоения порядковых номеров с резервированием определенного диапазона этих номеров одновременно для сборок, подсборок, деталей и последующей их индексации. Для автоматизации этого процесса можно теоретически использовать стороннее приложение, или с использованием средств открытого API SOLIDWORKS PDM написать отвечающий необходимым требованиям алгоритм. В настоящее время наших текущих клиентов устраивает вариант ручного заведения децимальных номеров. Но мы готовы рассмотреть вариант реализации необходимого под ваши задачи генератора номеров, для этого Вы можете обратиться к нам по адресу нашей службы технической поддержки solidworks@csoft.ru

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

NikitaKhvoryk да, это вполне себе рабочий вариант. Частично задавать вручную элементы децимального номера, а частично - за счёт автоматизации одной изменяемой переменной под номер детали. Спасибо, что поделились собственным опытом.

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

Например, что делать, если изменения в КД происходят в момент, когда оно уже на производстве?
Такого не может быть? Ха, если бы.

А потом всем конструкторским отделом придумываются "костыли" наподобии "не передавать КД в производство до завершения заказа"

Это скорее вопрос организационный. Если у вас в компании не принято использовать КД при производстве только из Архива, то никакая pdm/plm вам не поможет.

Служебные записки уже отменили что-ли? При этом модель и чертёж проводится как работа с ПИ с приложением скана служебки

Добрый день! Отслеживание изменений в КД возможно за счёт соответствующей настройки потока работ. Поток работ SOLIDWORKS PDM является гибким и всегда настраивается под конкретного заказчика индивидуально. В данной статье рассмотрен самый простой вариант потока работ исключительно для примера. При условии соответствующей настройки потока работ можно автоматизировать процесс выпуска Извещений об изменении по заранее настроенному шаблону, а также принудительно запретить изменять саму КД без проведения указанной процедуры. Кроме того, за счёт настраиваемых оповещений производство будет оперативно находиться в курсе всех выпускаемых извещений об изменении и соответственно корректировать свои производственные планы. Если Вам требуется более подробная консультация с демонстрацией возможностей работы с изменениями Вы всегда можете обратиться по адресу нашей службы технической поддержки solidworks@csoft.ru

Вы рассматриваете процесс разработки КД с точки зрения стабильной системы. Однако в реальной жизни вряд ли всё может быть так оптимистично. Отличной аналогией тут будет разработка софта и ветка prod.

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

И да, я рассуждаю с точки зрения бывшего инженера конструктора, который ныне стал программистом. Казалось бы, откуда ООП в проектировании сборок? А его там сильно не хватает.

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

atOmnik полагаем, что автор предыдущего комментария dimaaannn имел ввиду оптимальные приёмы формирования 3D-модели сборки с точки зрения конструирования, а не с точки зрения её хранения в электронном архиве. Более подробно с оптимальными приёмами проектирования (особенно это актуально именно для больших сборок) вы можете ознакомиться по ссылке https://www.youtube.com/watch?v=nXSCIsgq4Fo. Для построения устойчивых взаимосвязей между компонентами сборок и обеспечения более быстрого перестроения в будущем, рекомендуется пользоваться возможностями параметризации Уравнения - 2022 - Справка по SOLIDWORKS. Если же речь всё-таки идёт прежде всего о хранении компонентов, то SOLIDWORKS PDM автоматически отслеживает и корректирует все существующие ссылки на детали, входящие в состав сборки. Поэтому даже при их переименовании или вынужденном перемещении компонентов в другую директорию, при открытии самой сборки PDM система без дополнительной работы со стороны конструктора перечитает все ссылки и не будет выдавать назойливых ошибочных предупреждений.

Как SOLIDWORKS PDM работает с ECAD? Как формируется библиотека?

dimaaannn, вы хоть уточните, что не КАМ-программист, а на бекэнде сидите. Программистов сейчас много.

Сама "Архитектура проекта" в процессе разработки может меняться, не все работают по водопаду, а вот построение графа из объектов не всегда возможно, особенно, если у вас заимствованные(покупные) изделия и условия стыковки разные или опциональные.

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

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

И последнее совсем перестаёт быть похожим на ООП и С.О.Л.И.Д.-принципы не помогут, ибо вы сложную деталь не разобьёте на несколько простых из-за экономики, у вас нет изначальных абстракций, нет ромбовидного наследования и моками вы не заткнёте связи, чтобы прогнать тесты. Однако ПДМ вам подскажет, что изменяемая вами деталь ещё задействована в пяти других проектах, поэтому прежде, чем мерджить ваш бренч с изменениями, то загляните и в те веточки. Так что ПДМ, это всего лишь гитхаб, который не отвечает за выбранную вами архитектуру.

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

вы хоть уточните, что не КАМ-программист, а на бекэнде сидите.

Будучи ещё инжером, я занимался именно взаимодействием с SolidWorks API. Не сказать что был тогда сильным прогером, но задачи выполнял.

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

Вероятно, довольно сложно объяснить нюансы человеку далёкому от САПР, но абстракции там тоже могут быть. И несут ровно такую же смысловую нагрузку, как и в программировании.

Я могу создавать моки, наследования и внешние ссылки. Даж DI можно упихнуть, хотя работает он по другим принципам. И да, речь только про инженерное проектирование, без капли программирования вообще.

Если деталь связана с пятью другими - это не значит что мне нужно куда то смотреть. Потому что деталей может быть и 100.
Гораздо хуже, когда деталь НЕ связана по ссылке с каким либо новым изменением. Это очень сложно отследить.

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

Вероятно, довольно сложно объяснить нюансы человеку далёкому от САПР, но абстракции там тоже могут быть

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

Если деталь связана с пятью другими - это не значит что мне нужно куда то смотреть.

С пятью другими проектами! И это как раз значит, что при изменениях детали вам необходимо заглянуть в те пять проектов.

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

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

С пятью другими проектами! И это как раз значит, что при изменениях детали вам необходимо заглянуть в те пять проектов.

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

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

Но что это, привязки нельзя делать в обе стороны? А если обе детали или сборки должны быть связаны друг с другом? Внезапно нам требуется внутренний эскиз для привязок сделать внешним. Ещё один уровень абстракции.

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

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

Покажите мне хорошие проекты, где невозможно взорвать сборку

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

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

Есть же понятные слова: пример, опыт, случай и ещё по разному можно написать. Но нет, чемодан из практики.

Наш редактор тоже настаивал на слове "опыт", но в данном случае мы решили оставить трендовое слово "кейс")

Рисунок 3 содержит надпись "Возврат на КМ на доработку", возможно один из предлогов "на" здесь лишний?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий