Да, можно.

Вот здесь не совсем понимаю о чем речь. Можете на примере более подробнее объяснить?
Также не знаю, что такое ЭРИ и аппаратура ВН. Посмотрел в поисковике, понимание не наступило.

ЭРИ - электрорадиоизделие (именование электронного компонента по ГОСТ). См. например http://www.ciklon.ru/catalog/mop.htm, http://asonika.ru/?q=22. КРР - элемент экспертизы аппаратуры военного назначения.

Правильно ли я понимаю:
1) есть желание использовать готовую систему Асоника (не делать ее аналог)?
2) чтобы экспортировать данные в Асоника-Р, необходимо реанимировать прежнюю генерацию BOM, вырезанную недавно командой lp:kicad?
3) достаточно реанимировать именно в том виде как была до этого сделана генерация BOM или потребуется адаптация, например, под Асонику-Р?

P.S.:
К сожалению, не смог просмотреть chm файл из архива http://asonika.ru/documents/asonika_r.zip, пробовал из Windows 7.

Доработал в ревизии 4129.
Теперь окно офиса становится видимым только когда документ полностью сгенерирован. На время генерации добавлено отображение прогресса.

Разобрать готовый csv-файл несложно.
Важно иметь аппарат для задания всех необходимых атрибутов компонентов (в т.ч. ТУ).
И Асоника-Р, и программа которая применяется у нас, имеют сертификаты МО и используют перечень элементов в обычном формате BOM. Какая-то адаптация не потребуется.

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

Конечно же, и стабильные сборки не лишены недостатков, но все же багов вних гораздо меньше. Это наглядно видно по тому, как Жан Пьер рожает стабильный релиз: в какой-то момент в тестовой ветке берется сборка, которой присваивается наименование — стабильная. Далее, тестовые сборки развиваются как ранее — что-то дополняется, что-то временно отключается и почти всегда что-то глючит или вовсе падает, а в стабильной ветке больше ничего не меняется и только исправляются баги.
Через некоторое время вылизанная стабильная сборка становится финальным релизом и год или около того остается в неизменном виде, что ведет к отставанию от самых свежих веяний тестовой ветки. Но, такова плата за большую, чем у тестовых сборок, стабильность.
Такой сценарий принят во всех существующих проектах, т. е. стабильные релизы делаются в обязательном порядке и являются главным продуктом для широких масс юзеров, в отличие от тестовых сборок для узкой группы тестеров с разработчиками.
Не удивительно, что на нашем форуме тестовые сборки в большем почете, т. к. здесь собрались продвинутые пользователи. Но, я выступаю от лица обычных юзеров, мнение которых редко кто слышит, но в расчете на них все и делается.

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

Собственно, именно об этом я и писал. Однако, не совсем понятно, а зачем же ждать? Сборка Кикад4017стаб. близка к финалу, а может и станет финальной, а gost_docgen тоже достаточно зрел для объединения со стабильной сборкой, так чего же ждать? Вот и потестируем

Теперь о некоторых «нескладухах» которые вылезли при кратком и пока еще поверхностном взгляде. Скорее всего я что-то не так делаю и многое образуется при очередной порции объяснений. Сборка 4126 в вин7х64.
При генерации перечня элементов (не весь перечень, а только несколько элементов для теста) в штампе бросается в глаза то, что децимальный номер выводится не максимальным шрифтом, как сейчас в схеме с патчем Барановского Константина, а гораздо более скромным размером.
Далее, в названии изделия осталась надпись «схема электрическая принципиальная». Мне сейчас трудно соображать нанюхавшись краски во время ремонта, к тому же ночь на дворе, но, раз уж там есть надпись «перечень элементов», то «схема электрическая принципиальная» вроде должна отсутствовать, что можно осуществить воспользовавшись тем, что «схема электрическая принципиальная» идет после точки. Но, реально голова не варит, так что простите...
Далее, там где название организации вместо моих ОАО «Рога и копыта» стоит ООО «ХХХХХ», что совсем уж не понятно.
При генерации спецификации в штампе возникают аналогичные непонятки с надписями.
Беглый взгляд на менеджер тоже приводит к некоторым вопросам. Например, почему поле «наименование» содержит для выбора не все варианты, что встречаются на практике, причем часть наименований на англ.яз., а часть на русском. При этом, например, множественное число от capasitor образуется не добавлением s, а добавлением русского ы, что приводит к надписи capasitorы.
Бедный выбор предоставлен и в остальных полях. Видимо, все это пока сделано для пробы и все еще будет, но может быть уже пришло время придать этим полям завершенный вид, иначе ползучие изменения-дополнения будут тянуться до бесконечности.
Так же не понятно, почему, например, резисторы, конденсаторы, индуктивности.., выводятся в графе «имя» таблицы менеджера в одиночном экземпляре, а, например, джамперы раздваиваются? Например, изначально имеем J_JMP_SOLD (это попадает в поле “Type”), но еще генерится поле «Значение» J_JMP_SOLD и в результате получаем J_JMP_SOLD J_JMP_SOLD в графе «имя» таблицы.
Для повышения удобства и скорости заполнения таблицы можно воспользоваться наработками cvpcb, а именно: там при выбранном посадочном месте можно «проштамповать» все имеющие к этому отношение компоненты простым кликом без необходимости каждый раз выбирать одно и то же посадочное место. Вот и в менеджере текст. док. желательно сделать так, чтобы при выборе последующего компонента оставался активным выбранный вариант заполняемого поля (в том числе если поле было отредактировано). Если для следующего компонента потребуется другой вариант поля, то только тогда будет произведен очередной выбор, а не каждый раз, как это сейчас.
-=-=-=-=-=-=-=-=-=-=-=-=-=-
Думаю, для начала достаточно. Но есть у меня еще и очень большая просьба.

