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

Посмотрев на приаттаченный пример работы скрипта надежда на лучшее снова стала оживать, но опыт прежних неудач, когда тоже были продемонстрированы первые результаты, а потом пшик, заставлял приглушить радостные эмоции до момента тестирования готовой фичи, если, конечно, она будет реализована.
А дальше — больше, т. к. оказалось, что не только Константин занят разработкой вывода документации, но еще и AVL:

К тому же, возможно, они объединят свои усилия:

Но идет время и пока тишина... Неужели опять все напрасно? Хочется верить, что нет. Просто как всегда не хватает времени и еще все будет. Просто еще не время.
Как бы то ни было, я решил открыть эту тему для того, чтобы на ее страницах можно было обсуждать эту долгожданную мегафичу — вывод текстовой документации в Кикаде.

"Значение" (номинал элемента, value) - считывается из свойств элемента открываемой схемы без изменений и доступен для редактирования. При открытии библиотеки "Значение" тоже считывается из свойств элемента, но доступно только для чтения.
"Обозначение (буквенно-цифровое обозначение, reference) - также считывается из свойств элемента без изменений и доступно только для чтения как у схем, так и у библиотек. Элементы с знаком вопроса в конце (например "R?") игнорируются.

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

AVL
ГОСТ менеджер компонентов, при попытке формирования перечня или спецификации, выдаёт ошибку "RPC_DOC_IFACE: Не удается подключится к RPC серверу документов". После этого убивается возможность запуска любого компонента Libreoffice до перезагрузки. Может можно убить какой процесс, но я не исследовал.
Неправильно работает прокрутка колесом мыши - только при наведении на полосу прокрутки, хотя для большинства программ достаточно навести курсор на область прокрутки.

Барановский Константин
Я не спрашивал откуда берутся значения (это понятно, да и достаточно посмотреть вживую), я писал что реально происходит.
Проблема получается в том, что имеется, например, конденсатор с полями (первое наименование - ГОСТ менеджер, в скобках - Eeschema BZR 4391):
Наименование (Title): Конденсатор
Тип (Type): SMD0805
Подтип (SType): -X7R-50 В-
Номинал (Значение): 0,1 мк
Допуск (Presigion): 10%
В файле, полученном при помощи kicadbom2spec (версия 3.9), в ячейке "наименование" окажется только 0,1 мкФ (включена опция добавления единиц измерения).
Если есть производитель, то он в "Примечания" не попадает.
Или надо писать всё в одно поле "Номинал"? Тогда на схеме будет бардак.
В самом kicadbom2spec заполняются только поля "Обозначение" и "Значение".
На выходе получается файл с 1 листом (в графе "Листов" стоит 4), ни о каком листе регистрации изменений речи не идёт (хотя опция стоит).
Не понимает исполнений.
Рекомендация по изучению документации тоже не так просто выполнима. При попытке прочитать Руководство пользователя, вылезает надпись: "Чтобы открыть справку нужно выбрать программу просмотра PDF файлов." То есть, kicadbom2spec не понимает зарегистрированную в системе программу для просмотра pdf. Кроме того, при попытке выбора программы вручную, не видит ни одного файла без расширения (символов после точки в имени).

P.S. Kubuntu 14.04 x64

Похоже на ошибку в программе. Можно посмотреть файл схемы с каким это происходит?


В kicadbom2spec нет поддержки исполнений.


Раньше документация открывалась зарегистрированной в системе по умолчанию программой просмотра pdf-файлов, но иногда с этим случались проблемы, например, в Archlinux документация открывалась в GIMP'е. Поэтому пришлось сделать ручной выбор программы для просмотра документации. Начиная с версии 3.9 путь поиска программы в Linux по умолчанию начинается с /usr/bin в котором много файлов и, к примеру, у меня загрузка всего содержимого занимает много времени (секунд 10-15), но потом можно выбрать любой файл с расширением или без (сам использую "zathura").

В любом случае, Вы всегда можете открыть документацию вручную. Она расположена в /usr/share/kicadbom2spec/doc.
Я, все же, настоятельно рекомендую просмотреть руководство и приложенный пример (/usr/share/kicadbom2spec/sample). Большая часть вопросов должна разъясниться.

Барановский Константин

Можно. Выглядит немного странно, потому что удалены детали, относящиеся к другим исполнениям.


В том то и дело, что без расширений не видит (использую okular).
снимок1 - то, что видит kicadbom2spec
снимок2 - то, что видит менеджер файлов


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

Спасибо, буду разбираться.


Кажется, понял в чем может быть проблема. Попробую исправить.


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


Здесь действительно не хорошо вышло. Подумаю как можно решить эту проблему.


В kicadbom2spec тоже можно редактировать/копировать/вставлять/очищать поля сразу нескольких компонентов (см. третий абзац раздела 1.1.3.3 руководства пользователя).

В кикаде у меня есть поле "Посад.место". Хотелось бы чтобы оно было в kicadboom2spec вместо поля "Тип" или дополнительно. Можно это как-то организовать?

Ruslan.B, можно реализовать возможность подстановок. Например, в таблице редактора, в ячейке поля вставляем ${Моё_поле}, а при формировании перечня элементов вместо ${Моё_поле} будет подставлено значение поля с именем Моё_поле. Таким образом можно будет в любое поле вставить значение любого другого поля.
Попробую сделать, посмотрим что из этого получится.

