Версия для печати темы

Автор: Aldan Apr 9 2013, 21:17

Вот уже на протяжении нескольких лет время от времени предпринимаются попытки прикрутить к Кикаду вывод текстовой документации. Например, на Кикад-фтп в свое время была выложена альфа-утилитка (если мне не изменяет память), которая преобразовывала кикадовский ВОМ в некое подобие перечня элементов, который выводился в МсВорд. Помнится, я попробовал тогда ею воспользоваться и обнаружил, что утилита очень сырая, т. к. перечень получался с какими-то непонятными полосами и прочими недоработками. Но не беда, ведь это только начао — подумал я, ведь со временем все наладится. Но, надежды не оправдались, т. к. дальнейшего развития не произошло, да и необходимость иметь на компе платный МсВорд для бесплатного Кикада как-то тоже не радовало. Словом, все заглохло.
Параллельно этой утилите другим форумцем велась разработка своего варианта такой важной полезняшки. Он со временем даже демонстрировал скриншот Кикада с новой иконкой по нажатию на которую можно было активировать функцию вывода документации по ГОСТ. Более того, однажды он написал на форуме, что до полного окончания работ осталась всего неделя, что привело меня в бурную радость.., однако, когда прошло больше года и я обескураженный решил спросить его на форуме когда же можно будет потестить разрабатываемую им мегафичу. К моему удивлению, он ответил, что давно забросил эту разработку т. к. не смог с какой-то тонкостью Кикада разобраться.
Я так и не понял тогда, зачем же он объявил всем, что практически все готово, т. к. неделя на вылизывание не в счет, В общем, опять все заглохло.
Конечно, работа ведется на энтузиазме в свое личное время, которого чаще всего не хватает и на более важные дела, поэтому нельзя ничего определенного ожидать. Но все же...
Прошло еще достаточно много времени и вот, на нашем форуме появляется желанное сообщение Барановского Константина:

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

К тому же, возможно, они объединят свои усилия:

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

Автор: Барановский Константин Apr 10 2013, 06:37

В своем сообщении о скрипте я писал:

после чего было получено только одно замечание от faa и далее тишина. Раз никто не жалуется и ничего не предлагает, то возможны два варианта:
1) все пользуются и все довольны;
2) никто не пользуется, никому не нужно.
Я думаю что в данном случае имеет место второй вариант и раз так, можно не спешить с нововведениями и улучшениями, так как не для кого стараться, а для меня хватает и реализованной функциональности.

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

Автор: IgorKossak Apr 10 2013, 07:08

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

Автор: Leonid Egorov Apr 10 2013, 09:57

Скрипт скачал, но еще не прикрутил. Поэтому замечаний нет Штука-то полезная.

Автор: Aldan Apr 10 2013, 12:02

Константин, для того, чтобы можно было высказать свое мнение о работе Вашего скрипта, нужно попрактиковаться в выводе документации при помощи него, ведь так? А теперь посмотрим в на эту ситуацию глазами обычного пользователя Кикада, не программиста, каким являюсь я. Такой пользователь резонно ожидает такой готовности предлагаемого программного продукта, когда он будет органично интегрирован в Кикад, как все его составляющие. Например, при выводе перечня элементов будет достаточно поставить галочку в чекбоксе «выводить перечень в ГОСТ» и на выходе мы получим вместо абстрактной таблицы в Екселе именно то, что нам надо. Или, например, в менеджере Кикада к шести уже имеющимся кнопкам запуска приложений добавится седьмая - «текстовая документация». В любом случае речь идет о законченном приложении, интегрированном в существующий графический интерфейс и все это устанавливается без бубна совместно с установкой самого Кикада.
Ваше сообщение с анонсом своего скрипта я воспринял как обращение к программистам, могущим и «прикрутить» и в консоли поработать. Я же командной строкой пользовался за всю свою жизнь раз десять, да и скриптами с «костыликами» никогда не игрался. Таких как я, увы, много, возможно — большинство. Вот и молчит это большинство, т. к. еще не получило в свои руки сей важный инструмент, чтобы можно было его потестировать.
Тут уж Вам нужно определиться: либо вы делаете свой продукт только для «продвинутых» и тогда то, что уже реализовано можно считать достаточным, либо Вы делаете законченный продукт интегрированный в Кикад и тогда это будет «для всех». Хочется верить, что Вы настроены на доведение своей разработки до полной завершенности
В данный же момент мне даже не понятно поддерживает ли нынешняя версия Кикада python или нет. Ведь об этой поддержке уже многое писали, однако писали и о том, что вроде бы сейчас это отключено (я пишу о стаб. сборке 4009). Если поддерживает, то зачем Вы в своем readme требуете его установку, а также установку odfpy? Если пока не поддерживает, но может, так не лучше ли в ГОСТ версии таки реализовать эту поддержку, чтобы в довесок в Кикаду не устанавливать целый перечень доп. программ и потом разбираться в их взаимодействии вместо работы в САПРе? Почему нельзя сразу в общем пакете установить opengostfont, а нужно опять прыгать с бубном и как Вы пишете «может придется подобрать шрифт, желательно моноширинный»? А требуемая настройка шести пользовательских полей разве не может быть один раз на всю жизнь сделана при сборке Кикада? Ведь если кому-то не понравится, то он поля легко исправит?
Словом, я за то, чтобы все новые приложения по уровню безгеморройности и завершенности соответствовали самому Кикаду и вызывали радость, а не головную боль.
Но не зря существует поговорка: «сытый голодного не поймет». «Сытый» - продвинутый, самодостаточный, могущий «прикрутить», а «голодный» — тот, кто ожидает понимания и снисхождения, т. к. по сложившейся ситуации не владеет тем, чем владеет «сытый». Вот и проходят мимо «голодных» скрипты и «костылики на перловке», а могли бы украсить Кикад на радость всем, а не только продвинутым.
Чтобы не возникло вопросов типа, а сам-то чего не станешь «продвинутым», отвечаю. В этом году мен 59, а лет 6 — 7 назад я еще не умел самостоятельно устанавливать приложения и только-только сел за компьютер. Так уж сложилась жизнь, она у всех разная...
Простите за пространные речи, просто хочется, чтобы Вы могли понять реальное положение вещей, тогда будете несколько иначе мыслить. И не ждите шквала отзывов, а работайте на будущего пользователя, который обязательно появится, если Кикад станет дружественным и функциональным. Кстати, если замечали, все предлагаемые материалы обычно скачивают не более, чем полтора-два десятка человек, что говорит о том, что на форуме не так много «нашего брата».
И еще, пожелание: подумайте, может быть реализовать не только вывод перечня, но и ведомость покупных раз уж есть ВОМ, ведь тоже гостовский текстовый документ, причем гораздо более простой по организации.

Автор: AVL Apr 11 2013, 07:07

Всем привет.

Как раз и разрабатываю интегрированный модуль для формирования документации по ГОСТ.
Скоро выложу ветку на launchpad.

Автор: Aldan Apr 11 2013, 08:07

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

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

Автор: viknn Apr 13 2013, 03:28

Вариант шаблона спецификации для LibreOffice (с боковым и нижним штампами)

Автор: Барановский Константин Apr 20 2013, 08:12

Переписал свой скрипт, теперь он имеет графический пользовательский интерфейс и с ним можно работать как с обычной программой.
http://electronix.ru/redirect.php?http://postimage.org/

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

Архив с программой и руководством можно загрузить отсюда: http://electronix.ru/redirect.php?https://launchpad.net/kicadbom2spec

P.S.

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


К сожалению, на создание генератора спецификации интегрированного в KiCAD сейчас банально нет времени.

Автор: viknn Apr 20 2013, 20:16

Прошел по маршруту kicadbom2spec в Windows XP, руководство подробное (спасибо Косте).
Вместо рабочего стола для установки odfpy использовал строку Total Commander - получилось.
Пожелание: включить в дистрибутив простой набор файлов sample.* для примера и демонстрации результата.
Можно будет попробовать сделать автоустановку всего через NSIS.

Автор: AVL Apr 21 2013, 08:12

Всем привет.

Хотел узнать, есть ли где-либо (в bzr репозиториях, на ftp и т.д.) свободно распространяемый пример электрической принципиальной схемы (включая библиотеки) оформленной по ГОСТ для KiCad?

Хочу добавить такой пример в директорию demos дерева проекта KiCad по аналогии примерам не ГОСТ исполнения, которые находятся в директории demos. (Пока планирую вручную добавить нужные аттрибуты для компонентов такой схемы-примера).

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

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

Исходники выложил в ветке http://electronix.ru/redirect.php?https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen
Однако пока отлаживал под Linux Debian Squeeze (под Windows скорее всего пока не соберется).

Предварительно сделал генерацию документов через нажатие Eeschema->Tools->GOST Tools.

После сборки из исходников, генерируется файл env.sh в директории eeschema
Данный файл пока приходится запускать перед запуском eeschema следующим образом:
. ./env.sh
иначе eeschema не увидит библиотеки программы Open Office.

Буду еще думать как убрать этот костыль.

Для возможности сборки проекта из исходников, понадобится установить Open Office SDK.
Я пока работаю на версии 3.2, другие версии еще не тестировал.

Автор: AVL Apr 21 2013, 10:30

Нарисовал пока свой пример схемы http://electronix.ru/redirect.php?https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen:
demos/GOST/multivibrator.sch (путь в дереве кикада)

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

Автор: Aldan Apr 22 2013, 20:31

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

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

Автор: IgorKossak Apr 23 2013, 12:08

Действительно, жаль. Был бы хоть какой-нибудь "лайк", я бы поставил.
На одной консультируемой мною фирме последней каплей среди аргументов перехода на KiCAD послужило наличие вывода гостовской документации.

Автор: Барановский Константин Apr 24 2013, 08:05

Хотел попробовать, но в Ubuntu OpenOffice SDK просто так не установишь, а LibreOffice SDK не подходит. Если есть возможность, выложите собранные бинарники KiCAD, уж очень интересно что да как.

Автор: AVL Apr 24 2013, 09:26

Константин, а у Вас какая версия Ubuntu (включая архитектуру)?

Автор: Барановский Константин Apr 24 2013, 09:41

AVL, Ubuntu 13.04 32 bit.

P.S. лучше на "ты"

Автор: AVL Apr 24 2013, 09:55

Официальный релиз Ubuntu 13.04 вроде бы завтра выходит. По крайней мере сейчас я не нашел где официально можно скачать Ubuntu 13.04.
Константин, у тебя есть ссылка, где можно скачать Ubuntu 13.04?

Автор: Барановский Константин Apr 24 2013, 10:32

Да, официальный релиз должен появиться завтра, но я не смог удержаться и еще месяц назад перешел на тестовую версию, т.к. все говорили о высокой стабильности. Ежедневные сборки доступны здесь: http://electronix.ru/redirect.php?http://cdimage.ubuntu.com/daily-live/current/.

Автор: viknn Apr 24 2013, 15:47

Приведу два ГОСТа на текстовые КД:
ГОСТ 2.701-2008 - ЕСКД. Схемы. Виды и типы. Общие требования к выполнению. Здесь раздел 5.7 посвящен
перечню элементов (ПЭ), который "помещают на первом листе схемы или выполняют в виде самостоятельного документа".
ПЭ выполняют в виде таблицы заданной формы. Даны правила заполнения.

ГОСТ 2.106-96 (переиздание 2007 года) - ЕСКД. Текстовые документы (в том числе спецификация, СП).
В СП восемь разделов. В пункте 3.7 описывается заполнение самого трудоемкого раздела "Прочие изделия",
куда и заносятся компоненты ЭРИ для печатных плат. Приведены формы документов.

Автор: AVL Apr 28 2013, 10:45

Добавил поддержку LibreOffice, а также новых версий OpenOffice/LibreOffice (начиная с версии 3.4 разработчики OpenOffice/LibreOffice изменили способ соединения с офисом).

Отлаживал под Ubuntu 13.04 32-bit (официальный релиз), установленной под VirtualBox.



Сейчас есть две проблемы:
1) приходится до команды make запускать ". eeschema/env.sh", чтобы в переменную окружения LD_LIBRARY_PATH прописался путь к библиотекам URE
2) приходится до запуска eeschema также запускать ". eeschema/env.sh" по тем же причинам (в текущей сессии достаточно запустить только один раз)

Константин, есть какие-нибудь идеи как решить пункт 1, чтобы не приходилось руками выполнять эту команду? Вчера для этого экспериментировал с cmake, пока не удалось победить.

Насчет пункта 2 у меня пока только идея - это добавить возможность в каком-нибудь окошке в кикаде конфигурировать путь к OpenOffice / LibreOffice.

Автор: AVL Apr 28 2013, 22:07

Решил попробовать данный скрипт. Установил odfpy 0.9.6.
При запуске скрипта потребовало пакеты (у меня Linux Debian 6.0.7) - установил:
sudo apt-get install python-argparse
sudo apt-get install python-tk

Далее при запуске скрипта вываливается ошибка:


Заархивированный тестовый файл прикрепил.

Автор: Барановский Константин Apr 29 2013, 19:24

Спасибо большое за описание ошибки! Приложил исправленный скрипт.

Прости, но последнее время был очень занят и не мог заняться решением проблем gost_doc_gen. Обязательно что-нибудь придумаем

P.S.
В BOM файле, в поле Field 5 должна указываться точность, а примечание в поле Field 6.

Автор: AVL Apr 29 2013, 20:08

Спасибо. Теперь заработало.

Впечатление положительное, что нет проблем с всякими коннектами / путями к OpenOffice/LibreOffice.
Я уже стал задумываться, может как-то odfpy прикрутить к GOST-doc-gen, либо может есть c++ odfpy-альтернатива.

Автор: Барановский Константин Apr 30 2013, 09:16

AVL, GOST_doc_gen не хочет собираться:

Вроде бы библиотеки на месте, но никак...

Автор: viknn Apr 30 2013, 14:46

Получается, что если в C++/Qt-библиотеке (> 4.5) есть простые средства формирования ODF-файлов, то в C++/Wx их нет...

здесь кросс-платформенная свободная Qt-утилита kicad_service, © 2010, Павлюков.
написана для просмотра схем kicad (PDF формат kicad еще не поддерживал)
можно подключать ttf-шрифты типа opengostfont
попытка формировать BOM и перечень элементов (формат PS)

Автор: AVL Apr 30 2013, 20:34

Линкер не видит файлы so.3. Ему нужны файлы so.
На этапе линковки линкеру передается путь ${OOO_SDK_DIR}/lib (для ubuntu 13.04 32-bit этот путь = /usr/lib/libreoffice/sdk/lib). Там и лежат файлы so (симлинки на so.3, которые, в свою очередь, лежат в /usr/lib/libreoffice/ure-link/lib)

Раз линкер не может найти указанные библиотеки, значит по какой-то причине cmake не смог вычислить корректно значение переменной OOO_SDK_DIR (это вычисление выполняет модуль GOST-doc-gen/CMakeModules/FindOpenOffice.cmake, то есть на него возлагаются надежды, что он на произвольной машине найдет корректно расположение офиса и его SDK).

Поэтому нужны логи выполнения команды cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON | tail -n15
И логи команды ls -la /usr/lib/libreoffice/sdk/lib

P.S.
LD_LIBRARY_PATH тоже должен быть проинициализирован (в данном случае = /usr/lib/libreoffice/ure-link/lib, судя по приложенным логам, проинициализирован верно), иначе не будут найдены зависимости, необходимые библиотекам uno_cppuhelpergcc3, uno_cppu, uno_salhelpergcc3, uno_sal.



Жаль, что KiCad не на базе Qt

Прикручивать Qt только, чтобы формировать odf - избыточно, хотя тоже вариант.

Значит имеем 3 варианта:
1) оставить все как есть (OO SDK). В случае с Windows пытаюсь добиться компиляции KiCad с помощью VC Express 2010 (с помощью VC Toolkit 2003 уже не получается собрать wxWidgets, поскольку в составе VC Toolkit 2003 нет nmake.exe). Если удастся собрать сам KiCad, то появляется возможность слинковать OO SDK. Жаль, что библиотеки OO SDK не собирают для mingw, и очень странно, что они есть только для VC.
2) прикручивать odfpy
3) прикручивать qt

Автор: Барановский Константин May 1 2013, 05:38

Автор: AVL May 1 2013, 13:43

Константин, проверь, пожалуйста, новый коммит (4098) с исправлением. По идее должно заработать.

Автор: Барановский Константин May 2 2013, 16:55

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

Автор: Барановский Константин May 4 2013, 15:23

Немного обновил свой скрипт, изменений немного:

- добавил файлы для примера создания спецификации, описанного в руководстве;

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

Ну собственно и все. Скачать обновленный релиз можно отсюда http://electronix.ru/redirect.php?https://launchpad.net/kicadbom2spec

Автор: AVL May 4 2013, 23:34

Текущее состояние по GOST-doc-gen:
1) удается откомпилировать штатные исходники KiCad под винду только с помощью MinGW (перепробовал MS Visual C++ Toolkit 2003, MS Visual C++ 2008/2010 Express, ничем из перечисленного не удается откопмпилировать без ошибок)
2) с другой стороны OpenOffice/LibreOffice SDK поставляется с библиотеками под винду, которые можно линковать только с помощью MS Visual C++.
Таким образом, данный путь тупиковый. Единственное, что можно сделать - написать промежуточный проект-интерфейс (dll), соединяющий KiCad+GOST-doc-gen с OpenOffice SDK. Такой проект собирать с помощью MS Visual C++. Вариант не особо удобный.

Также размышлял насчет odfpy.

В результате решил добавить в GOST-doc-gen унифицированный интерфейс (класс COMMON_DOC_IFACE) для подключения различных модулей, реализующих какой-либо из способов подключения к офису, либо прямую генерацию файлов документов (например odfpy).

Весь специфический код по работе с OpenOffice/LibreOffice SDK вынес в отдельный модуль (класс OO_IFACE).

Дальше написал новый модуль с поддержкой odfpy (класс ODFPY_IFACE).
По odfpy вылезли следующие проблемы:
1) если открыть файл .odt и сразу же его без изменений сохранить, то в результирующем .odt файле "плывет" высота строк таблицы (то есть это баг odfpy).
2) оказалось, что odfpy поддерживает только абсолютную адресацию, которая полностью несовместима с именованной адресацией, используемой в GOST-doc-gen (вычислить одно из другого не возможно). В результате odfpy выбивается из построенной концепции унифицированного интерфейса (COMMON_DOC_IFACE).
По причине указанных проблем, пока принял решение отказаться от использования odfpy. По этой же причине исходники интеграции с odfpy пока не заливал.

В итоге набрел на еще один способ подключения к OpenOffice - использование Python-UNO.
И написал еще один модуль с поддержкой Python-UNO (класс OO_PYTHON_UNO_IFACE).

Отлаживался под Linux Debian 6.0.7. По крайней мере под Linux заработало. При использовании такого подхода (Python-UNO) ушли сложности с линкованием библиотек OO SDK.
Под винду еще не проверял, но по крайней мере линковать нелинкуемое уже не придется.

