Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Настройка текстовых блоков в PCB Editor
Форум разработчиков электроники ELECTRONIX.ru > Печатные платы (PCB) > Разрабатываем ПП в САПР - PCB development > Cadence
Hoodwin
Здравствуйте всем!

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

В Layout все было просто: каждая строка текста имела свои размеры букв и точка. Это было в целом удобно, за исключением случаев массовой подгонки шрифта, скажем, при окончательном оформлении сборочного чертежа. Нужно было каждый текст вручную поправить. Но я выбирал размер текста в соответствии с размерами компонента, так что это не мешало особо, позиционные обозначения редко когда вылезали за границы корпуса, а Value можно было и поджать немного при случае. Но суть в том, что текст для каждого компонента настраивался при его создании в гармонии с его размерами.

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

1) Как настраивать эту самую таблицу?!
Вначале я думал, что логично прописать стили для каждого конкретного назначения. Например, стиль refdes шелкографии. Однако, довольно быстро это стало неудобно. Скажем, на сборочном слое мне нужно указать позиционное обозначение. Стандартная высота букв для него была бы равна тексту шелкографии для позиционных обозначений, то есть около 1.25 мм. Это было бы терпимо для крупных деталей, а что делать с 0402, которые и сами то не больше 1 мм, да плюс стоят с таким же шагом? То есть, одним стилем не обойтись. Обычно я в таких случаях рисовал на сборочнике текст внутри контура детали и потом печатал с увеличением раз в 20.

2) И сколько тогда стилей надо? И если для одного назначения надо более одного стиля, то чем это лучше прямого задания размеров? И как потом рулить самим текстом, если нужно через кучу кнопочек продираться опять к редактору в таблице?
Собственно, родная таблица стилей и все библиотечные компоненты устроены просто. 16 стилей задают текст разной высоты, от маленького до большого, вообще без привязки к его назначению. Причем библиотечные компоненты, бывает, имеют этих текстов такую простыню, которая больше самого футпринта в несколько раз. Как этим пользоваться-то? Куда весь этот текст потом девать, когда он на реальной плате друг на друга налепится? Предлагается его потом ручками разгребать, чтобы он читался и не пересекался? Чем это лучше, чем написать все мелко, но чтобы не пересекалось, а потом распечатать с большим увеличением?

3) Допустим, приняли идеологию, что стиль - это некоторый квантованный размер текста. Значит, надо все проекты подгонять под какую-то продуманную сетку размеров, так? Какие размеры тогда взять? Например, те, что есть, очевидно, не катят при работе с мелкими деталями, просто негде писать такой большой текст. Проблема в том, что если мы создаем библиотечные компоненты, то текст в них должен так использовать стили, чтобы при импорте разных компонент в один проект тексты не разъехались в разные стороны по размерам. Например, текст для резистора был 1.25 мм и был в блоке 1, а для TO-220 текст был 5 мм, но тоже описан в блоке 1, при вводе в проект он может стать, скажем 3 мм, как настроен блок 1 для проекта. Для резисторов - много, для сборки - мало. Если же в будущем для какого-то компонента потребуется текст нового размера, то это потенциально ведет к развалу единой системы размеров для всех библиотек. Описанная ситуация, кстати, проявляется при импорте проектов из Layout, тексты там совсем не такие по размерам, как были в .max.

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

Может, как-то иначе правильно?
Uree
Ничего кривого и неудобного на самом деле в таком подходе нет. Просто нужно для себя разделить типы текстов на те, которые будут использованы в шелкографии и те, которые будут использоваться для оформления документации, т.е. только для распечатки с возможным масштабированием.
Дальше все просто: определяете несколько текстовых блоков разного размера для шелкографии и используете только эти блоки при создании футпринтов. Точно так же определяете несколько блоков разных размеров для документации и опять же используете их при создании футпринтов.
В итоге на плате имеете две группы текстовых блоков - для шелка и для документации. Учитывая способ работы с текстами можем очень быстро и удобно задавать/менять размеры соответствующих блоков и редактировать соответствующие надписи на плате.
Единственное, чего действительно не хватает в этом методе - это возможности задавать текстовым блокам не просто номера, а осмысленные названия, чтобы сразу видеть для чего был предназначен тот или иной тип текста.