Если я правильно понял, то в настоящий момент, даже если схема содержит компоненты с уже заполненными полями, то все равно придется каждому компоненту в менеджере заполнить поле «Наименование».
Однако, в библиотеке kicad_gost_lib_mod_3d_20.01.13.7z (конкретно - mixture.lib) ftp://ftp.kicad.ru/pub/kicad/library/aldan/ которую я составил и, надеюсь, не только я пользуюсь, компоненты имеют в своем названии префиксы согласно ГОСТ 2.710-81 (СТ СЭВ 6300-88) «Обозначения буквенно-цифровые в электрических схемах».
Префикс представляет из себя буквенное обозначение согласно ГОСТ и символ «_». Например: R_, SA_, VD_. Таким образом, префикс легко опознается, по нему можно заполнить поле «Наименование», а его отбросить от названия.
При помощи использования информации префиксов и имея компоненты с заполненными полями текстовый документ будет генерироваться автоматически после небольшой коррекции. Так вот, моя просьба использовать информацию префиксов, а их самих отбрасывать.
Уффффф..., пока все. Не знаю, что я тут понаписал на дурную голову. Если что, простите Скоро у меня потихоньку начнет появляться время и я продолжу свое нудное повествование.

Я тоже пользовался именно стабильной. И угораздило меня обновить KiCAD и пересобрать именно стабильную версию перед заказом. Но субъективно еще раз повторюсь. По моим ощущения тестовые релизы ведут себя гооораздо лушче. Помнится вышел один "стабильный релиз", в котором неправильно устанавливался размер шрифта в PCBNew. Причем до этого все было хорошо. Собрав тестовый релиз я был приятно удивлен отсутствием этого бага. Не думаю что кто-то в серьез вылизывает стабильные рализ, разве только раз в год.

PS: Пользуюсь тестовыми релизами с августа прошлого года, и пока еще тьфу тьфу тьфу ...

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

Думаю здесь потребуется пересмотр смысла полей File->Page Settings->Title Block Parameters->Title и Comment1. Считаю, что добавление окончания "Э3" в обозначении и "схема электрическая принципиальная" в наименовании правильнее делать в самой eeschema в момент отображения (чтобы сами параметры в File->Page Settings->Title Block Parameters не содержали эти окончания). Иначе придется делать некрасивое действие - удалять эти окончания в момент формирования спецификации и ПЭ3, что чревато ненадежностью как минимум.
Если никто не возражает насчет этого, то нужно доработать саму eeschema.

Доработал в ревизии 4130.

На этот вопрос уже отвечал в сообщении

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

В таком виде по умолчанию добавляются новые компоненты в схему в редакторе eeschema в момент разработки этой схемы. Я эту логику не понимаю. Считаю, что только поле Type должно устанавливаться согласно библиотечному наименованию компонента. Почему полю "Value" присваивается значение поля "Type" - для меня загадка.
Считаю это поведение нужно исправлять в самой eeschema.

Сейчас в менеджере компонентов работает механизм группового редактирования (удерживая CTRL выбираете интересующие одиночные строки, либо удерживая SHIFT - диапазон строк, и редактируете нужное поле сразу у всех выбранных компонентов). Это то, что требуется по этому вопросу?

Не совсем понимаю, для чего эти префиксы у наименований? Почему они не в позиционных обозначениях?
Автоматизировать заполнение полей "наименование" пока не берусь по 2-м причинам:
1) логика удобства незаполненности полей "наименование" объяснена в сообщении
2) не для всех случаев есть прямое сопоставление префикса поз.обозначения наименованию. Например, VD - это может быть диод, а может быть и диодная сборка. Поправьте, если не прав.

И не пытайтесь даже. Это такой французкий подход к заполнению этих полей. Была бурная дискуссия в kicad-developers, Жан-Пьер с компанией нескольких человек, просивших сделать это буквально смешали с г...

Реанимировано в ревизии 4132.


Если мы поймем, что так сделать - единственно возможный вариант, то мы сделаем это по крайней мере в lp:~kicad-gost-committers/kicad/kicad