На данный момент предусмотрены следующие варианты сборки KiCad+GOST-doc-gen:
1) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON - собирать KiCad с генератором документов как таковым. При этом генератор будет работать на базе Python-UNO (без OO SDK)
2) cmake ../. -DKICAD_STABLE_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON -DUSE_OPENOFFICE_SDK=ON - вместо Python-UNO будет использоваться OO SDK

Пока думаю, что новый вариант сборки на базе Python-UNO (вариант номер 1) предпочтительнее.

Автор: Барановский Константин May 5 2013, 10:22

AVL, в Ubuntu не хочет собираться (используя Python-UNO). Лог в приложении.

Автор: viknn May 5 2013, 11:58

Попробовал собрать под Windows. Cкомпилировалось без ошибок, но не собралось (путаница с версией python 2.7/2.6). Скриншоты начала и конца прилагаю.

Автор: AVL May 5 2013, 15:45

Константин, исправил в ревизии 4105.

Ubuntu 13.04 32-bit:


Пакет libreoffice-dev при такой конфигурации (сборка на базе Python-UNO без использования OO/LO SDK) устанавливать больше нет необходимости, но зато теперь нужны пакеты python-dev и python-uno (python-uno потребовался в случае ubuntu, я у себя на debian не ставил такой пакет).



Юрий, данную проблему исправил в ревизии 4105.
Под винду я еще недоотлаживал (в процессе). Там еще скорее всего сейчас вопросы выплывут.

Автор: viknn May 5 2013, 16:15

Application: Eeschema
Version: (2013-05-05 BZR 4105 GOST)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Сейчас все собралось до конца. Ошибка возникает по команде GOST Tools. Похоже не может запустить OpenOffice.
У меня XP и каталог программ - Program Files.

Автор: AVL May 5 2013, 17:31

Да, сейчас под винду в KiCad пока захаркодил строку к офису: C:\\Program Files (x86)\\OpenOffice.org 3\\program\\soffice.exe
Пока это можно обойти введя в командной строке: soffice "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
Если напишет ошибку "soffice не является внутренней или внешней командой, исполняемой программой или пакетным файлом", то ввести полный путь, например:
C:\Program Files (x86)\OpenOffice.org 3\program\soffice.exe "-accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"
при этом путь к soffice.exe указать фактический какой есть на установленной системе.
В данном случае KiCad все равно будет выдавать ошибку "unable to launch the process: ...soffice.exe", но выполнение пойдет дальше. Сделал так, чтобы в случае, если не удается из KiCad по какой-то причине запустить офис в режиме listening, то хотя бы дать возможность пользователю выполнить эту команду из ОС.

Не могу понять где в винде путь к офису прописывается. Если выполняю команду soffice из cmd.exe, то не находит что такое soffice.
Если же запускаю из far.exe, то находит soffice и запускает нормально.
Если выполняю команду soffice из KiCad, то тоже не видит, что такое soffice. При этом добавление в %PATH% не помогает в случае с KiCad.

...но дальше еще появится ошибка, что не может найти uno. Тоже пытаюсь понять, что сделать.

Автор: Барановский Константин May 5 2013, 19:47

Снова ошибка:

Автор: AVL May 5 2013, 20:54

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

Автор: AVL May 6 2013, 22:11

Наконец-то заработало под винду. Единственное пока пришлось написать bat файл, в котором настраиваются пути к питону. В линуксе (debian, ubuntu) такой кривости нет.

1) нужно установить Python 2.6.6 (именно эту версию, http://electronix.ru/redirect.php?http://www.python.org/ftp/python/2.6.6/python-2.6.6.msi). Если есть еще какие-то установленные версии питона, то их нужно либо деинсталлировать, либо переименовать временно директорию, чтобы cmake при сборке по ошибке не стал использовать какую-нибудь другую версию питона отличную от 2.6.6.

2) нужно установить OpenOffice 3.4.1 (именно эту версию).

3) нужно обновиться с lp:~al-lunev/kicad/GOST-doc-gen (на данный момент ревизия 4107).

4) выполнить сборку с опциями: -DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON -DUSE_GOST_DOC_GEN=ON
После сборки Python 2.6.6 в момент исполнения уже не потребуется кикаду. KiCad будет подгружать интерпретатор питона из офиса (все версии офиса распространяются вместе с питоном, который находится в директории офиса). Но и мешать никакой отдельно установленный питон не должен на этапе исполнения кикада.

5) установить собранный KiCad

6) отредактировать пути в файле KiCad-GOST-doc-gen.bat (путь к офису и путь к кикаду, см. вложение к сообщению) согласно путям к установленным программам на вашей машине

7) запустить KiCad-GOST-doc-gen.bat

При запуске KiCad-GOST-doc-gen.bat настраиваются пути к питону офиса; запускается офис в режиме listening (пока убрал запуск из самого кикада и перенес этот запуск в KiCad-GOST-doc-gen.bat, чтобы не вываливалась ошибка в кикаде на захаркоденый путь к офису); запускается кикад

----------------

Итог. В случае с виндой ситуация при применении Python-UNO стала лучше (хоть собирается теперь проект), но не идеальная.
При таком подходе есть зависимость между сборкой KiCad и версией OpenOffice / LibreOffice.
К примеру, если собрать KiCad по описанному алгоритму на базе Python 2.6.6, то KiCad будет работать только с OpenOffice 3.4.1 (ну и может еще некоторые версии офиса), в составе которого идет Python 2.6.6.
Если будем запускать к примеру LibreOffice 4.0.2, в составе которого идет Python 3.3.0 (и uno библиотеки собранные для именно этой версии Python 3.3.0), то сборка KiCad сделанная для Python 2.6.6 не будет работать с LibreOffice 4.0.2.

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

Так вот, какое у вас мнение? Можно с этим мириться или все-таки необходимо уйти от версионной зависимости?

На этот счет у меня есть новая идея X: запускать модуль uno_iface.py не из встраиваемого в KiCad Python-интерпретатора как сделано сейчас, а вместо этого запускать модуль uno_iface.py в питоне, идущем в поставке вместе с офисом. При этом превратить модуль uno_iface.py в сервер для KiCadа. То есть сделать следующую цепочку:
KiCad+GOST-doc-gen -> [uno_server.py -> office]
Взаимодействие между KiCad и uno_server.py сделать через TCP соединение.

При такой схеме тогда не должно быть никакой версионной зависимости.

Автор: Барановский Константин May 7 2013, 07:29

Думаю все таки стоит избавиться от зависимости.

Автор: viknn May 8 2013, 08:59

На http://electronix.ru/redirect.php?ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_doc/baranovsky_kicadbom2sp/
положил py-срипт К.Барановского для производства спецификации kicad на шаблоне LibreOffice.
Дополнительно сделан NSIS-скрипт для упрощения установки программы под Windows (пуск kicadbom2spec.exe).

Автор: AVL May 10 2013, 08:35

Реализовал идею с промежуточным сервером.
Теперь нет версионной зависимости на уровне сопряжения программ и теоретически должно работать с любой версией OpenOffice / LibreOffice.

Текущая ревизия 4111.

Проверено и работает в Debian 6.0.7 (OpenOffice 3.2.1) и Windows 7 (проверены OpenOffice 3.1.1 и OpenOffice 3.4.1).

Под Windows теперь не требуется вообще устанавливать Python, поскольку задействован Python, идущий в поставке вместе с офисом.
OpenOffice / LibreOffice SDK соответственно тоже не нужен.
Нужно установить только сам офис (OpenOffice / LibreOffice).

Под Linux (по крайней мере Debian) как оказалось Python не идет в поставке с офисом. Разработчики дистрибутива это делают намеренно и используется системный Python. Системный Python, идущий в дистрибутиве Debian полностью совместим с uno библиотеками, идущими с офисом, который так же идет вместе с дистрибутивом Debian.

Сборку на ubuntu пока не проверял (сломалась виртуалка), но по идее действия должны быть следующие:

Пакет python-dev больше не требуется.
Опцию -DUSE_GOST_DOC_GEN=ON убрал, достаточно указывать только -DKICAD_GOST=ON.

Сборка под винду теперь выполняется точно так же как и раньше, просто включая опцию KICAD_GOST:
-DKICAD_TESTING_VERSION=ON -DKICAD_GOST=ON

bat файл больше тоже не требуется (реализован поиск офиса и его питона из KiCadа).

Автор: AVL May 10 2013, 10:49

В ревизии 4112 добавил поддержку Python 3.
Теперь проверен и работает LibreOffice 4.0.2 под виндой (он поставляется с Python 3).

Автор: Барановский Константин May 10 2013, 12:04

AVL, спасибо за проделанную работу!
Ubuntu 13.04 32bit ревизия 4111 собралась после небольших правок (см. diff.txt).
При попытке создать спецификацию последовательно появляются два сообщения:

Автор: AVL May 10 2013, 15:14

Константин, спасибо за помощь.

Установил новую виртуалку с ubuntu 13.04 32bit.

Проверил, mb_str тоже не работает (как раз из-за него вываливается ошибка).

Сейчас в результате вернул использование TO_UTF8() как было в предыдущих коммитах.
Но когда был применен TO_UTF8() в винде кодировка не правильно отображалась.
Сейчас добавил принудительное декодирование в UTF8 в uno_iface.py, и это помогло.

Перепроверил в debian, ubuntu, Windows 7 (OpenOffice 3.1.1, OpenOffice 3.4.1 и LibreOffice 4.0.2). Сейчас везде работает.

Текущая ревизия 4113.

Автор: Барановский Константин May 10 2013, 17:09

4113 - собралась и работает.

Автор: AVL May 12 2013, 11:27

Всем привет.
В пятницу (10 мая) сделал запрос на слияние ветки lp:~al-lunev/kicad/GOST-doc-gen с lp:kicad.
Как и ожидалось, опять админы, пока в данном случае Жан-Пьер, противится.
Если кому интересно, читайте и участвуйте в этой "дискуссии": http://electronix.ru/redirect.php?https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen/+merge/163239

Основные камни преткновения:
1) Жан-Пьер считает, что встраивать данный инструмент в сам KiCad - это не правильно.
2) Жан-Пьер требует, чтобы исходники содержали литералы только на английском, а русский перевод делать через интернационализацию.

По 1-му пункту я ему объясняю, что иметь отдельное ПО - это не правильно и не удобно. И в данном случае технически не реально использовать промежуточный файл как он предлагает. Вдобавок я делаю менеджер компонентов, который постоянно читает/пишет атрибуты eeschemы. (Самое интересное, что в случае с pcad2kicad (изначально я его сделал отдельным исполняемым файлом, но в составе дерева исходников Кикада), они тогда уперлись и потребовали его переписать в виде плагина Pcbnew, то есть встроить в сам KiCad).

По 2-му пункту я ему объясняю, что GOST-doc-gen расчитан только на русскоязычных пользователей и сам ГОСТ на русском. Никак не предполагается, что генерируемые формы будут использоваться не русскоязычными пользователями. И зачем в таком случае усложнять жизнь мне и человеку, который это будет собирать?

Подробности и остальные аргументы читайте на http://electronix.ru/redirect.php?https://code.launchpad.net/~al-lunev/kicad/GOST-doc-gen/+merge/163239
Если требуется перевод на русский, пожалуйста, дайте знать.

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

Борьба с этими админами у меня уже продолжается с июня 2012, то есть уже год почти.
Уже все какие возможно капризы их выполнены, а к примеру pcad2kicadsch (lp:~pcad2kicad-committers/kicad/pcad2kicad) до сих пор существует в виде отдельного проекта и живет своей жизнью. Они до сих пор его не добавили в основную ветку! А pcad2kicadpcb добавили только в декабре 2012!

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

Мой план такой. Я сейчас еще понаблюдаю, что они решат по GOST-doc-gen. Если безрезультатно, то придется создать ветку lp:~GOST-committers/kicad/kicad или что-то вроде этого. Коммититься в нее. Синхронизироваться периодически с lp:kicad.
Условная компиляция KICAD_GOST - это и так по факту отдельный проект, собирается он только участниками этого форума для русскоязычных пользователей.
Исходный код части KICAD_GOST сопровождается тоже только разработчиками с этого форума. Так и так приходится самим синхронизироваться с изменениями, которые вне KICAD_GOST секции.

Значит тому и быть.

Автор: AVL May 12 2013, 22:22

Юрий, спасибо за сборку.

Как и обещал, добавил GUI менеджер компонентов (ревизия 4115).
Поскольку данный менеджер (я не говорю про сам генератор GOST-doc-gen) по идее может применяться любыми пользователями Кикада (не только ГОСТ пользователи), исходники его полностью на английском с расчетом на использование интернационализации. Потребуется руссификация.

Возможности менеджера компонентов:
1) список всех компонентов схемы с отображением полной строки в примерном виде в каком это попадет в КД
2) добавление новых исполнений
3) возможность просмотра и работы со списком компонентов в разных плоскостях (полный список, постоянная часть, переменная часть для выбранного исполнения)
4) указание компоненту в каких исполнениях он присутствует
5) возможность задать значение "Не устанавливается". В результате будет сделана отметка в ПЭ3, и данный компонент не попадет в спецификацию.
6) редактирование атрибутов компонента
7) если есть поз.обозначения вида A1C1, то такие компоненты образуются в комплекты и в соответствующем виде отображаются в КД
8) возможность группового редактирования компонентов
9) все изменения сделанные в менеджере компонентов автоматически, не видимо для пользователя, отражаются в eeschema и наоборот, все изменения сделанные в eeschema появляются в менеджере компонентов
10) запуск генератора перечня элементов (ПЭ3) и спецификации из менеджера компонентов (должен быть установлен OpenOffice или LibreOffice)
Идея реализации данного менеджера компонентов похожа на проприетарный генератор перечней Брагина.
------------------------------

У меня вопрос к Юрию Викулову и Андрею Федорушкову по руссификации:
На сколько я понимаю придется создавать ветку документации (bzr branch lp:~kicad-developers/kicad/doc)? Раз пока GOST-doc-gen не находится в lp:kicad и не известно будет он ли вообще там.
То есть я вижу сейчас следующую проблему. Если добавлю перевод в lp:~kicad-developers/kicad/doc, то скорее всего мой перевод будет затерт следующим коммитом, который будет сделан на базе lp:kicad, так как в lp:kicad отсутствуют фразы, которые есть в lp:~al-lunev/kicad/GOST-doc-gen.
Я сегодня пробовал запустить poedit, и он если видит, что в новых коммитах какие-то фразы уже отсутствуют, то выкидывает их, и результат сохраняется без старых фраз.
Поэтому я вижу выход из ситуации - создать ветку документации, которая будет в паре с lp:~al-lunev/kicad/GOST-doc-gen.

Если все так, то, Юрий и Андрей, вам бы это не помешало делать сборку, если документация будет в другой ветке отличной от lp:~kicad-developers/kicad/doc?
Либо может есть другой вариант как поступить с документацией?

Автор: viknn May 13 2013, 16:58

Думаю, что это не помешает взять ru-перевод из отдельной ветки для GOST-doc-gen, поместить его в GOST-сборку.
Надо подумать о методе пост-копирования ru-перевода новых сообщений из новых версий развития основной ветки kicad.
Может часть сообщений, нужных только ru-сообществу, делать изначально ru.

Автор: AVL May 13 2013, 23:09

В принципе уже все ясно с настроем админов проекта. Беспредел одним словом, который длится без конца.

Переименовал ветку lp:~al-lunev/kicad/GOST-doc-gen в lp:~kicad-gost-committers/kicad/kicad,
а ветку lp:~pcad2kicad-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/pcad2kicad

Добавил в нее участников среди русскоязычных разработчиков.
Если кто-то не хочет быть участником среди добавленных, дайте знать.

Все кто в этом списке, у вас есть доступ на запись в http://electronix.ru/redirect.php?https://code.launchpad.net/~kicad-gost-committers/kicad/kicad

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

Данную ветку рассматриваю альтернативной ветке lp:kicad.
Предлагаю давать возможность работать в ветке lp:~kicad-gost-committers/kicad/kicad по возможности всем желающим, не только ГОСТ-разработчикам.

Планирую ветку lp:~kicad-gost-committers/kicad/pcad2kicad смержить с lp:~kicad-gost-committers/kicad/kicad

Если есть замечания / пожелания, пишите.

Автор: Сергей Борщ May 14 2013, 07:10

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

Автор: AVL May 14 2013, 09:10

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

Единственное, может есть смысл все-таки оставить конструкции #ifdef KICAD_GOST #endif с целью сохранить некую границу между lp:kicad и lp:~kicad-gost-committers/kicad/kicad. Это, с моей точки зрения, облегчит работу при слияниях.

Не исключаю, что часть исходников все-таки будет вливаться из lp:~kicad-gost-committers/kicad/kicad обратно в lp:kicad.
Данное действие сможет делать самостоятельно Андрей Федорушков, если нет для этого препятствий. Судя по настрою админов, чувствую препятствия есть. И я пока не знаю мнение Андрея.
Также данное действие смогут делать админы lp:kicad, если вдруг снизойдут до этого.

Если вы поддерживаете сохранить конструкции #ifdef KICAD_GOST #endif, то изменения не касающиеся ГОСТ также предлагаю помещать в эти конструкции. Поскольку любые изменения, не только ГОСТ, сложно протолкнуть в lp:kicad. А конструкция #ifdef KICAD_GOST #endif, как я уже сказал, с моей точки зрения, облегчит нам работу по слиянию. И скорее всего облегчит работу тем, кто будет вливать изменения в lp:kicad.

Поскольку предлагаю помещать любые изменения в #ifdef KICAD_GOST #endif, при условии, что вы согласны и считаете это правильным, возможно имеет смысл переименовать эти дефайны в какое-то более универсальное имя вместо KICAD_GOST.

Автор: Сергей Борщ May 14 2013, 09:52

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

Автор: AVL May 15 2013, 08:37

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

Поразбирался с этой проблемой, с одной стороны обнаружил, что wxFrame некорректно обрабатывает событие wxEVT_ACTIVATE (фрейм теряет фокус даже, если нажать на ComboBox этого фрейма), с другой стороны я не учел, что при добавлении нового исполнения, выпадет диалоговое окно, и фрейм по нормальной логике потеряет фокус.

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

Это временная мера. Буду дорабатывать этот механизм, чтобы все-таки окно менеджера было независимым окном и было бы можно работать одновременно с eeschema и менеджером компонентов, не закрывая каждый раз окно менеджера компонентов.

По крайней мере сейчас ничего не "падает".

Текущая ревизия 4117 (lp:~kicad-gost-committers/kicad/kicad).

Автор: AVL May 15 2013, 21:39

Мне в личном письме Жан-Пьер написал такое, что существенно меняет картину по поддержке ГОСТ.
Я ему "порекомендовал" описать их намерения и видение по этому поводу публично на developer mailing list.
Данные намерения ожидаются в пользу ГОСТ. Как будет на самом деле, посмотрим.

