AVL: Александр, таким образом можно сказать что полная поддержка старых компонентов невозможна, потому что алгоритм не может заполнить автоматически поле Type, т.к. не знает, с чем имеет дело микросхемы/транзисторы/диоды или пассив, и т.д. Вроде именно поэтому я не стал делать Type = Value в этой части. В таком случае может быть добавить обработку на Refdes, чтобы это работало хотя бы для классических случаев: C, R, L. Т.е. определить круг компонентов, у которых однозначно есть номильное значение Value: C, R, L, которое не следует копировать в Type, а во всех остальных случаях было бы наоборот. Но полной совместимости все равно не получить. Делать это или нет? Я бы не стал делать, или сделал в самом упрощенном варианте, просто потому что у всех те же сборки резисторов обозначаются по-разному.

Выше я писал о проблеме с CvPCB. Т.к. Value больше неинформативно, возможно ли заменить там отображение поля Value на строку, идентичную GOST-Tools?

Возможна ли синхронная работа GOST-Tools с EESchema? Чтобы при указании конкертного компонента, в EESchema на него перепрыгивал курсор, как это сейчас реализовано в CvPCB и NewPCB. Это было бы удобно при заполнении полей, чтобы не заполнять их во время составления схемы. Последнее время я так и делаю, потому что в GOST-Tools заполнить номиналы теперь можно гораздо быстрее, однако долго ищется сам компонент на схеме для определения его роли.

Есть поле Designation - Обозначение, на данный момент я пишу сюда маркировку производителя. Актуально для резисторов CR0805.. или конденсаторов GRM21... Такова ли на самом деле функция этого поля?

Отвечаю пока частично.
Привязываться к C, R, L по вопросу заполнения поля Type, наверно, не всегда поможет.
Не могу утверждать, что это правильно, но я в некоторых случаях обозначаю конденсаторы не в виде тип+подтип+номинал+допуск, а в виде тип. Вот для сравнения:
1) 0805-X7R-50 В- 0,1 мкФ ±20 %
2) GRM43QR72J683KW

2-й случай - конденсатор фирмы Murata - здесь я решил вписать полное обозначение производителя, чтобы однозначно определить что это специфический конденсатор, который я нашел только у Murata.
Можно, конечно, и по другому было поступить - представить в виде GRM43-X7R-630 В-0,068 мкФ ±10 %, а в поле примечание указать, что это GRM43QR72J683KW. Скорее так было бы правильнее.

Однако, если вариант как в пунте 2 тоже может иметь смысл, то автоматом решать, что делать с полем type, в этом примере не получится (может еще можно придумать ситуации?).

Хочу подчеркнуть, что все, что сейчас обсуждаем в плане полей Value и Type - это только проблема как придумать адекватную автоматическую обработку поля Value уже ранее заполненной схемы старым способом. Имеется в виду, что GOST-doc-gen при правильном заполнении полей, правильно формирует КД. Конкретно по данной проблеме, поле Value должно содержать номинал, а дополнительное поле Type должно содержать тип (которое при необходимости делается видимым на схеме). Мешать все в кучу нельзя (помещать значение типа в поле Value).

Теперь, если все же обсуждаем как сделать автоматическую корректировку ранее заполненных схем, то пока вижу следующие варианты:
1) (не будет работать для приведенного примера с GRM43QR72J683KW) добавить пункт меню в менеджере компонентов, по выбору которого появляется диалоговое окно, в котором указываем префикс позиционного обозначения компонентов. Для компонентов с указанным префиксом по нажатию кнопки будет выполнен переброс поля Value в поле Type.
2) (полуавтоматический способ) предусмотреть дополнительный атрибут-флаг FixType у компонентов. В менеджере компонентов групповым методом выбрать интересующие компоненты и выставить им флаг FixType. В результате для таких компонентов GOST-doc-gen будет интерпретировать поле Value в качестве типа.

Пока все идеи, которые предлагаются, являются только лишь латанием дыр для eeschema.
Чтобы сделать все красиво, придется исправлять ранее обсуждаемый французский подход в eeschema, и получается, в cvpcb тоже.
Если пойти по пути исправления французского подхода в корне, можно попробовать обратиться к Brian Sidebotham по поводу его предложения. Вдруг у него этот патч на полке все это время лежит.

Монтажники никогда не задавали Вам вопрос, что такое GRM...? А мне часто . И какой толк от перечня, в котором указан частный код по кодировке производителя? Это хорошо что Вы знаете, что такое GRM21 ... Именно поэтому поле обозначение протрактовал как ход конем для таких случаев. Снабженцу проще всего забить GRM21... и купить. Наладчику нужно знать емкость и прочие характеристики. Монтажнику тоже лучше расшифровать. Поэтому мои обозначения выглядят как-то так.