Для примера в наших платах сейчас используется в районе десяти размеров шрифтов - 3-4 для шелка, 3-4 для документации и несколько дополнительных, для всяких названий платы, примечаний для изготовителя и т.п. Не так уж и много. Хватило получаса чтобы договориться между собой сколько их использовать и какие размеры применять. Определили их один раз, задали в Template, экспортировали в файл параметров и все - вопрос с текстами в пределах фирмы закрыт. Так что никакой проблемы не вижу, всего лишь вопрос привычки.
Hoodwin
... Ко всему человек привыкает. И к кривизне тоже. Проблемы действительно не было бы, если бы стили можно было использовать подобно автокаду: хочешь, наследуешь свойство от стиля/слоя/блока, хочешь переопределяешь его прямо на месте для конкретного применения. Не всегда хочется выносить в таблицу стилей разные мелкие модификации какого-то стиля.

Пример из практики. Вот возьмем корпус SOIC8. У меня в сборочном слое для этого корпуса определены два текста: позиционное обозначение и part number. Оба текста размещены внутри прямоугольника 4х5 мм, который есть проекция контура корпуса реального чипа. В 4 мм влезает две строки текста примерно по 1.5 мм, при нормальных пропорциях высоты и ширины это дает около 5-6 букв на 5 мм ширины корпуса, и этого хватает для многих реальных микросхем в таком корпусе. Но вот встречается иногда и какое-нибудь длиннющее название: AD485 (ADI) -> SN65HVD21 (TI), из 5 букв стало 9. И это не лезет в том же стиле в такой корпус. Приходится брать и сокращать размер текста, а часто и устанавливать зауженный текст. Ну и как тогда его сужать? Вводить новый стиль? И тогда у каждого проекта появится куча своих собственных стилей, смысл которых нигде не поясняется. Это что, удобно?! Уж лучше бы их и вовсе не было, а просто для указанного текста было указано. что стиль задан на месте.

И еще, Uree. Было бы интересно посмотреть на Ваш опыт с таблицей в конкретных цифрах. Скажем, могли бы Вы привести конкретно, какие именно высоты текста используются в каких стилях (глобальных). Значит ли это, что под эти стили все библиотечные компоненты фактически прорисованы заново?
Uree
Цитата(Hoodwin @ Oct 28 2010, 14:28) *
... Ко всему человек привыкает. И к кривизне тоже. Проблемы действительно не было бы, если бы стили можно было использовать подобно автокаду: хочешь, наследуешь свойство от стиля/слоя/блока, хочешь переопределяешь его прямо на месте для конкретного применения. Не всегда хочется выносить в таблицу стилей разные мелкие модификации какого-то стиля.


Странная мысль... ведь согласитесь - если что-то было использовано в проекте, будь-то текст, футпринт, падстэк etc., оно должно быть записано в файле. Соответственно доступно для редактирования, соответственно быть в таблице. Или по какому принципу программа должна отбирать кого записать в таблицу, а кого нет?

Цитата(Hoodwin @ Oct 28 2010, 14:28) *
И еще, Uree. Было бы интересно посмотреть на Ваш опыт с таблицей в конкретных цифрах. Скажем, могли бы Вы привести конкретно, какие именно высоты текста используются в каких стилях (глобальных). Значит ли это, что под эти стили все библиотечные компоненты фактически прорисованы заново?


Например вот такие:

Нажмите для просмотра прикрепленного файла

Блоки 1-3 для документации, поэтому толщина линий текста 0.01мм(их только на экран/принтер), 4 и 5 зарезервированы для "вдруг понадобится" еще документация, 6-8 для шелка, толщина линии 0.15мм(такое производство еще нормально делает), 9 и 10 тоже зарезервены.
12-14 похоже после каких-то копирований из других проектов вылезли. Изначально в футпринтах таких шрифтов нет. Но это потом поправится, не проблема.
А на счет прорисовки заново не очень понял вопрос. У нас на самомо деле нет ни одного элемента взятого откуда-то и оставленного без изменений - либо нарисовано с нуля нами, либо вытянуто из референс-проекта и поправлено в соответствие с нашими требованиями(шелк, тексты, Place_Boundary и Package_Keepout-ы).
Hoodwin
Цитата
Странная мысль... ведь согласитесь - если что-то было использовано в проекте, будь-то текст, футпринт, падстэк etc., оно должно быть записано в файле.

