[Буратино 0]

1 1 библа с УГО транзистора

2. 1 библа с УГО резистора

3. 1. Библа с УГО трасфортматора.

4 сколько разных посадочных мест столько и библиотек под Footprint транзисторв резисторв трансформаторав

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

 

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

 

Давайте обсудим эту разницу в подходах,

Что даст разделение библиотек для компонентов? Какие плюсы? Мне нравится в этой идее простота распространения компонентов на чисто физ. уровне, ведь в таком случае будет передаваться только тот компонент в котором нуждается разработчик, но мне не ясно как он (разработчик) будет интегрировать в свою базу полученные файлы? Также не ясно почему Вы говорите о том ,что групповые операции зло, ведь благодаря такой возможности можно будет привлечь пользователей, которым нужен ГОСТ, другие стандарты в изображении графики УГО/начертания футпринта! (я имею в виду возможность менять параметры моделей для всей(всех) компонентов одновременно)

Где и как вести дерево компонентов? Средствами файловой системы, либо все библиотеЧки свалены в одну/несколько папок а в самой программе ведется иерархия компонентов?

Как и откуда компоненты будут стаскиваться на схему?

Изменено 21 сентября, 2010 пользователем Буратино

[Uladzimir 65]

Что даст разделение библиотек для компонентов? Какие плюсы? Мне нравится в этой идее простота распространения компонентов на чисто физ.

+1

Что даст разделение библиотек для компонентов? Какие плюсы? Мне нравится в этой идее простота распространения компонентов на чисто физ.

Просто. используя общую базу.

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

или используя библиотеки добавить собственную запись

Также не ясно почему Вы говорите о том ,что групповые операции зло, ведь благодаря такой возможности можно будет привлечь пользователей, которым нужен ГОСТ, другие стандарты в изображении графики УГО/начертания футпринта! (я имею в виду возможность менять параметры моделей для всей(всех) компонентов одновременно)

Для ГОСТ, если нужно -- делать альтернативные изображения. Никто не мешает.

Хотя честно говоря в большинстве случаев годятся общие

Где и как вести дерево компонентов?

Как кому нравится. Деревья могут не совладать, Можно и в кучу свалить.

Главное чтоб изображения (файлы) не дублировались

Файлы прекрасно находятся, если указана опция поиска в папке, и во всех вложенных папках.

При этом в записях базы ничего менять не нужно

 

[masterofnature 0]

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

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

 

А вот что касается ссылок на документацию: где, предположительно, эта документация должна находится?

1. Для меня удобнее локальное размещение: быстрее, нет зависимости от интернета и трафик лишний раз не расходуется - не у всех на рабочем месте есть безлимитный интернет.

2. Встречаются компоненты, по которым нет информации на оф.сайтах.

 

Поэтому предлагаю такой вариант заполнения полей:

HelpURL - относительная ссылка на основной datasheet к источнику с определенной структурой

ComponentLink1URL - ссылка на страничку на сайте изготовителя/разработчика данного компонента.

ComponentLink2URL - ссылка на основной datasheet на оф.сайте (если есть)

 

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

[Uladzimir 65]

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

+1 +1 +1 По всем пунктам

Поэтому предлагаю такой вариант заполнения полей:

HelpURL - относительная ссылка на основной datasheet к источнику с определенной структурой

ComponentLink1URL - ссылка на страничку на сайте изготовителя/разработчика данного компонента.

ComponentLink2URL - ссылка на основной datasheet на оф.сайте (если есть)

В принципе согласен. Только назначение ComponentLink1URL ComponentLink2URL поменял бы местами. Главное все же даташит

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

Ну без разницы платный бесплатный-- все равно качать. а таких хранилищ в инете достаточно

[masterofnature 0]

Ну без разницы платный бесплатный-- все равно качать. а таких хранилищ в инете достаточно

Тут вопрос не в платности, конечно, а в том, чтобы простую структуру размещения документации можно было сделать, чтобы без труда ее дублировать на локальном компьютере, не пользуясь поднятием локальных серверов и правкой HOSTS

[Uladzimir 65]

Так я только так и делаю. Работаю со своим. Интерент только для синхронизации.

Отсюда и не любовь к постоянно обновляющимся файлам большого размера

 

[Буратино 0]

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

Допустим вы скачали с сайта компонент состоящий из 2х либ *.PcbLib, *.SchLib

Каким образом такой компонент будет интегрироваться в существующую(щие) библиотеки? Связь УГО и футпринта будет задаваться внутри этого софта? То есть, мне нужно будет положить части компонентов в общую кучу либ, а потом из программы найти УГО и найти футпринт и связать их в лог. единичку? Пральна?

 

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

Изменено 21 сентября, 2010 пользователем Буратино

[Uladzimir 65]

создание соответствующего ПО

Ну если базу в Access назвать ПО то да

Возможно это будет Аккцесс

