Re: gEDA-pt: Nomeclatura de componentes no gSchem

[Xtian Xultz <xultz@xxxxxxxxxxxx>]

Em Ter 12 Jul 2005 10:12, Antonio escreveu:
> Em Seg, 2005-07-11 Ãs 19:30 -0300, Xtian Xultz escreveu:
> > Em Seg 11 Jul 2005 14:30, Antonio escreveu:
> > > Em Seg, 2005-07-11 Ãs 13:28 -0300, Xtian Xultz escreveu:
>
> [snip]
>
> > > Ã.. 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.
>
> Concordo, Ã necessÃrio passar todo tipo de informaÃÃo que se puder ao
> layoutista. Penso que poderiamos criar um atributo especÃfico de
> "conversa" com o layoutista. Tipo, pode-se criar um atributo pcb_cue ou
> coisa parecida. Oque acham?
>
> > [snip]
> > 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.
>
> 	EntÃo pelo que estamos chegando a conclusÃo, o negÃcio seria
> simplificar ao mÃximo o nÃmero de detalhamentos na biblioteca em si.

Veja, eu comecei dizendo a minha opiniao a respeito que eh a seguinte: nÃs 
temos um problema. O codigo que temos para geda-gaf nao eh o ideal. A decisao 
a ser tomada Ã: ou fazemos o possivel com o codigo que temos (e corremos o 
perigo de perder um monte de trabalho quando o codigo necessario for feito ou 
coisa parecida) ou metemos a mao na massa e tentamos fazer o codigo 
necessario para atender o que acharmos necessario. Entende? De minha parte, 
esta eh decisao que nao foi tomada e que nao quero tomar sozinho, e acho 
preferivel discurtimos esse assunto uma semana a fio do que trabalhar numa 
solucao pior por um ano inteiro.

> 	Isto aumenta a mÃo-de-obra do projetista, que ao final do desenho
> deverà se esmerar em encher com detalhes os componentes, atravÃs de
> atributos, para passar todas as informaÃÃes para o layoutista e para o
> compras.
> 	Neste aspecto o gSchem auxilia com o bom suporte que tem a adoÃÃo
> de atributos, que pode-se atà inventar novos.
> 	Cabe agora discutir, que atributos existem hoje e como poderiam
> ser usados, e se seria interessante criar alguns novos.
> 	Mas eu nÃo tive clareza sobre o seguinte, vocà nÃo acha interessante
> que determinados componentes como um 1N4007 poderiam ser jà dotados dum
> atributo para compras com DO41, que tal criar para isso o atributo package?
>  O passo da dobra fica a critÃrio do layoutista, mas o encapsulamento nÃo
> deixou de ser o mesmo, entÃo ele faze o atributo footprint na mÃo, contendo
> os dados necessÃrios, tipo, DO41-400-55.
> 	Agora, quanto aos CI, por exemplo. O que acham da idÃia do package
> ficar assim: o 74HC573-SMD teria que fazer na mÃo o footprint SO20-500, ou
> como eu pedi, SO20-300/500 para fazer um com pads longos que caibam os
> dois. O que à algo comum e o PCB poderia ter na biblioteca isso pronto.

Isto quer dizer que a nomenclatura do encapsulamento nao vai seguir o padrao 
escrito pelo Luciani?

> 	Para os resistores e coisas assim, nÃo resta dÃvida, na biblioteca
> tambÃm nÃo vem nada de footprint. Fica totalmente a cargo do projetista
> especificar o material. Mas para isso, ele poderia passar o footprint
> RS300-55, para passar a largura da ilha. Ou seja como for a notaÃÃo, isto
> sÃo sà exemplos. Mas à certo que terÃamos que criar padrÃes da notaÃÃo dos
> footprints possÃveis para ir criando a biblioteca do PCB. O projetista
> teria a obrigaÃÃo de conhecer e consultar essas regras para aplicar.
>
> 	Xultz, vamos comeÃar com sugestÃes. SenÃo nÃo chegaremos a lugar algum.
> Sabemos bem as limitaÃÃes de ambos os SWs, mas sei bem que com os recursos
> que eles possuem a gente consegue ter como fazer isso! à sà usar a
> criatividade.
>
> > > 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.
> >
> > 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...
>
> NÃo à o PCB que faria isso. E sim o script de exportaÃÃo. basta que vocÃ
> tenha os sÃmbolos bem nomeclaturados e o projetista passe isto corretamente
> nos atributos footprint.
> 	A idÃia de passar um footprint incompleto, como o DIP20_ Ã Ãtima,
> para isto devemos criar um script mais experto para exportar.
>
> [snip]
>
> > > 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.
> >
> > 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).
>
> Bem, o que acharam do atributo package? Complementaria o atributo device
> na BOM.
>
> [snip]
>
> >  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.
>
> 	Pela experiÃncia que tive ultimamente, usaei o footprint para
> complementar as informaÃÃes de device e value, nÃo foi bom. Agora
> entendo que o footprint nada informa a quem vende componente.
> 	O negÃcio acho que à esse package mesmo. Onde vocà pode passar
> aspectos mecÃnicos tangÃveis a quem cota um material para vocÃ, sem
> estragar o device com dados alheios a eletrÃnica, muito menos o value.
>
> Onde poderÃamos ter um RJ 22 fÃmea 90 graus para PCB, com trava para cima:
>
> device=RJ22
> footprint=RJ22-Fblablabla (info para layoutista conforme for designado)
> package=RJ22 Female 90degres pol.up
> description=Conector, RJ22
> value=
>
> Um CI 74HC573, que eu queira pads largos
> device=74HC573
> footprint=SO20_300-500_blablabla (info para layoutista conforme for
> designado) package=SMD 500 mils (isto basta para compra)
> description=IC, Transparent Latche
> value=
>
> Neste caso, ao contrÃrio do que o Emerson mencionou, nÃo adianta basear
> pelos sufixos para esclarecer o componente, pois na hora da compra, cada
> fabricante tem uma nomeclatura. à necessÃrio dizer que à um 74HC573 SMD de
> 500 mils. Ou seja, posso montar um BOM com os seguintes atributos:
> device, value, package, description
> sem utilizar o footprint que me servia para confundir o fornecedor.
>
> Um resistor de 27R 1W do tipo chocolate:
> device=Resistor
> value=27R
> footprint=MR25_55_6 (algo tipo 400 mils, 55 de ilha, 6mm de altura)
> package=MR25 1W
> description=Resistor, MR25, 1W
>
> o script encontra o RM25_55_6 e acha o footprint correto
> a BOM fica com os demais dados.
>
> Ah! Descobri que se vocà nÃo cotar com o maldito "R" eles te vendem 27k.
> Eles jamais vÃo entender que se nÃo vem nada à a unidade simples.

Na 24 de maio tambem...