Корпоративная библиотека компонентов для Altium Designer своими руками

Пролог

В одной из предыдущих статей я описывал как создать библиотеку компонентов для Altium Designer на основе базы данных. В качестве бэкэнда был использован Access из пакета MS Office, который хранит все данные в одном файле. Это удобно, потому что MS Access доступен, не требует какой-либо настройки, а также потому, что Altium умеет с ним работать из коробки.

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

Во-первых, всем пользователям библиотеки необходимо предоставить доступ к .mdb файлу. В принципе, это решаемо сетевыми папками, если вы находитесь в одной локальной сети. Или можно использовать облачные файлохранилища вроде Dropbox или Google Drive для синхронизации файла между компьютерами. Но эти сервисы не умеют обрабатывать ситуацию, когда файл изменился на двух компьютерах одновременно: сохранится тот, который правили последним. Таким образом вы можете потерять изменения в базе данных. А файл в расшаренной папке может быть открыт на запись только одним пользователем, что доставляет неудобства при одновременной работе нескольких человек.

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

Чтобы решить проблему одновременной доступности БД мы откажемся от MS Access и посмотрим что мы можем сделать.


Если мы откроем файл .DBLib и внимательно посмотрим, то увидим там опцию Use Connection String. При помощи этой строки вы можете подключить к Altium (поправьте меня, если я не прав) любой источник данных, поддерживающий SQL запросы. Например, для подключения к серверу MySQL вам нужно будет установить драйвер MySQL Connector/ODBC и ввести параметры подключения в поле Use Connection String. Чтобы не писать всё вручную, можно воспользоваться кнопочкой Build (скоро мы к ней вернёмся). Но использование MySQL (как и любого другого движка БД) решает только первую проблему. Возможности посмотреть историю изменений нет (без танцев с бубном). Поэтому вариант с классической БД мы отметаем.

Чтобы видеть историю изменений в библиотеке нам необходимо иметь возможность каким-то образом сравнивать файлы, в которых хранятся данные. И в этом нам могут помочь обычные текстовые файлы. Ну не обычные, а с данными, разделёнными табуляторами (TAB-delimited Text Files). Их можно редактировать прямо в блокноте (хоть и неудобно). Но что самое важное, их легко сравнивать при помощи утилит сравнения файлов. Их вы можете найти в любом клиенте системы контроля версий, таких как SVN, Git или Mercurial, или установить отдельно, например WinMerge. Почему используется именно разделение табуляторами? Потому что по результатам экспериментов так оказалось удобнее: случайно закравшийся разделительный символ в описании компонента не нарушит работу библиотеки.

Систему контроля версий, каждый выбирает ту, что ему удобнее. Для себя я выбрал Mercurial по нескольким причинам: относительно невысокий порог входа, есть возможность offline коммитов и есть бесплатные приватные хостинги для репозиториев: Bitbucket, Gitlab и т.д.

Перейдём к практике. Для работы Altium Designer’а с текстовыми файлами нам необходим ODBC драйвер… от MS Access (вернулись к тому, от чего ушли). Где достать? Можно просто поставить MS Access и необходимый драйвер станет в комплекте, а можно установить сам драйвер отдельно. Тем более, что он бесплатен и лицензионно чист. Скачать можно тут.

Помните, что для Altium Designer 18+ нужно ставить x64 версию драйвера, для 17.1 и более ранних — 32-битную.

Если у вас уже установлен MS Office другой “битности”, то установщик ругнётся и не даст установить драйвер. Решение описано на сайте Altium: www.altium.com/documentation/ru/18.0/display/ADES/Using+Database+Libraries+with+32-bit+and+64-bit+Altium+Design+Software+on+the+same+Computer

Вторая программа, которая нам понадобится это клиент любимой системы контроля версий. Поскольку сам я пользуюсь Mercurial, то и примеры будут для него. Очень удобный клиент для работы с Mercurial называется TortoiseHG, скачивать тут. Вообще, рекомендую версию 4.4-rc2 как самую стабильную.