Скорее всего мы говорим о разных «стабильных» сборках, что и порождает наше недопонимание. Для прояснения данного вопроса вспомним как рождается финальный релиз в типичном проекте: сначала идет серия тестовых сборок, потом несколько релиз-кандидатов, а уж потом выкатывается финальный релиз о котором я и толкую.
Раньше Жан Пьер придерживался такой же цивилизованной модели разработки и после 5-6 кандидатов объявлялся финальный релиз и поэтому было совершенно ясно какой же релиз считать финальным.
Теперь же наш французский друг почему-то избрал странную манеру выпуска неограниченного числа якобы «стабильных» версий, которые по сути почти ничем не отличаются от тестовых, и после выпуска огромного их количества молча перестать делать обновления, что, по истечении некоторого времени, даст основания считать, что мы наконец-то имеем дело с финальным релизом. Например, за последние 3 месяца вышло десятка три «стабильных» сборок, которые на самом деле проходные и не имеют никакого отношения к действительно стабильному финальному релизу.
Так вот, если перед заказом Вы пересобрали именно такую якобы «стабильную» версию, то не мудрено, что результат был таким печальным.
Повторюсь, я подразумеваю под стабильным релизом именно ту сборку, которая является венцом «вылизываний» и остается неизменным эталоном на ближайший год.
И это, как говорят в Одессе — две больших разницы.

Согласен. Поэтому было бы здорово использовать в оформлении в текстовой документации патч Константина Барановского.

Конечно же так надежнее, но на это Жан Пьер не согласится, т. к. ему наши «гостовские страдания» до лампочки. Такие изменения можно сделать только в нашем варианте.

В том сообщении объяснение затруднений оканчивается фразой: «Так что буду это дорабатывать». Вот я и намекнул, что не плохо бы подступиться к решению этого вопроса

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

Как подсказал Сергей Борщ, так лучше не делать. А не проще ли отбросить лишнее в самом менеджере текст. Док.?

Да, вполне.

Для удобства поиска.
Похоже, что у Вас не хватило времени познакомиться с библиотеками о которых я писал. Тогда сделаю некоторые предварительные пояснения.
Компоненты распределены в три библиотеки: analog_IC.lib, digital_IC.lib и mixture.lib. Первые две содержат аналоговые и цифровые микросхемы, а последняя - все остальное.
Так вот, каждый компонент из библиотек analog_IC и digital_IC не нуждаются в префиксе т. к. определен названием самой библиотеки и имеет определенное наименование, которое и будет отображаться в текстовом документе.
А вот компоненты в библиотеке mixture различны по функциям и не могут быть определены названием библиотеки. Кроме того, они не имеют определенного наименования, но только временные названия с префиксами, которые потом в менеджере будут подменены на совершенно конкретные наименования. Например, L_IND (индуктивность) будет заменена на совершенно конкретное наименование.
Таким образом, префиксы позволяют промаркировать и сгруппировать разношерстные компоненты для удобства последующего поиска.

Логика удобства незаполненности полей "наименование" мне показалась сомнительной т. к. не отвечает главной цели — упрощение и ускорение генерации текстовой документации. В идеальном случае нужно достичь того, чтобы после выпуска схемы было достаточно нажать на одну кнопку и получить полный комплект текстовых документов.
Достичь такого не реально, т. к. изменения и дополнения будут всегда необходимы. Однако, нужно стремиться к максимальной автоматизации.
Считаю, что лучше иметь автозаполнение поля «наименование», а отметку на бумажке где остановился, чем вручную делать то, что мог бы мгновенно сделать компьютер. Еще лучше, если менеджер будет запоминать последнее расположение позиции в таблице и при следующем запуске выйдет в ту точку, где был закрыт в прошлый раз.
Если уж на то пошло, то можно сделать чекбокс с выбором возможности автозаполнений полей. Тогда все будет решать дело вкуса и конкретной ситуации каждого.

Если заглянуть-таки в библиотеку mixture, то можно увидеть, что на данный момент там находится 23 разновидности компонентов с префиксом VD_. Собственно, все название компонента в этой библиотеке, а не только префикс, нужно использовать для его идентификации.
Кстати, если пойти этим путем, то можно будет дописать префиксы DA_ и DD_ для библиотек analog_IC и digital_IC соответственно.
Словом, загляните в библиотеку mixture и все станет понятно.

Жду ответ на второе письмо от Андрея Федорушкова по переводу на русский (у меня есть технические вопросы с poedit). Он сейчас пока не доступен. Как только перевод будет добавлен, данный вопрос решится сам собой.

Тоже об этом думал, может так и сделаем.
Не будет ли таких редких ситуаций когда реально Type может быть равно Value?

В этом сообщении задал вопрос по библиотекам.
Если нет возражений, есть смысл добавить их в lp:~kicad-gost-committers/kicad/library

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

Ответил в теме по библиотекам в сообщении

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

Что-то не приходят на ум такие ситуации, но сейчас мой ум очень далек от совершенства, так что лучше промолчу.

Могу ответить только о библиотеках в разделе ”aldan”, к составлению которых приложил руку.
Весь мой нудный труд заключался в просеивании и отборе более-менее подходящих по некоторым критериям компонентов для библиотек и некоторых исправлениях. После того, как библиотеки сформировались я их выложил на форуме и «отпустил», т. е. каждый волен с ними делать что хочет.
Стараниями faa и viknn они попали на наш фтп. То, что они будут еще где-то находиться меня совершенно не заботит, а только радует, если кому-то еще пригодится. Так что моего согласия можно было и не спрашивать: у меня возражений нет.