Автор: tema-electric May 17 2013, 02:30

Собрал последнюю ревизию из репозитария lp:~kicad-gost-committers/kicad/kicad
Кроме нее больше ничего не докачивал.

Вылезает окно с ошибкой при попытке сгенерировать перечень: RPC_DOC_IFACE: Unable to load document

Собирал с такими опциями

Что я сделал не так?

Автор: AVL May 17 2013, 06:06

А какое наименование дистрибутива Linux? полностью?

Автор: tema-electric May 17 2013, 07:03

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

Автор: AVL May 17 2013, 07:13

Для Ubuntu 13.04 32-bit необходимо было установить пакет python-uno:
sudo apt-get install python-uno

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

Однако, судя по ошибке, не похоже, что это из-за неустановленного python-uno.
В любом случае необходимо установить этот пакет (если еще не установлен).
Если не поможет, я сегодня ночью, либо завтра установлю виртуалку с Ubuntu 10.04, посмотрю что не так.

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

Автор: tema-electric May 17 2013, 07:51

На машине нет OpenOffice. Стоит только LibreOffice 4.0. Устанаваливался из deb пакетов.
Еще есть вопрос по русификации самого окна GOST_Tools. Нужно докачать какие-то пакеты или это просто временно так сделано?

Автор: AVL May 17 2013, 08:25

LibreOffice тоже поддержан. Как раз в Ubuntu 13.04 выполнялась отладка на базе LibreOffice.
OK, тогда посмотрю на виртуалке что получится.

Руссификация в процессе. Ветку с документацией, соответствующую ветке lp:~kicad-gost-committers/kicad/kicad, создал здесь: lp:~kicad-gost-committers/kicad/doc

Автор: AVL May 17 2013, 21:29

Установил Ubuntu 10.04 (http://releases.ubuntu.com/lucid/ubuntu-10.04.4-desktop-i386.iso) на виртуалку.

выполнил:


Пакет python-uno не устанавливал, он уже был установлен. (получается что данный пакет предустановлен по крайней мере в Debian 6 (Squeeze) и Ubuntu 10.04, а вот в Ubuntu 13.04 он не предустановлен почему-то).

У меня все запустилось, работает.
В этом дистрибутиве предустановлен OpenOffice 3.2.0 и системный Python 2.6.5.

Попробую приблизиться к Вашей конфигурации, tema-electric.

Выполнил все обновления, которые предложил Update Manager. Опять все работает.

LibreOffice в репозитории Ubuntu для Ubuntu 10.04 вообще нет.
А LibreOffice 4.0.3 есть в Ubuntu 13.04. Но чувствую, если пытаться установить эти пакеты из репозитория Ubuntu raring, то выполнится апгрейд всего дистрибутива до Ubuntu raring.

Пошел другим путем, скачал http://electronix.ru/redirect.php?http://www.libreoffice.org/DownloadRedirect.php?target=http://download.documentfoundation.org/libreoffice/stable/4.0.3/deb/x86/LibreOffice_4.0.3_Linux_x86_deb.tar.gz
далее:


При запуске генератора перечня выпадает ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
Проверяю системный Python так и остался версии 2.6.5:


А вот в директории /opt/libreoffice4.0/program есть свой Python:


В данном случае понятно откуда ошибка RPC_DOC_IFACE: Unable to connect to RPC document server
В дистрибутивах Debian Squeeze и Ubuntu raring предустановленные офисы идут без своего питона. Питон используется системный.
В GOST-doc-gen пока на это и рассчитывается, что используется системный Python под Linux.
Получается, что при другом способе установки (установка пакетов deb из LibreOffice_4.0.3_Linux_x86_deb.tar.gz) как и в Windows используется Python, идущий в поставке с офисом.
Как данную ситуацию исправить - мне понятно, это доработаем.

А вот все-таки откуда берется ошибка RPC_DOC_IFACE: Unable to load document мне не понятно
tema-electric, есть идеи, почему не получается повторить ситуацию как у Вас?
Также пришлите, пожалуйста, результат выполнения команды:
$ python --version

Автор: tema-electric May 18 2013, 05:46

Open Office вроде штатный шел, но я его снес после уставновки LibreOffice. Сносил культурно через GUI. Не помню, как называется штатная утилита Update Center или Package Center или ....


По питону станет известно только в понедельник. Тачанка на работе .
Есть вероятность, что стоит питон 2.7, но она очень маленькая и там инсталяция была через altinstall. Это точно было на старой системе, а на новой, вроде, не успел еще.


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

1) Могу поставить штатный офис, и сравнить.
2) Можно сгенерировать перечень установленных пакетов, и сравнить. Не запомнил как это делается, но знаю что возможно.
3) Запустить KiCAD через консоль, посмотреть что он в нее выкидывает. Может там больше инфы.

Автор: AVL May 18 2013, 10:31

Да, сначала давайте так и сделаем.

В любом случае добавил поддержку инсталляций OpenOffice/LibreOffice, которые поставляются вместе с Python в случае Linux (это те установочные пакеты, которые можно скачать с сайтов www.openoffice.org и www.libreoffice.org).

текущая ревизия 4119 (lp:~kicad-gost-committers/kicad/kicad)

Автор: AVL May 18 2013, 14:43

У меня еще вопрос к Юрию Викулову и Андрею Федорушкову по руссификации (или может тоже кто подскажет). Делаю следующее:
1) bzr branch lp:kicad
2) bzr update -r4115 (на ревизию, для которой в последний раз делался русский перевод)
3) bzr branch lp:~kicad-developers/kicad/doc (текущая ревизия 441)
4) запускаю poedit (версия 1.4.2)
5) открываю File->Open, выбираю файл в хранилище документации: doc/internat/ru/kicad.po
6) открываю Catalog->Settings->Paths, изменяю Base path: с /home/faa/Project/kicad-dev на корневую директорию моего клона lp:kicad
7) нажимаю Catalog->Update from sources. Появляется окошко Update summary, в котором написано, что изменений нет (0 new, 0 obsolete)
8) нажимаю OK
9) нажимаю File->Save, после чего файл internat/ru/kicad.po примерно на 50% отличается от оригинала (пересортица строк по всему файлу).

Из-за чего это может быть? Может влияет версия poedit? Кто подскажет тогда с помощью какой версии poedit был сохранен файл internat/ru/kicad.po (в его содержимом версия poedit не указана).
Не хочется добавлять перевод менеджера компонентов на русский язык, в результате чего появится порядка 20 новых строк, но при этом весь файл internat/ru/kicad.po изменится до неузнаваемости.

Автор: AVL May 18 2013, 20:02

Как обещал, влил ветку lp:~kicad-gost-committers/kicad/pcad2kicad в lp:~kicad-gost-committers/kicad/kicad
ветку lp:~kicad-gost-committers/kicad/pcad2kicad удалил.

Также добавил в диалоговое окно "о программе" ссылку на этот форум (кто-то помню на этом форуме предлагал это сделать).

Добавил в eeschema пункт меню: Tools->Run pcad2kicadsch converter, чтобы не искать и не запускать конвертер из командной строки.

Автор: viknn May 19 2013, 19:18

Я использую poedit 1.4.1 в Windows. Что у Андрея не знаю, он формирует ru/kicad.po/mo.
Предложения по улучшению перевода отсылаю ему или через форум. Исходники давно не сканировал.

Автор: tema-electric May 20 2013, 02:50

В консольке тихо. Никаких записей об ошибках.
Запустил kicad под root, бестолку.
Поставил штатный OpenOffice. Не помогло.
Снес python-uno и установил заново. Не помогло.

Пересобираю последнюю версию. Алгоритм сборки один и тот же всегда.
Хочу обратить внимание, на то что инсталирую в /usr. Помнится, штатный кикад вставал в /usr/local
Установка через checkinstall не всегда заканчивалась хорошо. В таких случаях я использовал sudo dpkg -i --force-all kicad.
Не знаю, на сколько это плохо. С ГОСТовским KiCAD пока еще не применял.
Установка всегда идет поверх существующей версии.


Пересобрал

Все также: RPC_DOC_IFACE: Unable to load document

Прикладываю список пакетов в моей системе. Может у меня чего-то не хватает.
 packagelist.txt ( 234.61 килобайт ) : 856

Автор: AVL May 20 2013, 07:47

Удалил я свою предыдущую установку и повторил именно как у Вас:

с параметрами что-то не так: USE_PCBNEW_NANOMETRES=ON USE_BOOST_POLYGON_LIBRARY
по идее ж должно -D перед ними. Но это не играет роли сейчас.

В результате установился kicad в /usr и все работает.
Прикладываю свой список пакетов.

Хочу обратить внимание, что в Вашем списке пакетов мне подозрительно место:

То есть часть общих пакетов идут из одной установки, а kicad - из другой.
Предлагаю сделать следующее:


Я попробовал сэмулировать такую же ситуацию как у Вас, но мне не удалось установить пакет, выдалась ошибка конфликта, что логично:

Автор: tema-electric May 20 2013, 10:44

Привычка с винды осталась поверх закатывать. Да и библиотеки вроде в common лежат.
Попробовал. Даже kicad-doc-ru удалил. Бестолку.


ммм, у dpkg есть ключик --force-all, который поставит один кикад поверх другого.

Попробовал многое. Сравнил пакеты с разных систем и доустановил отсутствующие (freeglut3-dev). Еще питон 3.1 поставил на всякий случай.
Пробовал снести весь kicad полностью (apt-get purge kicad) и поставить заново. Заколдованный круг.
Ваш deb пакет подойдет для моей машины или нет? Может проблема в сборке? Что-то где-то не так компилится...

Автор: AVL May 20 2013, 12:10

Сегодняшний deb пакет смогу дать поздно вечером только, дома он.

1) Попробуйте выполнить which kicad
Допустим результат будет /usr/local/bin/kicad
2) Далее нужно выполнить ls -la /usr/local/bin/kicad
в списке должно показать директорию GOST-doc-gen
3) Далее нужно выполнить ls -laR /usr/local/share/kicad/GOST-doc-gen

Результат выполнения каждой из 3-х команд, пожалуйста, покажите.

Улучшил диагностику открытия файлов odt в ревизии 4124.
Пересобрал для ревизии 4124 deb файл (прикреплен к сообщению).
Там теперь должна быть ошибка с указанием пути к файлу, который не может открыть через RPC. Пожалуйста, пришлите эту инфу тоже.

Автор: tema-electric May 21 2013, 01:57

Поставил вашу сборку, окошко выпало, соответственно, с другой подписью:

Автор: AVL May 21 2013, 07:34

Добавил логирование RPC команд в файл uno_iface.py, приходящих из eeschema.
Нужно выполнить:
1) распаковать прикрепленный архив
2) sudo cp uno_iface.py /share/kicad/GOST-doc-gen/templates/uno_iface.py
3) запустить eeschema, попытаться сгенерировать КД
4) в Вашей HOME директории должен будет появиться файл kicad_uno_iface.log, пожалуйста, пришлите его.

Автор: tema-electric May 21 2013, 08:06

Немного кривой путь ... но я поправил как надо ( /usr/share/kicad/GOST-doc-gen/uno_iface.py).
Содержимое лога.

Автор: AVL May 21 2013, 08:17

Еще раз, пожалуйста )

Автор: tema-electric May 21 2013, 08:24

Автор: AVL May 21 2013, 08:46

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

Приложил еще один вариант скрипта.
1) нужно сделать тоже самое еще раз как в предыдущем сообщении и прислать лог.
2) далее выполнить и прислать результат:

3) далее выполнить soffice из командной строки (именно так, чтобы убедиться, что офис так запускается), должен открыться офис. В меню Help->About... скопировать полную версию офиса и прислать это значение.

Просьба в системе ничего не переустанавливать пока (офис, питон, python-uno).

Автор: tema-electric May 21 2013, 09:03

Нет, офис вообще себя никак не проявляет.


Скрипт будущего Тю-тю.


$ ls /opt
Adobe deadbeef libreoffice4.0


soffice - неа, не работает. Либра запускается иначе ... libreoffice4.0

Автор: AVL May 21 2013, 09:54

Эхх, забыл скрипт я приложить ) Уже не дома я, нет его с собой.

/opt/libreoffice4.0/program/python --version
Что пишет?

Я понимаю таким образом же запускается? :
/opt/libreoffice4.0/program/soffice

Если да, то какая версия в Help->About... ?

Автор: tema-electric May 21 2013, 09:59

Help->About Версия 4.0.1.2 (ID сборки: 84102822e3d61eb989ddd325abf1ac077904985)

Автор: AVL May 21 2013, 11:01

С версиями все в порядке.

Попробуйте сделать следующее:
1) убедиться, что никакие процессы soffice не запущены:
$ ps aux | grep soffice
a-lunev 17890 0.0 0.0 7548 880 pts/5 S+ 14:59 0:00 grep soffice

(никаких других строк быть не должно)

2) запустить интерпретатор
$ /opt/libreoffice4.0/program/python

3) прямо в окне интерпретатора вбить последовательно строки:
>>> import uno
>>> local = uno.getComponentContext()
>>> resolver = local.ServiceManager.createInstanceWithContext( "com.sun.star.bridge.UnoUrlResolver", local )
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
__main__.NoConnectException: Connector : couldn't connect to socket (Success)

Должна появиться ошибка как указано.

4) Не закрывая интерпретатор, выполнить в другом терминале:
$ /opt/libreoffice4.0/program/soffice --invisible "--accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager"

5) повторить в интерпретаторе:
>>> context = resolver.resolve( "uno:socket,host=localhost,port=8100;urp;StarOffice.ComponentContext" )
ошибок быть не должно теперь

6) далее:
>>> desktop = context.ServiceManager.createInstanceWithContext( "com.sun.star.frame.Desktop", context )
>>> document = desktop.loadComponentFromURL( "file:///usr/share/kicad/GOST-doc-gen/templates/SpecificationFirstSheet_template.odt", "_blank", 0, () )

должен открыться libreoffice с открытым документом

Автор: tema-electric May 21 2013, 11:22

Все получилось. Но прежде чем все получилось я грохнул офис в трее, что стартует по автозапуску, и еще офис по автозапуску для root. Чего он был запущен, я не совсем понял.

Выглядело это так ...


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

Автор: AVL May 21 2013, 13:08

Не могу понять откуда такая строка появилась:
"tenzor 2257 0.0 0.5 188196 10664 ? Sl May20 0:02 /usr/lib/openoffice/program/soffice.bin -invisible -accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager --invisible --accept=socket,host=localhost,port=8100;urp;StarOffice.ServiceManager -splash-pipe=4"

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

Автор: tema-electric May 21 2013, 15:13

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

Автор: tema-electric May 22 2013, 02:29

Мягко говоря, аномалия. Перезапустил тачанку сегодня:

И что самое непонятное, GOST Tools работает. Ему больше ничего не надо. Неужели надо было перезагрузиться?

У GOST Component manager нет пока русификации? Я залил с launchpad вашу ветку kicad/doc.
Поле "Наименование" содержит названия типа Capacitor ... Resistor ...
Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются

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

Спасибо

Автор: AVL May 22 2013, 05:26

Насчет перезагрузки, видимо из-за того, что оказались установлены оба типа офиса, да еще и одновременно запущены, были такие глюки. Наверно можно было не перезагружать, а просто сделать sudo kill лишних процессов.

Ветку lp:~kicad-gost-committers/kicad/doc пока только создал, но русский перевод еще не добавил. У меня пока не решенный вопрос с poedit, о котором я писал ранее.

Насчет
"Из интересных особенностей при генерации ПЭ ))
Первый лист: C34 1 Not installed
Второй лист: C100,C101 2 Не устанавливаются"
так и есть. Изначально я делал все на русском, поскольку бессмысленно делать еще на каком-то другом языке.
Был разговор с Jean-Pierre, он требовал, чтобы GOST-doc-gen был по умолчанию на английском. Согласиться с этим не могу.
Однако, для менеджера компонентов думаю есть смысл поддержки интернационализации, потому что он дает функции, которые будут полезны любому пользователю.
Таким образом, начал адаптировать на английский. А поскольку грамматика у русского и английского разная, то поплыла логика формирования падежей, числа и т.д.
Пока пришел к выводу, что GUI можно делать через интернационализацию, а содержимое выпадающих списков таких как поле "Наименование", надо формировать на основе языка, выбранного где-то в меню.
К примеру, я люблю GUI на английском, но значения в выпадающих списках менеджера компонентов мне нужны только на русском. Также такая опция выбора языка в меню дала бы возможность четко определять логику по формированию языковых конструкций в самом GOST-doc-gen в зависимости от языка. Так что буду это дорабатывать.

Автор: Aldan May 22 2013, 18:58

Самая острая фаза ремонта моей квартиры миновала и у меня стало появляться немного времени для форума. Первым делом решил потестировать возможность вывода текстовой документации. Поскольку вариант от AVL не требует что-то доустанавливать (а ЛибреОфис у меня и так уже установлен), то я остановился именно на нем. Скачал сборку для винды kicad_ins_gost_docgen_4115 с http://electronix.ru/redirect.php?ftp://ftp.kicad.ru/pub/kicad/kicad_eskd_doc/lunev_set/ и открыл схему проекта. Далее, зашел в «инструменты» и запустил «GOST Tools” и в раскрывшемся окне зашел в “файл» и выбрал генерацию спецификации. После этого запустился ЛибреОфис и показал пустой бланк (нет ни названия схемы, ни компонентов в списке).
Казалось бы, работая с конкретной схемой, можно надеяться, что все ее атрибуты будут автоматически использованы при формировании документа, а у меня что-то ничего не получилось.
Каких-то дополнительных возможностей изменить сложившуюся ситуацию к лучшему в опциях менеджера перечня я не обнаружил, да и хоть какая-то краткая инструкция по использованию GOST Tools мне на глаза тоже не попалась. Делаю вывод, ремонт квартиры совсем меня доканал и я не врубаюсь в то, что очевидно для для остальных форумцев, которые успешно генерят себе текстовую документацию в своих проектах и в ус не дуют.
AVL, подскажите, что нужно сделать, чтобы бланк спецификации был сгенерирован с заполненными полями.

Автор: AVL May 22 2013, 20:09

Более актуальная сборка http://electronix.ru/redirect.php?ftp://ftp.kicad.ru/pub/kicad/install/win32/gost_commit/kicad_gost_commit_bin_4126.zip, рекомендую начать с нее.

К сожалению, я не писал документацию на менеджер компонентов + GOST-doc-gen.
Скорее всего прийдется это сделать.
Пока отвечаю на Ваш вопрос. По умолчанию (если Вы взяли сырую схему) все компоненты имеют не заданные поля "Наименование" (атрибут Title), ну и остальные поля тоже не заданы.
Компонент начинает отображаться в КД после того как будет задано поле "Наименование", например, Конденсатор.
Сделано так для удобства. К примеру в схеме 1000 компонентов. Вы решили поработать и назначили через менеджер компонентов параметры двухстам компонентам, и решили продолжить работать на следующий день. Вы открываете проект, смотрите какие компоненты уже имеют заданное поле "Наименование", а какие имеют пустое поле. И понимаете, что заполнять нужно дальше те компоненты, у которых поле "Наименование" пустое.
Также скоро добавлю иконки напротив каждого компонента, будет нагляднее эта логика.

