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

Некоторое время назад разбирался, почему падает на wrl из Блендера. Ошибка была в отсутствии нескольких проверок указателей; впрочем, даже если исправить - это не поможет из-за неполной поддержки vrml, полностью грузятся только модели из wings3d с упрощенной структурой. Если есть желание, можете попробовать мой костыль для преобразования wrl - github.com/stxent/wrlconv (правда проверял только на экспортированных из блендера).

Спасибо. Косяки и ошибочные идеологии не дают возможности сделать окончательный набор инструментов. Недавно заинтересовался OpenSCAD. Имхо, вещь гораздо более правильная, чем порождение океана vrml -файлов в мутном wings-е. Как только попробую что-нить средней сложности реализовать - смогу сделать выводы. Но при этом, касательно сабжа, встают другие проблемы: отсутствие *.dxf - импорта и кривой *.dxf экспорт.
Хотя, в принципе, он кривой и в протеусе, например - как ни создавай контур платы в мм - он все равно в дюймах выдаст, и слои не обзовет так, как принято в проекте.

Спасибо. Косяки и ошибочные идеологии не дают возможности сделать окончательный набор инструментов. Недавно заинтересовался OpenSCAD. Имхо, вещь гораздо более правильная, чем порождение океана vrml -файлов в мутном wings-е. Как только попробую что-нить средней сложности реализовать - смогу сделать выводы. Но при этом, касательно сабжа, встают другие проблемы: отсутствие *.dxf - импорта и кривой *.dxf экспорт.
Хотя, в принципе, он кривой и в протеусе, например - как ни создавай контур платы в мм - он все равно в дюймах выдаст, и слои не обзовет так, как принято в проекте.

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

Application: Eeschema
Version: (2011-oct-02 BZR 3157 GOST)-testing
Build: wxWidgets 2.9.2 (wchar_t,compiler with C++ ABI 1002,GCC 4.5.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

Выводы всех символов питания (или стрелок разорванных цепей) должны быть обозначены как "Power_in" (Вход питания), иначе в списке цепей соединения не будет. Интересно, а для чего нужны "Power_out" (Выход питания)? Только для прохождения теста ERC?

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

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

Сообщение отредактировал break - Oct 26 2011, 07:41

Добрый день !

Неплохо бы было добавить в калькулятор что-нибудь из
http://focus.ti.com/analog/docs/gencontent...enContentId=860

Было бы весьма полезно.

Application: Pcbnew
Version: (2011-oct-02 BZR 3157 GOST)-testing
Build: wxWidgets 2.9.2 (wchar_t,compiler with C++ ABI 1002,GCC 4.5.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW

При перемещении сегмента с сохранением наклона при выбранном инструменте "Добавить дорожки и переходные отверстия", шаг перемещения берётся непонятно откуда - сетке не соответствует. При всех других инструментах (там где получается двигать) - соответствует.

fox1
Уж лучше тогда добавить 3-х выводные стабилизаторы и расчёт переходных отверстий.

Сообщение отредактировал break - Oct 27 2011, 14:50

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

Application: Pcbnew
Version: (2011-oct-25 BZR 3193 GOST)-testing
Build: wxWidgets 2.9.2 (wchar_t,compiler with C++ ABI 1002,GCC 4.5.2,wx containers,compatible with 2.8)
Platform: Windows XP (build 2600, Service Pack 3), 32 bit, Little endian, wxMSW
Options: USE_PNG_BITMAPS=ON
KICAD_GOST=ON
USE_WX_GRAPHICS_CONTEXT=OFF
USE_WX_OVERLAY=OFF
USE_BOOST_POLYGON_LIBRARY=ON

При переключении на масштаб "200" смещается центр масштабирования (и курсор).

faa
А нельзя ли узнать какие события в макросы заносятся, а какие нет? Пробую сделать действие через меню (очистка дорожек и переходных отверстий - очень востребованная команда) - и не получается.

События меню пока не заносятся, только горячие клавиши.

Pcbnew... всё тот же.

Что-то надо делать с блокированием проводников и переходок. Ситуация такая: пытаюсь связать полигоны на разных слоях - начинаю проводник, ставлю переходку, заканчиваю проводник. Перезаливаю зону - всё замечательно. Пытаюсь заблокировать цепь или дорожку ("Установить флаг"), устанавливается только просто "Блокировано". Делаю Очистку дорожек и переходных отверстий, после этого проводник и переходка отвязываются от полигонов. При следующей "Перезаливке" полигоны изолируются от этого проводника и переходки, при повторе "Очистке" проводник и переходка удаляются. Если соединить проводник с проводником или контактной площадкой, которые и так уже соединены с нужной цепью (и этим полигоном), то всё остаётся на месте.
Из-за этого в некоторых местах приходится дублировать соединение через полигон проводом, а где-то вообще затруднительно найти контакт с нужной цепью.

Надо обязательно соединять с нужной цепью. А то висящие дорожки при перезаливке будут отсоединены (будут без цепи), а зона будет их обтекать.

В дублировании нет ничего страшного.
А вот контакт придется находить - иначе дорожка повиснет при перезаливке зоны.



Жаль, что терпение иссякло

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

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

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



Хор. Проверю, посмотрим, что можно сделать.



Должен делать по сетке.
Недавно делал проект - много двигал наклонных сегментов (и руками и макросами) - проблем не заметил.
Посмотрю.

Расчет делителя для стабилизатора есть.

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



Но проблема эта есть (даже курсор не всегда на сетку попадает), решение тоже предложено (vovanium давно эту тему муссирует ), но там писанины...
Точность бесполезно повышать - там и так double. Надо переходить на "попугаи" (типа нанометров).
Пересчитывать только из "попугаев" в куда надо , чтобы дробных "попугаев" не было.

Пока стараюсь от дюймов уходить - делаю все в метрических единицах.
Вношу небольшую ошибку (в допустимых пределах), следующей ножкой компенсирую и т.д.
Некоторые сложности были с бга (300 с лишним шариков) с шагом 1.27, ее сделал в дюймовой сетке.


Сообщение отредактировал faa - Nov 2 2011, 15:38

faa
Спасибо за реагирование и исправления.

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

Расчет делителя для стабилизатора есть.
Там расчёт 4-х выводных стабилизаторов, а чаще используются 3-х выводные. Но для 3-х выводных придётся ещё вводить дополнительные параметры по напряжению "прямой" стабилизации и току утечки по управляющему/общему выводу.
Хотя это просто считается и на обычном калькуляторе.

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

Некоторые сложности были с бга (300 с лишним шариков) с шагом 1.27, ее сделал в дюймовой сетке.
Внутренний формат всё равно дюймовый, округление делается автоматически (надеюсь правильным методом), так что и в метрической системе рисование должно было быть нормально.