[AVL 0]

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

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

В первоисточнике и в полном виде об этом можно почитать здесь:

https://code.launchpad.net/~kicad-gost-comm...d/+merge/163239

и здесь:

https://lists.launchpad.net/kicad-developers/msg10412.html

 

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

[Aldan 0]

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

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

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

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

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

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

 

[tema-electric 0]

стабильная сборка — такая сборка которая приведена к максимально возможной завершенности и безглючности

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

[AVL 0]

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

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

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

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

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

Здесь могу предложить такой вариант, дожидаемся, когда менеджер компонентов+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 0]

gerbv

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

[AVL 0]

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

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

[tema-electric 0]

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

Смотрел. Вроде не показал тогда. Сейчас проверил - показывает. Это про кикадовский viewer.

А так я им не пользуюсь. По началу пользовался. Причина проста.

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

Имена герберов тоже в кикаде излишне подробные. Для этого скрипт написан, в стиле

#!/bin/bash
# Утилита для переименовывания файлов проекта KiCAD
rename -f 's/^.*/ADigBoard.g1/gi' *VCC.gbr
rename -f 's/^.*/ADigBoard.g2/gi' *GND.gbr
rename -f 's/^.*/ADigBoard.gbr/gi' *.gbr
rename -f 's/^.*/ADigBoard.gtl/gi' *.gtl
rename -f 's/^.*/ADigBoard.gts/gi' *.gts
rename -f 's/^.*/ADigBoard.gto/gi' *.gto
rename -f 's/^.*/ADigBoard.gbl/gi' *.gbl 
rename -f 's/^.*/ADigBoard.gbs/gi' *.gbs
rename -f 's/^.*/ADigBoard.gbo/gi' *.gbo

[viknn 0]

AVL

Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:

1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?

2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?

3) dcm-файл можно не формировать.

[AVL 0]

AVL

Gost Tools начал осваивать с конвертера библиотек и проектов Pcad. Вопросы и замечания:

1) Из файлов LIA можно получить только LIB-библиотеки kicad, а MOD?

2) Передаются параметры F0, F1, F2. Если есть F3 - например ТУ (TU) - он теряется?

3) dcm-файл можно не формировать.

Ответ перенес в новую тему по pcad2kicad

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

[viknn 0]

AVL

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

После работы с GOST Component Manager компоненты получают новые поля и атрибуты.

Обновленный BOM можно будет использовать разными способами. В частности,

для выпуска карт рабочих режимов ЭРИ (для аппаратуры ВН).

[AVL 0]

AVL

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

Да, можно.

После работы с GOST Component Manager компоненты получают новые поля и атрибуты.

Обновленный BOM можно будет использовать разными способами. В частности,

для выпуска карт рабочих режимов ЭРИ (для аппаратуры ВН).

Вот здесь не совсем понимаю о чем речь. Можете на примере более подробнее объяснить?

Также не знаю, что такое ЭРИ и аппаратура ВН. Посмотрел в поисковике, понимание не наступило.

[viknn 0]

Также не знаю, что такое ЭРИ и аппаратура ВН. Посмотрел в поисковике, понимание не наступило.

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

[AVL 0]

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

Правильно ли я понимаю:

1) есть желание использовать готовую систему Асоника (не делать ее аналог)?

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

3) достаточно реанимировать именно в том виде как была до этого сделана генерация BOM или потребуется адаптация, например, под Асонику-Р?

 

P.S.:

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

[AVL 0]

...

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

 

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

Сейчас нужно либо дожидаться пока КД сгенерируется и заполнится до последнего листа, либо ждать пока доработаю этот момент :)

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

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

[viknn 0]

достаточно реанимировать именно в том виде как была до этого сделана генерация BOM или потребуется адаптация, например, под Асонику-Р?

Разобрать готовый csv-файл несложно.

Важно иметь аппарат для задания всех необходимых атрибутов компонентов (в т.ч. ТУ).

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