Также не забывайте про пример корректно заполненной схемы demos/GOST/multivibrator.sch

Конечно же есть ряд правил как нужно работать с менеджером компонентов. Документацию делать надо.


Проверил 1.4.1 под винду. Проблема, к сожалению, не ушла.

Проверил также версии 1.3.9, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.5.5. Безуспешно.

Автор: Aldan May 22 2013, 20:52

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

Да, схема у меня «сырая». Задал у нескольких компонентов в списке поле «наименование» и, о чудо, - спецификация на эти несколько компонентов сформировалась! Это вызвало необычайно бурные эмоции, т. к. наконец-то появилась эта долгожданная возможность вывода текстовой документации! ОГРОМНОЕ ВАМ СПАСИБО!
Кстати, самый первый компонент в моей схеме — кварцевый резонатор, а его в списке наименований нет. Более детальное тестирование продолжу несколько позже, т. к. мой ремонт квартиры еще не закончен, но радость от сегодняшнего события просто огромная дает стимул побыстрее его завершить!

Документацию никто не любит делать, это естественно, т. к. все силы и время съедает написание программы, но все же хотя бы несколько пояснительных предложений стоит сочинить, т. к. только в этом случае созданное приложение будет использоваться с максимальной эффективностью. Хорошая документация, что позолота на добротном изделии.
----------------
И еще, обычно Жан Пьер заканчивает вылизывание стабильной сборки не позже мая месяца, по крайней мере так было раньше. Так вот, возможно версия 4017 http://electronix.ru/redirect.php?https://code.launchpad.net/~kicad-stable-committers/kicad/stable или какая-то ближайшая как раз этой самой наифинальной и будет. Так вот, хотелось бы иметь стабильную сборку со всеми последними усовершенствованиями в т.ч. и с генератором тектовой документации.

Автор: AVL May 22 2013, 21:01

Если Вы имеете в виду попадание менеджера компонентов+GOST-doc-gen в ветку lp:kicad, то боюсь это не реально из-за серьезных разногласий с командой lp:kicad. Если будет время, почитайте, некоторая информация была озвучена на этом форуме.
В первоисточнике и в полном виде об этом можно почитать здесь:
http://electronix.ru/redirect.php?https://code.launchpad.net/~kicad-gost-committers/kicad/kicad/+merge/163239
и здесь:
http://electronix.ru/redirect.php?https://lists.launchpad.net/kicad-developers/msg10412.html

Поэтому была создана ветка lp:~kicad-gost-committers/kicad/kicad

Автор: Aldan May 22 2013, 21:46

AVL, я, к сожалению, почти не разбираюсь в тонкостях взаимодействия стабильной ветки Кикад со всеми остальными его ветками. По жизни я вынес для себя урок: без крайней необходимости не переходить со стабильной сборки на тестовую, т. к. у меня был досадный случай некоторой порчи проекта при работе на тестовой сборке.
Вот я и стараюсь работать только на стабильных сборках, а тестовыми только иногда для тестирования пользоваться.
Видимо я наивен, т. к. до этого дня считал, что стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности, т. е. «вылизанная». Если к такой сборке прикручивается некий завершенный и стабильный программный код для расширения ГОСТ-функциональности, то, весьма вероятно, что результирующий программный продукт тоже будет стабильным.
Словом, хотелось бы в обозримом будущем иметь такую стабильную сборку со всеми ГОСТ-наворотами, а не тест-сборку, дабы не наступать на старые грабли в виде порчи проекта в самый не подходящий момент.
Хочется верить, что такое пожелание не является не исполнимым и вскоре стабильная сборка «с полным фаршем» будет доступна. Иначе, я перестаю что-либо понимать в логике развития ГОСТ-Кикада - что, теперь стабильных ГОСТ-сборок никогда не будет?

Автор: tema-electric May 23 2013, 02:19

По опыту работы с KiCAD в 2012 году пришел к выводу, что лучше собирать тестовые сборки. Тоже верил в стабильные по началу, пока не отправил герберы с косяками в заказ ... Как мне показалось, стабильные сборки мало кто тестит. А тестовые - наоборот.

Автор: AVL May 23 2013, 05:00

Здесь могу предложить такой вариант, дожидаемся, когда менеджер компонентов+GOST-doc-gen станет "стабильным" и мержим этот код с последним стабильным релизом lp:kicad. Получаем, надеюсь, "стабильный" агрегированный релиз.

Лично я не доверяю ни тестовым релизам, ни стабильным. Причем, что кто-то несет ответственность за полную исправность стабильного релиза? Нет, это не так.
Чтобы не испортить проект платы на любом из этапов ее разработки/сохранения на диск, я пользуюсь системой контроля версий. В данный момент использую git. Если становится понятно, что что-то пошло не так, то всегда можно вернуться к предыдущему коммиту и восстановить плату в нормальном виде.
Прежде, чем отдавать плату в производство, я обязательно визуально проверяю все сгенерированные gerber-слои и файлы сверловки. Удобная для этого программа - gerbv,
В случае с KiCad, стабильную сборку не использую никогда. Иначе буду сидеть в прошлом веке. Но это не значит, что так нужно делать всем. Каждый решает для себя сам и определяется с рисками.

P.S.:
NO WARRANTY

11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

На самом деле пока не видел ни одной коммерческой лицензии, где не было бы подобного отказа от ответственности.

Автор: tema-electric May 23 2013, 05:12

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

Автор: AVL May 23 2013, 06:07

Да уж, не повезло. А KiCad GerbView тоже не показывает тот дефект?

Автор: tema-electric May 23 2013, 08:43

Смотрел. Вроде не показал тогда. Сейчас проверил - показывает. Это про кикадовский viewer.
А так я им не пользуюсь. По началу пользовался. Причина проста.
В GerbV все настроено. В файле проекта (*.gvp) достаточно поменять ручками или скриптом имена герберов. Цвета слоев и порядок уже "как надо". Сами платы предпочитаю доводить по герберам. Там меньше лишних графических элементов. В Gerbv есть кнопка обновить ... а в кикадовском вьювере помойму нет.
Имена герберов тоже в кикаде излишне подробные. Для этого скрипт написан, в стиле

Автор: viknn May 23 2013, 18:29

AVL
Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:
1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?
2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?
3) dcm-файл можно не формировать.

Автор: AVL May 23 2013, 19:46

Ответ перенес в новую тему по http://electronix.ru/forum/index.php?showtopic=113016&view=findpost&p=1164739

Автор: viknn May 24 2013, 19:08

AVL
А нельзя ли в GOST-doc-gen сборке реанимировать кнопку BOM (или вставить Generate BOM в Component Manager).
После работы с GOST Component Manager компоненты получают новые поля и атрибуты.
Обновленный BOM можно будет использовать разными способами. В частности,
для выпуска карт рабочих режимов ЭРИ (для аппаратуры ВН).

Автор: AVL May 24 2013, 19:33

Да, можно.

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

Автор: viknn May 24 2013, 20:33

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

Автор: AVL May 25 2013, 11:25

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

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

Автор: AVL May 25 2013, 18:05

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

Автор: viknn May 25 2013, 18:14

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

Автор: Aldan May 25 2013, 22:32

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

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

Вот как раз для этого и должна быть стабильная сборка с гарантированным и проверенным результатом, чтобы всегда можно было к ней вернуться. Признаюсь, что хоть я и перестал доверять тестовым сборкам после неудачи в прошлом, но время от времени пользуюсь ими с большим удовольствием, потому что знаю, что у меня есть «тыл» - проверенная стабильная сборка.
Словом, стабильные релизы должны появляться, иное положение дел просто утопия.
Еще несколько лет назад все сборки на нашем фтп выкладывались в двух исполнениях — с установщиком и просто набор обновляемых файлов, как сейчас, причем делалось это регулярно. Потом сборки стали появляться гораздо реже и преимущественно только в виде обновляемых файлов. Однако, стабильные релизы все же всегда выкладывались.
В последнее время сборки для винды стали появляться еще реже и 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) http://electronix.ru/redirect.php?ftp://ftp.kicad.ru/pub/kicad/library/aldan/ которую я составил и, надеюсь, не только я пользуюсь, компоненты имеют в своем названии префиксы согласно ГОСТ 2.710-81 (СТ СЭВ 6300-88) «Обозначения буквенно-цифровые в электрических схемах».
Префикс представляет из себя буквенное обозначение согласно ГОСТ и символ «_». Например: R_, SA_, VD_. Таким образом, префикс легко опознается, по нему можно заполнить поле «Наименование», а его отбросить от названия.
При помощи использования информации префиксов и имея компоненты с заполненными полями текстовый документ будет генерироваться автоматически после небольшой коррекции. Так вот, моя просьба использовать информацию префиксов, а их самих отбрасывать.
Уффффф..., пока все. Не знаю, что я тут понаписал на дурную голову. Если что, простите Скоро у меня потихоньку начнет появляться время и я продолжу свое нудное повествование.

Автор: tema-electric May 26 2013, 07:36

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

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

Автор: AVL May 26 2013, 08:08

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

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

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

На этот вопрос уже отвечал в http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1163994

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

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

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

Не совсем понимаю, для чего эти префиксы у наименований? Почему они не в позиционных обозначениях?
Автоматизировать заполнение полей "наименование" пока не берусь по 2-м причинам:
1) логика удобства незаполненности полей "наименование" объяснена в http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1164336
2) не для всех случаев есть прямое сопоставление префикса поз.обозначения наименованию. Например, VD - это может быть диод, а может быть и диодная сборка. Поправьте, если не прав.

Автор: Сергей Борщ May 26 2013, 10:49

И не пытайтесь даже. Это такой французкий подход к заполнению этих полей. http://electronix.ru/redirect.php?https://lists.launchpad.net/kicad-developers/msg03628.html в kicad-developers, Жан-Пьер с компанией нескольких человек, просивших сделать это буквально смешали с г...

Автор: AVL May 26 2013, 20:20

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


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

Автор: Aldan May 27 2013, 00:09

Скорее всего мы говорим о разных «стабильных» сборках, что и порождает наше недопонимание. Для прояснения данного вопроса вспомним как рождается финальный релиз в типичном проекте: сначала идет серия тестовых сборок, потом несколько релиз-кандидатов, а уж потом выкатывается финальный релиз о котором я и толкую.
Раньше Жан Пьер придерживался такой же цивилизованной модели разработки и после 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 и все станет понятно.

Автор: AVL May 27 2013, 05:59

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

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

Автор: AVL May 28 2013, 13:01

В этом http://electronix.ru/forum/index.php?showtopic=111723&view=findpost&p=1165798 задал вопрос по библиотекам.
Если нет возражений, есть смысл добавить их в lp:~kicad-gost-committers/kicad/library

Автор: Сергей Борщ May 28 2013, 13:11

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

Автор: AVL May 28 2013, 15:38

Ответил в теме по библиотекам в http://electronix.ru/forum/index.php?showtopic=111723&view=findpost&p=1165840

Автор: Aldan May 28 2013, 20:53

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

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

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

Автор: tema-electric May 29 2013, 05:00

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

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

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

Автор: AVL May 29 2013, 06:56

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

Автор: AVL May 31 2013, 20:28

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


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

Автор: AVL Jun 1 2013, 07:01

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

Автор: Guest_Aldan_* Jun 1 2013, 21:01

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

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

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

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

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

Автор: AVL Jun 2 2013, 07:05

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

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

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

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

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

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

Автор: Aldan Jun 2 2013, 20:38

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

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

Автор: AVL Jun 2 2013, 20:56

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

Автор: faa Jun 3 2013, 04:18

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

Автор: AVL Jun 3 2013, 21:12

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

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

Автор: tema-electric Jun 10 2013, 10:56

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

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

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

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

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

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

Автор: AVL Jun 10 2013, 13:27

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

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

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

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


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

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

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

Автор: tema-electric Jun 10 2013, 15:28

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

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

Автор: faa Jun 10 2013, 18:47

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

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

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

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

Автор: AVL Jun 10 2013, 19:22

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

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

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

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

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

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

Автор: AHTOXA Jun 11 2013, 04:55

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

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

Автор: AVL Jun 11 2013, 05:14

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


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

Автор: viknn Jun 11 2013, 17:58

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

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

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

Автор: AVL Jun 11 2013, 18:51

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

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

Автор: AHTOXA Jun 11 2013, 19:46

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

Автор: viknn Jun 12 2013, 04:49

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

Автор: AHTOXA Jun 12 2013, 05:36

Зачем?!

Автор: zöner Jun 12 2013, 08:56

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

Автор: mobidev Jun 13 2013, 06:40

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

Автор: tema-electric Jun 14 2013, 09:41

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

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

Автор: AVL Jun 14 2013, 10:49

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

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

Автор: AHTOXA Jun 14 2013, 15:43

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

Автор: AVL Jun 14 2013, 16:13

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

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

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

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

Автор: AVL Jun 14 2013, 21:26

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

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

Автор: Aldan Jun 15 2013, 05:36

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

Автор: Барановский Константин Jun 15 2013, 11:57

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

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

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

Автор: Aldan Jun 15 2013, 14:03

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

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

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

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

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

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

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

Автор: AVL Jun 15 2013, 22:35

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

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

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

Автор: Aldan Jun 16 2013, 22:13

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

Автор: tema-electric Jun 17 2013, 02:22

Александр недавно писал что и как, постов 10 выше в этой ветке. Не знаю, что еще нужно.


Да, поначалу были проблемы с тем, что если поле "Тип" не заполнить, то каждый раз будет автозаполнение. А я по первости их удалял, а ГОСТ-tools их снова автоматом заполнял. Но после того, как заполнил по рекомендациям Александра, то автозаполнения прекратились. Это было особенно актуально для микросхем, т.к. я не знал куда писать наименование в "Тип" или "Значение". Если в значение, тогда проблемы с автозаполнением. Если пробелом Тип везде задать, то его видно в перечне.

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

Чип 0805-X7R-25 В- 1 мкФ ±10 %
Чип 0805 1 кОм ±5 %

Вот здесь в кондеры забрался лишний пробел "В- 1 мкФ". В самом менеджере надпись выглядит как "В-1 мкФ". Резисторы я хотел сделать по подобию. Вообще предложение пробелы самим ставить, если нужны.

Автор: AVL Jun 17 2013, 08:14

Вы все ждете у моря погоды, что КД сгенерируется на основе произвольной сырой схемы полностью без Вашего участия
Мы можем идти в этом направлении автоматизации заполнения атрибутов на основе каких-то предопределений. Но пока этого нет в требуемом объеме. Чтобы это было, это нужно сделать. А прежде, нужно сначала понять что и как делать.

Одно из Ваших предложений было - добавить обработку префиксов полей Chip Name из библиотеки mixture.lib.
Так можно сделать. Прикручиваем кнопку, по нажатию на которую выполняется сканирование префиксов у поля Chip Name, выполняется сопоставление префиксов с ГОСТ наименованиями на основе таблицы. В результате атрибуты Title (Наименование в менеджере компонентов) заполнятся ГОСТ наименованиями. Заполненные атрибуты Title сохранятся обратно в схему. Если какие-то будут исключения, через менеджер компонентов пользователь поправит для определенных компонентов поле Title руками.

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

Теперь о "c_cap".
Менеджер компонентов читает атрибуты компонентов схемы и делает следующее:
Если у компонента в схеме нет атрибута Type (в сырой схеме его обычно не должно быть) , то в поле "Тип" менеджера компонентов отобразится значение обязательного атрибута Chip Name этого компонента. Иначе, если атрибут Type у компонента есть, то в поле "Тип" менеджера компонентов отобразится значение атрибута Type этого компонента.
Если атрибут Type отсутствовал у компонента, то после ввода в поле "Тип" в менеджере компонентов какого-то другого значения отличного от значения атрибута Chip Name, создастся атрибут Type, и с этого момента в поле "Тип" менеджера компонентов будет отображаться введенное пользователем значение (сохраняется в схему в виде атрибута Type).
Данный алгоритм используется только для поля "Тип" менеджера компонентов.

То, что попадает в ПЭ3 и спецификацию, грубо говоря, складывается из полей, которые можно видеть в менеджере компонентов.
Упрощенно в ПЭ3 столбец "Наименование" формируется конкатенацией значений полей из менеджера компонентов:
поле "Наименование" + поле "Тип" + поле "Подтип" + поле "Номинал" + поле "Допуск" + поле "Обозначение".

Теперь наверно вопрос, зачем такой алгоритм для поля "Тип"?
В основном это дает преимущество генерации КД на основе схем, выполненных в P-Cad, и скорее всего в большинстве других CAD.
У P-Cad есть обязательный атрибут Type, который обозначает имя компонента (не имя УГО). Проще всего объяснить для микросхем логики серии 74xx.
К примеру существует реальная микросхема SN74HC04D. Так вот нормальная ситуация, когда есть пикадовский компонент SN74HC04D (его атрибут Type="SN74HC04D"). Компонент у пикада - это агрегатор УГО, посадочного места и еще некоторой агрегирующей информации.

В KiCad поле Chip Name несет в себе другой смысл. Chip Name в KiCad - это имя УГО компонента. В случае KiCad значение Chip Name для микросхемы SN74HC04D будет = 7404.

В результате имеем:
1) для схем импортированных из P-Cad в KiCad в менеджере компонентов поле "Тип" будет иметь для вышеприведенного примера значение "SN74HC04D". В результате именно это значение и попадет в КД. Останется только задать поля "Наименование" = "Микросхема" и "Производитель" = "NXP" (и/или возможно ТУ еще).
2) для сырой схемы KiCad в менеджере компонентов поле "Тип" будет иметь для вышеприведенного примера значение "7404", что ни о чем не говорит, и в КД такое отправлять нельзя. Поэтому в менеджере компонентов для этого компонента в поле "Тип" нужно руками вбить "SN74HC04D". После чего в КД попадет то, что нужно.

Я совсем не продвинутый пользователь KiCad. Возможно не знаю откуда можно автоматом получить значение "SN74HC04D".
Однако при задании полей через менеджер компонентов, а это делается один раз при разработке схемы, вся проделанная работа по заполнению сохраняется в схему в виде атрибутов. То есть ничего не разрозненно, все внутри проекта, и введенная информация дополняет проект (многие из вводимых атрибутов на столько важны, что в некоторых ситуациях без них проект устройства не может считаться проектом). Нужно понять что за микросхема DD5 на схеме? Смотрим чему равен атрибут Type у компонента в схеме, либо открываем менеджер компонентов и смотрим в нем, ну и конечно же смотрим КД.

Может. Я, к сожалению, еще не вникал как сделано в скрипте. Нужно будет посмотреть.