Итак, все необходимые компоненты для нашей системы у нас есть, начнём её собирать.

Создание библиотеки

Шаг 1

Первым делом создадим необходимую структуру каталогов (имена, понятное дело, произвольные):

  • каталог, в котором будут храниться таблицы компонентов: пусть будет database.
  • каталог с символами (УГО): symbols
  • каталог с футпринтами: footprints


Шаг 2

Далее создадим файлы таблиц. Для этого нам понадобится Excel и Блокнот. Зачем Блокнот сейчас объясню.

В Excel’е создаём таблицу с необходимыми заголовками столбцов (параметры наших будущих компонентов). Какие параметры обязательны, какие нет можно почитать в предыдущей статье. Поэтому на этом останавливаться не буду, приведу лишь список основных полей, которые использую сейчас:

ID
Manufacturer
Partnumber
Description
HelpURL
Status
Type
Temperature Min
Temperature Max
Library Ref
Library Path
Footprint Ref
Footprint Path
Notes


Сохраняем эту таблицу в текстовый файл, разделённый табуляторами. Грамотные люди скажут, то Excel умеет сохранять их через File->Save As… и будут правы. Но проблема в том, что при этом он добавляет вокруг некоторых текстовых полей кавычки. Или дублирует кавычки или ещё какая-то чертовщина с этими кавычками происходит. А это важно, поскольку при неправильно расположенных кавычках поля “съезжают” и библиотека ломается.

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

Повторяем операцию столько раз, сколько считаем нужным. У меня получилось 14.



Имя файла определяет наименование таблицы, а значит и библиотеки в панели Libraries в Altium Designer. Разделение на разные таблицы делается не только для удобства поиска, но и для того чтобы разные типы компонентов могли иметь разный набор параметров (столбцов таблицы). Это удобно.

Шаг 3

Следующим шагом необходимо создать подключение ODBC. Постараюсь описать кратко, с картинками.

Ищем ярлык Data Sources (ODBC) или запускаем odbcad32.exe из командной строки. Откроется мастер управления источниками данных, где нам нужно добавить новый источник: кнопка “Add...”.



Выбираем драйвер “Microsoft Access Text Driver (*.txt, *.csv)



Задаём название источника данных, например vault (запомните его, оно нам пригодится далее). Далее необходимо снять галочку “Use current directory” и указать каталог с нашими таблицами компонентов (в моём случае это каталог database).



Нажимаем кнопку "Options>>", затем “Define Format..." и настраиваем формат наших таблиц: указываем, что наши таблицы имеют заголовки (“Column Name Header”) и разделяются табуляторами (Format: “Tab Delimited”).



Запомните этот шаг: от этих настроек зависит правильность работы БД.

Тут надо предупредить отдельно: в общем случае указаний настроек таблиц по умолчанию (пункт «default») вполне достаточно, чтобы библиотека заработала, однако, не всегда. Бывают случаи, когда драйвер по каким-то причинам неправильно определяет тип данных в столбцах, и некотрые параметры компонентов могут не отобразиться в Altium'е. Тогда нужно будет выбрать проблемную таблицу в списке слева, а в правой части настроить типы данных (используйте кнопочку «Guess»).


Сохраняем результаты настройки, нажимая на OK. В окне мастер управления источниками данных должно получиться примерно так:



Также в папке \database появится файл schema.ini. В нём как раз хранятся эти настройки таблиц, не удалите его случайно.

Шаг 4

Далее создаём в Altium’е новую .DbLib библиотеку. Этот шаг мало отличается от настройки .DbLib для MS Access за исключением настроек подключения к БД. Щёлкаем меню “File” -> “New” -> “Library” -> “Database Library”
Выбираем режим “Use Connection String” и нажимаем кнопку “Build”.



В мастере настройки подключения выбираем “Microsoft OLE DB Provider for ODBC Drivers”, жмём «Next>>»



Указываем имя созданного нами источника данных. Сохраняем: «OK».



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



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



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