Чип 2512 100кОм ±5 % (RC2512JK-07100KL)
Супрессор биполярный SMA 18В (SMAJ18CA)

То, что указано в скобках - как раз поле обозначение, он же код производителя.

По старым схемам: Их все равно нужно будет так или иначе редактировать. Благо, сделать это не долго. Весь этот разговор со старыми схемами родился из-за маленькой неприятности Type = ChipName, что вроде сайчас решится. Так сильно упираясь в поддержку старых схем можно зависнуть на этом и прекратить всякое движение вперед.


Имеете в виду тотальную правку кодов во всем KiCAD? Реально ли это нужно?

Константин, очень рад, что Вы снова сможете продолжить свою работу!
Игры с диапазоном печати ни к чему не приводят и я думаю, что все дело скорее всего в «кривой» установке odfpy. Напомню, что я сначала по незнанию поставил питон3, а потом собрал odfpy. Далее, понял, что нужен питон2 и установил его, но скрипт не запускался.
Далее, мне пришла мысль, что, возможно, odfpy собранная при питоне3 как-то влияет на запуск. Пересобрал odfpy и все стало запускаться.
Так вот, сейчас меня меня гложет мысль, что именно odfpy все портит, т. к. МсОфис проблем с выводом листов не имеет.
Константин, более подробный ответ с результатами экспериментов смогу предоставить только вечером, скорее ближе к ночи, а сейчас нет никакой возможности.
Было бы здорово, если бы Вы написали мне, как можно «почистить» odfpy и все постараться установить с чистого листа. Тогда все последующие эксперименты могут и не понадобиться.

Добавил экспериментальную поддержку полей Chip Name, Value и Type в CvPCB в ревизии 4158. Данная доработка только для нового формата netlist (s-expressions). Пока не вижу смысла добавлять это для старого (legacy) формата netlist. Если все-таки есть смысл, дайте знать.

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

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

Не помню, поле Обозначение делал по аналогии с генератором перечня Брагина или сам его решил ввести в свое время. Данное поле использую для указания обозначения спецификации устройства или механической детали. У меня есть проекты схем соединений Э4, представляющие собой систему из набора печатных плат, в которых я в качестве компонентов имитирую платы. То есть в поле Обозначение при этом вписываю обозначение спецификации конкретной платы, входящей в состав данной схемы Э4. Обозначение в формате АБВГ.000000.000. Соответственно это позволяет мне генерировать КД для таких сборок из устройств автоматом.
Также я предполагал, что поле Обозначение может использоваться для ввода ТУ.

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


Насчет тотальной правки пока не известно. Если рассматривать потенциальный патч Brian Sidebotham (на самом деле может быть патча то и нет), то я не видел его содержание. Пока не вникал какой объем правки при этом может быть.

Насчет архитектурных ошибок. Обычно так и бывает. Латают, латают, причем при этом хаос разрастается с каждым разом, и образуется ком проблем. Рано или поздно, все равно принимается решение сделать тотальную переработку с целью улучшения архитектуры. Бывает часто и так, что проект в каком-то имеющемся виде просто умирает.
Насчет P-Cad все помнят?

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

Посмотрел ГОСТ 2.105-95 и ГОСТ 2.106-96. В ГОСТ 2.105-95 все-таки указано следующее:

Про возможность применения ГОСТ 2.702-2011 для текстовых документов не нашел нигде. Если все-таки кто-то найдет информацию о разрешении не указывать "Ом" и "нФ", а также замене "мкФ" на "мк", "кОм" на "к", "МОм" на "М", "ГОм" на "Г" в текстовых документах, пожалуйста, дайте знать.

Пока в документации на менеджер компонентов + GOST-doc-gen пишу следующую формулировку:

Только косвенную, по примерам.
Электрические схемы.pdf Рисунок 11.21, в. "МЛТ-0,5-51к±5%"
Чертежи изделий с электромонтажом.pdf Рисунок 6.17, а. "МБМ-160-0,1±10%"
Общие сведенья о схемах.pdf Просто, до кучи.

Не уверен, но источник вроде: Разработка и оформление конструкторской документации РЭА: Справ.пособие/ Э.Т. Романычева,А.К. Иванова, А.С. Куликов, Т.П. Новикова. – М.: Радио и связь,- 1984, 256 с.

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

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

Как я уже написал, игры с диапазоном печати ни к чему не привели. Тогда я взял в руки бубен и решил все переустановить еще раз, а то ведь то питон правил, а потом отдельно odfpy. Распечатке первых листов это не помогло, а вот проект с названием из трех букв стал конвертироваться без проблем. Все же одной проблемой меньше

Что касается пропадения нескольких горизонтальных разделительных линий, то это оказался глюк ЛибреОфиса при предварительном просмотре перед печатью. Сама печать проходит без этих артефактов.