Сижу на версии (2013-05-19 BZR 4123 GOST)-testing
Та которая заработала. Питоновский скрипт я вернул какой был изначальный.
При генерации спецификации повесился GOST-Tools. Повис pyuno. Выводил резисторы в спецификацию, и часть вывел, а на другой части повис.

Это попало в спецификацию:


А это то что реально в перечне:

Есть возможность прислать файл *.sch на основе которого генерируете КД?

Исправил в ревизии 4133.


Сделал в ревизии 4133.

Может есть смысл добавить в эти библиотеки поле Title и дать ему конкретные значения прямо в библиотеке?
Например компоненту VD_DIODE_DUAL_AOA добавить поле Title Диодная сборка
и т.д.

Если я не ошибаюсь, то редактор библиотек схематика имеет вкладку «описание» («правка свойств компонента» > «описание» > «описание») именно для этого. Но нужно ли ею пользоваться для достижения нашей цели?
Рассмотрим описание упомянутого компонента VD_DIODE_DUAL_AOA. Что говорит нам такая запись? «VD» говорит о том, что речь идет о диодах и все 23 разновидности их благодаря этому префиксу расположены вместе, что облегчает поиск нужного компонента из этой подгруппы при просмотре библиотеки. Далее, «DIODE_DUAL» сообщает нам о том, что это двойной диод, а « AOA» говорит о том, что на 1-й ноге анод, на 2-й катод объединенный с анодом и на 3-й другой анод.
Такая запись полностью описывает компонент, что необходимо для удобной работы разработчика с ним, но эта информация избыточна для перечня. Таким образом, подобная запись годится «и вашим и нашим». А что еще нам даст дополнительная запись в поле Title? Ничего.
Мне кажется, я понимаю, откуда у Вас появилось желание ввести еще одно поле. Наверно думается, что наличие такого спец. поля сделает возможным заполнить поле «наименование» в менеджере. Однако, Вам все равно придется стандартизировать список наименований и обрабатывать эти поля для распознавания и последующей сортировки.
Думаю, Вы опасаетесь, что нарушение стандартизованных наименований не даст правильно распознать компонент, что приведет к ошибке составления перечня. Но ведь введение дополнительного поля не решит эту проблему, а распознавать с не меньшим успехом можно и префиксную группу, которая уже имеется.
Кроме того, даже сейчас уже есть несколько действующих библиотек, а со временем их станет еще больше. Будут ли они все иметь эти префиксы и/или поля заполненные по стандарту?
Чтобы разрубить этот узел, предлагаю сделать редактируемый список соответствия префиксов и соответствующих им записей, которые будут отображаться в перечне. Причем, это автозаполнение сделать отключаемым (по умолчанию отключено), чтобы избавить пользователя, который еще не разобрался в тонкостях автозаполнения от ошибок. Предлагаю этот редактируемый список соответствия изначально сделать на основе префиксов в библиотеке mixture.lib, т. к. какой-то другой системы структурирования библиотеки пока еще никто не представил.
И еще, можно сделать так, чтобы анализировалось наличие как префикса, так и поля «описание». Если префикса нет, но поле «описание» заполнено, то автозаполнение ведется на основании информации именно этого поля. Такое решение поможет промаркировать компоненты из библиотек analog_IC.lib и digital_IC.lib, которые префиксов не имеют.

Увы, мне доступна только сборка 4132, так что не могу это протестировать.
Кстати, правильно ли я понял, что пока что оформление штампа все еще ведется не при помощи патча Константина Барановского? Делаю такой вывод так как информация об обратном отсутствует. Что мешает внедрить патч Константина Барановского в оформление текстовых документов, чтобы все было красиво и однообразно? От кого зависит решение этого вопроса, от Вас или от Константина?

Предлагаю в «настройки страницы» схематика в поле «наименование» ввести «нестираемую» серую надпись «схема электрическая принципиальная», которая будет автоматически отображаться вместе с названием схемы. Кроме того, в поле «децимальный номер» ввести «нестираемую» серую надпись «Э3», которая будет приписана к децимальному номеру. При таком раскладе без "серых записей" в перечень уйдет только то, что нужно и ничего не придется отбрасывать.

А есть ли возможность разобраться с русификацией менеджера без помощи faa? Ведь нельзя признать удовлетворительным положение, когда судьба проекта зависит от отдельного человека. А если Андрей еще несколько месяцев не сможет ответить? Мало ли какие у него обстоятельства.
Может быть Жан Пьера насчет poedit поспрошать?

В прежние годы Жан Пьер прекращал вылизывание финального релиза в мае. Конечно, в этот раз все может быть иначе, но, возможно, стабильная сборка 4019 https://code.launchpad.net/~kicad-stable-co...rs/kicad/stable вышедшая в последний день мая все же финальная. В пользу данного предположения говорит еще и то, что данная сборка незамедлительно появилась на фтп Жан Пьера http://iut-tice.ujf-grenoble.fr/cao/
Так не пора ли выпустить сборку kicad_gost4019_Gdg4133_stable? (Gdg - GOST documents generator)
Предлагаю тестировать Gdg именно в стабильных сборках, которые и выльются в финальный ГОСТ-релиз, а уж потом пересесть на тестовые сборки (когда стабильный релиз целый год не будет изменяться). В противном случае стабильный релиз так и не получит необходимого тестирования в составе Gdg.