Повторяем эту операцию для всех таблиц, настраиваем при необходимости правила передачи параметров из библиотеки на схему и сохраняем .DbLib файл в нашу рабочую папку.

На этом настройка нашей библиотеки завершена, и она готова к использованию, пусть пока она пустая и доступна только на этом компьютере. Осталось настроить синхронизацию библиотеки на другие рабочие места. Это мы сделаем при помощи системы контроля версий Mercurial и бесплатного сервиса Bitbucket.

Шаг 5

Настройка репозитория. Все, кто в курсе как работают DVCS могут дальше не читать, итак всё понятно. Однако, как показала моя практика, немногие «железячники» используют в своей работе какие-либо системы контроля версий.

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

Сначала необходимо репозиторий создать: в контекстном меню папки с библиотекой выберите “TortoiseHG” -> “Create Repository Here” и в появившемся окне нажмите кнопку “Create”.



Если всё сделано правильно, содержимое папки с библиотекой должно выглядеть примерно так.



Делаем первый коммит. В контекстном меню папки с библиотекой выберите «Hg Commit...». Отметьте все файлы (сейчас можно все, впредь внимательно смотрите что вы добавляете в коммит, чтобы не разводить свалку) и напишите какой-нибудь комментарий.



Если вы вы впервые используете TortoiseHg, то при первом коммите он попросит вас представиться, чтобы использовать ваше ник\почту в качестве подписи. Просто заполните поле «Username» в открывшихся настройках. Учтите, что изменить подпись в уже подписанных коммитах будет очень сложно.

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



После нажатия на кнопку «Create repository» вы увидите подсказку как в командной строке клонировать или импортировать существующий репозиторий на Bitbucket. Нас это не интересует, нам нужен только адрес. Скопируйте вот эту часть.



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



Нажмите на «дискетку» рядом с адресной строкой, чтобы сохранить этот адрес на будущее. После того как адрес сохранён нажмите на кнопку PUSH (туда) сверху для того, чтобы залить коммиты на сервер.



При этом у вас должно спросить логин и пароль от Bitbucket. Чтобы не вводить каждый раз, их можно сохранить в настройках, кнопка «замочек», рядом с «дискеткой».

Если всё хорошо, то обновив страницу Bitbucket вы увидите свой первый коммит.

Всё, на этом рабочем месте справились. Осталось слить библиотеку на оставшиеся рабочие места. Для этого запустите Hg Workbench в режиме синхронизации, вставьте адрес репозтитория и нажмите кнопку PULL (сюда). После того как разберётесь с логинами\паролями, и синхронизация завершится, вы получите на всех рабочих местах одинаковый набор файлов.

Работа с библиотекой

Итак, библиотека создана, синхронизация настроена, теперь посмотрим как это работает.

Добавление нового компонента

Для начала попробуем добавить новый компонент в базу. Как обычно для библиотеками в виде БД, «запчасти» (символ и футпринт) компонента необходимо поместить в соответствующие папки. Затем нужно добавить запись в одну из таблиц. Проще всего сделать это в Excel'е, предварительно скопировав туда содержимое текстового файла (таблицы). После редактирования, точно так же, копи-пастом, все изменения сохраняются обратно в текстовый файл.

После добавления записи в таблицу можно обновить в Altium'е библиотеки и компонент появится в списке, и вы уже можете им пользоваться. Однако для того, чтобы сохранить компонент в истории и дать возможность коллегам его использовать, необходимо сделать коммит.

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



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

В случае, если одновременно два разработчика сделают коммит в репозиторий, то ничего страшного не случится, в истории сохранятся оба изменения, однако теперь каждый из них будет видеть свой вариант базы, где нет изменений от коллеги: история распараллелится, появится две ветки. Ведь система контроля версий сама не сможет решить оставлять ли оба варианта, или какой-то нужно отменить. Процедура слияния ветвей (а точнее «голов», если следовать терминологии DVCS) называется «Слияние» или «Merge». Это ручная работа и требует некоторого навыка. Об этом чуть позже.

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


