[Uladzimir 60]

Не согласен. Вне зависимости от сложности проекта опытный воспользуется библиотеками заказчика( если работа на сторону), либо своими библиотеками, которые у опытного уже давно наработаны.
Если нужного компонента нет -- его следует в с любом случае создать, а опытный и добавит в свою библиотеку (библиотеку заказчика или своего предприятия). 
Потерь времени нет, а если такой компонет еще понадобится для другого проекта -- он уже под руками.

[Ulkizz 3]

не уловил какого-то преимущества (впрочем как и недостатка)... неопытный сделает ровно тоже самое.

[Uladzimir 60]

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

[Bad0512 2]

Всё то же самое (копирование ранее сделанных компонентов) можно делать и методом cut&paste из ранее созданных проектов. Помещение в отдельную библиотеку как правило требуется только в случае, когда необходимы серьёзные модификации в УГО. Параметры или footprint можно легко править в конкретном инсансе компонента на схеме. При необходимости исправлений во многих однотипных инатансах = использовать групповое выделение.

 

[Uladzimir 60]

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

Мне проще будет пересоздать его. А в библиотеке -- вот он под руками.

[DSIoffe 2]

В 31.08.2023 в 13:35, Bad0512 сказал:

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

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

[Ulkizz 3]

7 hours ago, Uladzimir said:

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

Мне проще будет пересоздать его. А в библиотеке -- вот он под руками.

у меня в библиотеке десятки сотен компонентов. Я вот тоже не вспомню какой я уже нарисовал и вот это всё))

БД (конкордом) стало полегче за таким следить.

 

6 hours ago, DSIoffe said:

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

так-то альтиум же не позволяет работать без библиотек. Копипаста копипастой, но связность проекта развалится. Если конечно не лень добавлять посадочные места отдельно УГО отдельно.

[Uladzimir 60]

Цитата

Я вот тоже не вспомню какой я уже нарисовал

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

[Lotos 4]

Библиотека компонентов или БД обязательна к использованию при работе больше, чем с одним проектом. Поиск кто и когда добавил компонент с ошибкой решается логами или системой контроля версий. А ручная правка компонентов на схеме или плате вместо исправлений в библиотеке приводит к хаосу и костылям. Каждый раз нарушение маршрута разработки ведет к большим потерям времени на ручные переделки вместо обновления однотипных компонентов из библиотеки.

[Arlleex 131]

За время обсуждений я уже успел разработать 3 устройства по несколько плат в каждом Схемы + трассировка.

Но щас мне скажут, мол, если б базой пользовался, еще б 10 успел сделать, да?

[Uladzimir 60]

Наверняка больше
половина новых четверть почти не трогалось. четверть переделанных по топологии но 100%, а х да. Это только в одном  направлении.  Надо бы умножить наверное на два.
Да и там пару сотен компонетов пришлось перевести с одной базы в другую, а пару десятков новых компонетов создать
Хотя хвалится не чему. Проект проекту рознь. Одних можно штамповать десятками. Над другим корпеть месяцами. 

Меряться пиписьками нет смысла.

 

[Basil13 3]

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

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

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

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

У производства/склада - есть своя база компонентов (1С или подобное), туда вносятся аналоги - абсолютные или только для конкретного изделия. Иногда, когда один компонент просто меняется на другой - заведением аналогов в этой базе можно и ограничиться, но желательно аналоги создавать сразу в библиотеке среды разработки.

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

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

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

В итоге:

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

2)Склад будет заполнен гораздо меньшим числом номиналов - компоненты можно покупать оптом, заранее, катушками. 

3)Цепочка "закупка - склад - производство" работает с минимумом сбоев. Никому не надо лишний раз ДУМАТЬ - а думать люди ленятся больше всего - работа идет быстрее и легче.

4)Разработчика дергают по минимуму.

 

P.S. У меня вообще DipTrace - мне это ваш Альтиум нафиг не нужОн!😜

Изменено 7 сентября, 2023 пользователем Basil13

[GeorgK 1]

Есть ещё вариант параметрической генерации - паскалевский скрипт создаёт библиотеки графического обозначения, посадочного места, трёхмерной модели для всех номиналов (с правильными записями в параметрах и правильными надписями на трёхмерной модели). Пробовал так (правда, без графического обозначения) с OpenSCAD - в командном скрипте опенскадовская программа выдаёт через консольный вывод паскалевский скрипт, потом с другими параметрами создаёт набор трёхмерных тел (например, планарные корпуса разной ширины с разным количеством и шагом выводов), которые преобразуютсяиз stl в STEP, потом полученный паскалевский скрипт запускается в Альтиуме и создаёт библиотеку посадочных мест с корпусами.