Я не вижу противоречия здесь. В файле - не значит в таблице. Например, в документе Word может быть много разных оформлений текста, но отнюдь не все объявлены как стили. Можно применить стиль к абзацу, а потом какое-то слово выделить жирным, но это не будет новый стиль. В проектах Layout стилей не было вообще, все свойства хранились для каждого текста отдельно. В проектах Allegro все наоборот, никакой текст не может быть оформлен иначе чем через таблицу стилей. И то, и другое - крайности, но вторая, на мой взгляд, хуже, поскольку нужно принимать единую систему соглашений о стилях, а для layout этого в принципе делать не нужно.

По приведенной картинке вопросы есть.
1) Вот есть такая тема как номера выводов. Их тоже принято подписывать. Вот, скажем, типовой корпус BGA сегодня имеет более десятка рядов шариков с шагом 1 мм и контактной площадкой что-нибудь около 0.35-0.4 мм (NSMD вариант). И название вывода у такого корпуса может быть, скажем, что-нибудь вроде AB12. Спрашивается, какого размера должны быть буквы, чтобы уместиться в кружочек диаметром 0.4 мм. И где они в Вашей таблице? Можно, конечно, писать номера выводов текстом высоты 0.5 мм, в потом выключить вообще класс подсветки номеров выводов за невозможностью прочесть что-либо в перекрывающейся матрице букв. Но это не мой случай...

2) Допустим, остаемся в рамках слоев сборки и маркировки. Берем типовой резистор 0603 - 0.8х1.6 мм. Требуется вписать в сборочном слое позиционное обозначение и номинал - всего 2 строки. Делать это вокруг резистора - себя не любить, потому что потом в большом и плотном проекте придется долго двигать все эти надписи, чтобы они читались. Остается одно - писать их внутри габарита, то есть в 0.8 мм нужно уместить 2 строки текста, да еще с 3 зазорами. Даже если зазор всего по 0.1 мм, то (0.8 - 3*0.1)/2 = 0.25 мм, а такого текста и нет в таблице. Я не говорю уже о 0402, которые еще в 1.6 раза меньше. Что с этим делать?

В общем, чем больше я думаю про эти стили, тем больше склоняюсь к варианту а-ля ряд E12 или E24. Логарифмическая линейка размеров, причем убывающая, от высоты в 5 мм и до 0.05 мм. Если не влезает по ширине текст определенного размера, то берем на несколько номеров более мелкий, пока по ширине не влезет. При этом aspect ratio шрифтов либо постоянное, либо для каждого есть зауженный вариант, следующий за ним по списку. Например, текст 1 - высота 5 мм. аспект стандартный 0.8:1, текст 2 - аспект зауженный - 0.6:1. Тогда хоть появляется шанс на какой-то порядок.
Uree
Цитата(Hoodwin @ Oct 29 2010, 10:01) *
...И то, и другое - крайности, но вторая, на мой взгляд, хуже, поскольку нужно принимать единую систему соглашений о стилях, а для layout этого в принципе делать не нужно.


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

Цитата(Hoodwin @ Oct 29 2010, 10:01) *
1) ...номера выводов. Их тоже принято подписывать... И где они в Вашей таблице? Можно, конечно, писать номера выводов текстом высоты 0.5 мм, в потом выключить вообще класс подсветки номеров выводов за невозможностью прочесть что-либо в перекрывающейся матрице букв. Но это не мой случай...