Я специально зарегистрировался на https://launchpad.net и зашел к Вам на https://launchpad.net/kicadbom2spec где нашел Ваш адрес электронной почты. Выслал на него часть проекта полуторагодовалой давности. Предлагаю дальнейшее общение продолжить по переписке. Считайте, что я обратился к Вам не через форум, а прямо на launchpad. Так будет гораздо удобнее.

Сделал хоть какую-то документацию для менеджера компонентов и GOST-doc-gen. Пока без описания работы с исполнениями и комплектами.

Ревизия 445 ветки lp:~kicad-gost-committers/kicad/doc

doc/help/ru/GOST_Tools.pdf
doc/help/ru/docs_src/eeschema/GOST_Tools.odt

ссылка для скачивания

Это делается оптимизация атрибута Type. Оптимизация заключается в том, что если по факту после работы с менеджером компонентов атрибут Type оказывается пустым, то он удаляется из-за ненадобности из компонента. Причем в EESchema используется такая же логика. Если пользовательский атрибут становится равен пустой строке, то атрибут удаляется самой EESchema.

По поводу автоматической очистки поля Value пока не вижу красивого решения. Надо еще думать.
А вот по поводу принудительного создания Type и отмены его оптимизации согласен. Здесь получаем преимущества:
1) обеспечиваем прозрачность работы с полем Тип
2) даем возможность делать видимым атрибут Тип (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)

Таким образом, будем действовать поэтапно.
На данном этапе предлагаю пока только сделать добавление атрибута Type равное Chip Name, если до этого атрибут Type отсутствовал.
В этом случае в целом не ломаем все, что было раньше (схемы ранее введенные / импортированные из P-Cad как работали с GOST-doc-gen так и продолжат работать).
Но зато получаем преимущества в приведенных выше пунктах 1 и 2.

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


Оно должно очищаться только в случае, если совпадает с ChipName. Это означает, что компонент только вставлен в схему и пользователь еще не определил значение. На данный момент целесообразно было бы делать это только для новых компонентов, в которых есть поля для GOST-Tools.

Может быть не отказываться от автоудаления пустых полей в компонентах, хотя бы со стороны GOST-Tools? Это конечно раздует файл, но зато при редактировании компонента, можно ручками уже набрать нужное значение, если лень лезть в GOST-Tools.

В EESchema оно у меня ругнулось, что ввожу пустое значение и предупредило, что если все-таки введу пустое значение, то атрибут будет удален.
Также странная ситуация с Вашим примером, в котором поле Value в каком-то случае вообще не отображалось в свойствах компонента.
Ну здесь проще сделать так, как это ожидает EESchema получить. В случае пустой строки GOST-doc-gen сделаю, чтобы не пустую строку обратно в схему сохранял, а символ "~".
Это пока касается атрибутов Value и Type.

А как менеджер компонентов сможет различить где старые, а где новые? И что такое старые, что такое новые?

Я вот думаю, а что нам мешает (только на уровне кода EESchema) в момент добавления сделать все как надо? А именно, при добавлении нового компонента прямо в коде EESchema сделать, чтобы атрибут Value по умолчанию устанавливался в "~", и по умолчанию сделать чтобы автоматом добавлялся атрибут Type равный значению Chip Name?
При этом даже совместимость ни с lp:kicad ни с существующими схемами никак не пострадает.
Данная мера после ее принятия наладила бы нормальный режим работы при разработке новых схем и редактировании имеющихся схем в случае редактирования атрибутов через GUI EESchema.
Есть ли у такой меры подводные камни?

Первое предложение не понял. Имеется в виду, чтобы все 8 атрибутов, которые используются менеджером компонентов создавать безусловно, даже если они пустые?
Пока уверенность есть, что нужны всегда поля Value и Type. Насчет остальных полей и так и так вроде хорошо. Надо тогда продумать какие плюсы и минусы у каждого из подходов и выбрать тот, у которого плюсов больше.

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


Были бы, если бы библиотечный компонент содержал предопределенное Value. Сейчас попробовал сделать это. Переименовал поле Value и, в итоге, он сохранился уже по переименованному полю Value.
Сделал еще финт ушами, поправил прям в библиотечном файле через текстовый редактор ChipName и Value. В итоге при просмотре через Viewer отображается все нормально Резистор такой то, сопротивление 1 кОм, однако после добавления на схему он заменяет поле Value на ChipName. Вывод: если сменится подход в самом редакторе библиотек, то возможно затирание предопределенного значнения. Поэтому нужна проверка ChipName==Value.



