[vhlshik 0]

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

[elantra 0]

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

Мы тоже столкнулись с обеими проблемами. Решение:

1 Тюном не польземся.

2 Часто используем режим выключенного DRC

[Vadim 0]

Если я хочу переименовать две цепи питания в компоненте, какой должен быть синтаксис атрибута Supply Rename?

GND=GNDD VCC=+5V

или

GND=GNDD;VCC=+5V

или какой-то еще?

[fill 2]

Если я хочу переименовать две цепи питания в компоненте, какой должен быть синтаксис атрибута Supply Rename?

GND=GNDD VCC=+5V

или

GND=GNDD;VCC=+5V

или какой-то еще?

Два раза аттрибут Supply Rename, т.е для каждого переименования свой.

GND=GNDD

VCC=+5V

[Vadim 0]

Два раза аттрибут Supply Rename, т.е для каждого переименования свой.

GND=GNDD

VCC=+5V

Part Editor не позволяет поставить два раза атрибут Supply Rename. Как грамотно поступить - в Property Definition Editor установить для Supply Rename Instances Allowed в Multiple или экспортировать партицию PDB в *txt, исправить и импортировать обратно?

[fill 2]

Два раза аттрибут Supply Rename, т.е для каждого переименования свой.

GND=GNDD

VCC=+5V

Part Editor не позволяет поставить два раза атрибут Supply Rename. Как грамотно поступить - в Property Definition Editor установить для Supply Rename Instances Allowed в Multiple или экспортировать партицию PDB в *txt, исправить и импортировать обратно?

 

Не понял, а причем здесь PDB, ведь аттрибут Supply Rename ставится непосредственно на схеме, у всех символов, на которых надо поменять имя цепи прописанной в PDB.

И естественно в Property Definition Editor надо разрешить множественное применение аттрибута на символе в схеме.

[Vadim 0]

Не понял, а причем здесь PDB, ведь аттрибут Supply Rename ставится непосредственно на схеме, у всех символов, на которых надо поменять имя цепи прописанной в PDB.

И естественно в Property Definition Editor надо разрешить множественное применение аттрибута на символе в схеме.

Во-во. Непосредственно на схеме. Вот если я пропишу атрибут в PDB, то он и появится на схеме после размещения символа из PDB. А если не пропишу, то и не появится :) Придется вручную ставить. А я очень ленив :)

В принципе теперь все понятно. Спасибо.

[Vadim 0]

Ни фига не выходит. PDB все равно не дает два раза вводить Supply Rename, хоть Instances Allowed у него установлен в Multiple :angry2: . Экспорт - импорт создает видимость решения проблемы, но в решающий момент (при установке символа из PDB на схему) система все равно создает один Supply Rename для данного символа:angry2: Второй Supply Rename придется ставить вручную.

А вот интересно, если Supply Rename предлагается ставить только при рисовании схемы, то это означает:

1. Вспомнить, какой именно атрибут нужен в этом случае.

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

3. Чтобы ввести значение атрибута, нужно вспомнить его синтаксис.

4. Вспомнив или посмотрев в хелпе синтаксис, остается самая малость - разузнать, как называются цепи питания в PDB, для чего придется открыть Part Editor и поискать там нужный компонент.

 

ЗЫ И что, все это нужно делать для каждого символа, для которого планируется переименовать питание, ведь в общем случае неизвестно, как Packager упакует схему? Можно упаковать и самому, надеюсь в этом случае можно вышеописанные действия произвести только с одним вентилем многовентильного компонента?

[fill 2]

Ни фига не выходит. PDB все равно не дает два раза вводить Supply Rename, хоть Instances Allowed у него установлен в Multiple :angry2: . Экспорт - импорт создает видимость решения проблемы, но в решающий момент (при установке символа из PDB на схему) система все равно создает один Supply Rename для данного символа:angry2: Второй Supply Rename придется ставить вручную.

А вот интересно, если Supply Rename предлагается ставить только при рисовании схемы, то это означает:

1. Вспомнить, какой именно атрибут нужен в этом случае.

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

3. Чтобы ввести значение атрибута, нужно вспомнить его синтаксис.

4. Вспомнив или посмотрев в хелпе синтаксис, остается самая малость - разузнать, как называются цепи питания в PDB, для чего придется открыть Part Editor и поискать там нужный компонент.

 

ЗЫ И что, все это нужно делать для каждого символа, для которого планируется переименовать питание, ведь в общем случае неизвестно, как Packager упакует схему? Можно упаковать и самому, надеюсь в этом случае можно вышеописанные действия произвести только с одним вентилем многовентильного компонента?

 

Установка Instances Allowed касается схемы

 

1. При постоянной работе вспоминать какой аттрибут нужен не приходится, т.к это что называется "сидит постоянно в ОЗУ, т.е голове" :)

2. С другой стороны это лучше чем набивать каждый раз имя аттрибута :)

3. см. п1

4. А как иначе посмотреть внутренние данные PDB?

 

Packager должен учитывать при упаковке наличие Supply Rename и помещать в один корпус только символы с одинаковым значением этого аттрибута.

 

PS. Может вам DxD более подойдет? Там можно работать с Expedition через нетлист (не через CDB), при этом всю информацию об упаковке размещать на символах в схеме, соответственно интересующий вас аттрибут Signal всегда виден и доступен для редактирования (в том числе одновременно на множестве символов, через Attributes_Editor) ;)

[Vadim 0]

