Re: gEDA-pt: Nomeclatura de componentes no gSchem

[Xtian Xultz <xultz@xxxxxxxxxxxx>]

Em Seg 11 Jul 2005 14:30, Antonio escreveu:
> Em Seg, 2005-07-11 Ãs 13:28 -0300, Xtian Xultz escreveu:
> > Se quiser desenho tres diferentes, por exemplo um com pads enormes
> > para
> > montagem de prototipo, um com pads infimos para montagem
> > completamente
> > automatizada e sem manutencao, e um meio termo.
> >
> > Componentes como CIs DIL eu tenho dois footprints diferentes, isso
> > porque eu
> > nao costumo faze-los com ilhas oblongas.
>
> Ã.. Daà complica. Mas acho que isso sÃo mais detalhes do layout mesmo,
> comparÃvel à questÃes do tipo por onde vÃo passar as trilhas, entende?
> NÃo mudou o encapsulamento do componente, e sim como ele està ligado, Ã
> como o caso da dobra do terminal do resistor!
>
Neste caso, o que o gnetlist -gPCB faz eh perfeito, mas sabemos que nao eh.

> Tipo, uma coisa à saber atà onde o o projetista eletrÃnico tinha
> informaÃÃes a passar para o layoutista.
>
Idem acima.

Veja, o projetista se preocupa com detalhes eletronicos. O layoutista com 
detalhes mecanicos (eu considero a espessura duma trilha, a distancia entre 
elas, etc detalhes mecanicos, por mais estranho que possa parecer). 
A questao eh: como podemos automatizar isso tudo?
Voce sabe bem que tenho feito muitas placas sem usar gsch2pcb, gattrib, etc. 
Isso nunca foi um impedimento. Porem eu tenho me re-perguntado sobre muitas 
coisas, ateh (pasmem!) auto-roteamento. Eu sempre fico pensando "peraih, isto 
que estou fazendo agora, nao poderia ser mais automatico? Catzo, tenho um 
computador que opera na frequencia do meu forno de microondas, nao posso 
tirar partido nisso?"
Eu acho que a discussao aqui gira em torno disso.

> Talvez seja isso.
> Talvez devamos determinar isso em dois universos e tentar estabelecer o
> que cabe a cada um deles.
> O que à informaÃÃo que depende de funcionamento eletrÃnico ficar
> tangÃvel ao projetista eletrÃnico, ao fazer o diagrama. Onde ele possa
> especÃficar as coisas muito genericamente, como por exemplo, se à SMD ou
> TH, potÃncia de um resistor etc. Mas acho importante que se passe, desde
> o diagrama "uma expressÃo mÃnima" do tipo de componente.
>
Veja, eh impossivel desenhar um diagrama sem saber absolutamente tudo sobre o 
projeto, desde o tipo de alimentacao, tolerancia dos componentes, etc. 
Exatamente o mesmo ocorre com o layout. O layoutista precisa saber ateh os 
minimos detalhes para comecar o trabalho. E voce Antonio sabe como eh comum o 
cliente pedir orcamento para uma "coisa" sem especifica-la, e voce Emerson 
sabe como eh comum ter que desenhar uma placa sem saber sequer que caixa vai 
ser usada, que conectores, etc. E isso faz a todos nÃs arrancar os cabelos. 
Entao, passar uma informacao que nao seja completa eh mesmo que nada. Porque 
o layoutista vai ter que preencher a informacao que falta de alguma maneira 
manual. Se for assim, mais facil fazer a biblioteca sem informacao alguma, a 
biblioteca vai crescer muito mais rapidamente e o resultado serah o mesmo. 

> E detalhes mais minunciosos, como distÃncias entre trilhas, tamanhos de
> ilhas e pads, coisas referentes à montagem, ou seja, coisas que sÃo de
> cunho mais mecÃnico deixar de vez para o layoutista.
>
> Se puder ser assim, faltaria resolver, dentro do desenho da biblioteca,
> o que à embutido, ou seja, vem no sÃmbolo, e oque deve ser posto nÃo
> mÃo, em atributo footprint sobre o componente. Eu nÃo acho problema em
> vocà ter, jà dispostos na biblioteca, especificados um 74HC573-TH e um
> 74HC573-SMD, ao menos cada um jà carrega consigo o DIP20 ou SO20. Neste
> caso o layoutista deve escolher entre seus footprints cabÃveis o que se
> aplica na ocasiÃo. entende?
>
Isso funcionaria se o codigo do pcb ou do gnetlist ou ateh do gsch2pcb fossem 
diferentes. Ficaria pratico ele pesquisar na biblioteca e encontrar um 
componente tipo DIP20_OBL100 e outro DIP20_OBL70 e outro DIP20_ e perguntar 
"Qual voce quer?". Mas o codigo nao faz isso, entao voltamos ao comeco da 
discussao...

> Mas no caso de resistor. Realmente, um para cada encapsulamento jà Ã
> loucura. No mÃximo uma designaÃÃo de potÃncia, porque isso à algo
> calculado e de cunho eletrÃnico e nÃo mecÃnico.
>
> Uma idÃia eu quero deixar aqui bem disposta:
>  Imaginem que o ideal seria que ao ter-se um diagrama pronto, e
> extrair-se a BOM, se poderia fazer as compras, sem mais dÃvidas de
> especificaÃÃo de material.
> Isso nÃo tem nada com o fato de qual ilha ou forma de ilha o componente
> Ã soldado!

Em se tratando de BOM, voce estah coberto de razao. Soh que a BOM tem muito 
mais a ver com o campo device e value do que com footprint (eu nunca usei o 
campo footprint para gerar BOM).

> Nem que para ter-se esse BOM completo, os CIs possam vir com os
> atributos embutidos, ok ,mas os resistores, e "variantes" de CIs devam
> ser editados ou sobrepostos os seus atributos footprint.
> Tenho trabalhado muito com cotaÃÃo de material ultimamente e vejo agora
> como certos detalhes sÃo importantes. NÃo devemos achar que sà interessa
> a informaÃÃo que deva ir ao layoutista, mas tambÃm ao Dpto. de compras.
> E Ã do diagrama que sai esta lista. NÃo do arquivo do PCB, o que seria
> uma idÃia bem melhor (fica aà pro Emerson no seu projeto), afinal o PCB
> Ã sim o resultado final.
>
> Xultz, um conector SIP18... que diabos Ã? berg? barra de pinos torneada?
> MDW18 (para membrana)? Molex? Isso faz falta na BOM. Mas deve ser
> editado pelo projetista, seria absurdo colocar cada opÃÃo na biblioteca.
> Na verdade estou chegando a uma conclusÃo. Footprint à para fazer
> layout, mas difere de especificaÃÃo de material para compra. Que acho
> que deva ser regido por um atributo prÃprio, que nÃo à o device, e deve
> ser editado na mÃo. A nÃo ser que o footprint assuma completamente a
> especificaÃÃo do material. Seria interessante? O footprint se chamar
> RJ22-F-90 para um conector RJ 22 fÃmea 90 graus?

Eu acho que os campos device e value atendem o BOM, mas minha visao neste 
campo eh menor que a tua, talvez um campo a mais com observacao seja 
necessario. Certamente o footprint nao se enquadra na BOM.