[break 0]

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

[alexen 0]

Реально ли разобраться, отчего 3Д просмотр падает при указании wrl, созданного во фрикаде?

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

[_Pasha 0]

Если есть желание, можете попробовать мой костыль для преобразования wrl - github.com/stxent/wrlconv (правда проверял только на экспортированных из блендера).

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

Хотя, в принципе, он кривой и в протеусе, например :) - как ни создавай контур платы в мм - он все равно в дюймах выдаст, и слои не обзовет так, как принято в проекте.

[_Pasha 0]

Если есть желание, можете попробовать мой костыль для преобразования wrl - github.com/stxent/wrlconv (правда проверял только на экспортированных из блендера).

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

Хотя, в принципе, он кривой и в протеусе, например :) - как ни создавай контур платы в мм - он все равно в дюймах выдаст, и слои не обзовет так, как принято в проекте.

[break 0]

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

[break 0]

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.

Изменено 26 октября, 2011 пользователем break

[fox1 0]

Добрый день !

 

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

http://focus.ti.com/analog/docs/gencontent...enContentId=860

 

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

[break 0]

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-х выводные стабилизаторы и расчёт переходных отверстий.

Изменено 27 октября, 2011 пользователем break

[ukpyr 0]

Сегодня исполнился ровно год с момента вот этой короткой переписки в данной теме:

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

[break 0]

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" смещается центр масштабирования (и курсор).

[break 0]

faa

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

[faa 4]

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

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

 

[break 0]

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

 

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

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

[faa 4]

Если соединить проводник с проводником или контактной площадкой, которые и так уже соединены с нужной цепью (и этим полигоном), то всё остаётся на месте.

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

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

В дублировании нет ничего страшного.

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

 

 

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

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

 

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

Можете лучше? Тогда принимайте участие в разработке.

А то хаять желающих много, а когда до дела доходит - то терпения нет, то времени, то еще что мешает :(

ЗЫ: Кто хочет делать, тот ищет возможности, кто не хочет - ищет причины (с) не мой

 

Теперь по делу:

Выложу перловый скриптик - делает из бом-а текстовые строки под рамку перечня элементов

с нужным шагом по вертикали и форматом (позиция, номенклатура, количество, примечание).

Удобно, если перечень делать на первом листе схемы. Добавляем эти строки в файл первого листа схемы - имеем перечень.

 

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

Надо вводить новый тип листа со своей нумерацией и т.д. и т.п.

И еще встает колом вопрос, как листы перечня связать с листом схемы.

Один из вариантов - разместить листы перечня за рамкой первого листа.

И надо это все оборачивать в коде в соответствующие дефайны (KICAD_GOST), чтобы супостаты не бухтели.

Писанины много, да и мысли по этому поводу еще не все устаканились.

 

 

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

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

 

 

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

Должен делать по сетке.

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

Посмотрю.

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

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

 

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

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

 

 

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

Но проблема эта есть (даже курсор не всегда на сетку попадает), решение тоже предложено (vovanium давно эту тему муссирует :)), но там писанины...

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

Пересчитывать только из "попугаев" в куда надо , чтобы дробных "попугаев" не было.

 

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

Вношу небольшую ошибку (в допустимых пределах), следующей ножкой компенсирую и т.д.

Некоторые сложности были с бга (300 с лишним шариков) с шагом 1.27, ее сделал в дюймовой сетке.

 

Изменено 2 ноября, 2011 пользователем faa

[break 0]

faa

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

 

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

А зачем тогда нужно блокирование, которое всё равно не работает?

 

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

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

Хотя это просто считается и на обычном калькуляторе.

 

Точность бесполезно повышать - там и так double.

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

 

Некоторые сложности были с бга (300 с лишним шариков) с шагом 1.27, ее сделал в дюймовой сетке.

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