[AVL 0]

...

Да, интересные все-таки люди бывают.

[tema-electric 0]

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

 

В зависимости от типа компонента ГОСТ-tools производит разную обработку.

 

Для старых: добавляется поле Type = ChipName; Value = "~" в случае, если ChipName==Value; Иначе просто добавляется поле Type="~"; Value остается без изменений. Старый компонент становится "Новыми". Первый случай подходит для микросхем. Второй случай подходит для чего угодно, например резисторов и конденсаторов.

 

Для новых: Value="~", если ChipName==Value. Иначе ничего не трогается. Структура уже заполнена как надо.

 

Сегодня сделал вручную из пары "старых" компонентов пару "новых" во время работы по предложенному подходу, и тут же обжегся в CvPCB. Поле Value пустое оказалось и что за микросхема - не понятно, т.к. она записана в поле Type. Есть обозначение DA10 и корпус. А копуса перепутались до этого. Надо было восстановить порядок. :smile3046:

[AVL 0]

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

 

В зависимости от типа компонента ГОСТ-tools производит разную обработку.

 

Для старых: добавляется поле Type = ChipName; Value = "~" в случае, если ChipName==Value; Иначе просто добавляется поле Type="~"; Value остается без изменений. Старый компонент становится "Новыми". Первый случай подходит для микросхем. Второй случай подходит для чего угодно, например резисторов и конденсаторов.

 

Для новых: Value="~", если ChipName==Value. Иначе ничего не трогается. Структура уже заполнена как надо.

Провел анализ предложенного Вами алгоритма.

 

Тестируемые случаи

 

импортированные схемы из P-Cad:

1) ChipName = "SN74HC00D", Value = "~"

2) ChipName = "К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 мкФ"

 

тестируемый алгоритм

if (ChipName==Value):
    Type = ChipName
    Value = "~"
else:
    Type = "~"

Результирующие поля после обработки алгоритмом

1) ChipName = "SN74HC00D", Type = "~", Value = "~": OK

2) ChipName = "К73-17", Type = "~", Value = "0,1 мкФ": OK

3,9) ChipName = "7400", Type = "SN74HC00D", Value = "~": OK

4,10) ChipName = "C", Type = "К73-17", Value = "0,1 мкФ": OK

5) [ChipName = "7400", Value = "7400"] => [ChipName = "7400", Type = "7400", Value = "~"]: OK

6) [ChipName = "C", Value = "C"] => [ChipName = "C", Type = "C", Value = "~"]: OK

7) ChipName = "7400", Type = "~", Value = "SN74HC00D": FAILED

8) ChipName = "C", Type = "~", Value = "0,1 мкФ": OK

 

В пункте 7 я пометил, что тест не пройден, потому что в поле "Value" реально попал не номинал, а тип.

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

[Aldan 0]

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

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

Если не секрет, когда рассчитываете стать посвободнее и написать новый скрипт?

И еще, если у Вас появится время, помогите побороть странную особенность в работе скрипта: сгенерированные файлы .ods просматриваемые в ВинОфисе имеют нормальный вид за исключением некоторых погрешностей с форматированием, а вот если эти файлы просматривать, как положено, в ЛибреОфисе, то все совсем не так красиво. Наблюдается такая закономерность (проверял на 4-х проектах): если перечень получается больше, чем на одном листе, то первый лист не виден на предварительном просмотре и, следовательно, не печатается; если же перечень помещается на один лист, то тогда этот лист становится виден, но с артефактами: у некоторых групп строк по три строчки пропадают горизонтальные разделительные линии. Не думаю, что эти артефакты будут обязательно проявляться и в других коротких перечнях, а вот невозможность распечатать первый лист в длинных перечнях — стойкая закономерность.

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

И еще, когда я генерил перечни из разных проектов, то попался мне один из них с именем «SOR”. Так вот, после всех стандартных действий перечень так и не появлялся. Мне пришла мысль, что, возможно, имя слишком короткое и, после того, как я добавил к нему еще пару букв - все пошло. Лучше убрать такое ограничение на длину названия файла если это не вредит скрипту или указать это ограничение в доке.

 

[baranovskiykonstantin 0]

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

Если не секрет, когда рассчитываете стать посвободнее и написать новый скрипт?

Процесс формирования перечня элементов останется прежним. Новая идеология генерации BOM файлов, реализованная в KiCAD в виде плагинов, позволит запускать скрипт из интерфейса EEschema.

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

Планирую начать работу над этим в конце следующей недели.

 

И еще, если у Вас появится время, помогите побороть странную особенность в работе скрипта: сгенерированные файлы .ods просматриваемые в ВинОфисе имеют нормальный вид за исключением некоторых погрешностей с форматированием, а вот если эти файлы просматривать, как положено, в ЛибреОфисе, то все совсем не так красиво. Наблюдается такая закономерность (проверял на 4-х проектах): если перечень получается больше, чем на одном листе, то первый лист не виден на предварительном просмотре и, следовательно, не печатается; если же перечень помещается на один лист, то тогда этот лист становится виден, но с артефактами: у некоторых групп строк по три строчки пропадают горизонтальные разделительные линии. Не думаю, что эти артефакты будут обязательно проявляться и в других коротких перечнях, а вот невозможность распечатать первый лист в длинных перечнях — стойкая закономерность.