Пустое поле под документацию лежит и не жужжит. Они его застолбили, и возможная причина тому, что всего полей может быть 11. Из них 4 уже заняты. Так написано в описании к форматам файлов. Т.е. если кто-то еще захочет добавить какие-то свои поля, то они просто могут не сохраниться или наоборот они будут, а GOST-Tools какие-то свои поля не сохранит. Возможно сейчас формат поменялся. Но раньше такое ограничение было.

С учетом имеющейся картины, появилась еще идея алгоритма №2. Однако ни о какой прозрачности для пользователя при таком подходе речи не идет. Но зато судя по анализу всех рассматриваемых тестовых случаев, работает!

На этапе конвертации pcad2kicad сделаю следующую обработку:

Тогда это позволит применить алгоритм №2 (см. ниже).

Тестируемые случаи с учетом доработки в конвертере pcad2kicad

импортированные схемы из P-Cad:
1) ChipName = "SN74HC00D", Type = "SN74HC00D", Value = "~"
2) ChipName = "К73-17", Type = "К73-17", Value = "0,1 мкФ"
3) ChipName = "7400", Type = "SN74HC00D", Value = "~"
4) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

оригинальные схемы KiCad сразу после добавления компонента в схему (без каких пока еще корректировок полей)
5) ChipName = "7400", Value = "7400"
6) ChipName = "C", Value = "C"

оригинальные схемы KiCad при использовании в режиме навязанного кривого подхода
7) ChipName = "7400", Value = "SN74HC00D"
8) ChipName = "C", Value = "0,1 мкФ"

оригинальные схемы KiCad при использовании в режиме выправленного подхода
9) ChipName = "7400", Type = "SN74HC00D", Value = "~"
10) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"

тестируемый алгоритм №2 под кодовым названием "взрыв мозга"
Здесь для понимания:
а) имена атрибутов на английском (ChipName, Type, Value) - это те атрибуты, которые хранятся в схеме.
б) имена полей на русском (Тип, Номинал) - это те поля, которые отображаются/редактируются в менеджере компонентов, и которые в результате поступают на вход генератора GOST-doc-gen.

Результирующие поля после обработки алгоритмом
1) [ChipName = "SN74HC00D", Type = "SN74HC00D", Value = "~"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
2) [ChipName = "К73-17", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK
3,9) [ChipName = "7400", Type = "SN74HC00D", Value = "~"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
4,10) [ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK
5) [ChipName = "7400", Value = "7400"] => [Тип = "7400", Номинал = "~"]: OK
6) [ChipName = "C", Value = "C"] => [Тип = "C", Номинал = "~"]: OK
7) [ChipName = "7400", Value = "SN74HC00D"] => [Тип = "SN74HC00D", Номинал = "~"]: OK
8) [ChipName = "C", Value = "0,1 мкФ"] => [Тип = "0,1 мкФ", Номинал = "~"]: FAILED
Однако в пунте 8 в любом случае, чтобы сформировать КД нужно также указать какого же все-таки типа конденсатор. После добавления типа (через схему добавить и назначить атрибут Type, либо задать поле Тип через менеджер компонентов) будем иметь следующий тестовый случай:
8a) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"
Тогда результирующие поля для данного тестового случая после обработки алгоритмом будут:
8a) [ChipName = "C", Type = "К73-17", Value = "0,1 мкФ"] => [Тип = "К73-17", Номинал = "0,1 мкФ"]: OK!

Да, реально взрыв мозга. Зачем это надо?
Вы правда собираете генерировать перечень, в котором будет просто указана емкость 0.1 мкФ? Или все же у Вас это запись для примера?

Еще реторический вопрос: чего всегда больше в проекте? Пассива или микросхем? отсюда приоритет можно расставить поля Type или Value.

Там где нельзя определить тип автоматически, лучше заполнить его Type="Не определен" и подсветить такие компоненты красным цветом.

Это в продолжение для "Предлагаю решение, которое скорее всего устроит всех..." Я пока только не знаю кто такие все
По крайней мере для всех тестовых ситуаций, которые взял в рассмотрение (может еще какие-то еcть?), алгоритм №2 выглядит, что работает.
Но еще подумав, понял, что сделать нормальный ввод поля Тип с помощью менеджера компонентов для тестового случая 8 - это еще одна головоломка и добавление костылей в код.

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

Нет, я не собираюсь генерировать перечень, в котором будет просто указана емкость 0.1 мкФ
Тестовый случай 8 - это промежуточное состояние схемы до того как она будет доведена до состояния 8а.
Если я правильно понял, есть те, кто заполняет только атрибут Value. Это как раз случаи 7 и 8. Теперь, если эти люди хотят сформировать КД, то для случая 8 им нужно сделать так, чтобы появился атрибут с заполненным типом компонента. Это можно сделать либо посредством добавления/заполнения атрибута Type в свойствах компонента через GUI EESchema, либо, если прикрутить дополнительные костыли, то это будет возможно в менеджере компонентов.