Барановский Константин
А чем вызвана необходимость выдачи документации в формате ods (электронной таблицы)? Нельзя ли в формате odt? Как-то привычнее.

Барановский Константин
Обновил kicadbom2spec. В форме "Редактор полей" не удаётся выбрать значение из списка. Любого.

kicadbom2spec v3.10

• Переработана документация:
  - изменена структура документа (более упорядочена);
  - новый формат исходного документа - asciidoctor вместо *.odt;
  - изменен формат выходного файла - HTML вместо PDF;
  - единый документ вместо разных версий для Linux и Windows;
  - не требуется никаких настроек, документация открывается в веб-браузере.
• Исправлена обработка компонентов с копиями: не обозначенные компоненты игнорируются.
• Исправлена сортировка элементов в перечне (теперь соотв. ГОСТу). Если раньше элементы без названия группы располагались в начале перечня, то теперь все группы и подгруппы элементов без названия сортируются по обозначению первого элемента.
• Исправлена сортировка в таблице редактора.
• Изначально, содержимое таблицы сортируется по колонке Обозначение.
• Добавлен индикатор сортировки в заголовок колонки.
• Исправлена обработка нажатия клавиш при пустой таблице.
• Изменён редактор ячеек таблицы. Теперь это не просто текстовое поле, а поле с выпадающим списком доступных вариантов значений. В выпадающем списке собираются все доступные значения из текущей колонки и добавляются стандартные значения для активного поля. Т.е. теперь редактировать ячейку так же легко, как и в редакторе полей.
• Переделано контекстное меню в редакторе ячейки и редакторе полей.
• В контекстное меню редактора ячейки и полей добавлен пункт позволяющий добавлять текущее значение в список стандартных значений (если отсутствует) или удалять его из стандартных (в противном случае).
• Добавлено контекстное меню для таблицы элементов. В нём дублируются некоторые команды из меню и панели инструментов для редактирования полей.
• Добавлены подстановки полей. Если в любом, доступном для редактирования, поле вставить надпись типа ${Название_поля}, то при формировании перечня элементов эта надпись будет заменена значением поля Название_поля этого компонента. В контекстном меню редактора ячеек и полях ввода редактора полей добавлен пункт меню с несколькими вариантами подстановок стандартных полей.
• Изменены некоторые сочетания клавиш, добавлены новые.
• Исправлена обработка элементов, обозначения которых начинаются с цифры.
• Изменён механизм вставки полей из буфера обмена. Теперь при вставке отображается специально диалоговое окно, подобное редактору полей.
• Исправлен перенос строк в ячейках таблицы перечня элементов (*.ods).

С *.ods намного проще работать через odfpy.


Спасибо за сообщение. Чуть было не выложил релиз с такой серьезной ошибкой.

P.S. Прошу первое время работать с копиями документов (схем/библиотек)! Стараюсь проверять перед релизом, но за всем не уследишь...

Большой проект, много листов. "Толстая" микросхема XCKU085-1760, 28 частей рассыпаны по многим листам, посчитана 4 раза - четыре строки с DD4.
Билиотеку брал от xess тут.
Причину с ходу не понял, просто снял галки в списке с лишних строк.

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

Можно ли как-то это обойти? В kicadbom2spec, к сожалению, не нашёл настроек для руления мапингом полей - например, чтобы можно было указать, какое свойство (поле) компонентов использовать для колонки "Обозначение", какое для - "Примечание". Можно ли как-то порулить передаваемыми в плату свойствами? Из документации понял, что там для этого путь - использовать xsl, парсить обобщенный нетлист и генерить из него свой файл, какой надо. Но это как-то сложновато и длинно.

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

Кто как делает в этом или подобных случаях? Ну, и вообще, идеи?

Принято. Буду искать причину.


В поле обозначения должно быть только обозначение (например, С12), в поле значения - только значение (например, 10мк), вся остальная информация помещается в пользовательские поля. Какие пользовательские поля нужно создать и как - указано в документации (см. разделы 2.1 и 5.1 для версии 3.10).

Я думал, что достаточно подробно все описал, или нужно изложить еще детальнее?

Да, я имел в виду, конечно же, "Наименование", а не "Обозначение".


Как я понял, у вас применяется принцип "создать предопределённые поля", т.е. пользователь должен создать у себя в схеме именно такие поля. Это в известном смысле "прокрустово ложе", более гибким подходом было бы, когда помимо этого существует возможность назначить, какие поля пользователя использовать в качестве наименования, примечания. Например, мне требуется от программы только сгенерировать перечень, а "клеить" значение столбца "Наименование" мне не надо, я это делаю сам своими средствами - например, в пользовательском поле Description. В этом случае очень подошло бы, если бы программа брала просто из указанного поля значение и помещала его в наименование. Точно так же, из другого поля (например, Remark) - в примечание. Это очень добавило бы гибкости - можно так использовать, а можно этак, кто хочет - редактирует в этой программе, кто хочет иначе - своими средствами, а с помощью kicadbom2spec только генерирует перечень.

Попробую реализовать это в следующей версии. А пока, как временный выход из положения, можно воспользоваться новой функцией подстановок (см. раздел 2.2.8 руководства пользователя).