[Guest White_Rabbit]

Что-то в 4115 никак не могу перегнать полигоны в гербер. Проводники идут, полигонов не видно.

[AVL 0]

По поводу BOM:

1. Раньше практически устраивало.

1.1. Сейчас вместо нормального разделителя (например, табуляции) - запятые, даже без пробелов - всё сливается.

1.2. Совсем ни к чему выводить поля, которых нет - надо иметь возможность задавать необходимые. Не надо выводить поля, которые не отвечают за тип элемента. Например, в разъёмах навания цепей сделаны дополнительными полями, которые можно оперативно редактировать. Спрашивается: для чего их надо выводить в BOM?

1.3. Нет сортировки.

1.4. То, что получается сейчас, это не BOM, а просто список компонентов, присутствующих на схеме.

1.5. Если формирование BOM можно корректировать изменением XLS файла, то это шаг назад (или даже два) в использовании современного интерфейса. Вместо того, чтобы использовать графический интерфейс, как это стараются делать везде (удобно же ведь), придётся править в текстовом виде, да ещё и в структуре многим неизвестного формата XML. Плагин должен выглядеть как нормальная GUI программа (если уж нельзя это встроить в Eeschema) с набором кнопок и других графических элементов управления.

Например:

"добавить поле"

"сортировать по полю"

"объединить по полю"

"обратная сортировка"

"порядок сортироки по полям"

"объединение только смежных элементов"

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

Вводить и править XML теги - это нонсенс.

2. "Для применения процессора xsltproc в Windows надо распаковать его архив в каталог c:\Windows\System32." Это совершеннейшее безобразие.

Надо или ставить как отдельную программу в "Program Files", или куда-нибудь в каталог KiCAD'а. Мало всякого хлама лежит в "System32", так надо ещё загадить, тем более сторонней программой.

Не стал пока "бодаться" с lp:kicad

AVL

А нельзя ли в GOST-doc-gen сборке реанимировать кнопку BOM (или вставить Generate BOM в Component Manager).

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

[break 0]

Pcbnew совсем испортили.

При попытке вставки посадочного места на плату (через просмотр модулей) возникает следующее сообщение об ошибке:

 

Could not load footprint "имя модуля" from library "моя библиотека".

Error IO_ERROR: Путь библиотека посадочных мест <путь+имя моей библиотеки> не существует
from c:/msys/1.0/home/vik/kicad_testing/pcbnew/kicad_plugin.cpp : Load() : line 214.

Хотя список модулей в библиотеке виден.

При повторной попытке вставки модуля, Pcbnew вообше глухо виснет.

 

Application: Pcbnew

Version: (2013-05-22 BZR 4159 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

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

 

P.S. Дополнение.

Может не совсем точно, но у меня создалось впечатление, что при сохранении настроек из Pcbnew, в файле проекта стираются настройки от Eeschema.

Edited May 29, 2013 by break

[qxov 0]

Первый баг: перетаскиваем компонент с зажатым Ctrl, жмем R.

Второй баг: пытаемся отменить результат первого бага (Undo) - не до конца отменяется (поворот сохранился)

 

Третий баг (или фича - я первый раз KiCAD запустил, не в курсе пока): попытка перетаскивания компонента с Ctrl, если он был подсоединен к проводнику перпендикулярно без промежуточного провода, приводит к отрыванию компонента от проводника.

 

Четвертое. Не уверен вообще, что есть проблема, но пока не нашел способа как после перетаскивания компонента поправить проводники без их удаления с последующим восстановлением.

[break 0]

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

 

4181 win - всё то же самое, что и в 4159. Pcbnew не работает.

[AVL 0]

По поводу BOM:

1. Раньше практически устраивало.

1.1. Сейчас вместо нормального разделителя (например, табуляции) - запятые, даже без пробелов - всё сливается.

1.2. Совсем ни к чему выводить поля, которых нет - надо иметь возможность задавать необходимые. Не надо выводить поля, которые не отвечают за тип элемента. Например, в разъёмах навания цепей сделаны дополнительными полями, которые можно оперативно редактировать. Спрашивается: для чего их надо выводить в BOM?

1.3. Нет сортировки.

1.4. То, что получается сейчас, это не BOM, а просто список компонентов, присутствующих на схеме.

1.5. Если формирование BOM можно корректировать изменением XLS файла, то это шаг назад (или даже два) в использовании современного интерфейса. Вместо того, чтобы использовать графический интерфейс, как это стараются делать везде (удобно же ведь), придётся править в текстовом виде, да ещё и в структуре многим неизвестного формата XML. Плагин должен выглядеть как нормальная GUI программа (если уж нельзя это встроить в Eeschema) с набором кнопок и других графических элементов управления.

Например:

"добавить поле"

"сортировать по полю"

"объединить по полю"

"обратная сортировка"

"порядок сортироки по полям"

"объединение только смежных элементов"

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

Вводить и править XML теги - это нонсенс.

2. "Для применения процессора xsltproc в Windows надо распаковать его архив в каталог c:\Windows\System32." Это совершеннейшее безобразие.

Надо или ставить как отдельную программу в "Program Files", или куда-нибудь в каталог KiCAD'а. Мало всякого хлама лежит в "System32", так надо ещё загадить, тем более сторонней программой.

 

AVL

А нельзя ли в GOST-doc-gen сборке реанимировать кнопку BOM (или вставить Generate BOM в Component Manager).

 

В ревизии 4214 ветки lp:kicad появились еще нововведения по BOM. Вместо той ссылки на FAQ добавлена работа с плагинами.

Нужно ваше мнение. Эти плагины решают проблему? Или пока все еще проблему решает только реанимированный нами BOM?

Я BOM пока вообще не пользовался (не уверен, что вообще буду пользоваться), поэтому полного представления по проблеме нет.

[AVL 0]

В ревизии 4214 ветки lp:kicad появились еще нововведения по BOM. Вместо той ссылки на FAQ добавлена работа с плагинами.

Нужно ваше мнение. Эти плагины решают проблему? Или пока все еще проблему решает только реанимированный нами BOM?

Я BOM пока вообще не пользовался (не уверен, что вообще буду пользоваться), поэтому полного представления по проблеме нет.

Восстановил старую генерацию BOM после вырезания очередной порции кода в ревизии 4214 ветки lp:kicad.

Сделал 2 пункта меню:

1) eeschema->Tools->Generate Bill of Materials (old implementation)