Не возможно, а точно. еселл не дает всего

Каким образом такой компонент будет интегрироваться в существующую(щие) библиотеки?

Ни как. Достаточно чтобы он был хотя бы в одной из библиотек дерево.

Желательно чтобы только в одно

Связь УГО и футпринта будет задаваться внутри этого софта?

Ну да, внутри базы

То есть, мне нужно будет положить части компонентов в общую кучу либ, а потом из программы найти УГО и найти футпринт и связать их в лог. единичку? Пральна?

Оно само найдет. Нужно просто указать чтобы искало во всех поддиректориях

что получится если хранить 100 футпринтов в одном файле и сколько в 100 файлах?

Конечно в одном файле меньше. Но несущественно.

И чем более разлапистей и сложней компонент, тем менее существенно. Сравните 1000 ногие :)

 

 

 

[masterofnature 0]

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

Допустим вы скачали с сайта компонент состоящий из 2х либ *.PcbLib, *.SchLib

Каким образом такой компонент будет интегрироваться в существующую(щие) библиотеки? Связь УГО и футпринта будет задаваться внутри этого софта? То есть, мне нужно будет положить части компонентов в общую кучу либ, а потом из программы найти УГО и найти футпринт и связать их в лог. единичку? Пральна?

Это нужно в любом случае. Но, на сайте уже есть БД со всеми связями.

А во-вторых - удобнее будет названия файлам УГО ( и ФП ) давать по названиям самих УГО

 

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

Вопрос не в избыточности, а в удобстве.

 

[Uladzimir 65]

А во-вторых - удобнее будет названия файлам УГО ( и ФП ) давать по названиям самих УГО

Именно так :) Не удобней, а необходимо!!! Чтоб голова не болела :)

[Буратино 0]

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

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

Наличие 5 версий Акцесса также оптимизма, применительно к этой задаче, мне не добавляет.

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

 

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

Кто конкретно сделает такой анализ? Владимир, Вы тут один из самых опытных пользователей, может быть потестите, в конце концов идея то ваша. :rolleyes:

Изменено 21 сентября, 2010 пользователем Буратино

[Uladzimir 65]

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

Странно. У меня нету, а я работаю :)

Не обязательно это. Достаточно указать директорию для базы где искать, и указать что искать во всех подпапках

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

Еще как. на работе папки по разному находятся, а в контрагентов даже не знаю как. А проблем то нету :)

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

Наличие 5 версий Акцесса также оптимизма, применительно к этой задаче, мне не добавляет.

Не все страдают этим.

Кстати сам Altium использует крайне ограниченные возможности Акцесса

Менять на что-то иное-- такие же проблемы. У кого то не будет такого же иного

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

Я же писал все зависит от сложности компонента.

Вот для джойстика аля 6 выводов относительно простой графики отдельная библа имеет размер это 5500. Это много?

[masterofnature 0]

В частности: это часть офисного пакета микрософт, и у многих на машинах его нет и быть не должно. А на тех машинах где есть офисный пакет, не факт что найдется акцесс.

Существуют бесплатные Redist'ы для пользования БД там, где пакет офиса не установлен. Смотрите на сайте мелкомягких.

 

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

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

 

[Uladzimir 65]

А для чего вам дерево?

Как дерево файлов библиотек-- так сложно.

как дерево записей в базе-- так необходимо :):):)

Да излишества в базе в виде дерева не нужны.

Максимум достаточно запросов

[jkrieger 0]

Файлы прекрасно находятся, если указана опция поиска в папке, и во всех вложенных папках.

При этом в записях базы ничего менять не нужно

А не происходит ли в таком случае замедление работы? По-идее на это же нужно какие-то вычислительные ресурсы.

 

1. Для меня удобнее локальное размещение: быстрее, нет зависимости от интернета и трафик лишний раз не расходуется - не у всех на рабочем месте есть безлимитный интернет.

Я тоже за хранение даташитов локально, рядом с базой. Но пока отбросил эту идею из-за того что нужно много места (на Google Code вроде гектар дается).

Несколько полей для ссылок постараюсь прикрутить.

 

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

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

 

 

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

Рассмотрим строение одной БД (например транзисторы). В ней есть таблица корпусов Packages с полями: Package, Footprint Ref (2,3,4), Pin Count, Power Dissipation; таблица Simulations с полями SIM Model, SIM... (все что относится к симуляции); и есть собственно таблица компонентов например NPN с полями Part Number, Manufacturer, ссылки на даташиты, и все что относится к конкретному элементу, и эта таблица связана с Packages и Simulations по соответствующим полям.

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

 

Зачем это надо?

1. Избегаем ошибок в записях Package, Footprint Ref (2,3,4), Pin Count.. (ведь для разных компонентов с одним и тем же корпусом они будут одинаковы)

2. Уменьшаем избыточность (а следовательно размеры БД)

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