Да, постараюсь заняться в ближайшее время. Русский перевод уже есть и как раз уже отсоединил логику генерации для русского и английского языков. Так что теперь есть на что ссылаться (GUI на русском) при написании документации.


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

Автор: AVL Jun 17 2013, 09:50

Здесь хочу добавить, что пока не вижу обоснования прикручивать эту программную обработку префиксов атрибутов Chip Name, которые добавлены в библиотеке mixture.lib, поскольку это частный случай реализации библиотеки mixture.lib.

С другой стороны, если говорить непосредственно о позиционных обозначениях (поле Reference), то такая обработка (даже и с таблицей сопоставления) скорее всего будет иметь смысл. Поскольку позиционные обозначения регулируются ГОСТом, и в данном случае хочется надеяться, что это не будет частным случаем. То есть мысль такая, если мы сможем написать список всех типов позиционных обозначений, которые соответствуют ГОСТ и при этом не будет неоднозначности в их трактовании, то такой список (таблицу) есть смысл программировать и обрабатывать (обрабатывать не chip name компонента, а его Reference, который также устанавливается на этапе создания библиотечного компонента).
Я поэтому и спрашивал ранее, почему префикс позиционного обозначения находится в поле chip name в библиотеке mixture.lib вместо того, чтобы находиться в самом позиционном обозначении (я пытался на тот момент вникнуть в логику mixture.lib). Вы, Aldan, тогда сказали, что эти префиксы находятся в поле chip name, чтобы было удобно выбирать библиотечный компонент из списка. Хорошо. Также понятно, что в том виде, в каком эти префиксы сейчас прописаны в поле chip name в библиотеке mixture.lib не получится прописать прямо в позиционные обозначения этих библиотечных компонентов. Например, префикс VD_DAO (точно сейчас не помню обсуждаемый пример) никак не ложится в формат позиционного обозначения.

А вот другой пример, позиционное обозначение DR - резисторная сборка.
ГОСТ явно не указывает, что DR - это резисторная сборка, однако ГОСТ указывает, что D - это микросборка, а R - это резистор.
То есть мы можем договориться, что все-таки DR - резисторная сборка - соответствует ГОСТу, и создавать библиотечные компоненты резисторных сборок строго с позиционным обозначением DR.
Как быть с диодной сборкой и другими не простыми наименованиями пока не знаю. Диодные сборки я обычно обозначал VD, из чего не возможно принять решение диод это или диодная сборка.


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

Автор: tema-electric Jun 17 2013, 10:04

А DD - это сборка сборок, а DA - сборка устройств
Тяжело приследовать здесь какую-либо логику. Вот http://electronix.ru/redirect.php?http://tremona.ru/wp-content/uploads/5457df3b58/05/16/elektricheskie_ce9.jpeg товарищи резисторные сборки вообще обозначают как E, а микросхемы все как D. В студенчестве мне было очень сложно отнести микросхему к цифровой или аналоговой. Хоть тот же микроконтроллер. Философия Гейзенберга )).

Автор: AVL Jun 17 2013, 10:31

Нет, согласно ГОСТ (номер ГОСТа на прошлой неделе указывал, сейчас нет под рукой) имеет значение позиция символа. В случае двухбуквенных обозначений для каждой буквы своя таблица по интерпретации в ГОСТе.
У ведущей буквы D, на сколько помню, варианты интерпретации: микросхема, микросборка и еще что-то.
У следующей буквы, видимо, детализация:
DD - цифровая микросхема
DA - аналоговая микросхема
DR - резисторная сборка
? - диодная сборка
по аналогии если рассуждать DC - конденсаторная сборка - я никогда не встречал.

Я поэтому и говорю, что надо договориться потому что наш ГОСТ (и не только) - это что-то с чем-то

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

Автор: tema-electric Jun 17 2013, 10:55

2.710


Да, это действительно проблема. Нет ничего хуже неопределенности, и слов типа "стандарт не запрещает", но и легче от этого не становится )).

Автор: faa Jun 17 2013, 17:01

Резисторные сборки обозначаем как RA (resistor array) или RN (network - если связи есть между резисторами). Внутри УГО ставили *R.
Набор конденсаторов - по аналогии CA или CN (внутри УГО *C).
В перечне - отдельным разделом "Резисторные/конденсаторные сборки".
Нормоконтроль пропускает без вопросов.
Диодные сборки - как набор из диодов VD1.1, VD1.2 и т.д.

Автор: AVL Jun 17 2013, 19:46

Открыл ГОСТ 2.710-81. Эти товарищи по ссылке в принципе ГОСТ не противоречат
Согласно ГОСТ элементы могут обозначаться однобуквенным или двухбуквенным кодом.
Вот примеры из однобуквенной таблицы:
D - Схемы интегральные, микросборки
E - Элементы разные (ну а чем резисторные сборки не "разные", раз отдельной категории для них нет )
Однако у товарищей по ссылке обозначение предприятия внизу написано "ГНБК", а вверху "НИЦС"

И я тоже обозначаю микросхемы одной буквой D, если микросхему не получается отнести ни к аналоговой, ни к цифровой.


А вот в ГОСТе не смог найти ничего похожего на RA / RN.

Да, но и мы успешно проходили сертификацию и последующие проверки, при этом у нас префикс DR для резисторных сборок

Это на схеме? А в ПЭ3 и спецификации что?


Посмотрел реализацию скрипта Константина. Так в GOST-doc-gen и так одинаково сделано в плане чтения из схемы. Различие в том, что в скрипте Константина читается атрибут "Группа", а в GOST-doc-gen читается атрибут "Title".

Автор: Aldan Jun 17 2013, 23:19

И у меня поначалу были проблемы и у кого-то еще они будут.., зачем это все? Если Александр напишет руководство объемом (20...30)% от того, что пишет за день на этом форуме, то таких проблем больше ни у кого не будет.

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

Если брать пару «обозначение-значение» на каждый компонент из схемы, то никакие поля дополнять и их заполнять не придется. Напрягать пользователя объемной и не нужной работой — ложный путь. Успешная работа скрипта Константина Барановского показала, что ничего этого не нужно.

В который уже раз, когда речь заходит об организации библиотек у меня складывается впечатление, что между нами какая-то стена недопонимания. Вы все время игнорируете мои слова насчет того, что некое обобщенное название компонента в библиотеке становится совершенно конкретным (и совершенно другим) в конкретной схеме. Постараюсь проиллюстрировать это еще одним примером и заодно покажу, что все это касается не только mixture.lib.
Зайдем в библиотеку analog_IC.lib. Просматривая компоненты мы будем видеть их реальные названия без всяких префиксов, т. к. каждое название относится только к одному конкретному компоненту а принадлежность к группе аналоговых микросхем содержится в самом названии библиотеки.
Однако, дойдя до буквы «о» мы увидим «OPAMP1_8» и еще пять других «OPAMP». В данном случае это уже не конкретное название компонента, а условное название группы «OPAMP» - операционные усилители. Сделано это для того, чтобы этими шестью условными компонентами описать несколько тысяч реально существующих операционных усилителей различных фирм.
«OPAMP1_8» означает, что это УГО одного операционного усилителя в корпусе с 8-ю выводами. «OPAMP2_8» означает, что это УГО двух операционных усилителей в корпусе с 8-ю выводами и т. д.
Если конкретные названия микросхем перекочуют в схему без изменения, то условные названия операционных усилителей будут заменены на конкретные названия компонентов в схеме. Таким образом, совершенно не важно как назывался компонент в библиотеке, важно как он в конце-концов называется в схеме. И если черпать информацию именно из схемы, то перечень будет содержать лишь то, что нужно и все косяки типа «с_сар» пропадут.

Как я написал выше: нужно сделать автозаполнение полей только тех компонентов, которые могут быть определены однозначно — C, R, L и т. д., если же однозначность невозможна, то такое поле не автозаполняется, а выделяется цветом до завершения ручного заполнения.

Это мое не совсем корректное выражение указывающее на то, что в скрипте Константина Барановского выводится именно та информация, что присутствует на схеме, а не в названиях компонентов в библиотеке.

Видимо, теперь все будет в полном порядке. Если что, Константин обещал, что поможет.

Автор: tema-electric Jun 18 2013, 03:52

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

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

По поводу того, надо ли автоопределять что-то. Думаю что это плюшка-дополнение. Сейчас можно работать и так. Есть ли время у Александра, другой вопрос. Кроме того, когда я предлагал делать библиотеки с предопределенными номиналами, что из этого получилось? В большинстве своем люди против. Да, полезно было-бы это делать, но это опция. Чем mixture.lib лучше других? У меня все библиотеки собственного изготовления, и я готов их адаптировать под GOST-Tools. И считаю, что без этого нельзя. Волосы нужно не только причесывать, но и мыть иногда.

PS: Честно, мне очень нужны были автогенераторы ПЭ и Спецификации. На создание подобных документов у моей коллеги уходило несколько дней, ввиду большого количества компонентов. То что есть сейчас снимает вопросы нескольких дней до половины дня, за что выражаю еще раз Большое Спасибо авторам GOST-Tools, и Александру в частности. В перспективе хотелось бы автогенерацию без настроек. Но этот вопрос упирается в библиотеки и у каждого они свои, похоже.

Автор: tema-electric Jun 18 2013, 05:57

Вернулась старая проблема "RPC_DOC_IFACE: Unable to put cell"

Шрифт в форматках страшный. Надо его копировать, как я щас вспоминаю.

Автор: AVL Jun 18 2013, 07:09

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

Да, шрифт нужно установить пока http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1170278.

Автор: Aldan Jun 18 2013, 09:02

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

Если бы Вы были внимательны к моим сообщениям, то давно бы поняли — я тот самый конечный пользователь:

Улыбнуло: «Солженицина не читал, но осуждаю»

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

Я писал ранее и об опциональности автоопределений. И вот Вы опять мне пишете:

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

Кто же спорит. Речь идет о поиске путей по усовершенствованию программы, а не о том, может ли она уже работать. Чувствуете разницу? Мне кажется, Вы пытаетесь защитить AVL от моих «нападок». Не стоит это делать, т. к. AVL может и сам послать меня куда-подальше, если пожелает.

Конечно, и я против. Только одних резисторов с учетом высокоточных рядов получилось бы несколько тысяч вместо одного единственного компонента. А там еще конденсаторы, индуктивности... Бррр... Все же здоровое у нас сообщество на форуме, раз отвергает такие предложения.

Я считаю AVL умным собеседником, который получил подтверждение, что убрать косяки можно без того, чтобы напрягать пользователя дополнительными доделками-переделками. Это очень важно, т. к. вольность в оформлении библиотек «не переделанных под менеджер» будущими пользователями может привести к косякам в будущем. Нужно радоваться, что нескладухи проявились именно сейчас — на старте.

Автор: AVL Jun 18 2013, 09:20

Так, по-спокойнее Любое общение по делу важно.
Единственное, Aldan, я не всегда понимаю смысл того, что вы пишите, извините:

Вот пока ничего не понял.


Да, так реально сделать (кроме L, что такое L? дроссель, катушка индуктивности, еще варианты? ).

Автор: break Jun 18 2013, 10:08

Aldan
Только одних резисторов с учетом высокоточных рядов получилось бы несколько тысяч вместо одного единственного компонента. А там еще конденсаторы, индуктивности... Бррр... Все же здоровое у нас сообщество на форуме, раз отвергает такие предложения.
А у Mentor Graphics это основной принцип. Да ещё всё не собрано в библиотеки, а валяется отдельными файлами.

Автор: Aldan Jun 18 2013, 21:10

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

Здесь я отвечаю на Ваше предложение о том, что если в свойствах компонента ввести доп. поле и заполнить его у каждого компонента, то это может помочь решить проблемы появления «косяков». В прошлом сообщении я объяснил Вам, что не важно как назывался компонент в библиотеке, главное, как он называется на схеме. Каждый компонент на схеме имеет пару «обозначение-значение», например, обозначение — R1, значение — 1кОм.
Если Вы будете брать только эту информацию, то именно она и уйдет в перечень, а вот если Вы начнете ее еще смешивать с информацией из библиотеки, то в перечне вместо «1кОм» появится «R_RES 1кОм», где «R_RES» - не нужный нам «косяк». Информация отраженная в схеме самодостаточна и нет нужды к ней примешивать еще что-то. В каких полях брать эту информацию из схемы Вам виднее, как специалисту.
Далее я пишу о том, что раз схема все уже содержит, то нет необходимости вводить дополнительные поля и заставлять заполнять их пользователями. Уверенность в правильности такого решения опирается на то, что скрипт Константина Барановского работает без «косяков».
Таким образом, главная мысль — поскольку мы составляем перечень (спецификацию) схемы, то и брать информацию нужно со схемы, а не откуда-то еще.

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

Здесь я пишу о том, что раз скрипт Константина Барановского выводит перечень без «косяков», то это означает, что он выводит только то, что есть на схеме, а не подмешивает еще и информацию из библиотек.

Здесь я пишу о том, что раз уж Вы ознакомились с кодом скрипта Константина Барановского, выводящего перечень без «косяков», то теперь то уж и в Gost doc gen все будет в порядке.

Если заглянуть в ГОСТ 2.710-81, то там мы увидим: L — катушки индуктивности, дроссели. Больше никаких вариантов не предусмотрено. Правильными будут оба варианта, но наиболее употребимый вариант, на мой взгляд, - дроссели. Но не надо особо заморачиваться над окончательным вариантом по двум причинам: во-первых, если не удается добиться однозначности, то, как предлагалось мною, не автозаполняем такое поле, а выделяем его цветом; во-вторых, если будет сделан редактируемый список вариантов соответствия, то время его отшлифует и каждый сможет его «заточить» под себя.

Ужааасссс!

Автор: AVL Jun 18 2013, 21:55

Может кто подскажет по обозначению сопротивлений? На сколько мне было известно, сопротивление ниже 1 кОм в КД вроде как должно обозначаться просто числом без слова "Ом". Например 220 Ом должно обозначаться просто числом 220. Пробежался по ГОСТ 8.417-2002, однако нигде не могу найти такого требования, что указывать Ом не нужно.
Как правильно должно быть, кто знает?

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

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

Вы пишите:

Я не могу понять как они будут заменены на конкретные названия компонентов в схеме, кем / чем?
Возможно, я что-то упускаю?

Смотрите мой ответ выше.

Вот не вижу связи

Автор: Aldan Jun 18 2013, 22:41

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

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

Именно! Я ведь не единожды Вам писал, что обобщенное условное обозначение, например, «OPAMP2_8» из моего предыдущего сообщения, разработчиком принудительно заменяется, к примеру, на TLV2452. При этом скрипт Константина Барановского выведет в перечень именно TLV2452, а Ваша программа выведет OPAMP2_8 TLV2452. Но ведь никакого «OPAMP2_8» на схеме нет!
Вот я и пишу, что не важно как назывался компонент в библиотеке, а важно как он стал называться в схеме и брать информацию нужно только из схемы + те доп. поля, что генерит Ваш менеджер.
Если теперь Вы перечитаете несколько моих последних сообщений на эту тему, то теперь все должно быть понятно.

См. ответ в моем предыдущем абзаце.

Как же нет связи? Если Вы ознакомились с кодом скрипта Константина Барановского и Вам стало ясно как он выводит информацию в перечень без «косяков», то что мешает применить новое знание на практике? Вот я и пишу, что теперь-то все будет в порядке, разве не так?

Автор: tema-electric Jun 19 2013, 02:30

Я разработчик, и я от этого ушел! Жалко времени. У нас на предприятии широко используется два типа усилителей: AD820 и OP2177. Все! И спрашивается, зачем мне каждый раз писать AD820 или OP2177? И в таком случае при использовании даже того-же OPAMP2_8 создайте к нему псевдонимы и они автоматом встанут в поле "Тип", и Вы получите сразу нормальное обозначение в перечне. Но, похоже, Вам лень добавить Alias к тому же OPAMP2_8, которого в схеме нет и быть не может. Добавте к OPAMP2_8 поля Title и Type и не будет у Вас проблем, что вдруг случайно какое-то мясо попало в перечень.

Вот если даже невольно вдуматься в исходную логику разработчиков KiCAD и поле "ссылка на документацию" в компоненте. Вы на какой абстракт ссылаться собираетесь? OPAMP2_8.pdf? А эти ссылки заполняются до того, как компонент попадет на схему.

Автор: break Jun 19 2013, 07:18

Aldan
Информация отраженная в схеме самодостаточна и нет нужды к ней примешивать еще что-то.
Недостаточна. На схеме, как правило, не указывается мощность (хотя и можно в УГО, но не все, а только до 5 Вт), точность, и уж точно не указывается тип резистора. Про конденсаторы и говорить нечего, там это ещё важнее. Я практически постоянно использую разные типоразмеры резисторов и конденсаторов. А у конденсаторов и разные напряжения (соответственно и диэлектрики).

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

брать информацию нужно со схемы, а не откуда-то еще.
Это правильно. На схеме в дополнительные поля элемента можно внести необходимую информацию. Эти поля можно сделать невидимыми (или как-то ещё, чтобы видно было, но не печаталось), и вставлять эти поля в перечень/спецификацию. Может к каждому полю завести кроме атрибута "Показать", атрибут "Печатать"?

Второе — прошу, например, break в качестве стороннего наблюдателя сообщить нам на самом ли деле я так путано выражаюсь или все же что-то можно понять из моих объяснений.
Откровенно говоря, я не вчитывался в этот спор, только просмотрел "по-диагонали" - "слишком много букв", а времени не хватает вникать. (Мне тут ещё столько схем надо проверить... включился защитный клапан

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

AVL
Может кто подскажет по обозначению сопротивлений? На сколько мне было известно, сопротивление ниже 1 кОм в КД вроде как должно обозначаться просто числом без слова "Ом". Например 220 Ом должно обозначаться просто числом 220. Пробежался по ГОСТ 8.417-2002, однако нигде не могу найти такого требования, что указывать Ом не нужно.
Как правильно должно быть, кто знает?
Не тот ГОСТ.
ГОСТ 2.702-75 Правила выполнения электрических схем

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

tema-electri
И спрашивается, зачем мне каждый раз писать AD820 или OP2177?
С точки зрения трудозатрат, никакой разницы нет - писать в каждом элементе прямо на схеме, или добавить Alias.

Автор: tema-electric Jun 19 2013, 07:50

1) Псевдоним делается 1 раз, по первой необходимости. Делается за 10-30 секунд.
2) Нет разницы, что искать в библиотеке OPAMP2_8 или AD820
3) В настоящий момент применение псевдонимов позволяте автоматически заполнить поле "Тип" у микросхем.
Спорить нет особого желания об этом. Каждый работает в своем стиле, и экономит время по-своему. Писать о важности суффиксов в конце обозначения микросхем тоже не хочу.

Автор: AVL Jun 19 2013, 07:53

