Jump to content

    

Создание mechanical part в Central Library

Приветствую!

Возникла необходимость создания mechanical part в центральной библиотеке. Основная цель заключается в получении возможности добавлять эти элементы в схему на этапе её разработки с последующей их компоновкой в топологии, в том числе с привязкой 3D-модели. В качестве средства генерации BOM используется PartLister, как наиболее удобный и гибкий путь получения приемлемого результата.

При попытках создания подобных Part'ов в библиотеке PartEditor не дает их сохранять, т.к. отсутствует Pin mapping: ему необходимо, чтобы у Cell и у Symbol был хотя бы один пин. Что в нашем случае невозможно, т.к. у механического элемента обычно нет контактных площадок и подключения к цепям на схеме.

Возможности Output=>Bill of Materials... не устраивают, т.к. требуется дополнительное преобразование для получения нормальной таблицы LibreOffice Calc/Excel. Точнее, до возникновения этой проблемы полностью устраивали возможности PartLister'a и не хотелось бы от него отказываться, как от проверенного и испытанного средства.

На форумах Ментора был найден древний рецепт, заключающийся в создании Cell'ов c нулевым по размеру падом, но видимо с тех пор Padstack Editor сильно поумнел и уже не дает возможности создавать такие виртуальные КП. Создание КП минимального размера тоже неудобно, т.к. неизбежно будет приводить к проблемам с DRC. В ряде случае эти проблемы будут являться наименьшим злом, но хотелось бы обойтись без них, если это возможно.

Кто как решает эту проблему?

Share this post


Link to post
Share on other sites
11 minutes ago, makc said:

Приветствую!

Возникла необходимость создания mechanical part в центральной библиотеке. Основная цель заключается в получении возможности добавлять эти элементы в схему на этапе её разработки с последующей их компоновкой в топологии, в том числе с привязкой 3D-модели. В качестве средства генерации BOM используется PartLister, как наиболее удобный и гибкий путь получения приемлемого результата.

При попытках создания подобных Part'ов в библиотеке PartEditor не дает их сохранять, т.к. отсутствует Pin mapping: ему необходимо, чтобы у Cell и у Symbol был хотя бы один пин. Что в нашем случае невозможно, т.к. у механического элемента обычно нет контактных площадок и подключения к цепям на схеме.

Возможности Output=>Bill of Materials... не устраивают, т.к. требуется дополнительное преобразование для получения нормальной таблицы LibreOffice Calc/Excel. Точнее, до возникновения этой проблемы полностью устраивали возможности PartLister'a и не хотелось бы от него отказываться, как от проверенного и испытанного средства.

На форумах Ментора был найден древний рецепт, заключающийся в создании Cell'ов c нулевым по размеру падом, но видимо с тех пор Padstack Editor сильно поумнел и уже не дает возможности создавать такие виртуальные КП. Создание КП минимального размера тоже неудобно, т.к. неизбежно будет приводить к проблемам с DRC. В ряде случае эти проблемы будут являться наименьшим злом, но хотелось бы обойтись без них, если это возможно.

Кто как решает эту проблему?

Вам нужно сделать mechanical cell

https://docs.sw.siemens.com/documentation/201907019/en/docs/htmldocs/celleditor_gd/topics/TaskTop_CreatingMechanicalCell_id674d99ae.html#id674d99ae-517f-4460-adc1-bcc073df7db0__TaskTop_CreatingMechanicalCell_id674d99ae.xml#id674d99ae-517f-4460-adc1-bcc073df7db0

 

 

Share this post


Link to post
Share on other sites

По этому пути мы ходили. После описанной по ссылке процедуры мы делали Nested Cell, но остаётся вопрос каким образом получить Part Number этого компонента в схеме и, соответственно, выдаче PartLister'a?

Вариант с Nested Cell работает только если для формирования перечней использовать меню Output=>Bill of Materials...

Но это неудобно как минимум еще по одной причине: допустим, что у нас есть элемент тактовая кнопка и нам необходимо заложить в проект несколько разных по цвету колпачков. При желаемом подходе мы делаем один part для кнопки и еще несколько механических part'ов для колпачков. В схеме размещаем кнопки + по колпачку нужного типа для каждой из них. Далее, это всё попадает в топологию и сборочный чертеж. При генерации part list'a нам PartLister всё делает правильно. Но если использовать подход nested cell нам придётся создавать сборки для каждого из вариантов компоновки кнопки и колпачка, что совсем-совсем неудобно. Я бы даже сказал крайне криво, т.к. в общем случае число подобных альтернативных cellов будет равно число_кнопок*число_колпачков.

Share this post


Link to post
Share on other sites
3 minutes ago, makc said:

По этому пути мы ходили. После описанной по ссылке процедуры мы делали Nested Cell, но остаётся вопрос каким образом получить Part Number этого компонента в схеме и, соответственно, выдаче PartLister'a?