На самом деле с точки зрения полностью автоматической генерации КД на основе заполненной схемы сейчас это уже работает. После того как схема заполнена, все необходимое для полностью автоматической генерации уже хранится в атрибутах компонентов этой схемы, и генерация проходит полностью автоматически. То есть каждый раз, открывая вновь схему, КД формируется автоматически по нажатию одной кнопки.
Есть смысл обсуждать автоматизацию заполнения схемы.
Насчет логики незаполненности полей "Наименование" (как это сделано сейчас). Вы говорите можно делать отметку на бумаге на чем остановились при заполнении. Если говорить о заполнении по одному компоненту по порядку возрастания позиционного обозначения, да, можно было бы обходиться отметкой на бумаге. А теперь представьте другую ситуацию, заполнение выполняется групповым методом с выбором компонентов через CTRL. К примеру имеется 500 позиционных обозначений конденсаторов. 200 из них назначены групповым методом, например, назначены C1...C3, C54...C55, C81, C92, C94...C95 и т.д. Согласитесь, не удобно такое отмечать на листе бумаги.
Если рассматриваем вариант автозаполнения поля "Наименование", то я бы механизм незаполненности все-таки сохранил. Можно этот механизм незаполненности перенести в какой-то дополнительный флаг у компонента для этой цели (отвязать механизм незаполненности от поля "Наименование").
Также механизм незаполненности можно сделать включаемым/выключаемым настройкой из меню.

Считаю важным сохранить возможность модификации пользователем каждого из полей, в данном случае речь о поле Title (Наименование).
То есть каким бы ни был удобным или правильным механизм автозаполнения, нужно чтобы была возможность отредактировать поле компонента после автозаполнения, и данная информация сохраняется обратно в схему.
Насчет формирования отдельной таблицы сопоставления, разработки кода, который будет все это анализировать и преобразовывать, и опять же делать это для частного случая (анализ префиксов), пока не вижу, что это целесообразно.
Если заранее в библиотечном компоненте определять поле Title и назначать ему точное наименование согласно ГОСТ, которое и попадет в КД, не думаю, что это избыточная информация. Этой информации, с точки зрения вычислительной машины, в наличии нет.
Не думаю, что проблема - делать ГОСТ библиотеки согласно набору требований. Одна из рекомендаций - добавлять в библиотечные компоненты поле Title. Если поле Title было заранее добавлено, то для таких компонентов в большинстве случаев не нужно будет заполнять поле "Наименование". Если же поле Title не было добавлено в библиотечный компонент, ничего страшного, пользователь заполнит поле "Наименование" через менеджер компонентов. Либо добавит это поле в библиотечный компонент в хранилище, чтобы всем остальным пользователям было потом проще.
С одной стороны, хранилище с библиотеками и хранилище с исходниками программы - это 2 отдельных хранилища. С другой стороны, вижу смысл делать библиотеки так, чтобы по умолчанию они были максимально совместимы с программой. Зачем их делать изначально несовместимыми?

Будем делать это совместно с Константином. Нужно подождать. Сейчас не у всех есть время.

Да, хороший вариант.

Я могу уже сделать коммит с русификацией, но тогда файл kicad.po изменится примерно на 50%, а то и полностью, не смотря на добавление всего около 20 строк перевода.

Я не считаю сейчас, что менеджер компонентов и GOST-doc-gen являются завершенными. Сейчас есть еще ряд вопросов, которые нужно обязательно доработать. К примеру, русификация.
То есть делать попытки стабильного агрегированного релиза все-таки надо позже.

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

Так называемые «стабильные сборки», коих Жан Пьер наплодил огромное количество, по сути являются теми же тестовыми сборками с той лишь разницей, что в процессе их «вылизывания» ошибок в них становится все же меньше, чем в тестовых.
Здравый смысл мне подсказывает, что качественный финальный релиз может получиться только после серии тестов стабильных сборок в составе GOST-doc-gen, но, похоже, у Вас есть уверенность, что в таком тестировании нет необходимости и будет достаточно «прикрутить» отшлифованный GOST-doc-gen к финальному стабильному релизу и все будет чики-пуки. Не буду спорить, Вам виднее...

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

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

Сделал русификацию менеджера компонентов в ветке lp:~kicad-gost-committers/kicad/doc

На реальной сборке пока не проверял.

Тестирую генератор перечней и спецификаций.

Пока теряюсь в полях. ЕСКД изучал, но по перечню ничего не помню толком, кроме ГОСТ 2.701, в котором по этому поводу тихо. Обозначение электрорадиоэлементов где-то расписано в других стандартах? Если не сложно, направьте, пожалуйста.

А то, например создаю резисторы, а там есть просто чипы, а есть сборки. Ну к сборкам сделал приписку в типе "Сборка". Он мне выдал в перечне:



С разъемами тоже интересно. Разгруппировывает X, XT, XP, XS ... Т.е. ориентируется не на наименование "Разъем", а на префикс. Вот не знаю, правильно оно так или нет. Вроде делали всегда все в кучу.

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