Спасибо Вам за ответы!!! Не-не-не. DxD я не рассматриваю. Я поясню в чем дело. Перехожу на DC/Exp. Библиотеки частично перетащил, частично переделал. Скоро следующий проект нужно будет начинать. Хочу успеть завершить подготовку к работе в DC до его начала. Хочу работать комфортно :) Т.е вопрос с переходом уже решен и никакие неудобства DC меня не остановят. Вопросы я задаю с целью определить для себя способы обхода неудобств DC, а не с целью перебрать варианты с редактором схем. Так что если иначе никак - то и ладно, буду делать так как рекомендуется. С Supply Rename пока еще не сдался ;) , продолжаю разбираться.

[fill 2]

Спасибо Вам за ответы!!! Не-не-не. DxD я не рассматриваю. Я поясню в чем дело. Перехожу на DC/Exp. Библиотеки частично перетащил, частично переделал. Скоро следующий проект нужно будет начинать. Хочу успеть завершить подготовку к работе в DC до его начала. Хочу работать комфортно :) Т.е вопрос с переходом уже решен и никакие неудобства DC меня не остановят. Вопросы я задаю с целью определить для себя способы обхода неудобств DC, а не с целью перебрать варианты с редактором схем. Так что если иначе никак - то и ладно, буду делать так как рекомендуется. С Supply Rename пока еще не сдался ;) , продолжаю разбираться.

 

Интересно, насколько я помню, вы работали на связке Power_Logic-PowerPCB и вдруг решили перейти к DC-Exp. Т.е не стало хватать PowerPCB или есть какие-то другие причины? Просто хотелось бы услышать от вас как от пользователя, что вы не смогли найти в предыдущем варианте софта и нашли в новом (это полезно знать как мне, так и возможно другим). А также почему не выбрали сразу DxD-Exp, ведь в принципе к этой связке вам было перейти проще (схема сразу переводится из Power_Logic в DxD)? Чем на ваш взгляд комфортность DC-Exp отличается от DxD-Exp (на мой взгляд в данный момент у них практически одинаковая интеграция схема-плата-ЦБ)?

[Vadim 0]

Интересно, насколько я помню, вы работали на связке Power_Logic-PowerPCB и вдруг решили перейти к DC-Exp. Т.е не стало хватать PowerPCB или есть какие-то другие причины? Просто хотелось бы услышать от вас как от пользователя, что вы не смогли найти в предыдущем варианте софта и нашли в новом (это полезно знать как мне, так и возможно другим).

Извините за задержку.

Причины перехода в порядке убывания:

1. Бесконечные метания в процессе разводки платы между PadsLayout и PadsRouter. Я даже завел специальный макрос для этого и вывел его на горячую клавишу. Смысл - в Layout неудобно разводить, в Router невозможно работать с полигонами, т е Router не является редактором плат, это "довесок" к Layout со всеми вытекающими. Обидно, ведь к самому Routerу претензий нет - очень классная вещь.

2. Layout не понимает полигонов в качестве разведенных цепей. Это очень осложняет мне жизнь. Разведенная плата выглядит неразведенной. А Router понимает. Опять метания... Да и с заливками беда - "неразведенные" цепи все равно появляются.

3. Стало нехватать возможностей Logic. С помощью скриптов планировал генерить VHDL-описание разрабатываемой схемы для моделирования работы ПЛИС в составе платы. Не тут-то было. У символов в Logic нет понятия "имя вывода". Зацепиться не за что! Думал, брать имена выводов из компонентов, а тут тоже беда - имена выводов в компонентах у Logic можно сделать невидимыми только для всего компонента сразу, поэтому при создании компонентов в библиотеке часто приходилось использовать выводы компонента без имени. T.е. не хватает информации для генерации VHDL - описания.

4. Всегда хотел моделировать в SPICE "боевую" схему в противовес общепринятой практике - рисовать схемы для моделирования отдельно в других редакторах (MicroCap, PSpice Schematics и т. д.) Logic этого не позволяет.

 

Приятно удивил Analog Designer. Spice без излишеств. Поскольку в Spice я не новичек, именно то, что надо.

А также почему не выбрали сразу DxD-Exp, ведь в принципе к этой связке вам было перейти проще (схема сразу переводится из Power_Logic в DxD)? Чем на ваш взгляд комфортность DC-Exp отличается от DxD-Exp (на мой взгляд в данный момент у них практически одинаковая интеграция схема-плата-ЦБ)?

По этому вопросу могу сказать только, что я пробовал DC/Exp уже давно в бытность радиолюбителем. (у меня даже до сих пор диск валяется c Veri Best 99 :)) И потом периодически предпринимал попытки перейти с PADS на DC/Exp. Так что это старый знакомый :) . А почему не DxD - я его не знаю, пробовал - не понравилось. Насчет комфортности, извините, отвечать не буду. Это все очень индивидуально и провоцирует флейм.

[vhlshik 0]

подскажите,

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

В mask generator ввожу "board outlline", "minus", разные там элементы. Выдает ерунду-тонкие вертикальные полосы. Что я делаю не так?

[fill 2]

подскажите,

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

В mask generator ввожу "board outlline", "minus", разные там элементы. Выдает ерунду-тонкие вертикальные полосы. Что я делаю не так?

 

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

 

Вообще генератор маски вам нужен только если не задали Solder_Mask в padstack. Если задали, то просто выдайте в Gerber все что есть на слое Solder_Mask, в результате и получите изображение мест где не будет маски (т.е негатив маски). Если не задали Solder_Mask на уровне padstack, вот тогда придется сгенерить в Mask Generator слой с негативом маски (по контактным площадкам) и его уже использовать при выдаче в Gerber.

[vhlshik 0]

пробовал xor и другие логические функции - тоже самое.

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