Здесь необходимо "разжевать молекулы на атомы" чтобы я понял.
Как можно изменить поле Chip Name у компонента, после его вставки в схему на новое имя X при этом не имея в наличии другого библиотечного компонента либо его псевдонима с именем X?

Так GOST-doc-gen и так берет все поля компонентов из схемы, напрямую из библиотек ничего не берется. Библиотечные атрибуты используются только в момент разработки схемы (вставки библиотечных компонентов в схему). После того как разработчик вставил компонент в схему, он либо оставляет значение атрибутов компонентов как есть, либо редактирует по необходимости.

Я отвечал Вам ранее:

Какое новое знание мне нужно применить на практике?
А в http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1170530 я подробно объяснил как формируется поле "Тип".
Здесь добавлю резюме:
1) в скрипте Константина читается атрибут "Марка"
2) а в GOST-doc-gen читается атрибут "Type" при условии, что атрибут "Type" был задан у компонента тем или иным способом (руками в схеме, либо через менеджер компонентов). Если же атрибут "Type" отсутствует (сырая схема), то читается поле Chip Name этого компонента.

И в случае скрипта Константина и в случае GOST-doc-gen нужно задать необходимые атрибуты, чтобы значения этих атрибутов в конечном итоге появились в КД.
Эти атрибуты, если их нет в библиотечном компоненте изначально, ни откуда не возьмутся, пока разработчик схемы сам их не добавит каким-либо из способов.

Я поэтому не понимаю к чему Вы клоните


Отлично, спасибо.

Автор: break Jun 19 2013, 10:40

Что-то у меня ничего не получается с kicadbom2spes. Делаю всё по инструкции (кроме пути - не "Program Files (x86)", а "Program Files"), но:
1. Pyton не устанавливается. Приходится вручную устанавливать отдельно.
2. Не знаю как и куда устанавливается odfpy (причём тоже вручную отдельно), но в консоли пишет только:

3. При нажатии "Создать спецификацию", ничего не происходит.

Похоже CSV файл не нравится.

Автор: Aldan Jun 19 2013, 11:31

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

Наверное Вы являетесь начальником, так как не замечаете как переходите на менторские нотки: «создайте», «вам лень добавить», «добавьте».., но разве я просил Вас поучать меня, или Вы считаете себя умнее всех?
Поскольку Вы не считаете возможным для себя читать мои сообщения внимательно, то повторяю, что «OPAMP2_8» является прототипом тысяч, Вы слишите, ТЫСЯЧ различных операционников с такой структурой, так что, мне заполнить на них всех алиасы? Если так сделать, то вместо нескольких прототипов «OPAMP» появятся несколько ТЫСЯЧ названий алиасов и библиотека превратится в помойку. Конечно же, конечный пользователь, да еще такой как Вы с двумя операционниками может заполнить парочку алиасов и радоваться, но зачем же говорить за всех?

И об этом я Вам уже писал в конце своего прошлом сообщения: «Это очень важно, т. к. вольность в оформлении библиотек «не переделанных под менеджер» будущими пользователями может привести к косякам в будущем. Нужно радоваться, что нескладухи проявились именно сейчас — на старте.» Разве не понятна простая мысль, что различные разработчики библиотек могут просто не знать о каких-то дополнительных правилах и ограничениях, навязанных Gost doc gen, поэтому разумно постараться не заставлять пользователя что-то дооформлять или переделывать, а пойти таким путем, который позволит обойтись без этого. Только тогда можно будет быть уверенным, что у пользователей «некалиброванных» библиотек не появятся проблемы в виде каких-то «косяков». Скрипт Константина Барановского показал, что такой путь возможен, все остальное — отговорки и нежелание быть честным перед собой.

Если скачать полную сборку Кикада, т. е. с документацией, с фтп Жан Пьера и посмотреть в поле "ссылка на документацию", то мы увидим, что там находится именно ссылка на документацию — pdf-даташит на данный компонент. Я этим не пользуюсь, т. к. не считаю нужным захламлять свой компьютер ненужной документацией. Все, что мне нужно для работы есть в моей удобной библиотеке даташитов, причем, я постоянно отслеживаю их «свежесть». При желании, я мог бы дать ссылки на эти даташиты в используемых мною компонентах, но не нахожу в этом необходимости.
Для такого пользователя, как Вы, работающего с малым количеством комплектации, можно и нужно заполнить все поля компонента при его создании и радоваться, ну а тем, кто работает с разнообразной комплектацией придется пользоваться услугами менеджера Gost doc gen. Все поля у моих компонентов чисты, т. к. их содержание будет изменятся в зависимости от того, какой КОНКРЕТНО компонент в данной схеме они представляют.
-----
tema-electric, наше с Вами общение не несет содержательного характера, но отнимает много времени на ответы Вам. Прошу Вас впредь писать мне только то, что очень важно или не писать вовсе иначе мне просто придется уклоняться от ответов Вам.

Да, действительно Вы не вчитывались в данную дискуссию, иначе бы заметили, что только что я ответил AVL по данному поводу:

Ваше отношение к «злобным буратино» тоже не разделяю

И на это я уже отвечал, считая, что лучше избегать такого подхода, чтобы у любого пользователя не возникало косяков. Раз есть возможность обойтись без дополнительных доделок-переделок, то почему бы это в Gost doc gen не сделать? Вот скрипт Константина Барановского, например, без доделок-переделок выводит все правильно.

AVL, я ведь простой пользователь и не обязан знать «кухню» внутреннего устройства Кикада. Все эти «поля», «атрибуты» и их конкретные названия предлагаю отодвинуть в сторону и услышать меня чистым непредвзятым разумом. Я предлагаю Вам потратить несколько минут на проведение небольшой практической работы по установке компонента из библиотеки в схему и понаблюдать за тем, что происходит. Т.е. акцент будет смещен не на то, что я объясняю, а на то, что Вы сами увидите. Думаю, такой подход должен полностью исключить всякое недопонимание.
Итак, запускаем kicad_gost_commiters, подключаем мою библиотеку analog_IC.lib и открываем какую-нибудь из Ваших небольших схем, которую не жалко будет испортить.
Далее открываем библиотеку analog_IC.lib и выбираем для схемы парочку компонентов, например, - LM2664 и OPAMP1_8. Далее, двойным щелчком кликаем по полю «OPAMP1_8», правим это поле на TLV2450 и тем самым условное обобщенное название одиночного операционника в 8-ногом корпусе - «OPAMP1_8» принудительно приобретает конкретное название «TLV2450». После этой процедуры «OPAMP1_8» остался в библиотеке, на на схеме фигурирует уже только «TLV2450».
Далее, для достоверности эксперимента, присоедините эти микросхемы куда-нибудь в своей схеме и, завершив работу со схемой, создайте перечень с помощью Gost doc gen. Рассматривая полученный перечень, Вы заметите, что микросхема LM2664 в нем отразилась чисто, без «косяков», а вот TLV2450 отразилась как OPAMP1_8 TLV2450. В схеме OPAMP1_8 нет, а в перечне — есть. Непорядок
Все мои усилия были направлены только на то, чтобы избавиться от этого «косяка» и выводить название компонента так же чисто, как это делает скрипт Константина Барановского. Все.
AVL, теперь у Вас нет права говорить, что Вы что-то не поняли, по крайней мере, если не хотите, чтобы я застрелился Кикад, библиотека и косяки — все перед Вами и в Вашей власти, так что все вопросы к ним

Автор: break Jun 19 2013, 13:06

Aldan
Да, действительно Вы не вчитывались в данную дискуссию, иначе бы заметили, что только что я ответил AVL по данному поводу:
Это как раз прочитал. Мне казалось, что я тоже имею право высказывать своё мнение, а не просто поддакивать.

Вот скрипт Константина Барановского, например, без доделок-переделок выводит все правильно.
У кого как. У меня вообще ничего не выводит.

Автор: AVL Jun 19 2013, 14:19

Это зря. Дьявол в деталях.

Отлично, тоже хотел предложить.

У меня чувство, что Вы знаете то, чего я не знаю.
Из Вашего описания я не могу понять что, где и как открыть, чтобы получилось как у Вас. Я даже открыл eeschema и не могу понять что я должен где нажать.
Есть ли где-то инструкция по данной функциональности, может в документации на EEschema? Можете указать страницу где про это написано, чтобы я изучил? Документацию на eeschema я однажды читал мельком, времени досконально перечитывать документацию у меня пока нет.
Либо сами сможете четко по пунктам изложить, что куда нажать? Вплоть видеоролик сделать этих действий, я уж не знаю.

По крайней мере, пока не пойму Ваши действия по добавлению компонента в схему, нет смысла ссылаться на скрипт Константина. На текущий момент, имея мое представление, я не вижу разницы в работоспособности между GOST-doc-gen и скриптом по данному вопросу.
Сейчас первым делом мне нужно понять как Вы добавляете компонент.
Я добавляю компонент иным образом, поэтому у меня, наверно из-за этого, другое представление о проблеме.
Единственное, прямо сейчас нет под рукой библиотеки analog_IC.lib. Я открывал стандартную библиотеку 74xx. Надеюсь это не играет роли?

Автор: tema-electric Jun 19 2013, 14:49

Нет здесь таинства. Таково поведение программы. Если взять стандартный компонент с определенными полями: Позиционка (F0), Значение (F1), Посадочное (F2), Документация (F4), то GOST-tools менеджер отобразит в поле "Тип" библиотечное название компонента. В спецификацию попадет склейка "Type" + "Значение"(F1). Об этом и пишет Aldan. В данном случае "Type" автоматом определился как OPAMP1_8, а значение (F1) забито ручками как " TLV2450".

Об аномалиях я уже писал Вам. Если GOST-Tools не находит поле "Type" в компоненте, он его определяет автоматом по библиотечному наименованию, при этом это поле не прописывается в компонент до тех пор, пока пользователь руками не введет некое значение (не пустое). Я по первости мучился. Очищал поле "Тип" в менеджере бэкспейсом, генерировал перечень, но если переоткрыть GOST-Tools то снова сработает автозаполнение, потому что удаление значений из поля "Тип" в менеджере не приводит к сохранению пустого поля "Type" в компоненте. Вот если пробел записать или полное название, тогда все будет супер.

Аномалия, которую я обнаружил, это то что в GOST-Tools для двух разных компонентов "Тип" компонента в менеждере в одном случае автоопределился по библиотечному названию, а в другом по полю "Значение"(F1). Т.е. что-то где-то не так работает. Чтобы увидеть эту аномалию, посмотрите схему, которую я Вам выслал и комментарии к ней в первом письме.

Здесь я разграничил для понимания.

"Тип" в менеджере - это то что менеджер показывает.
Type - это поле, хранящееся в компоненте.

PS: Сейчас подумал о тильде. Может с ней какие-то фокусы. Поле не может быть пустым, там должна быть она ~.

Автор: AVL Jun 19 2013, 15:41

Ваше объяснение понял. Неужели Aldan это и имел в виду?
Вроде с ним вели речь об имени компонента (chip name). Не мог подумать, что имелось в виду поле "Номинал" ("Value") компонента в eeschema.
Aldan, все правильно? Это и имели Вы в виду?

Насчет поля "Номинал" у компонента мы уже ведь обсуждали. С моей точки зрения (и, как выяснилось, не только моей) автозаполнение поля "Номинал" значением из "Chip Name" в момент добавления компонента в схему - это баг дизайна eeschema.
Было предложено простое решение - при чтении схемы, если значения полей Chip Name и Value совпадают, то поле Value интерпретировать как пустое. Такую доработку я и внес в GOST-doc-gen. Мне казалось, что на этом вопрос исчерпан.

Соответственно возникает вопрос, а зачем идти на поводу кривости дизайна eeschema по указанной проблеме и вбивать в поле "Номинал" тип (марку) реального компонента?
Ну допустим вы идете этим путем:
1) добавляете в схему библиотечный компонент 7400 (поле "Chip Name" = "7400", поле "Value" = "7400")
2) меняете поле "Value" с "7400" на "SN74HC00D"
а что вы будете делать в случае с конденсаторами, резисторами и т.д.?
1) добавляете в схему библиотечный компонент С (поле "Chip Name" = "С", поле "Value" = "С")
2) меняете поле "Value" c "C" на "К73-17"
3) и дальше что? куда вводить номинал "0,1 мкФ"?

В GOST-doc-gen для вбивания типа (марки) используется дополнительный атрибут "Type". И нет проблем.

Пример схемы пока не смотрел. Поздно вечером смогу посмотреть. Но я так понимаю я правильно понял все?

Не совсем понял о какой проблеме идет речь.
Если что, GOST-doc-gen интерпретирует поле "Value" как пустое, если поле "Value" == полю "Chip Name", либо поле "Value" == "~".

Автор: tema-electric Jun 19 2013, 17:02

Это первое, с чем я столкнулся. У меня также были записульки в стиле CAP_0805_BOX Чип 0805 X7R 1 мкФ 25 В ))).


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


Это я понимаю, и этим пользуюсь.
_____________________________________________________________________________

Ммм, не прошло и часа. Александр, я понял, зачем Вы привели пример с микросхемой и конденсатором.

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

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

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

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

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

Автор: AVL Jun 19 2013, 21:01

Сейчас осознал, что они пишут в этом ГОСТе об указании номиналов около УГО (на схеме).
А вот интересно, есть ли какой-то ГОСТ по этому поводу для ПЭ3 и спецификации? Я на сколько понял ГОСТ 8.417-2002 это регулирует (засомневался, что ГОСТ 2.702-75 это определяет). Если все-таки ГОСТ 8.417-2002 для ПЭ3 и спецификации, то насчет использовать "Ом" или без "Ом" там не могу найти.

P.S.: так для информации, в поисковике нашел ГОСТ 2.702-2011, который взамен ГОСТ 2.702-75.

Автор: Aldan Jun 19 2013, 21:14

А я и не просил поддакивать.

Руководство по пользованию скриптом kicadbom2spes, написанное Константином Барановским просто до дотошности подробно. Главное, нужен питон2, а не питон3. И еще, у меня питон установился в корень диска С, а Вы пихаете его "Program Files", что может быть и не критично, но уже является самодеятельностью.
На мой взгляд, если хотите получить гарантированный результат, следуйте требованиям руководства пользователя без самодеятельности и все должно получиться.
Самое лучшее, конечно, это получить консультацию от самого Константина, но он, видимо, пока очень занят т. к. не ответил на Ваше сообщение, да и на мое http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1170196 тоже не ответил.

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

Не имеет значения каким образом компонент добавлен в схему, главное, чтобы он таки был добавлен.

А что, скачать с фтп слабо или мощности интернета хватает только на форум? Прилагаю эту библиотеку в аттаче.

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

Автор: AVL Jun 19 2013, 22:48

Не совсем правильно меня поняли. Владею кикадом в том объеме, какой мне потребовался для разработки пока одного устройства, о котором я писал в этой http://electronix.ru/forum/index.php?showtopic=113370. А также в том объеме, чтобы интегрировать/разрабатывать pcad2kicad, а также менеджер компонентов + GOST-doc-gen.
Но уверен, что не владею кикадом в 100% функциональности.
Я просто написал Вам, что я усомнился в том, что знаю все способы добавления компонента в схему, поскольку Вы объясняете столь уверенно, а я не понимаю, что Вы имеете в виду.

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

Предлагаю не отклоняться от темы.

Ну почему слабо. На той машине, с которой писал сообщение и запускал кикад, закрыт доступ по 21 порту и еще куче других портов.

Хорошо, вот дома у меня есть Ваша библиотека analog_IC.lib.
1) Я вставил в схему компонент OPAMP1_8. Сверху УГО написано DA?. Снизу УГО написано OPAMP1_8.
И тут я наконец-то нашел место о котором Вы говорили где нужно щелкнуть 2 раза.
2) щелкнул 2 раза, появилось диалоговое окно "Edit Value Field". Исправил OPAMP1_8 на TLV2450. Нажал ОК. Снизу УГО теперь написано TLV2450.
3) щелкаю 2 раза на УГО. Открывается окно "Component properties". И что я вижу? Поле "Chip Name" = "OPAMP1_8". Поле "Value" = "TLV2450".
Вывод. Имя компонента как было "OPAMP1_8", так и осталось, о чем я Вам и писал. А изменилось поле "Value" - это номинал компонента, который имеет смысл только для таких компонентов как конденсаторы, резисторы и др. Для микросхем поле "Value" не имеет смысла. Только вводит людей в заблуждение.

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

Значит tema-electric правильно объяснил мне, что Вы имели в виду.
Тогда вернитесь к нашей с ним переписке и попробуйте вникнуть в объяснение, которое я там дал. А также в предложение tema-electric как изменить логику.
См. мое http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1171356 и его http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1171365.

Если Вы мне сейчас начнете говорить "а как же быть с пустыми полями "Value", теперь не будет надписи TLV2450 под УГО". Здесь ответ такой - в общем случае этого добиться не возможно.
К примеру у меня много схем, в которых есть исполнения. Есть схема с 13-ю исполнениями. Так вот в таких ситуациях не реально отобразить все возможные значения номиналов, типов и еще чего-либо. Я в свое время пришел к решению вообще ничего не отображать рядом с УГО кроме позиционного обозначения. ГОСТ разрешает вообще не указывать номиналы и т.д. кроме позиционных обозначений.
Вся информация по компонентам (номиналы, допуски, типы и т.д.) содержатся в спецификации и ПЭ3. Спецификация в основном для закупки. ПЭ3 и монтажная схема для монтажа.
На схеме в основном отображение номиналов/типов может быть полезным для разработчика и регулировщиков. Но как я сказал, в случае схем с исполнениями, это не реально. Для схем без исполнений, если есть большое желание показывать на схеме номиналы/типы, то для конденсаторов/резисторов/др. использовать поле "Value", а для остального (микросхем и подобного) использовать дополнительное поле "Type" (делать его видимым), а также делать остальные поля видимыми при крайней необходимости (например, "Precision" (Допуск), "Note" (примечание) и др.).

Автор: tema-electric Jun 20 2013, 00:53

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

С другой стороны новый подход с применением GOST-Tools позволяет расставлять номиналы возле компонентов, потому что теперь они короткие, и не надо в поле Value пихать вся и все. А синхронизация с перечнем и спецификацией выполняется автоматически.

Автор: break Jun 20 2013, 06:53

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%". В конце-концов разобраться можно, но вероятность ошибки возрастает.

Спасибо за информацию об обновлении ГОСТа.

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

ГОСТ разрешает вообще не указывать номиналы и т.д. кроме позиционных обозначений.
Скорее наоборот:

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

tema-electric
Нас на кафедре за расположение номиналов около элементов в Э3 очень сильно ругали.
Меня тоже учили не писать на схеме, но потом на работе убедили, что с номиналами гораздо удобнее для монтажников и, особенно, регулировщиков/ремонтников.

Автор: AVL Jun 20 2013, 07:08

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

Автор: IgorKossak Jun 20 2013, 07:16