2) eeschema->Tools->Generate Bill of Materials

 

Возможно пригодятся обе реализации генерации BOM (новая и старая).

[viknn 0]

В ревизии 4214 ветки lp:kicad появились еще нововведения по BOM. Вместо той ссылки на FAQ добавлена работа с плагинами. Нужно ваше мнение. Эти плагины решают проблему? Или пока все еще проблему решает только реанимированный нами BOM?

Если посмотреть на пример ECAD-системы Altium Designer 2013, то в ней по команде Report/Bill of Materials

дается пять альтернативных способов вывода BOM-данных: от обычнных таблиц CSV и XLS до XML-файла.

Понятно, что все эти виды являются тоже полуфабрикатными в смысле формирования ПЭ и СП по ГОСТ. Проблемы те же, но есть альтернативность.

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

В нашем случае JP и команда ликвидируют CSV-вывод в угоду PY-плагинам и XSL-методам обработки XML от пользователей.

Видимо, правильно оставить и CSV, и XML, и PY, и Component Manager с ODT-выводом. Наверно неплохо, если бы Component Manager мог черпать исходные данные не только со схемы, но и из промежуточного формата типа XML или CSV.

Вопрос, как это все лучше увязать.

_____________BOM_AD.pdf

Edited June 16, 2013 by viknn

[AVL 0]

Наверно неплохо, если бы Component Manager мог черпать исходные данные не только со схемы, но и из промежуточного формата типа XML или CSV.

Вопрос, как это все лучше увязать.

В каком случае это было бы полезно? В случае если генерировать КД из других CAD типа Altium Designer (особенно, если не предусмотрен их импорт в KiCad) посредством GOST-doc-gen?

Или есть еще случаи, когда это нужно?

[viknn 0]

В каком случае это было бы полезно? В случае если генерировать КД из других CAD типа Altium Designer (особенно, если не предусмотрен их импорт в KiCad) посредством GOST-doc-gen?

В первую очередь я имел ввиду смежные ECAD-программы (коммерческие и нет) с аналогичными проблемами.

[break 0]

Хоть кто-нибудь может понять принцип по которому при черчении в DXF (Pcbnew) некоторые надписи преобразуются нормально, а большинство теряют координаты и становятся жирными? Может это как-то связано с какими-то символами в тексте?

[tema-electric 0]

Хоть кто-нибудь может понять принцип по которому при черчении в DXF (Pcbnew) некоторые надписи преобразуются нормально, а большинство теряют координаты и становятся жирными? Может это как-то связано с какими-то символами в тексте?

Не было такого, сколько сборочников делали. Единственное неудобство, что текст преобразуется в кривые. Сейчас проверил на сборке 3985 от 06.03.2013. Смотрел в LibreCAD. Все нормально.

 

ADigiBoard_F_SilkS.zip

 

Может у Вас проблемы с чем-то другим?

[baranovskiykonstantin 0]

Хоть кто-нибудь может понять принцип по которому при черчении в DXF (Pcbnew) некоторые надписи преобразуются нормально, а большинство теряют координаты и становятся жирными? Может это как-то связано с какими-то символами в тексте?

 

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

Из-за этого в DXF файлах текстовые блоки, сохраненные как текст (латиница) отображаются с помощью шрифта, установленного в настройках программы просмотра/редактирования DXF, а текстовые блоки, нарисованные с помощью кривых - отображаются также как и в PCBnew.

 

[viknn 0]

DXF, официально, поддерживает только латиницу.

Странное ограничение. Может DXF в Kicad так настроен. А вообще-то не должно быть разницы

латиница-кириллица. Сейчас и LibreCAD и Компас отображают utf8 текстовые строки на русском

ttf-шрифтами. Переход к векторному генератору текста в kicad создает проблемы (так как это уже не текст, а набор линий).

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

[baranovskiykonstantin 0]

Странное ограничение. Может DXF в Kicad так настроен. А вообще-то не должно быть разницы

латиница-кириллица.

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