Номера у выводов конечно есть. Без номеров выводы становятся механическими. Все номера писаны текстом блока 1. Вот только я их не включал и не включаю - не вижу в этом необходимости. Теперь вот сам себе не могу ответить зачем они мне раньше нужны были в ПКАДеsmile.gif На самом деле, какая мне разница, какой у этого пина номер? Мне важна цепь, которая на пине висит. А для работы с цепями есть более удобные средства нежели видимость номеров пинов.
С именами пинов связан еще один неудобный в использовании момент: ввиду того, что в Аллегро это просто текст, он вращается вместе с футпринтом. А вот читать неудачно повернутый текст крайне неудобно. Поэтому уже года 3 как отошел от практики смотреть на имена пинов.

Цитата(Hoodwin @ Oct 29 2010, 10:01) *
2) Требуется вписать в сборочном слое позиционное обозначение и номинал - всего 2 строки...


Ну это ваше желание. У нас вписывается только RefDes, а на все остальное существует ВОМ, поэтому проблема в два раза меньше. Хотя основная часть элементов как раз 0402 и разница вписать туда 2-значный рефдес(С7) или втиснуть 5-значный (R2417) существуетsmile.gif. С другой стороны монтаж только автоматический, поэтому сборочный(а точнее просто assembly) - вещь просто для информации. Основное это ВОМ и файлы Pick&Place для SMD компонентов.

Цитата(Hoodwin @ Oct 29 2010, 10:01) *
В общем, чем больше я думаю про эти стили, тем больше склоняюсь к варианту ... Тогда хоть появляется шанс на какой-то порядок.


Вот видите, возможность навести порядок есть всегда. Нужно просто подумать на эту тему. Какую примете систему уже не так важно, главное чтобы она была понятна Вам и позволила держать проекты в порядке.
Hoodwin
Ну, подведем итог. Чтобы создать единую систему соглашений, нужно иметь приличный опыт того, как делать не надо. А опыт этот показывает, что никогда нельзя быть уверенным, что до конца познал, как делать не надо. И именно по этой причине единую систему создать нельзя. И дискуссия лишь подтверждает это.
Uree
Единую может быть и нельзя, но систему, которая удовлетворит потребности определенной команды разработчиков - вполне. Для разных команд естественно могут быть разные в деталях системы, но создать наверняка возможно. Это мнение именно исходя из личного опыта.
Hoodwin
Вот оказывается все не так уж просто с этими текстовыми блоками. Создал свою сетку размеров на 32 блока. Потом создал SOIC8, в котором использовал такие параметры блоков. Потом попытался вставить этот SOIC в сделанный ранее brd, в котором еще текстовые блоки были стандартные. В итоге все тексты стали какие-то крохотные, блок #10 почему-то стал #18, а они у меня убывают по высоте в таблице. Так и не понял, что это такое было.

Ладно. Создал новый проект. Сразу импортировал туда все настройки цветов, текста, сеток и т.п. Уже после этого вставил свой SOIC-8. И вот тогда уже вышло нормально, как и ожидалось. Потом вставил SOIC14 из библиотеки PCB Editor. И к своему удивлению обнаружил, что он навтыкал туда текст, размеры которого я не задавал. Посмотрел на свойства элемента этого текста, пишет - блок #33!, А у меня их всего то 32 задано.

Вывод: при вставке в проект некоторого символа оно как-то хитро пытается мержить две таблицы стилей, причем не всегда правильно. Но факт, что стили добавляются, если их нет в исходном проекте, а не применяются, скажем, ближайшие по размеру. То есть, городить такую большую таблицу вроде бы и не было большой нужды, правда, тогда она росла бы бесконтрольно.
Hoodwin
Надо как-то упростить процедуру, что ли.
Uree
Help надо читать, хоть и времени не хватает...
Есть два метода как Аллегро работает с текст-блоками.
В первом случае вставляет с теми блоками. которые были прописаны при создании футпринта, естественно не глядя на их размер.
Во втором каждый элемент вставляется с проверкой приписанных ему текст-блоков и поиском аналогов в дизайне. Если аналог найден - устанавливается он, если не найден - добавляется новый текст-блок в таблицу.
Варианты переключаются установкой Setup -> User Preferences -> Placement -> General переменная preserve_symbol_textblock.
У Вас сработало по второму варианту, в итоге получили 33-й текст. не заданный изначально в таблице.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.