[Aldan 0]

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

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

На счет отсутствия первого листа при печати, то думаю дело в диапазоне печати

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

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

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

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

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

[AVL 0]

Сделал хоть какую-то документацию для менеджера компонентов и 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

 

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

[AVL 0]

Видимо это я и принял за аномалию, а он оказывается сравнивает и выкидывает. 2 = 2; 2 + 2 = 2. В этом был вопрос. Теперь ясно. Но механизм не прозрачен. Лучше бы он автоматом очистил Value (при совпадении с ChipName) и создал Type для однозначности. :)

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

 

По поводу автоматической очистки поля Value пока не вижу красивого решения. Надо еще думать.

А вот по поводу принудительного создания Type и отмены его оптимизации согласен. Здесь получаем преимущества:

1) обеспечиваем прозрачность работы с полем Тип

2) даем возможность делать видимым атрибут Тип (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)

 

Таким образом, будем действовать поэтапно.

На данном этапе предлагаю пока только сделать добавление атрибута Type равное Chip Name, если до этого атрибут Type отсутствовал.

В этом случае в целом не ломаем все, что было раньше (схемы ранее введенные / импортированные из P-Cad как работали с GOST-doc-gen так и продолжат работать).

Но зато получаем преимущества в приведенных выше пунктах 1 и 2.

[tema-electric 0]

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

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

 

По поводу автоматической очистки поля Value пока не вижу красивого решения.

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

 

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

[AVL 0]

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

В EESchema оно у меня ругнулось, что ввожу пустое значение и предупредило, что если все-таки введу пустое значение, то атрибут будет удален.

Также странная ситуация с Вашим примером, в котором поле Value в каком-то случае вообще не отображалось в свойствах компонента.

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

Это пока касается атрибутов Value и Type.

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

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

 

Я вот думаю, а что нам мешает (только на уровне кода EESchema) в момент добавления сделать все как надо? А именно, при добавлении нового компонента прямо в коде EESchema сделать, чтобы атрибут Value по умолчанию устанавливался в "~", и по умолчанию сделать чтобы автоматом добавлялся атрибут Type равный значению Chip Name?

При этом даже совместимость ни с lp:kicad ни с существующими схемами никак не пострадает.

Данная мера после ее принятия наладила бы нормальный режим работы при разработке новых схем и редактировании имеющихся схем в случае редактирования атрибутов через GUI EESchema.

Есть ли у такой меры подводные камни?

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

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

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

[tema-electric 0]

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

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

 

Есть ли у такой меры подводные камни?

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

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

#
# Chip_CR0805_1k
#
DEF ~Chip_CR0805_1k R 0 40 N N 1 F N
F0 "R" 0 80 60 H V C CNN
F1 "1кОм" 0 -15 20 H I C CNN
F2 "Chip_CR0805_Box" 0 -75 20 H V C CNN
F3 "" 0 0 60 H V C CNN
DRAW
S -100 40 100 -40 0 1 0 N
P 2 0 1 0  -40 -20  0 20 N
P 2 0 1 0  0 -20  40 20 N
X 1 1 -150 0 50 R 50 50 1 1 P
X 2 2 150 0 50 L 50 50 1 1 P
ENDDRAW
ENDDEF

 

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

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

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

[AVL 0]

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

 

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

 

импортированные схемы из 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" реально попал не номинал, а тип.

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

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

 

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

if (Type==""):
    Type = Chip Name

Тогда это позволит применить алгоритм №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.

if (Type!=""):
    Тип = Type
    Номинал = Value
else if (Value=="~"):
    Тип = Chip Name
    Номинал = "~"
else:
    Тип = Value
    Номинал = "~"

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

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!

[tema-electric 0]

Да, реально взрыв мозга. Зачем это надо? :)

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

 

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

 

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

 

[AVL 0]

Да, реально взрыв мозга. Зачем это надо? :)

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

Это в продолжение для "Предлагаю решение, которое скорее всего устроит всех..." Я пока только не знаю кто такие все ;)

По крайней мере для всех тестовых ситуаций, которые взял в рассмотрение (может еще какие-то еcть?), алгоритм №2 выглядит, что работает.

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

 

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

 

Нет, я не собираюсь генерировать перечень, в котором будет просто указана емкость 0.1 мкФ :)

Тестовый случай 8 - это промежуточное состояние схемы до того как она будет доведена до состояния 8а.

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

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

 

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

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

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

[tema-electric 0]

кто такие все ;)

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

 

Aldan смущала склейка ChipName + Value в документации. Но это так или иначе вылечится.

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

 

[ChipName = "C", Value = "0,1 мкФ"] => [Тип = "0,1 мкФ", Номинал = "~"]

 

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

 

[AVL 0]

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

 

Aldan смущала склейка ChipName + Value в документации. Но это так или иначе вылечится.

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

 

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

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

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

Надеюсь пользователи посмотрят на него, ужаснутся, и не будут настаивать идти таким путем :)

[tema-electric 0]

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

[AVL 0]

Таким образом, будем действовать поэтапно.

На данном этапе предлагаю пока только сделать добавление атрибута Type равное Chip Name, если до этого атрибут Type отсутствовал.

В этом случае в целом не ломаем все, что было раньше (схемы ранее введенные / импортированные из P-Cad как работали с GOST-doc-gen так и продолжат работать).

Но зато получаем преимущества в приведенных выше пунктах 1 и 2.

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

 

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

if (Type==""):
    Type = Chip Name

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

 

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

 

Итоговые преимущества:

1) обеспечиваем прозрачность работы с полем Тип

2) даем возможность делать видимым атрибут Type (в EEShema не предусмотрена возможность делать видимым атрибут Chip Name)

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

[AVL 0]

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

 

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

if (Type==""):
    Type = Chip Name

Данная мера позволит уйти от необходимости чтения атрибута 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. Не смотря на то, что в свойствах компонента предусмотрена опция сделать видимым пользовательский атрибут, при включении этой опции атрибут так и не отображается. Так что данный баг надо исправлять.

[tema-electric 0]

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

Посмотрел CvPCB. Длинновата запись, но это лучше чем было до этого. :)