Доброго времени!

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

1. Возможно ли в альтиуме создать вместо пинов в символе шину данных? Сейчас шины данных приходится разбивать на пины и создавать УГО (условно графическое обозначение) со всеми двумястами с лишним выводами - весьма трудоёмко. Если возможно обойтись шиной, прошу, опишите как это делать правильно. Особенно интересует дальнейшее использование подобных компонентов, особенно в тех случаях, когда не все адреса используются.

2. Правильно ли скрытым выводам присваивать номер части, которой они принадлежат, равный 0? просто в таком случае скрытые выводы можно найти на всех частях, а не на конктретной.

3. Связанный с предыдущим вопросом. Если создается несколько режимов отображения частей УГО, есть совет, чтобы одинаковые пины находились в одних и тех же частях УГО. Если один режим со скрытым питанием, а втором с отображаемым, это правило нарушается. Какие могут быть проблемы в связи с этим?

4. Может ли повлиять отсутствие пинов NC в УГО на корректное прикрепление ПМ (посадочного места) к данному УГО? например, если выводов меньше, чем контактных площадок, в итоге.

1/ нет
2. рекомендую не использовать скрытые
3 Не поможет от багов
4 не влияет

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

Если вы собираетесь использовать скрытые выводы, секции, альтернативные отображения, значит вам плевать на разработчиков.
Все эти извращения интересуют только нормоконтролеров.

Более того, пытаясь создав такую библиотеку, далеко не факт, что она устроит нормоконтролеров.
Правильный вариант: создаете несколько основынй элементов как хотят разработчики/конструктора и идете с этим элементом к нормоконтролю.
Утверждаете графику, создаете СТП и подписываете.
И на основнии этого создаете УГО.
Потому что если внимательно почитать гост, то сейчас достаточно свободно можно рисовать УГО, никаких жестких рамок. Почти весь текст на уровне рекомендаций.

По пункту 4 вам ответили.
2 и 3 - зло.
1. Даже если бы и были шины, входящие в компонент, то проблем было бы море.
Решение здесь такое:
Один раз компонент все равно придется нарисовать в библиотеке. Затем один раз его рисуем на листе схемы, подключаем к шине как нужно и сохраняем этот лист в хорошем месте.
Теперь этот лист вставляем в любой проект и на главноем листе проекта уже соединяем шиной, а не отдельными проводниками

Не. Неверен постулат

Последнее вообще не вяжется с базой
из первых четырех нужно выбрать любые 2 пункта, чтобы хоть что-то получилось

Владимир, peshkoff, благодарю вас за ответы про шины - был наиболее интересующим в плане возможности реализации.

Теперь по поводу остальных пунктов:

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

Т.к. планируется связать элементы с БД снабженцев, необходимо соотношение 1:1 в двух базах. А теперь представьте какой-нибудь элемент логики, который одним разработчиком использовался целиком, а другой захотел разделить его на несколько частей, т.е. по сути два УГО с похожими,но обязательно разными (иначе не будет уникальности, которая необходима индентификатору) названиями, с разным количеством частей и с одинаковыми ПМ. Возникает вопрос, какой из элементов оставлять, чтобы обоим разработчикам было удобно этим пользоваться?
Дискретизация добавляет маневренности и в итоге УГО меньше съедает места на схеме, когда часть выводов не используется. Это с одной стороны. С другой - кому-то проще поставить огромную микросхему на лист и уже с готовой одной работать.

Режимы отображения являются выходом в том случае, когда разные разработчики требуют разные УГО на один и тот же элемент. Но в режимах появляется проблема тогда, когда один вид - одна часть (Part), другой вид - 4 части, т.к. в итоге будут видны все 4 части, только в одном режиме три будут пустыми, что ОЧЕНЬ нехорошо и чревато некорректным использованием и ошибками.

В моем случае наиболее сложными качествами библиотеки в реализации являются удобность и универсальность.


Что вы имеете в виду? Пример можно привести?

И новый вопрос всем:
5. насколько удобно и корректно использовать разваленные УГО микросхем? т.е. каждый вывод рисуется отдельно с левым либо правым бортом корпуса на отдельной части (Part), а потом разработчик просто собирает УГО в той последовательности, как ему будет удобно.

В подобном подходе лично я вижу несколько проблем. Переубедите меня, если кто с таким сталкивался.
Итак:
1) кто-нибудь забудет какой-нибудь вывод поставить на схему
2) выходы и входы поставит вперемешку (иначе за всеми надо будет ПЛИС проверять, что занимает много времени и ничего не упрощает)
3) в принципе разработчик не захочет полусырое УГО, т.к. с ним много возни
4) в ручную необходимо будет дорисовать корпус УГО, скрыть позиционное обозначение, которое формируется автоматически, и добавлять ручками текстовый блок, куда и будет прописываться правильное позиционное обозначение без точки.

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

Формально это вы такой же дали ответ, что я привел ранее. Раз УГО разные, то и компонеты разные и записи в базе отдельные



Не делайте альтернативные изображения, если используете базу. Это тоже отдельные элементы для база и отдельные строки в базе
в библиотеке нет проблем. Проблемы начнутся на схеме.
Поставить на схему, например счетвереный усилитель. Первая часть подключена на первом листе и требует подключения например к -5 вольтам.
Разработчик ставит 3 часть на 41 листе и там нужно подключение к -12 вольт, что он и делает. Потом они попадают в 1 Footprint и имеем конфликт. оба усилителя будут подключены к одному из указанных напряжений--- Кто это будет разгребать в автоматичсеком режиме?
Не удобно. Только при крайней необходимости советую

вы сами и ответили. Список можно расширить

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

Он и так это может сделать, просто тогда нельзя обновлять из базы. Но в вашем случае тоже нельзя. Тогда зачем все эти навороты?

А вы спросите их откуда взялись скрытые выводы? Вероятность 90% что это нормоконтроль их заставил так сделать, т.к. такой пример был приведен в ГОСТ.
В 17 веке, когда элементы рисовались вручную, конечно, это было актуально 300 раз на схеме не писать "+12V" (меньше не было)
Сейчас этой проблемы нет вовсе. Накопипастить можно хоть тыщу.

Но сейчас подобрался конкретный конец скрытым выводам, надеюсь их вообще скоро уберут из всех САПР.
Дело в том, что сейчас под потенциалом, например, +3.3В скрывается далеко не одна цепь!

Вот, например, три потенциала: 1В, 1.2В, 1.5В.

И что будете прописывать в скрытый вывод в библиотеке?



Каждый разработчик должен использовать то, что утвердите по СТП. А в СТП должен быть 1 вид. Нормальный. Само собой, элементарная логика должна быть разбита.



режимы отображения - зло!



Извините, но это треш невероятный.

17:41 peshkoff вспомнил, что имел дело с таким...

А да, вспомнил. Мы такое импользовали на разъемах. Дело еще в пикаде было. Если разъем состоял из 50 выводов, то элемент состоял из 50 вентилей по одному выводу.
Типа должно было сэкономить место на листах (кстати, нормоконтроль именно возникал, что нерациональное использование места).
В итоге получаем трудночитаемую схему. Чтобы понять куда поступает цепь физически в разъему нужно обязательно читать номер вывода.
+ гемеррой при установке этого разъема на плату. Чтобы шло быстрее дело, проще найти схему с таким же и скопировать. Фтопку