Смотря кто убеждал. Если начальник отдела монтажа, настройки, ремонта, тогда понятно. В своё время один из таких начальников настаивал изображать УГО микроконтроллеров в корпусах TQFP квадратными, чтобы выводы УГО точно совпадали с ножками микросхемы. Опять же объяснял это заботой о ремонтниках.
Меня учили, что в первую очередь удобно должно быть разработчику, ибо его ошибки дороже всего обходятся. Поэтому в данном случае я как разработчик считаю, что номиналы загрязняют схему.

Автор: AVL Jun 20 2013, 07:34

Думаю для ситуаций, когда печатается схема для регулировщиков, можно предложить поддержать пункт в меню в eeschema, чтобы включить отображение всех вспомогательных полей такие как номинал, тип. Причем лучше, чтобы было также введено понятие слоев как в печатной плате и управлять видимостью слоя, куда помещены эти атрибуты (номинал, тип и др). Причем помещены на этот слой только те атрибуты только тех компонентов, которые хочется отобразить для таких случаев печати схемы.
У нас в случае ручного монтажа на производстве монтажники, если им дать сборочный чертеж платы без указания номиналов (только поз.обозначения + ПЭ3, а именно в таком виде сборочный чертеж хранится в архиве), все равно сами руками подрисовывают номиналы на своей копии (переносят информацию из ПЭ3 на сборочный чертеж). Поэтому я в проекте pcb номиналы / типы / допуск и др. полезную инфу помещаю на отдельный слой. Этот слой включаю на печать только для монтажников.

Автор: break Jun 20 2013, 07:53

AVL
Сможете Ваш пример привести?
К сожалению, нет. Нам запрещено показывать свои схемы на сторону (хотя отдельным заказчикам предоставляем). Даже сотрудники не всех отделов доступ имеют. Я лично смысла не вижу, но не я определяю политику.

У меня тоже не только номинал, но и тип, а также факт установки/не установки компонента варьируется от исполнения к исполнению. Все это отражается в ПЭ3 и спецификации. Если говорить непосредственно о проводниках, то они ведь полностью соответствуют топологии печатной платы и представляют собой полную схему с покрытием всех исполнений (мы же не можем в зависимости от исполнения добавлять / отрезать дорожки на реальной готовой подложке при условии, что это не прототип и не исключительные ситуации по устранению мелких багов разработки).
Зато те элементы, которые не устанавливаются, на схеме рисовать не надо. В одной из последних приведённых разводок на плате в одном посадочном месте присутствовало сразу несколько элементов, которые должны устанавливаться в зависимости от исполнения. Понятно, что на схеме для разводки я нарисовал всё, чтобы попало на плату. Но при оформлении чертежа конкретного исполнения это бессмысленно и даже вредно.
В одной схеме я даже на место резисторов поставил конденсаторы, а вместо диода - резистор, чтобы не делать лишнюю разработку ради пары плат, которые не должны были больше повторяться.

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

Барановский Константин
Вот такая фигня происходит при попытке генерации спецификации:

Файл csv прикладываю. Это я его уже немного преобразовал - удалил ненужные поля (в разъёме названия цепей сделаны полями, чтобы не рисовать сотни разъёмов), заменил запятые табуляцией. Но и исходный файл не обрабатывается.
Образец обрабатывается нормально.
Про косяки с установкой я уже писал ранее.

Автор: AVL Jun 20 2013, 08:10

Удалось проблему повторить на виртуалке Ubuntu.
Проблема не старая, а новая (в новом коде для поддержки новых форматок).
Исправил в ревизии 4155 ветки lp:~kicad-gost-committers/kicad/kicad.


Да, я имел в виду на словах пример объяснить.

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

Автор: Барановский Константин Jun 20 2013, 08:25

Похоже из-за последних изменений BOM-генератора в KiCAD формат csv уже не соответствует тому, который был при написании скрипта. Да и вообще хочу уйти от csv перечня и использовать только файл схемы, ведь внутри все есть. Но сейчас на это нет времени, извините.

Автор: AVL Jun 20 2013, 08:50

Константин, к сожалению и файл схемы скорее всего изменится скоро по аналогии как это было сделано относительно недавно для Pcbnew (переход на S-expressions).
Вообще многократно слышал на developer mailing list, что многие там текущий дизайн eeshema не воспринимают и озвучивают желание переписать eeschema с нуля, чем ходить вокруг до около. С другой стороны, в последнее время много коммитов идет для eeschema. То есть пока выглядит все как эволюция.
Революцию они устроили пока только для BOM.

Автор: tema-electric Jun 20 2013, 10:14

Собрал, проверил. Перечень получился. Глубоким тестированием пока некогда заниматься, но внешний вид уже как у конфетки

Очень жалко, если формат eeshema поменяется. Там и до библиотечных компонентов недалеко, а там и скрипт для ПЛИСов приедтся переделывать.

Автор: AVL Jun 20 2013, 10:37

Но с другой стороны, старый формат же должно у них хватить ума оставить (legacy). Хотя на примере с BOM не знаю, что и ожидать еще.


Спасибо Константину Барановскому, что уделил время на разработку новых форматок для GOST-doc-gen, имея при этом очень важные другие дела.

Автор: tema-electric Jun 20 2013, 11:00

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

Автор: Aldan Jun 20 2013, 22:24

AVL, признаться, я до сего дня я не пытался вникнуть во многие умные слова типа «поля», «атрибуты» и все их разновидности, которыми Вы осыпаете собеседника ежесекундно. Я думал так: «есть специалисты, я им доверяю и нечего мне непрофессионалу лезть туда, куда не следует». И хоть я пользуюсь Кикадом не первый день, все еще искренне считаю себя начинающим юзером и по этой причине с жадностью впитывают то, что пишут более опытные пользователи.
К опытным пользователям я причислял и Вас, пока не стала накапливаться стена очень странного непонимания, а потом проявилась Ваша откровенная неопытность в самых простых вещах пользования Кикадом. Не подумайте, что я пишу в критическом ключе, я даже наоборот еще больше зауважал Вас, т. к. Вы не побоялись ввязаться в довольно сложное и трудоемкое дело по созданию средства по выпуску текстовой документации, но, вместе с тем, Вы перестали быть для меня авторитетом, как пользователь, и теперь я решил сам посмотреть на «поля» и «атрибуты».
Для начала, я изучил пример, который идет вместе со скриптом Константина Барановского. И что я вижу? Константин, если я его правильно понял, выводит в перечень обозначение и значение, поэтому его перечень строго соответствует тому, что мы видим на схеме и не имеет «косяков». Таким образом, Константин выводит в перечень именно то, что я Вас многократно просил «обозначение-значение». Вы же пишете, что поле «значение» - «не имеет смысла. Только вводит людей в заблуждение». Так вот, если Вы наконец-то начнете выводить поле «значение», вместо бесполезного поля «имя компонента», которое нигде не отображается и не используется в схеме, то «косяки» исчезнут.

Что я имею в виду я только что Вам написал.

Надписи под УГО должны быть, это без вариантов т.е. пара "обозначение-значение" это святое. Если кто-то захочет их убрать (трудно найти такую причину), то он сделает их невидимыми. Если же их убрать вовсе, то это просто безграмотность и безответственность.
Если Вы адекватный человек, то должны понимать где находится граница дозволенного и что на слом устоявшейся традиции предлагая что-то новое могут претендовать только высокоопытные пользователи Кикад, к которым Вы, увы не относитесь. Так что сделайте так, как Вас просят и наступит всеобщее счастье.
Если же Вы и дальше будете с упорством настаивать на том, что поле «значение» - «не имеет смысла. Только вводит людей в заблуждение», то забудьте меня, как собеседника, т. к. наше дальнейшее общение с Вами будет бессмысленным.
Пора ставить в этом вопросе точку к тому же сделать это крайне просто.

Автор: AVL Jun 21 2013, 08:39

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

Автор: tema-electric Jun 21 2013, 13:13

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

Автор: AVL Jun 21 2013, 19:56

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

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

импортированные схемы из 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 мкФ"

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

Результирующие поля после обработки алгоритмом
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 Jun 21 2013, 22:51

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

Автор: Барановский Константин Jun 22 2013, 04:49

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


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



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



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

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


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


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

Автор: tema-electric Jun 22 2013, 05:34

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 Jun 22 2013, 07:43

Отвечаю пока частично.
Привязываться к 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.
Чтобы сделать все красиво, придется исправлять ранее обсуждаемый http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1165220 в eeschema, и получается, в cvpcb тоже.
Если пойти по пути исправления французского подхода в корне, можно попробовать обратиться к Brian Sidebotham по поводу его http://electronix.ru/redirect.php?https://lists.launchpad.net/kicad-developers/msg03628.html. Вдруг у него этот патч на полке все это время лежит.

Автор: tema-electric Jun 22 2013, 09:09

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

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

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

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


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

Автор: Aldan Jun 22 2013, 09:43

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

Автор: AVL Jun 22 2013, 11:10

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

Автор: tema-electric Jun 22 2013, 11:25

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

Автор: AVL Jun 22 2013, 11:44

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

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

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


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

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

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

Автор: AVL Jun 22 2013, 13:36

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

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

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

Автор: tema-electric Jun 22 2013, 14:14

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

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

Автор: AVL Jun 22 2013, 14:50

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

Автор: Aldan Jun 22 2013, 19:49

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

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

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

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

Автор: AVL Jun 22 2013, 20:47

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

http://electronix.ru/redirect.php?http://bazaar.launchpad.net/~kicad-gost-committers/kicad/doc/download/head:/gost_tools.pdf-20130622203756-jttyezbb89mchikf-1/GOST_Tools.pdf

Автор: AVL Jun 23 2013, 10:49

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

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

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

Автор: tema-electric Jun 23 2013, 11:16

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


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

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

Автор: AVL Jun 23 2013, 11:56

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

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

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

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

Автор: tema-electric Jun 23 2013, 12:39

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


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



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

Автор: AVL Jun 23 2013, 13:20

С учетом имеющейся картины, появилась еще идея алгоритма №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!

Автор: tema-electric Jun 23 2013, 13:41

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

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

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

Автор: AVL Jun 23 2013, 15:33

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

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

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

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

Автор: tema-electric Jun 23 2013, 16:02

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

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



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

Автор: AVL Jun 23 2013, 16:15

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

Автор: tema-electric Jun 23 2013, 16:51

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

Автор: AVL Jun 23 2013, 17:39

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

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

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

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

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

Автор: AVL Jun 23 2013, 20:45

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

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

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

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

Автор: tema-electric Jun 24 2013, 04:16

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

Автор: AVL Jun 24 2013, 07:51

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

Автор: break Jun 24 2013, 09:47

AVL

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

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

Автор: AVL Jun 24 2013, 10:02

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

Автор: tema-electric Jun 24 2013, 11:18

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

Автор: tema-electric Jun 24 2013, 13:34

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

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


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

Автор: AVL Jun 24 2013, 18:36

Обновил руководство пользователя менеджера компонентов и 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

http://electronix.ru/redirect.php?http://bazaar.launchpad.net/~kicad-gost-committers/kicad/doc/download/head:/gost_tools.pdf-20130622203756-jttyezbb89mchikf-1/GOST_Tools.pdf

Автор: tema-electric Jun 25 2013, 10:50

62я ревизия.

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

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

Автор: AVL Jun 25 2013, 21:12

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

Автор: tema-electric Jun 26 2013, 02:16

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

Автор: AVL Jun 26 2013, 05:09

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

Автор: AVL Jun 26 2013, 06:24

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

Автор: break Jun 27 2013, 07:24

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

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

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

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

Автор: AVL Jun 27 2013, 07:43

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

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

Автор: break Jun 27 2013, 08:49

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

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

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

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

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

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

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

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

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

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

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

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

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

Автор: AVL Jun 27 2013, 19:01

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

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

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

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

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

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

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

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

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

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

Автор: break Jun 28 2013, 07:35

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

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

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

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

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

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

Сможете дать указание на ГОСТ?
Только по поводу количества:
http://electronix.ru/redirect.php?http://fmi.asf.ru/library/book/Gost/24-301-80.html

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

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

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

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

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

Автор: break Jun 28 2013, 09:05

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

Автор: AVL Jun 29 2013, 11:31

Значение поля Тип (атрибут Type) намерено добавил, чтобы отображалось в строке с номиналом в CvPcb (см. http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1172081).

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

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


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


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

Автор: AVL Jun 29 2013, 21:24

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


Это не глюк. Так сделано намеренно. Если у компонента атрибуты Chip Name и Value совпадают, то менеджером компонентов поле Value интерпретируется как пустое (см. руководство пользователя).
Данный вопрос уже много раз обсуждали в этой теме. Одни из первых обсуждений по данному вопросу в сообщениях:
http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1165197, http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1165220, http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1165358, http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1166662.
И потом многократно обсуждали этот нюанс французского подхода. Для меня это пока главная головная боль.

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

Я бы хотел переработать EESchema как описал в http://electronix.ru/forum/index.php?showtopic=111968&view=findpost&p=1172193.


Смотрите руководство пользователя и объяснение выше.
А тильда может появиться в атрибуте 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.

Автор: tema-electric Jun 30 2013, 06:29

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

Автор: AVL Jun 30 2013, 07:29

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

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


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

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

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

Автор: AVL Jun 30 2013, 09:11

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

Автор: tema-electric Jun 30 2013, 09:59

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

Автор: AVL Jun 30 2013, 10:48

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

Автор: tema-electric Jun 30 2013, 12:58

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

Автор: tema-electric Jul 2 2013, 11:10

Тестирую менеджер. Блин, в какой-то недавней ревизии добавлялись пустые поля Type и теперь полный атас ((. В каждый элемент надо заходить и грохать пустое поле, иначе в менеджере поле "Значение" пустое. А по факту - нет. Но это так, мелочи жизни.

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

Автор: AVL Jul 2 2013, 12:20

Ничего не понял.

Можно.

Автор: tema-electric Jul 2 2013, 15:00

Просто я попал в неприятную ситуацию.
Разрабатывать схему я начал 2 недели назад. За эти две недели довольно активно собирал KiCAD и инсталировал. Пару раз запускал GOST-Tools, просто, ради интереса. Теперь на схеме большая часть элементов имеет пустое поле Type, в том числе и микросхемы. Исключением являются элементы, добавленнные в последних версиях, в которых менеджер добавляет не просто пустое поле, а копирует туда ChipName, если ChipName == Value. Так вот, если открыть менеджер, там будет пусто, сами знаете почему. Поле Value есть, и оно совпадает с ChipName, а Type пустое. Как хочешь, так и определяй, что в схеме стоит: полн "значение" пустое, хотя по факту и нет. ChipName не отображается. Пришлось вручную заходить во все микросхемы и удалять пустое поле Type, чтобы в 70-й сборке поле type создалось автоматом и корректно.

Такие пироги.

Автор: AVL Jul 2 2013, 15:45

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

Атрибут Type может стать равен "~" (отображаться в поле Тип пустым) только в том случае, если в ручную стереть поле Тип используя текущую реализацию менеджера компонентов (4170).

Автор: tema-electric Jul 2 2013, 16:16

Я тоже

Дома 4157, на работе я начал с 62й ревизии и закончил на 70й. У меня есть контрольные ревизии разработки, но их немного, всего 6. Изменения произошли между 4й и 5й. Четвертую ревизию я коммитил 27 числа. Как определить версию сборки, не знаю. Посмотрю завтра на работе даты создания deb пакетов.

Удалять умышленно у всех элементов поле type я бы не стал.

Автор: AVL Jul 2 2013, 16:30

Сможете прислать 4-ю и 5-ю ревизии схемы?
Надо посмотреть, может баг где закрался.

Автор: AVL Jul 2 2013, 20:02

В ревизии 4171 расширил проверку атрибута Type. Теперь проверяется не только отсутствие атрибута Type, но также проверка на Type=="".
Задать руками атрибут Type = "" через GUI EESchema не удается, EESchema при попытке задать пустую строку в атрибуте предупреждает, что атрибут будет удален, и удаляет его.
А вот менеджер компонентов в старых ревизиях присваивал пустую строку атрибуту Type, если поле Тип было стерто в менеджере компонентов, и в этом случае все-таки EESchema такой атрибут не удаляла (механизм редактирования атрибутов через GUI EESchema отличается от редактирования атрибутов программным путем, а именно со стороны менеджера компонентов. EESchema удаляет пустой атрибут только, если редактирование идет через GUI EESchema).

Так что в ревизии 4171 такие нештатные ситуации с пустым атрибутом учтены. Теперь все в порядке. Ранее введенные схемы теперь отображаются нормально (поле Тип).

Автор: tema-electric Jul 3 2013, 02:57

Вроде да, облегчило мою учесть Спасибо.

Ошибка текстовая в менеджере "-NPO-50 В-", вместо нуля стоит буква O, т.е. должно то быть "-NP0-50 В-".

При выводе спецификации в одну строку запихал слишком длинное название и оно не вместилось.

(В спецификации)
Кварцевый резонаторKX-K 16.0 MHz (эта строчка не влезла)
Фирма "Gayer"
корпус HC-49SMD

(В компоненте структура полей)
F 0 "ZQ1"
F 1 "QUARTZ"
F 2 "Quartz-HC-49SM"
F 3 ""
F 4 "Кварцевый резонатор" "Type"
F 5 "Прочее" "Title"
F 6 "KX-K 16.0 MHz" "SType"
F 7 "корпус HC-49SMD" "Note"
F 8 "Gayer" "Manufacturer"

Автор: AVL Jul 3 2013, 06:39

исправил в ревизии 4172.

А с чем связано прописывание в поле "Наименование" = "Прочее", а в поле "Тип" = "Кварцевый резонатор"?
По идее должно быть:
"Наименование" = "Кварцевый резонатор"
"Тип" = "KX-K 16.0 MHz" (либо разбивка строки на части и использование полей "Тип", "Подтип", и возможно, "Номинал")
"Подтип" = ""
"Примечание" = "корпус HC-49SMD"
"Производитель" = "Gayer"

Поля "Тип" и "Подтип" пока предполагал, что лучше чтобы не отделялись друг от друга (перенос на новую строку заблокирован) при генерации документов.

Автор: tema-electric Jul 3 2013, 06:49

Хорошо, буду знать Я просто думал Вы определяете полную ширину записи и потом разбиваете ее так или иначе.

Автор: AVL Jul 3 2013, 07:00

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

Автор: tema-electric Jul 4 2013, 09:35

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

Сейчас приходится затирать поле Title у дубликатов, чтобы они не попадали в документацию.

Автор: AVL Jul 4 2013, 23:29

По-позже посмотрю что можно сделать. Сейчас дела навалились...

Автор: AVL Jul 6 2013, 08:01

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

Автор: AVL Jul 6 2013, 22:24

Развязал окна менеджера компонентов и EESchema в ревизии 4176.

Автор: tema-electric Jul 7 2013, 02:14

Александр, попробовать получится только через неделю Тоже работа навалилась. Спасибо!

Автор: AVL Jul 7 2013, 08:14

Добавил автоматическое перемещение курсора согласно выбранному компоненту в менеджере компонентов в ревизии 4177.
Сделал управление курсором из менеджера компонентов не только в EESchema, но и в Pcbnew (актуально для тех, кто вводит атрибуты компонентов на поздней стадии, либо редактирует существующую плату).

Автор: break Jul 15 2013, 14:18

AVL
Всё-таки я не понимаю. В выложенной схеме A1 и A2 в полях, кроме содержимого, отличий нет. Но почему-то у A1 при запуске Менеджера компонентов поле "Значение" остаётся, а у A2 стирается. Если в поле "Type" забить одинаковые значения, то у A1 начинается дублирование.
У меня создаётся впечатление, что сказывается содержимое поля "Значение".
Более того, я уверен в этом. Когда я вставил точку перед последней буквой, то содержимое поля не стёрлось и в Менеджере отобразилось.
Сборка 4179 вин.

Автор: AVL Jul 15 2013, 20:09

еще раз дублирую свой ответ:

Вы пишите "В выложенной схеме A1 и A2 в полях, кроме содержимого, отличий нет."
Как раз это и влияет:
A1: ChipName == Value ? Нет, значит отобразить поле "Номинал" равное атрибуту "Value".
A2: ChipName == Value ? Да, значит отобразить поле "Номинал" пустым.

Если Вы пишите, что у Вас поле называется "Значение", попробуйте обновиться из хранилища lp:~kicad-gost-committers/kicad/doc. Там в ревизии 446 исправлен перевод с "Значение" на "Номинал" в менеджере компонентов.

Автор: break Jul 16 2013, 05:46

AVL
A1: ChipName == Value ? Нет, значит отобразить поле "Номинал" равное атрибуту "Value".
A2: ChipName == Value ? Да, значит отобразить поле "Номинал" пустым.
A1 - "нет", A2 - таки тоже "нет".
Там всё одинаково, кроме содержимого полей "Значение" и "Посадочное место" (названия приведены как они сделаны в Eeschema). В поле "Тип" у каждого элемента стоит тильда.
Более того, добавление или удаление точки в поле "Значение" (в любое место, хоть в середину, хоть в начало, хоть в конец) приводит к тому, что ничего не стирается. И, кроме того, поле "Номинал" ("Значение" в Eeschema) не отображается пустым, оно стирается, точнее становится тильдой (и на схеме тоже!!!).
Правда удаление точки у A1 ничего не меняет.
Ничего не понимаю. (с)

Там в ревизии 446 исправлен перевод с "Значение" на "Номинал" в менеджере компонентов.
В Eeschema одно название, в Менеджере компонентов - другое. Путаница возникает, однако.

P.S. Сейчас ради эксперимента попробовал разные символы. Кроме точки можно в конец добавить пробел, чтобы безобразия прекратились.

Автор: AVL Jul 16 2013, 06:41

Поскольку поле в EESchema не во всех случаях однозначно соответствует полю в менеджере компонентов (осталась непрозрачность для "Value"), то я в объяснениях использую термин "атрибут", когда речь идет о свойствах компонента в EESchema. А термин "поле" я использую, когда речь идет о полях в менеджере компонентов.

Как же тоже нет? A2: атрибут ChipName (Имя компонента) = AM20CW-4812SZ, атрибут Value (Значение) = AM20CW-4812SZ.

Атрибут "Значение" (Value) влияет на поведение поля в менеджере компонентов. Атрибут "Посадочное место" (Footprint) ни на что не влияет в менеджере компонентов.

Тильда означает, что атрибут пустой. Вам нужно написать тип компонента в атрибуте "Тип" (Type) в свойствах компонента в EESchema, либо через менеджер компонентов в поле "Тип".

Так будет в случае компонента A1, поскольку у этого компонента атрибут ChipName != атрибуту Value.
В случае компонента A2 (ChipName == Value), если внесете любую модификацию в значение атрибута Value, то после этого значение атрибута Value отобразится в поле "Номинал" в менеджере компонентов.

Это после чего так происходит?

Да, все правильно (см. объяснение выше).

Как лучше? "Значение" или "Номинал"? Видимо надо голосование будет устраивать?

Это не верный подход. Чтобы "безобразия" реально прекратились, нужно прекратить вписывать тип компонента в атрибут Value ("Значение") / поле "Номинал".

Непрозрачность с полем "Номинал" введена только для того, чтобы не заставлять пользователей в старых схемах стирать значение атрибута Value ("Значение") для таких компонентов как микросхемы и др., поскольку атрибут Value ("Значение") не имеет смысла для них, а его заполненность вызывает путаницу и проблемы.

При правильном использовании должно быть заполнено следующим образом. Я уже не знаю сколько повторять одно и тоже

Для компонентов с номиналами (конденсаторы, резисторы, дроссели и некоторые другие):
атрибут Value = номинал, например, 1 кОм
атрибут Type = тип, например, МЛТ-0,125

Для компонентов без номиналов (микросхемы и другие):
атрибут Value = ДОЛЖЕН БЫТЬ ПУСТЫМ!, но так как через EESchema пустым его задать не получится, то нужно вписать "~".
атрибут Type = тип, например, SN74HC00D

Автор: tema-electric Jul 16 2013, 09:25

Вернулся из командировки, и собрал свежий кикад 4180 )) Хотел добить перечень Запуск менеджера выдал мне 4 предупреждения с текстом, мол некоторые компоненты были изменены вне схемы, после чего я попытался ткнуть в первый попавшийся компонент чтобы увидеть данные, после чего менеджер повис наглухо Пойду пересобирать.