Да у меня уже такое чувство, что только внедрение искусственного интеллекта в менеджер компонентов может как-то сдвинет ситуацию

На тот момент было два человека Я и Aldan.

Aldan смущала склейка ChipName + Value в документации. Но это так или иначе вылечится.
Меня смущала непрозрачность, связанная с полями Type и Value. И до сих пор смущает. Повторюсь. Пользователь видит некие значения в менеджере GOST-Tools, и эти значения однозначно должны находится в соответствующих полях внутри компонента. В предложенном втором алгоритме нарушается эта идеология. Появляется Русский подход



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

Я лично отдаю предпочтение прозрачному простому подходу, пусть даже за счет доработок в самой EESchema.
А вот алгоритм №2, хоть и справляется успешно с интерпретацией запутанного кома проблем, но пусть будет наглядным примером сути обсуждаемой ситуации.
Надеюсь пользователи посмотрят на него, ужаснутся, и не будут настаивать идти таким путем

За прозрачность . Александр, на следующей неделе (во второй половине) буду заполнять схему примерно из 250 элементов с целью получить перечень. Конденсаторы и резисторы в большинстве своем там уже с новыми полями. Если будут какие-то решения конечные по алгоритму, и желание протестировать его в боевых условиях, я готов.

С учетом имеющейся картины, даю обновление действий по первому этапу.

I) На этапе конвертации pcad2kicad сделать следующую обработку:

Данная мера позволит уйти от необходимости чтения атрибута Chip Name в менеджере компонентов.

II) сделать принудительное добавление атрибута Type равный "~", если до этого атрибут Type отсутствовал.

Итоговые преимущества:
1) обеспечиваем прозрачность работы с полем Тип
2) даем возможность делать видимым атрибут Type (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)
3) уход от необходимости чтения атрибута Chip Name менеджером компонентов ("Aldan смущала склейка ChipName + Value в документации." Теперь явной такой склейки не будет. Однако, если кто-то так и будет продолжать вбивать значение типа компонента в атрибут Value, то GOST-doc-gen, как я объяснял, не будет корректно генерировать КД в целом, не смотря на то, что отдельно взятые строчки в документах будут выглядеть корректно).

Реализовал данную логику в ревизии 4162.
Однако, стало видно недостаток. Из-за того, что убрал чтение Chip Name менеджером компонентов, теперь пострадали компоненты-псевдонимы. Таких компонентов-псевдонимов достаточно много даже в стандартных библиотеках KiCad.
Вернул начальную инициализацию атрибута Type значением из Chip Name. Соответственно доработку пункта I) для pcad2kicad тоже отменил.

Если вдруг кому-то все-таки захочется атрибуты Type затереть пустыми строками (я правда так и не в состоянии понять зачем так делать), то это можно сделать в менеджере компонентов групповой операцией: выделить все компоненты через SHIFT и стереть содержимое поля Тип.

Таким образом, нововведение заключается в следующем:
1) при открытии менеджера компонентов, если у компонента нет атрибута Type, то он принудительно создается, и ему делается начальное присвоение значения атрибута Chip Name. С этого момента атрибут Type больше никогда не удаляется менеджером компонентов, даже если поле Тип было очищено. Также с этого момента поле Тип полностью прозрачно по отношению к атрибуту Type
2) атрибут Value/Type теперь становится равен "~", если поле Номинал/Тип было стерто в менеджере компонентов

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

AVL. Собрал 62ю ревизию, проверил. Да, все работает так, как Вы написали. Автоматом появляется поле Type. Поле Value очистить не долго. Благо есть групповое выделение. Айс
Посмотрел CvPCB. Длинновата запись, но это лучше чем было до этого.

Странный баг какой-то. Если добавляю пользовательский атрибут через GUI EESchema, то опция Visibility работает. Если же атрибут добавляет менеджер компонентов, то опция Visibility через GUI EESchema не реагирует. Надо будет разбираться.

AVL

Но, с другой стороны, в примере

(по ГОСТ 2.702-2011) нет единиц "Вт", которые тоже надо указывать.
Создаётся впечатление, что пишут скорее данные производителя (код производителя).

Может в данном случае интерпретация такая, что тип (марка) выглядит как "МЛТ-0,25"?

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

Сейчас повспоминал 2й курс. Когда я впервые делал перечень, я задал этот вопрос в кабинете стандартизации мегокрутой тетке. На что она мне дала ТУ на резисторы Р1-12 и сказала читай. И там было написано, как их обозначать. (с) Р1-12 - 0.125 - 30 кОм ± 5 % - М - ЛЛЯР.434110.005ТУ И это логично. В перечне есть обозначение элемента и есть ТУ, в соответствии с которым можно это обозначение расшифровать.

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