Еще один момент. В форматках выравнивание в строках по верху, а не по центру.

Если речь о позиционных обозначениях, то ГОСТ 2.710-81.

Хотя ГОСТ 2.710-81 прямо не описывает резисторные сборки, но там есть понятие микросборки, которые обозначаются префиксом D.
Я обозначаю резисторы с префиксом R, а резисторные сборки с префиксом DR.
С другой стороны, диоды и диодные сборки обозначаю с префиксом VD.

В менеджере компонентов заполняю следующим образом для Вашего примера:
1) резисторы: поле "Наименование" Резистор, поле "Тип" 0805, поле "Номинал" 3 кОм, поле "Допуск" 5%
2) резисторные сборки: поле "Наименование" Резисторная сборка, поле "Тип" YC164, поле "Номинал" 1 кОм, поле "Допуск" 5%

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


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

Думаю можно сделать.

Новые форматки Константина Барановского в процессе.

Меня просто смутила строчка "Резисторы Сборка"
Александр, Вы можете сказать какие поля за что отвечают?
F0 - Позиционка
F1 - Значение
F2 - Посадочное место
F3 - вроде ссылка на документацию.
F4..
А вот остальные, которые Вы используете для хранения информации GOST-Tools, если это не сложно.

Вы не планируете менять расстановку полей, она конечна?

Я тут выпадал из процесса на два месяца.
Может кто подскажет, когда супостаты выпилили генерацию нормального BOM в csv из eeschema?
У меня уже костыли были прикручены на перловке: из csv в tex, потом через eskdx -
на выходе готовый перечень с рамочкой.
А тут бац, и ссылка на доку с xml-ями

UPD: Нашел. Окончательно выпилили в bzr4151. Слов нет, одни буквы.

У меня предложение назрело:
добавить файл русского перевода в lp:~kicad-gost-committers/kicad/kicad и слегка поправить CmakeLists.txt,
чтобы он сразу добавлялся в сборку.
А из lp:~kicad-gost-committers/kicad/doc директорию internat с содержимым убрать.

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

Намеренно не сделал привязку к номерам F.
Существенно только имя атрибута, при этом номер F может быть любой. Сделал так, чтобы гарантировать стабильность. К примеру, если кто-то по ошибке сдвинет атрибуты вверх/вниз в редакторе свойств компонентов в eeschema, это не отразится на работоспособности генерации КД.
Имена дополнительных атрибутов (помимо Reference и Value) используются следующие:
Title - Наименование
Type - Тип
SType - Подтип
Precision - Допуск
Note - Примечание
Designation - Обозначение
Manufacturer - Производитель

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

В ветке lp:~kicad-gost-committers/kicad/kicad мы реанимировали BOM.

С одной стороны - хорошая идея.
Но вижу следующие моменты:
1) файлы kicad.po и kicad.mo действительно меняются часто. В основном проблема с kicad.mo, это бинарный файл. Каждый такой коммит увеличивает размер хранилища на его размер (дельта каждый раз максимальная).
2) задумывал, что группа kicad-gost-committers ориентирована не только на русскоязычных разработчиков и пользователей, но и на интернациональных. Пока не вижу смысла не давать не русскоязычным разработчикам участвовать в этой ветке. Данная ветка - алтернатива ветке lp:kicad.

То есть давайте обсудим все плюсы и минусы, и решим.

Я бы предложил следующую схему:
1) коммитим русскоязычный перевод только в lp:~kicad-gost-committers/kicad/doc
2) изредка подтягиваем интернациональный перевод из lp:~kicad-developers/kicad/doc обратно к себе в lp:~kicad-gost-committers/kicad/doc

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

Идея faa мне понравилась. Файл перевода необходим для работы программы, поэтому логично его держать вместе с ней. Ну, типа как dll.

А правда, кто знает почему бинарные файлы kicad.mo коммитят в хранилище документации?


Добавил бы еще пункт:
3) добавить сборку перевода, и возможно, документации в процесс сборки самого KiCad (в CMakeLists.txt) как предлагает Андрей. Единственное, если держать документацию и перевод в отдельном хранилище как сейчас, то в процесс сборки KiCad добавить заливку хранилища в директорию .downloads-by-cmake по аналогии как это было сделано для boost.
То есть процесс сборки был бы прозрачным, не нужно отдельно скачивать хранилище документации, отдельно его собирать. Сделать, чтобы это делалось автоматически.

Наверно, чтобы не перепутать - видно соответствие po/mo с точностью до байта.

Хотелось бы, чтобы вся эта автоматика (boost/doc) не закрывала возможность после пересобирать программу в offline, если понадобится.

PS. Может быть в папке GOST-doc-gen наряду с шаблонами КД надо разместить и файлы шрифтов opengostfont.

При описанном подходе не должно быть разницы по сравнению со старым подходом в плане сборки в offline.

Да, так и сделаем.

Вот чтоб не перепутать, как раз нужно избегать дублирования информации. Если хранить только *.po, то *.mo в любой момент можно получить гарантированно актуальный.

Здесь получается, что каждый должен иметь редактор/транслятор переводов и желательно одной версии.

