[makc 190]

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

Возникла необходимость создания 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. В ряде случае эти проблемы будут являться наименьшим злом, но хотелось бы обойтись без них, если это возможно.

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

[PBO 1]

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

 

 

[makc 190]

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

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

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

[PBO 1]

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 например

[makc 190]

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

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

[PBO 1]

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

[makc 190]

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

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

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

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

[PBO 1]

8 minutes ago, makc said:

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

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

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

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

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

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

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

Изменено 27 января, 2020 пользователем philipov

[makc 190]

Только что, 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 никто присваивать не будет и это тоже является некоторой проблемой.

[PBO 1]

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можно обнвоить позиционной обозначение.

Изменено 27 января, 2020 пользователем philipov

[makc 190]

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

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

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

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

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

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

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

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

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

[PBO 1]

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. Но связи между ними не будет конечно

[makc 190]

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

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

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

[PBO 1]

2 minutes ago, makc said:

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

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

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

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

[makc 190]

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

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

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

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