Вот тот перечень. Обратите внимание на АЛ307Б. "Индикатор единичный". Видимо так было записано в ТУ. Резисторы тоже интересно записаны. Там где Ом - пробел. А где килоом - нет.
Нажмите для просмотра прикрепленного файла

Обновил руководство пользователя менеджера компонентов и GOST-doc-gen согласно изменениям, сделанным в ревизии 4162.

Актуальная ревизия 447 ветки lp:~kicad-gost-committers/kicad/doc

doc/help/ru/GOST_Tools.pdf
doc/help/ru/docs_src/eeschema/GOST_Tools.odt

ссылка для скачивания

62я ревизия.

В перечне элементов строчка: "Дроссель Чип бусина 0805-200мА- 1кОм ±20 % BLM21AG102SN1D"

Менеджер запихал это все в одну строку, а оно не влезло. Думаю что в алгоритме, если рассчитывается длина текстовой строки, не учитывается "Дроссель".

Добавил авто разбивку строки печатаемой в столбце Наименование в перечне элементов (ревизия 4163).
Также отцентровал текст имен групп в перечне элементов. В случае перечней с исполнениями не уверен, что стало лучше (см. пример demos/GOST/multivibrator.sch). Интересно мнение остальных.

На данный момент доступна только 4162.

push забыл сделать Теперь сделал.

Исправил глюк: подчеркивался любой центрованный текст.
Теперь центрованный текст имен групп выглядит вроде нормально, не сливается с заголовками исполнений.
Ревизия 4165.

AVL
Ревизия 4165.
При запуске kicadbom2spec через "Сформировать перечень элементов":

При генерации перечня через Менеджер компонентов - нормально.

Есть предложение завести отдельное поле для единиц измерения. Сейчас при прописывании полностью единиц измерения в Менеджере компонентов, они попадают на схему. Мало того, что надписи (номиналы) расползаются (а места мало!), так ещё и получается несоответствие ГОСТу. Например, на схеме надо писать "мк", а в перечне "мкФ". С пикофарадами ещё сложнее - на схеме ничего не пишется, а в перечне - "пФ".

Недоработка Менеджера компонентов - не запоминаются содержимое полей редактирования, приходится каждый раз набирать одно и то же.

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

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

AVL
применение "мк" и отбрасывание "пф" разрешается ГОСТом для принципиальных схем, но не требуется
Вообще-то да, но фактически все делают именно так.

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

Сможете описать эксперимент как это повторить?
Так и экспериментировать не надо - просто есть предопределённые наборы (кстати, в "Наименовании" отсутствует "транзистор"), которые такими и остаются и не пополняются.

В децимальном номере в штампах перечня и спецификации вставляется "Э3".

В справке оп GOST_Tools.pdf написано:

Только это не работает. Пишет всё.

Ещё есть пожелание: устанавливать курсор в схеме на редактируемый в Менеджере компонентов элемент, как это сделано в CvPcb. Если нет возможности, то хотя бы развязать окна Eeschema и Менеджера, чтобы переключение на Менеджер не поднимало автоматически Eeschema.

При групповом заполнении полей (если есть различия в других полях), то ввод каждого символа сопровождается предупреждением. Это утомляет.

Ещё пожелание: добавить основное исполнение (фактически, индекс 0, который не пишется).

Насколько я знаю, в данных исполений название изделия не пишется, только децимальный номер (без "Э3", кстати), после чего пишется "Лит.".

Вот ещё выяснил:
- Если перечень/спецификация меньше 3 листов, то лист регистрации изменений не делается.
- В листе регистрации изменений применяется штамп для второго и последующих листов (мелкий).

Есть предложение, в спецификации вместо "фирма" писать "производитель".

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

Если устроит применение "мк" (в том числе не указание "пф") одновременно и на схеме и в документах, то GOST-doc-gen нормально понимает и обрабатывает эти случаи (добавил поддержку отсутствия "пФ" в ревизии 4166). Я в руководстве пользователя не стал эти случаи описывать, чтобы не вводить читателей руководства в заблуждение. Мы же не нашли прямое подтверждение тому, что в документах можно использовать такие сокращения. Нашли только косвенное подтверждение, что это можно делать. Таким образом, лучше пусть каждый пользователь сам для себя решит, применять такие сокращения или нет.
По крайней мере, то как написано в руководстве пользователя уж точно соответствует ГОСТу, и человек следующий такой инструкции, гарантированно не ошибется.

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

Да, это также обсуждали с Aldan. Aldan, по-моему, предложил хорошее решение. Это надо делать.

Сможете описать точную последовательность действий как это воспроизвести?
Если в схеме у компонента ChipName==Value, то у меня в менеджере компонентов поле Номинал пустой.

