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

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

Вот как раз для этого и должна быть стабильная сборка с гарантированным и проверенным результатом, чтобы всегда можно было к ней вернуться. Признаюсь, что хоть я и перестал доверять тестовым сборкам после неудачи в прошлом, но время от времени пользуюсь ими с большим удовольствием, потому что знаю, что у меня есть «тыл» - проверенная стабильная сборка.
Словом, стабильные релизы должны появляться, иное положение дел просто утопия.
Еще несколько лет назад все сборки на нашем фтп выкладывались в двух исполнениях — с установщиком и просто набор обновляемых файлов, как сейчас, причем делалось это регулярно. Потом сборки стали появляться гораздо реже и преимущественно только в виде обновляемых файлов. Однако, стабильные релизы все же всегда выкладывались.
В последнее время сборки для винды стали появляться еще реже и 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 они попали на наш фтп. То, что они будут еще где-то находиться меня совершенно не заботит, а только радует, если кому-то еще пригодится. Так что моего согласия можно было и не спрашивать: у меня возражений нет.

Сообщение отредактировал Aldan - May 28 2013, 21:00

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

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


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

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

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


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

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