Вариант с Nested Cell работает только если для формирования перечней использовать меню Output=>Bill of Materials...

Но это неудобно как минимум еще по одной причине: допустим, что у нас есть элемент тактовая кнопка и нам необходимо заложить в проект несколько разных по цвету колпачков. При желаемом подходе мы делаем один part для кнопки и еще несколько механических part'ов для колпачков. В схеме размещаем кнопки + по колпачку нужного типа для каждой из них. Далее, это всё попадает в топологию и сборочный чертеж. При генерации part list'a нам PartLister всё делает правильно. Но если использовать подход nested cell нам придётся создавать сборки для каждого из вариантов компоновки кнопки и колпачка, что совсем-совсем неудобно. Я бы даже сказал крайне криво, т.к. в общем случае число подобных альтернативных cellов будет равно число_кнопок*число_колпачков.

Можно добавить alternate cell для каждого nested cell например

Share this post


Link to post
Share on other sites

Каки образом? Alternate Cell это, на сколько я понимаю, свойство Part, а не Cell.

Каждый Cell внутри не предполагает альтернатив для вложенных в него других Cell'ов. Или я что-то упустил в документации?

Share this post


Link to post
Share on other sites

Вы же можете добавить туда внутрь Drawing Cell много слоев пользователтских, на один поместить с красной кнопкой на другой с зеленой и т.д использую DXF например, а потом в Layout уже играться слоями

Share this post


Link to post
Share on other sites

По-моему Вы меня неправильно поняли. Речь идёт не о формировании сборочного чертежа, точнее не только о нем.

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

А так нарисовать я могу вообще всё что угодно и слоёв насоздавать в том числе. Но задача стоит в автоматическом формировании перечня элементов, включающем в себя и механические компоненты для исключения "человеческого фактора" и забывчивости разработчика.

PS: Drawing Cell это вообще из другой оперы.

Share this post


Link to post
Share on other sites
8 minutes ago, makc said:

По-моему Вы меня неправильно поняли. Речь идёт не о формировании сборочного чертежа, точнее не только о нем.

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

А так нарисовать я могу вообще всё что угодно и слоёв насоздавать в том числе. Но задача стоит в автоматическом формировании перечня элементов, включающем в себя и механические компоненты для исключения "человеческого фактора" и забывчивости разработчика.

PS: Drawing Cell это вообще из другой оперы.

МоЖет, конечно я не так понял.

Но вот на примере с кнопкой, это же у вас компонент, правильно?  у него есть УГО + CELL. Далее вы внутри этого Cell добавляете Mechanical Cell, для каждого цвета свой на разный слой, внутри одного Cell.

При этом p/n кпопки меняется в зависимости от цвета

Edited by philipov

Share this post


Link to post
Share on other sites
Только что, philipov сказал:

у него есть УГО + CELL. Далее вы внутри этого Cell добавляете Mechanical Cell, для каждого цвета свой на разный слой, внутри одного Cell.

При этом p/n кпопки меняется в зависимости от цвета?

Нет, не меняется. Кнопка - это один p/n. Колпачок - другой p/n. Вместе - это сборка.

Так вот получается, что вместо библиотеки базовых элементов мы будем вынуждены делать библиотеку сборок (кнопка + колпачок). Но это еще полбеды, а основная беда в том, что эти сборки никак не видит PartLister, т.к. он живет на уровне схемы и p/n элементов на схеме, а предлагаемые Вами сборки живут в layout. Я же начал как раз с того, что Layout => Output => Bill of Materials... нас не устраивает по целому ряду причин. Чувствую всё идет к написанию своего скрипта PartLister для Layout, но тут встаёт еще один вопрос - обозначения сборочных элементов, т.к. для part'ов в схеме Packager штатным образом присваивает RefDes, а вот для этих механических элементов никаких RefDes никто присваивать не будет и это тоже является некоторой проблемой.

Share this post


Link to post
Share on other sites
11 minutes ago, makc said:

Нет, не меняется. Кнопка - это один p/n. Колпачок - другой p/n. Вместе - это сборка.

Так вот получается, что вместо библиотеки базовых элементов мы будем вынуждены делать библиотеку сборок (кнопка + колпачок). Но это еще полбеды, а основная беда в том, что эти сборки никак не видит PartLister, т.к. он живет на уровне схемы и p/n элементов на схеме, а предлагаемые Вами сборки живут в layout. Я же начал как раз с того, что Layout => Output => Bill of Materials... нас не устраивает по целому ряду причин. Чувствую всё идет к написанию своего скрипта PartLister для Layout, но тут встаёт еще один вопрос - обозначения сборочных элементов, т.к. для part'ов в схеме Packager штатным образом присваивает RefDes, а вот для этих механических элементов никаких RefDes никто присваивать не будет и это тоже является некоторой проблемой.