Да, о курсоре писал tema-electric. Я объяснил, что потребуется значительная переработка взаимодействия с EESchema. Это тоже надо делать.

Какие предложения?
Я в данной ситуации поступаю следующим образом. Выделяю всю строку символов целиком в редактируемом поле, нажимаю Delete. В результате появляется окно предупреждения только один раз. Далее спокойно ввожу нужное значение.
Я бы данное предупреждение не убирал. Оно помогает в том случае, когда выбираешь группу компонентов с одинаковыми параметрами, и если вдруг нечаянно выделил лишний компонент, у которого параметры отличаются, то программа предупреждает об этом, что обратите внимание, не исключено, что зацепили лишнее по ошибке.

Если Вы хотите задать основное исполнение, то нужно создать исполнение с индексом 00. Это и будет интерпретироваться GOST-doc-gen как основное исполнение, и выводиться в документы без отображения 00. Руководство пользователя по работе с исполнениями в процессе.

Сможете дать указание на ГОСТ?

Можем это слово сделать конфигурируемым через меню.

Здесь мне нужно более детальное описание. Желательно скриншот с указанием в каком месте проблема.

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

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

Да, о курсоре писал tema-electric. Я объяснил, что потребуется значительная переработка взаимодействия с EESchema. Это тоже надо делать.
А хотя бы развязать окна можно?

Выделяю всю строку символов целиком в редактируемом поле, нажимаю Delete. В результате появляется окно предупреждения только один раз. Далее спокойно ввожу нужное значение.
Это предупреждение появляется на каждый вводимый символ.

Я бы данное предупреждение не убирал.
Не надо совсем убирать. Но достаточно одного раза.

Если Вы хотите задать основное исполнение, то нужно создать исполнение с индексом 00.
Понял. Спасибо, помогло. Вот только пункт меню "Удалить существующее исполнение" всегда неактивен, соответственно не работает. Правда если в исполнении нет элементов, то оно автоматически пропадает при следующей загрузке Менеджера.

Сможете дать указание на ГОСТ?
Только по поводу количества:
ГОСТ 24.301-80*

По поводу штампа могу только рассуждать логически.
1. Если Лист регистрации изменений включается в документ, имеет тот же децимальный номер и название, включается в общую нумерацию листов, то явно в одном документе не может быть два первых листа.
2. Заполнение граф "Лист" и "Листов" при котором номер листа есть (да ещё не первый), а количества нет - выглядит странно. Наверняка где-то есть правило заполнения этих граф. Сейчас уже искать не буду, может потом, если понадобится.

Здесь мне нужно более детальное описание. Желательно скриншот с указанием в каком месте проблема.
Схема и спецификация приложены. Например, диоды, конденсаторы. Да и остальные... С микросхемами вообще интересно: DD1, DA1, DD2.

Есть ещё один глюк. Я думал, что это у меня, но оказалось - нет. Повторяется неоднократно. Почему-то у A2 (на приложенной схеме) пропадает номинал.

Ещё непонятно по каким критериям поле "Значение" из библиотеки преобразуется в поле "Тип", а иногда в поле тип появляется тильда. В библиотеке элементы выглядят одинаково, за исключением позиционного обозначения (A и DD). Может в этом дело?

Ещё один катастрофический глюк обнаружился.
После работы Менеджера что-то происходит со свойствами элементов, после чего в CvPcb попадает поле "Type". Просмотр посадочного места работает, но после сохранения ".cmp" файла, импорта посадочных мест в Eeschema и последующей генерации списка цепей, Pcbnew уже не понимает некоторых посадочных мест (хотя в логе пишет все правильные буквы, но не может найти соответствующий футпринт). Те, которые были не плате - проверяет, те, которых не было - не находит.
После прохода CvPcb с повторным назначением посадочного места, лишние символы из CvPcb пропадают, список цепей формируется нормальный и Pcbnew распознаёт все элементы с футпринтами.

Ещё поступило предложение по поводу резисторов, конденсаторов и пр.
Не делать заголовки - отдельные строчки "Резисторы 0805", "Резисторы 1206" и т.п., а просто написать одной строчкой "Резисторы".

Значение поля Тип (атрибут Type) намерено добавил, чтобы отображалось в строке с номиналом в CvPcb (см. сообщение).

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

Однако по Вашему эксперименту пока вижу следующее:
1) открыл схему multivibrator.sch, проделал действия как Вы описывали. Ничего подобного не обнаружил. Все корректно загружается в pcb и посадочные места отображаются как надо.
2) открыл схему Вашего примера (tst.sch). Открыл CvPcb. Всем компонентам уже назначены посадочные места. На многих позициях, если попытаться просмотреть графическое изображение, ничего не находит. При загрузке нетлиста в Pcbnew действительно выпадают ошибки о том, что не может найти посадочные места. Так их и так нет на самом деле в стандартных библиотеках. Например TQFP64 такого нет, есть только TQFP_64.


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


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

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