Автор: AVL Jul 16 2013, 17:13

Этот баг удается повторить?
Предупреждения появлялись и при этом реально компоненты в схеме корректировались в ручную не закрывая менеджер компонентов? Или предупреждения вылезли без всякой причины?

Автор: tema-electric Jul 17 2013, 02:12

Повторить проблемы нет. Просто открываю схему и запускаю менеджер и он падает сразу, после 4х предупреждений. Над схемой работал 10 дней назад. Четыре предупреждения, потому что для каждой подсхемы вылазит свое, видимо. Но подсхем там больше четырех. До этого была сборка 4171, и все было хорошо. Сама схема у Вас уже есть (ее первый лист). Я присылал, когда были проблемы с пустым полем Type.

Чтобы сузить круг откатился до 76й ревизии и собрал ее. Она тоже не работает. Вот как-то так.

Автор: AVL Jul 17 2013, 05:37

Попробовал открыть схему из директории 4 и 5 (Схемы.zip), при открытии менеджера компонентов не падает. Может у меня не падает из-за того, что у меня только 1-й лист?

Автор: tema-electric Jul 17 2013, 07:08

Неа. Я пробовал на другой схеме однолистовой, к которой GOST-Tools вообще никогда не притрагивался. Поведение одно и тоже. Если у Вас есть deb пакет последней сборки, которая якобы рабочая, скиньте, я поставлю. Мне кажется это как-то связано с операционкой Ubuntu 10.04 LTS.

Автор: break Jul 17 2013, 07:28

AVL
я в объяснениях использую термин "атрибут", когда речь идет о свойствах компонента в EESchema. А термин "поле" я использую, когда речь идет о полях в менеджере компонентов.
Хорошо, пусть будет так.

Понял в чём дело. Я на "имя компонента" даже не смотрел. Считал, что это просто имя, под которым компонент числится в библиотеке и больше ни для чего не нужно. И это было бы правильно, чтобы не плодить кучу лишних элементов (но это уже давний спор, в котором к одному мнению так и не пришли).
С этими переименованиями/стираниями при совпадении/несовпадениями атрибутов у меня происходит стирание имён компонентов при генерации списка цепей, даже без запуска Менеджера компонентов.

Это после чего так происходит?
Если "Имя компонента" совпадает с атрибутом "Значение", то, при вызове Менеджера компонентов, содержимое атрибута "Значение" заменяется на тильду.

Чтобы "безобразия" реально прекратились, нужно прекратить вписывать тип компонента в атрибут Value ("Значение") / поле "Номинал".
Но у меня все библиотеки уже сделаны с использованием атрибута "Значение". Посмотрел старую стороннюю библиотеку от середины 2010 года, так там вообще нет атрибутов "Type". Это значит придётся переделывать все библиотеки?!!

Как лучше? "Значение" или "Номинал"? Видимо надо голосование будет устраивать?
Я бы предпочёл "номинал". Точнее описывает сущность.

P.S. И всё-таки как-то механизм не очень прозрачный. Может сделать по принципу "что вижу, то и имею"? Поставил опцию видимости атрибута - увидел на схеме, не поставил - не увидел. Продублированы атрибуты - в перечень/спецификацию вставляется только один. Но никакой самодеятельности по очищению атрибутов в схеме!

Автор: AVL Jul 18 2013, 07:51

Автор: tema-electric Jul 18 2013, 08:08

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

Автор: AVL Jul 18 2013, 11:42

На схеме из директорий 4 и 5 (Схемы.zip) у меня даже предупреждений никаких не выпадало при открытии менеджера компонентов. Выпадали предупреждения только при открытии самой схемы в EESchema, ругалось, что нет остальных листов схемы.

Автор: AVL Jul 18 2013, 20:05

Не пойму о чем речь.

Странно, у меня такого эффекта нет. Вот даже проверил еще раз, в пустую схему добавил элемент 7400 из стандартной библиотеки. Открываю менеджер компонентов, закрываю менеджер компонентов. Смотрю свойства элемента, как был атрибут "Значение" равен "7400" так и остался равен "7400".

Не обязательно. Можно пользоваться и текущей реализацией менеджера компонентов. А дальше посмотрим.

мне тоже больше "Номинал" нравится.

Да, хотелось бы поле "Номинал" тоже сделать полностью прозрачным. Вопрос открыт пока как лучше это сделать.

Так сейчас так и сделано. Что именно не так?

Автор: tema-electric Jul 19 2013, 03:06

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

Автор: AVL Jul 19 2013, 05:39

Ваш пример с одним элементом проверил в Ubuntu 10.04 и ситуация повторилась как у Вас.
Я вчера собрал пакет для Ubuntu 10.04 и проверил пример с мультивибратором, с ним проблемы не было. Также проблемы нет при любых примерах в Debian.

Буду разбираться.

Автор: break Jul 19 2013, 06:24

AVL
Не пойму о чем речь.
На примере всё той же многострадальной схемы.
A1 имеет имя компонента "R-785.0-0.5", атрибут "Значение" - "AMSR-783.3Z", атрибут "Type" - "AMSR-783.3Z". На схеме отображается атрибут "Значение".
A2 имеет имя компонента "AM20CW-4812SZ", атрибут "Значение" - "AM20CW-4812SZ", атрибут "Type" - "AM20CW-4812SZ". На схеме отображается атрибут "Значение". При запуске Менеджера компонентов, или при генерации списка цепей, атрибут "Значение" на схеме заменяется тильдой и, соответственно, не отображается. Атрибут "Type" не отображается, потому что он изначально не указан как видимый (в библиотеке такого атрибута вообще нет!).
Происходит при совпадении имени компонента и атрибута "Значение".

Так сейчас так и сделано. Что именно не так?
То, что атрибут стирается в схеме, а не просто добавляется или нет в перечень/спецификацию.

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

Application: Eeschema
Version: (2013-07-10 BZR 4179 GOST-COMMITTERS)-testing
Build: wxWidgets 2.9.4 (wchar_t,compiler with C++ ABI 1002,GCC 4.7.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW
Boost version: 1.53.0
Options: USE_PCBNEW_NANOMETRES=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
KICAD_SCRIPTING=OFF
KICAD_SCRIPTING_MODULES=OFF
KICAD_SCRIPTING_WXPYTHON=OFF

Автор: AVL Jul 20 2013, 09:49

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

Автор: AVL Jul 20 2013, 16:28

Все описанные глюки смог повторить.
Итог:
1) поскольку непрозрачность работы с атрибутом Value стала существенно мешать разработке (часть из последних глюков была в усложнившейся логике по обработке этого атрибута на разных этапах после того как развязал окна), принято решение сделать работу с атрибутом Value прозрачной. Прежняя логика по анализу ChipName==Value теперь выполняется отдельной функцией. Данная функция при открытии менеджера компонентов делает проверку всех компонентов. Если обнаруживается ситуация ChipName==Value, выдается предупреждающее сообщение о том, что будут внесены изменения в атрибуты таких компонентов. Пользователь либо подтверждает, либо отказывается.
2) "Запустил менеджер, выпало предупреждение." Как оказалось, у меня проявляется только в Ubuntu 10.04 (wxWidgets 2.8.10). Выглядит все так, что поведение wxWidgets отличается у разных версий то ли самих wxWidgets, то ли ОС. Исправил.
3) "Выбрал элемент, завис менеджер." тоже самое, что и в п.2. Чтобы побороть эту проблему для Ubuntu 10.04 (wxWidgets 2.8.10), пришлось отказаться от управления менеджером компонентов курсором в Pcbnew (оставил управление курсором только в EESchema). То есть в Ubuntu 10.04 (wxWidgets 2.8.10) зависание происходит из-за того, что отправляю сообщения и в EESchema и сразу в Pcbnew через механизм dde. Похоже, что нужно дорабатывать механизм dde в самом KiCad. Либо это баг wxWidgets, поскольку используется работа с сокетами от wxWidgets.

Актуальная ревизия 4186.

Сейчас в основном могут выпадать 2 типа сообщения, на которые пока не добавлен русский перевод. Привожу перевод пока здесь:
1) "Some components have equal 'Chip Name' and 'Value' attributes!
'Value' attributes will be copied to 'Type' ones including their position, orientation and visibility. After that 'Value' attributes will be cleared.
If some of components do not have 'Type' attribute then such attributes will be created.
Continue?"

"Некоторые компоненты имеют равные значения атрибутов "Chip Name" ("Имя компонента") и "Value" (Номинал / Значение) !
Значения атрибутов "Value" будут скопированы в атрибуты "Type", включая их координаты, ориентацию и флаг видимости. После чего значения атрибутов "Value" будут стерты.
Если некоторые из компонентов не будут иметь атрибут "Type", то такие атрибуты будут созданы.
Продолжить?"

2) "Some components were changed outside of the Component Manager.
The changes have been transferred back to the Component Manager."

"Некоторые компоненты были изменены вне Менеджера Компонентов.
Эти изменения загружены обратно в Менеджер Компонентов."

Автор: faa Jul 20 2013, 18:09

Обновил перевод в gost-committers-doc - bzr449.

Автор: AVL Jul 20 2013, 18:28

Спасибо

Автор: break Jul 22 2013, 06:59

AVL

Не очень удачный вопрос - может ввести в заблуждение. Лучше написать "Выполнить перобразование?".
(По-басурмански тоже соответственно.)

пришлось отказаться от управления менеджером компонентов курсором в Pcbnew
А это нужно? Я считаю, что нет.

оставил управление курсором только в EESchema
Это нормально.

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

Автор: AVL Jul 22 2013, 07:58

OK

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

Ну Вам никто не мешает добавить эти атрибуты в библиотеки

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

Автор: tema-electric Jul 22 2013, 08:39

Собрал сегодня последнюю версию. Все работает Большое спасибо )

Автор: tema-electric Jul 23 2013, 04:07

Баги.

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

Если зажать shift и попытаться выделить группу элементов, менеджер виснет.

Автор: AVL Jul 23 2013, 05:39

Вчера сделал merge с lp:kicad, а сегодня обнаружил, что eeschema при запуске падает. Так что будем сначала с этим разбираться.

Автор: AVL Jul 23 2013, 19:50

В ревизии 4189 теперь OK.

Автор: AVL Jul 24 2013, 08:08

Удалось повторить только в Ubuntu 10.04. Пока выяснил только, что зависает опять из-за отправки пакетов через dde (управление курсором). Надо разбираться как это исправить.

Автор: blmt Aug 4 2013, 00:04

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

Патч прилагается.

Автор: AVL Aug 4 2013, 10:11

Приветствую, Максим. Спасибо за патч. Патч применен в ревизии 4199 ветки lp:~kicad-gost-committers/kicad/kicad .

По поводу dde Вы похоже говорите о стандартном DDE, который используется как одна из технологий взаимодействия процессов в винде.
В исходниках KiCad используется свой собственный механизм, который, похоже, разработчики KiCad назвали одноименной аббревиатурой dde. Этот механизм в KiCad сделан на основе сокетов фрейморка wxWidgets и является кросс-платформенным (а виндовый DDE только для винды). С учетом того, что KiCad dde отправляет сообщение через сокеты, не вижу проблемы в использовании KiCad dde в том числе пределах одного процесса. В чем там проблема, так и не разбирался пока.

P.S.:
если хотите, можем добавить Вас в команду lp:~kicad-gost-committers, чтобы коммитить изменения в lp:~kicad-gost-committers/kicad/kicad. Для этого нужно зарегистрироваться на http://electronix.ru/redirect.php?https://login.launchpad.net/+login (если еще не зарегистрированы) и далее http://electronix.ru/redirect.php?https://launchpad.net/~kicad-gost-committers/+join

Автор: blmt Aug 4 2013, 21:21

Я имел ввиду внутренний механизм Kicad, реализованный через wxSocket. Если ипользовать его внутри одного процесса, то возможно зацикливание. Подробнее: При клике мыши в gtk_main() при ходит сообщение, которое через wx вызывает GOST_COMP_MANAGER::OnClickListCtrl(), SendCommand(), wxSocketClient::Connect(),wxSocketClient::WaitConnect(), wxSockeBase::_Wait(),wxApp::Yield() . wxApp::Yield() вызывает gtk_main_iteration(), которая вызывает EDA_DRAW_FRAME::OnSockRequest(), wxSockeBase::Read(), потом wxSockeBase::_Wait(), которая повторно вызывает wxApp::Yield(). wxApp::Yield() анлизирует повторный вход и вызывает wxAppBase::OnAssertFailure(). В Release сборке wxAppBase::OnAssertFailure() выкидывается, и программа уходит в цикл. В Debug версии выкидывает диалог исключения. Подробное описание зацикливания очень многословно, хотя код весьма простой. Проще читать прямо код. Резюме: встроенный dde служит для межпроцессного взаимодействия, применение внутри одного процесса чревато трудноуловимыми глюками.



Я не смогу заниматься этим проектом на постоянной основе. Моё хобби читать код открытых проектов. Здесь я увидел небольшую головоломку и попытался её решить. Сам проект некрасив архитектурно, развивался эволюционно без должного проектирования. Изначально были заложены весьма ограниченные модели данных. Теперь практически невозможно переделать систему без потери совместимости, и значит проект практически обречён на статус поделки. Ситуация с аттрибутом Value == Chip-Name, наглядно это показывает. Поэтому я только читать.

Автор: AVL Aug 5 2013, 04:55

Буду надеяться, что головоломки KiCad, хотя бы и небольшие, будут Вас заинтересовывать и впредь

Автор: tema-electric Aug 5 2013, 05:32

Апробировал 99 сборку. Большое спасибо за патч. Теперь все работает