Зачем?!

может потому что poedit при сохранении .ро автоматом обновляет .mo ?
наверно можно обойти фильтрами bzr (исключением .mo из репозитория). Но в таком случае при компиляции бинарников нужны утилиты gettext для конвертации РО-МО.

Не совсем понятно в чём такая сложность хранить оба файла?
Тем более что при обновлении локального репозитория из внешнего (launchpad) грузятся только изменённые файлы.

При генерации перечня вместо слова "Соединители" пишет " Соединительы" ))

Микросхемы разделил мне ... DA отдельно DD отдельно. Может все-таки сортировать по полю "Тип", потом уже внутри по позиционке.

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

Нужно "поднимать" ГОСТ.

Да сложности наверное особой нету, просто неаккуратненько это как-то.
Вот вчера, собирал я кикад. lp:~kicad-gost-committers/kicad/kicad занимает 280Мб , а lp:~kicad-gost-committers/kicad/doc - 600Мб! Я чуть не закипел, пока дождался окончания закачки%)
А всё почему? Потому, что в kicad не хранят результаты компиляции (для исходных кодов программ это считается нормой). А в doc - хранят и исходники документов, и сами документы ("в чём такая сложность хранить оба файла" ). Вот и пухнет репозиторий, как на дрожжах.
Меня что добило: получается, что ради одного файла перевода я вынужден качать 600 метров. Разве это нормально?
(Места не жалко, жалко времени.)

Насчет бинарных файлов в хранилище. Мое мнение:
1) бинарные файлы тоже полезно хранить в хранилище с точки зрения учета и надежности хранения самих файлов. Это касается бинарных релизов и документации по крайней мере. Насчет надежности хранения говорю по крайней мере за git. bazaar скорее всего тоже хранит файлы надежно. Например git выполняет контроль на основе hash. Также, если кто-то или что-то не авторизованно в локальной копии затерло/изменило/удалило файл, то команда status показывает, что файл изменился, и можно спокойно его восстановить из хранилища.

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

3) плохо мешать исходники программы с бинарными файлами, особенно большого размера, например релизами программы (в каких-то ситуациях могут быть исключения, особенно, если файлы небольшого размера, меняются редко и в них есть особая необходимость):
- если уж в случае хранилища для бинарных файлов можно смириться, чтобы работало медленно, то для хранилища с исходниками программы с этим нельзя смириться, где выполняются рутиные операции (log, commit, diff, merge...)
- в случае коммерческих проектов важно хранить исходники программы и ее бинарные релизы в разных местах с разными правами доступа (ну в случае KiCad это не имеет силы)

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

Добавил обработку мягкого знака в конце слов. Такие слова теперь не нужно будет харкодить в словаре словоформ.

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

Константин, у меня наконец-то появилось время попробовать Ваш скрипт. Скачал с https://launchpad.net/kicadbom2spec свежую версию — 2.3 и стал все делать по описанию. Хочу еще раз отметить добротность описания — все понятно даже для самого-самого начинающего.
Во время установки всех компонентов все происходило именно так, как описано. Однако, результат отличается: не удается запустить kicadbom2spec.pyw, т. е. при двойном клике по файлу на долю секунды возникает значок начавшегося процесса и все...
Константин, какие еще действия нужно предпринять, чтобы получить результат?
Имеющиеся различия у меня с тем, что в описании:
- у меня не ХР, а Вин7х64,
- загрузился python-3.3.2, а не 2.7.4, как в описании. (потом переставил на python-2.7.5 и все равно не запускается)
Заодно еще доп. Вопрос: какой шрифт лучше opengostfont-otf-0.3 или opengostfont-ttf-0.3 и для какого случая? Стоит ли установить все шрифты сразу OpenGostTypeA-Regular.otf, OpenGostTypeB-Regular.otf, OpenGostTypeA-Regular.ttf, OpenGostTypeB-Regular.ttf? Какие шрифты стоят у Вас?

Aldan, если третий питон не удален из системы, то, возможно, скрипт пытается запуститься с его помощью. Если не сложно, проделайте, пожалуйста, ряд несложных операций, чтобы убедится что проблема именно в этом.
Нужно открыть с помощью любого текстового редактора файл kicadbom2spec.pyw и в первой строке явно указать версию питона:

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

На счет шрифтов. Для оформления я использовал один шрифт - OpenGostTypeB-Regular.ttf, его будет достаточно. OTF или TTF - дело вкуса. OpenTypeFont (OTF) новее чем TrueTypeFont (TTF) и поддерживает больше функций и разных примочек. Но это скорее важно для дизайнеров шрифтов, а конечный пользователь разницы не заметит. TTF выбрал в сило того, что на Windows используются шрифты, в основном, этого типа.

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