Блин, интересная задача конечно))
Ну вообще наверное правильно было бы создать под каждый цвет колпака свой nested cell, c пользовательским аттрибутом p/n  механической части. А потом через part lister извлекать этот аттрибут. Но с позиционным обозначением сложнее конечно,  это вообще задача уже конструктора делать спецификацию на механические детали.

8 minutes ago, philipov said:

Блин, интересная задача конечно))
Ну вообще наверное правильно было бы создать под каждый цвет колпака свой nested cell, c пользовательским аттрибутом p/n  механической части. А потом через part lister извлекать этот аттрибут. Но с позиционным обозначением сложнее конечно,  это вообще задача уже конструктора делать спецификацию на механические детали.

Кстати добавить RefDef для Mechanical Cell можно вот так:

  1. Создать Mechanical Cell  и разместить RefDes на уровне Cell  (Silkscreen or Assembly).
  2. Разместить Mechanical Cell  в Layout.
  3.  Используя ECO>Renumber Ref Desможно обнвоить позиционной обозначение.
Edited by philipov

Share this post


Link to post
Share on other sites
11 минут назад, philipov сказал:

Блин, интересная задача конечно))

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

14 минут назад, philipov сказал:

Ну вообще наверное правильно было бы создать под каждый цвет колпака свой nested cell, c пользовательским аттрибутом p/n  механической части.

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

15 минут назад, philipov сказал:

Но с позициооным обозначением это вообще задача уже контруктора делать спецификацию на механические детали. 

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

Share this post


Link to post
Share on other sites
16 minutes ago, philipov said:

Блин, интересная задача конечно))
Ну вообще наверное правильно было бы создать под каждый цвет колпака свой nested cell, c пользовательским аттрибутом p/n  механической части. А потом через part lister извлекать этот аттрибут. Но с позиционным обозначением сложнее конечно,  это вообще задача уже конструктора делать спецификацию на механические детали.

Кстати добавить RefDef для Mechanical Cell можно вот так:

  1. Создать Mechanical Cell  и разместить RefDes на уровне Cell  (Silkscreen or Assembly).
  2. Разместить Mechanical Cell  в Layout.
  3.  Используя ECO>Renumber Ref Desможно обнвоить позиционной обозначение.

Еще как вариант для Mechanical Cell можно создать тупо УГО с типом MODULE и Forward to PCB=False  и размещать его в DxD тогда он попадет в BOM. Но связи между ними не будет конечно

Share this post


Link to post
Share on other sites

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

Сейчас пришла в голову другая немного сумасшедшая мысль: делать Cell с единственной КП, вынесенной за пределы Placement Outline на приличное расстояние около одного метра. Таким образом можно практически со 100% вероятностью гарантировать, что КП не попадет на будущей плате в пределы Board Outline и мешать DRC не будет. На всякий случай можно еще поставить галочку Movable в свойствах Cell, чтобы можно было подвинуть КП если вдруг что-то пойдет не так.

В итоге мы получаем возможность размещать Cell где нам нужно, собираем с этим Cell'ом Part и вроде бы все условия задачи удовлетворены. Вы видите какие-нибудь подводные камни у этого решения?

Share this post


Link to post
Share on other sites
2 minutes ago, makc said:

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

Сейчас пришла в голову другая немного сумасшедшая мысль: делать Cell с единственной КП, вынесенной за пределы Placement Outline на приличное расстояние около одного метра. Таким образом можно практически со 100% вероятностью гарантировать, что КП не попадет на будущей плате в пределы Board Outline и мешать DRC не будет. На всякий случай можно еще поставить галочку Movable в свойствах Cell, чтобы можно было подвинуть КП если вдруг что-то пойдет не так.

В итоге мы получаем возможность размещать Cell где нам нужно, собираем с этим Cell'ом Part и вроде бы все условия задачи удовлетворены. Вы видите какие-нибудь подводные камни у этого решения?

Подводный камни вижу схожу только то что Fit to PCB будет вам возращать слишком большую область платы ( как раз тот самый метр)
Так пока не вижу больше

Share this post


Link to post
Share on other sites
3 минуты назад, philipov сказал:

Подводный камни вижу схожу только то что Fit to PCB будет вам возращать слишком большую область платы ( как раз тот самый метр)

Сейчас попробовал и, как ни странно, нет этого эффекта. Зато есть проблема с Gerber'ами и 3D, где на большом расстоянии болтаются неприкаянные КП и это неудобно.

Второй вариант - всё то же самое, только делать падстек минимального размера, чтобы его нельзя было изготовить на производстве (например, 0.01 мм в диаметре) или просто уносить эти КП за пределы Board Outline после размещения механического компонента. Не очень удобно, зато надежно.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now