Загрузка изменений с сервера

Для того, чтобы получить изменения необходимо нажать кнопку PULL. Если какие-то новые коммиты есть, то вы увидите их в истории сверху от того, что уже было. Обратите внимание, что строка с последним «старым» коммитом выделена жирным.



Важно: Когда вы загрузили коммиты с сервера, то в вашей папке библиотеки на самом деле ещё ничего не изменилось, и Altium не будет видеть новые компоненты. Чтобы применить изменения к вашей папке библиотеки, необходимо выбрать самый верхний коммит и в контекстном меню выбрать «Update».

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



Разрешение конфликтов

Иногда всё же возникают случаи, когда история разветвляется, и требуется сделать слияние (Merge) двух веток. Самый распространённый случай, это когда вы и ваш коллега добавили компоненты в одну и ту же таблицу. Последний из вас при попытке загрузить коммит на сервер увидит ошибку. Она означает, что на сервере уже есть обновления и их надо загрузить.



После загрузки коммитов с сервера будет видно разделение истории.



Чтобы выполнить слияние ветвей нужно в контекстном меню «чужого» коммита выбрать «Merge with Local...»



В появившемся диалоге снимаем галочку «Automatically resolve merge conflicts», чтобы система не решала за вас какие изменения оставить, а какие откинуть (иногда у меня так терялись новые компоненты).



Жмём далее, система пробует совместить изменения, и если есть изменения в одном и том же файле, то предложит вам эти конфликты «разрулить».



При нажатии на надпись «resolved» появится окно, где вам для каждого конфликтного файла нужно будет выбрать что с ним делать: позволить системе самой решить (Mercurial Resolve), «разрулить» конфликт при помощи специальной утилиты (Tool Resolve), оставить ваш файл как есть (Take Local), оставить файл вашего напарника как есть (Take Other) или вообще ничего не делать (Mark as Resolved). Поскольку мы хотим быть уверены, что остались изменения и наши и нашего коллеги, то нужно выбирать «Tool Resolve».



В окне утилиты сравнения будет показано сразу все имеющиеся версии файла: тот, что был до каких либо изменений (A); файл с вашими ищменениями (B) и файл с изменениями напарника (C). При помощи кнопочек «A», «B» и «C»на панели инструментов указываем какие изменения оставляем (обычно это комбинация «B» и «C»). Результат показывается внизу, проверяем чтобы там было всё как надо.



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



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



Не забываем залить коммит слияния на сервер, иначе всё начнётся сначала.

Заключение

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

Из минусов:
— не очень удобное добавление новых компонентов и редактирование существующих — потому что нужно вручную следить за правильностью заполнения всех полей, в том числе и уникального идентификатора компонента (в отличие от обычных БД тут могут быть дубликаты записей), однако, думаю это несложно решить самописными программами;
— невозможно править записи прямо из Altium Designer'а — это вроде как ограничение драйвера, не получится решить;
— относительно сложно объяснить правила работы тем, кто не знаком с системами контроля версий.

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

P.S.: Фух… Вымучил! Не бейте сильно — написание статей не мой конёк, рожаю их долго и с трудом, но уж очень хотелось поделиться опытом. Все кто смог дочитать — молодец!
Спасибо за уделённое время =)
  • +3
  • 18 февраля 2019, 22:22
  • Krieger

Комментарии (3)

RSS свернуть / развернуть
Вот наверное эта статья отличный ответ на вопрос почему не стоит использовать Альтиум и МС офис в 2019. Хранить библиотеку как набор файлов в любой современной системе контроля версий проще, надёжнее и безопаснее.
0
  • avatar
  • dekar
  • 18 февраля 2019, 23:47
Мы проблему конфликтов решили проще. Добавляет и редактирует компоненты только один человек. Он же и отвечает за корректность данных. Такой себе библиотекарь-инженер.

А вообще, есть готовое решение от Altium: Altium Vault и Altium Nexus Server.
0
— Вы маньяк, Ковальски, — Шкипер хрипло смеется и затягивается.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.