Это не глюк. Так сделано намеренно. Если у компонента атрибуты Chip Name и Value совпадают, то менеджером компонентов поле Value интерпретируется как пустое (см. руководство пользователя).
Данный вопрос уже много раз обсуждали в этой теме. Одни из первых обсуждений по данному вопросу в сообщениях:
1, 2, 3, 4.
И потом многократно обсуждали этот нюанс французского подхода. Для меня это пока главная головная боль.

По Вашему примеру с A2 не понятно почему атрибут Type равен "~". Видимо это было сделано руками (стерто руками в менеджере компонентов автоматически проинициализированное до этого поле Тип). Попробуйте в свойствах компонента удалить атрибут Type. Дальше запустите менеджер компонентов, и Вы увидете, что поле Тип станет равно значению атрибута Chip Name (см. руководство пользователя), и атрибут Type воссоздастся. Данное присвоение происходит однократно, если до этого не существовал атрибут Type. Эти действия привел только наглядный эксперимент. Можно это не делать, а просто задать сразу в менеджере компонентов в поле Тип то, что нужно.
Тип компонента нужно хранить в атрибуте Type. Если тип компонента хранить в атрибуте Value, то порядка не будет.

Я бы хотел переработать EESchema как описал в сообщении.


Смотрите руководство пользователя и объяснение выше.
А тильда может появиться в атрибуте Type, если очистить поле Тип в менеджере компонентов. Непосредственно в поле Тип менеджера компонентов тильда появиться не может.


Пункт меню "Удалить существующее исполнение" запланирован и еще не реализован.
Пока можно это делать выделив через SHIFT все компоненты в режиме "Полный список компонентов", и далее щелкнуть на удаляемый номер исполнения в списке "Выбранный компонент по исполнениям". В результате все компоненты, участвовавшие в данном исполнении будут из него выведены. Переоткрыв менеджер компонентов, номер исполнения, из которого были выведены все компоненты, больше не будет отображаться в списке. То есть фактически выполнено удаление исполнения.


Рассмотрим на примере XP2 из tst.sch.
Открываю свойства компонента XP2:
1) Chip Name = M80-8281242
2) Value = M80-8531242
3) Type = M80-8531242
Chip Name == Value? -> Нет. Значит атрибут Value не интерпретируется как пустой.
В данном случае нужно стереть значение поля Номинал в менеджере компонентов, либо ввести в свойствах компонента в атрибуте Value значение "~".


Да, глюк какой-то. Буду разбираться.


Сделано было в соответствии с ГОСТ 2.701—2008, п.5.7.6.

А по фокусу на окошко нельзя перечитывать значения с EESchema? Не то что бы мне это нужно )) Курсор лучше.
А вообще, щас под виндами попробовал, и там можно свернуть и схему и менеджер и даже отредактировать значение в схеме при открытом менеджере. И в Ubuntu тоже так можно, по памяти.

Я по фокусу изначально и сделал. Но так как этот фокус глючный в wxWidgets, пришлось от него отказаться. Как раз на сколько помню Вы первый наткнулись на проблемный фокус. При нажатии на выпадающие списки падал менеджер компонентов.

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


ГОСТ 24.301-80 не относится к ЕСКД.
По листам регистрации изменений ГОСТ 2.503-90, Приложение 3:

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

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

Исправил в ревизии 4170. Проблема была с локалью.
А с микросхемами что не так? (DD1, DA1, DD2.)
Сортировка в спецификации выполняется не по позиционным обозначениям, а следующим образом:
1) по наименованиям
2) по типам
3) по обозначению, если нет подтипа и номинала. Иначе по подтипу, если нет номинала. Иначе по номиналу.

Я так не делаю В реальности теперь почти не лезу в свойства компонентов. Если только быстро что-то посмотреть. Раньше больше лазил, но потом сделал видимым поле посадочного места, и надобность отпала вовсе. А потом поля исчезают, года делаю обратную загрузку посадочных мест. Вообще странно что не могли сделать фильтр, типа того, что сделано в PCBNew, чтобы можно было по щелчку отключать видимость полей Value/Footprint на всей схеме.

Надо будет сделать что-то подобное.

Я вот часто думаю, а если они что-то подобное тоже решат сделать, как потом быть? Не так давно натыкался на документ (notes_about_pcbnew_new_file_format.odt лежит в корне исходников). После его прочтения 2 Ideas for layers handling, я понял, что смысла особого создавать нечто аналогичное LAYERSET в разного рода САПР ПП нет, т.к. они уже об этом думают. Жалко что только медленно.