Вот уже достаточно долгое время изучаю Allegro и честно говоря результат почти нулевой.

Пока искал информацию в интернете наткнулся на статью на хабрахабр. Вот несколько цитат из неё:
"Будьте уверены вы ещё его полюбите, даже если сначала возненавидите. C'est la vie."
"Теперь немного о том, как вообще жить в этом пространстве, т.к. если вы попытаетесь покликать и сделать что-то вменяемое, то будете удивлены как тут всё неудобно, но это на первый взгляд… в общем и на второй и на третий тоже, как я уже сказал Cadence вы ещё возненавидите, но это ничего потом вы смеритесь и даже полюбите его причём так что уже не распрощаетесь, это навсегда. Серьёзно."
"...это Cadence вы будете сначала презирать тех садистов которые его сделали, но потом всё изменится и кроме Cadence -a другая САПР вам будет уже не нужна."

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

Хотелось бы задать один из основных вопросов который меня мучает. Как же так можно просто писать название футпринта чтобы присоединить его к part? Откуда он возьмётся? Из папки которую я пропишу в psmpath? А если в другой папке тоже будет футпринт с таким названием? Как мне создать part именно с определённым футпринтом из определённой папки? И вообще интересно почему нужно именно писать это название, а не нажать на кнопку и выбрать его? По моему это просто рассадник ошибок. И вообще хотелось бы понять общую философию общения part и футпринта.
Вот например в Altium нажимаешь кнопку и присваиваешь определённому символу определёный футпринт из определённой библиотеки, компилируешь и всё - получаешь интегрированную библиотеку не зависящую ни от одной исходной библиотеки.

Буду очень признателен тем кто откликнится.

Сообщение отредактировал djhall - Jan 21 2013, 19:42

Для Capture футпринты определяются в файле Capture.ini, например это нужно для просмотрщика футпринтов.


Для APE все правильно, psmpath указывает на папки с футпринтами.
Также нужны и падстэки - padpath.

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

Что бы небыло ошибок, существует база данных CIS, где прописывается соответствие УГО и футпринта (вот сдесь, кстати, можно нажимать кнопки).

Схему в чем рисуете?

А что будет в Альтиум, если в нескольких либах корпуса с идентичными именами?

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

Если в Альтиуме не делать компилированные библиотеки, то всё работает точно так же, в чертеже задаёте имя а в разводке указываете пути к библиотекам. В Алтиуме нет библиотек педов вообще (каждый раз надо строить по новой), так что и путь к ним указывать не надо. Если у Вас несколько заказчиков, которые футпринты называют одинаково, а требования к ним разные, то всё равно надо подвязывать разные библиотеки, или менять их приоритет.

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


Схему рисую в Allegro Design Entry CIS. По сути в соответствии с Kraig Mitzner "Complete PCB Design Using OrCAD Capture and PCB Editor"


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


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

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

Очевидно, прописывать на схеме для каждого компонента значение атрибута для футпринта с полным путем к файлу. Только зачем такие сложности, когда можно отвести на футпринты один каталог, прописать его в psmpath и забыть о проблеме? Два одинаковых имени файла Вам не позволит сделать ОС. Наименования - по IPC7351 или еще как-то. БД - только для удобства, если сильно хочется видеть прочие свойства компонентов типа вольтажа и места на складе. И в чем трудности?

Имя, сестра, имя! (с)

http://pcbget.ru/Files/Standarts/IPC_7351.pdf
http://electronica.ugr.es/~amroldan/cursos...0Convention.pdf
http://landpatterns.ipc.org/IPC-7351BNamingConvention.pdf
http://electronix.ru/forum/index.php?act=A...st&id=54424

На мой взгляд в корне неверное решение. Относительные пути обычно намного гибче и удобнее в работе.
ОС не позволит, IPC еще как позволит. В этом случае либо оставляете одно посадочное место на все случаи жизни (или 3 с учетом допусков), либо придется использовать какой-либо суфикс, например "#1", "#2" и т.д.
Как это делаю я: имеется одна основная папка посадочных мест. Если в конкретном проекте возникла необходимость видоизменить уже имеющийся футпринт, достаточно создать в проекте папку "symbols" (на сколько я помню она по умолчанию прописана в psmpath, ну или просто добавить ее туда), поместить туда измененную версию и в этом проекте будет использоваться этот измененный футпринт. Ну и конечно в psmpath "symbols" находится выше основной папки футпринтов.
 11__________________________________.pdf ( 2.27 мегабайт ) Кол-во скачиваний: 2752

Уникальное имя и никаких проблем.

Сообщение отредактировал Bear_ku - Jan 22 2013, 07:57

Bear_ku А у вас случаем не будет полной версии пособия, а не только одной главы

Все написали
2 djhall
В Аллегро действительно проще всего делать как написал Bear_ku - одна папка, в которой все футпринты. Никто ведь не сказал, что она не может быть внутри структурирована, хотя бы минимально:



Дальше имя футпринта в схеме и пути к либе в РСВ эдиторе. Этого достаточно, чтобы из схемы сгенерить нетлист, а в РСВ загрузить все футпринты проекта.

Можно скачать отсюда Кайков

Сообщение отредактировал Bear_ku - Jan 22 2013, 08:25

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

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

Да ничего не будет катастрофичного, увидите предупреждение (warning) в логе когда будете делать экспорт физики. Или когда будете выгружать символ на "плату".
А когда на плате (brd файл) расставлены все компоненты, библиотеки уже не нужны - вся информация есть в brd файле (по сути это БД). Причем там лежат далеко не только символы, но и например модели, причем все это можно из платы извлечь назад в исходном виде.


Cadence очень маштабируема платформа, поэтому вначале кажется что некоторые вещи это глупость... но потом приходит понимание что глупость она в голове