Добавил двоечку, сохранил, запустил.., не пошло. Константин, а в каком направлении думать, ведь этот скрипт работал у других, так? Так почему мой случай требует какого-то особого подхода?
И еще, Константин, а не может odfpy, который был установлен при третьем питоне мешаться? Вроде глупая мысль, но решил спросить? Если что, то просто повторить процесс установки, но при втором питоне?
-----------
Константин, моя догадка сработала: я переустановил odfpy и скрипт стал запускаться, причем и без дополнительной двоечки. Так что все беды были от того, что я не зная засады от третьего питона установил именно его, думая, что он самый-самый Чуть попозже буду тестировать дальше.
-=-=-=-=-=-=-=-=-=-=-=-
Константин, предлагаю небольшой отчет о моем кратком тестировании Вашего скрипта.
Прежде всего, вспоминая ситуацию когда я не мог запустить скрипт, предлагаю во избежание ее повторения создать ехе-файл, запуск которого инициирует последовательную установку всех компонентов — python, odfpy и шрифт — автоматически.
В развитие этого предложения можно питон не устанавливать, а использовать тот, что в ЛибреОфисе. Это не будет интеграцией скрипта в Кикад, но будет дружественной автоматизацией процесса установки.

Порадовало Ваше изящное решение брать информацию о компонентах из схемы. Действительно, все схемные элементы имеют обозначения согласно ГОСТ, что позволяет однозначно определить к какой группе они относятся. Я в своей библиотеке сгруппировал компоненты при помощи префиксов по этому же самому ГОСТ и предлагал AVL использовать их для автозаполнения в GOST-doc-gen, а Вы сделали все еще изящнее — точно такую же информацию взяли прямо из схемы. В результате спецификация в Вашем скрипте получается по нажатию всего лишь одной кнопки — это здорово. Однако, непонятно, почему же Вы не пошли дальше и не ввели названия групп компонентов? Ведь С — это конденсаторы, R — резисторы и т. д., так почему же не ввести автозаполнение наименования таких групп?

В вашем скрипте, как и в GOST-doc-gen не решена проблема отбрасывания надписи «схема электрическая принципиальная». На мой взгляд автодописывание «Ф», «Гн», «Ом» нужно сделать отключаемым т. к. не всегда это к месту. Неплохо бы ввести лист регистрации изменений.

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

Обнаружилась странность с выводом на печать: я сформировал документ на 3 листах и попробовал вывести его на виртуальный pdf-принтер, так вот, первый лист почему-то бесследно теряется и не хочет распечатываться.

Словом, Ваш скрипт — огромный шаг от ВОМ к цивилизованной текстовой документации, но расти еще есть куда и даже очень.

Завершен переход на новые форматки Константина Барановского. Ветка lp:~kicad-gost-committers/kicad/GOST-doc-gen-new-templates закрыта.
Актуальная ревизия 4152.

Пока не предусмотрена автоматическая установка шрифтов (нужно думать как вообще это сделать).
Комментарий Константина по ручной установке шрифтов:

Копировать нужно только один файл, а именно, файл из дерева исходников: kicad_src_root/eeschema/GOST-doc-gen/templates/OpenGostTypeB-Regular.ttf

AVL, я решил глянуть как продвигается дело с GOST-doc-gen для чего установил самую свежую из доступных сборок kicad_gost_commiters_testing_bzr4146, сформировал перечень и обнаружил подтверждение пословице «быстро сказка сказывается, да не быстро дело делается», что и ожидаемо, т. к. времени прошло немного. По этой причине я не буду касаться того, что мы уже обсуждали, а сделаю лишь некоторое дополнение.
Итак, о перечне. Начинается мой перечень с конденсаторов и сразу же бросается в глаза то, что в поле «наименование» перед каждым значением конденсатора стоит «с_сар», а предваряет всю эту группу конденсаторов шапка «конденсаторы с_сар». Поскольку так быть не должно, попробую дать свою трактовку полученного результата.
Ранее я писал, что библиотека mixture.lib содержит обобщенные названия компонентов, которые в конкретной схеме приобретают совершенно конкретные значения.
Как образовалось наименование «с_сар»? Изначально в кикадовских библиотеках были графические обозначения двух типов конденсаторов постоянной емкости: «сар» — конденсатор и «сарр» — конденсатор поляризованный, т. е. электролитический. Позже, когда я всем компонентам раздал префиксы по ГОСТ из этих двух обозначений «сар» и «сарр» получились «с_сар» и «с_сарр». Таким образом, префикс «с» говорит о том, что это конденсаторы, а «сар» и «сарр» позволяет отличить обычный конденсатор от электролитического. Все это важно только до момента выбора компонента из библиотеки. Далее, в самой схеме, различение обычного конденсатора от электролитического обеспечивает его графическое изображение и никакие «сар» и «сарр» не применяются и на схеме Вы их не найдете.
На схеме у каждого конденсатора имеется обозначение «с» с порядковым номером, что говорит о принадлежности к группе конденсаторов, а также его номинал.
Поскольку перечень формируется по конкретной схеме на которой нет никаких «с_сар», непонятно откуда же они и для чего в нем появляются? То же самое происходит и со всеми другими компонентами из библиотеки mixture.lib.
Для примера, в скрипте Константина Барановского используется информация прямо из файла схемы и по этой причине такие накладки исключены. Может быть и Вам сделать так же?
И еще, повторяю свою просьбу о написании хоть самого-самого краткого руководства пользователя GOST-doc-gen, чтобы понимать тонкости работы и делать все правильно.