На счет отсутствия первого листа при печати, то думаю дело в диапазоне печати - его нужно задать. Для этого необходимо открыть первый лист и выделить ячейки А1:Q46. Это можно сделать разными способами, например, явно указать диапазон ячеек в соответствующем поле:

 

 

и нажать Enter. Или с помощью мыши. Нажать ЛКМ на самой первой (верхней левой) ячейке и не отпуская ЛКМ тянуть вниз, выделяя нужные ячейки:

 

 

После выделения нужно выбрать в меню: "Формат -> Диапазон печати -> Определить".

Теперь на печать должны выводиться все страницы.

 

На счет пропадания горизонтальных разделительных линий, хотелось бы больше подробностей.

 

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

Я бы посмотрел что внутри *.csv, если не жалко.

 

И еще, когда я генерил перечни из разных проектов, то попался мне один из них с именем «SOR”. Так вот, после всех стандартных действий перечень так и не появлялся. Мне пришла мысль, что, возможно, имя слишком короткое и, после того, как я добавил к нему еще пару букв - все пошло. Лучше убрать такое ограничение на длину названия файла если это не вредит скрипту или указать это ограничение в доке.

Никаких ограничений на длину имени файла нет (разве что ограничения файловой системы). Только что переименовал файлы из примера sample -> SOR, все работает. Похоже проблема была в чем-то другом.

 

 

 

[tema-electric 0]

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... Такова ли на самом деле функция этого поля?

[AVL 0]

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

Отвечаю пока частично.

Привязываться к 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 по поводу его предложения. Вдруг у него этот патч на полке все это время лежит.

[tema-electric 0]

Не могу утверждать, что это правильно, но я в некоторых случаях

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

 

Чип 2512 100кОм ±5 % (RC2512JK-07100KL)

Супрессор биполярный SMA 18В (SMAJ18CA)

 

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

 

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

 

Вдруг у него этот патч на полке все это время лежит.

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

[Aldan 0]

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

Планирую начать работу над этим в конце следующей недели.

Константин, очень рад, что Вы снова сможете продолжить свою работу!

Игры с диапазоном печати ни к чему не приводят и я думаю, что все дело скорее всего в «кривой» установке odfpy. Напомню, что я сначала по незнанию поставил питон3, а потом собрал odfpy. Далее, понял, что нужен питон2 и установил его, но скрипт не запускался.

Далее, мне пришла мысль, что, возможно, odfpy собранная при питоне3 как-то влияет на запуск. Пересобрал odfpy и все стало запускаться.

Так вот, сейчас меня меня гложет мысль, что именно odfpy все портит, т. к. МсОфис проблем с выводом листов не имеет.

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

Было бы здорово, если бы Вы написали мне, как можно «почистить» odfpy и все постараться установить с чистого листа. Тогда все последующие эксперименты могут и не понадобиться.

[AVL 0]

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

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

[tema-electric 0]

Если все-таки есть смысл, дайте знать.

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

[AVL 0]

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

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

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

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

Также я предполагал, что поле Обозначение может использоваться для ввода ТУ.

 

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

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

А вот те, кто будут мешать разные типы информации в одно поле, не смогу ни чем помочь.

 

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

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

 

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

Насчет P-Cad все помнят? :)

 

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

Изменено 22 июня, 2013 пользователем AVL

[AVL 0]

AVL

Если все-таки ГОСТ 8.417-2002 для ПЭ3 и спецификации,

Вообще-то нет. Именно ГОСТ 2.702-2011, ГОСТ 2.105-95, ГОСТ 2.106-96. Напрямую нигде не нашёл, хотя есть образец перечня с обозначением единиц измерения номинала, да и по-логике нужно писать, чтобы не путать с другими обозначениями, например, "Резистор МЛТ-0,25-120 Ом ±10%". Предположим, что его мощность 1 или 2 Вт, а сопротивление 1 или 2 Ом, соответственно. Если не писать единицы измерения, то получится "МЛТ-1-1 ±10%" или "МЛТ-2-2±10%". В конце-концов разобраться можно, но вероятность ошибки возрастает.

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

4.2.8 В документе следует применять стандартизованные единицы физических величин, их наименования и обозначения в соответствии с ГОСТ 8.417.

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

 

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

единицы величин могут иметь только следующие значения: Ом, кОм, МОм, ГОм, пФ, нФ, мкФ, мФ, Ф, нГн, мкГн, мГн, Гн, Гц, кГц, МГц, ГГц. (ГОСТ 2.105-95 и ГОСТ 8.417-2002). Остальные единицы величин, предусмотренные ГОСТ 8.417-2002, будут добавлены в генератор КД в случае востребованности.

[tema-electric 0]

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

Только косвенную, по примерам.

Электрические схемы.pdf Рисунок 11.21, в. "МЛТ-0,5-51к±5%"

Чертежи изделий с электромонтажом.pdf Рисунок 6.17, а. "МБМ-160-0,1±10%"

Общие сведенья о схемах.pdf Просто, до кучи.

 

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

[AVL 0]

Только косвенную, по примерам.

Электрические схемы.pdf Рисунок 11.21, в. "МЛТ-0,5-51к±5%"

Чертежи изделий с электромонтажом.pdf Рисунок 6.17, а. "МБМ-160-0,1±10%"

Общие сведенья о схемах.pdf Просто, до кучи.

 

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

Спасибо.

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

На практике каждый сам в своем случае решит как лучше поступить.