[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Display refdes and value on silkscreen?



If you place all of the values on the silkscreen layer you will decrease the
density of your board (if you purchase boards with a silkscreen).

What may be better is an assembly-silkscreen layer with this additional
information on it. The assembly-silkscreen layer would be used in
the assembly documentation not the PCB fabrication.

Alternatively, you could take your PCB layout and run it through a
script to create a documentation PCB layout that contained text
elements for each component.

I agree that this could be very handy.

(* jcl *)

On 9/29/05, Randall Nortman <geda-lists@xxxxxxxxxxxxxxx> wrote:
> Is it possible to get pcb to display/print both the refdes and the
> value on the silkscren layer, preferrably on a element-by-element
> basis?  This would be very handy during manual assembly, so that I can
> see exactly which of the dozen different resistor values is supposed
> to go on each spot without looking it up on my BOM every time.  At the
> same time, I need some elements (such as ICs) to display the refdes,
> as the value is meaningless.
>
> I suppose I could write a script to find every element with a refdes
> of "R*" or "C*" and replace the refdes with a concatenation of
> refdes+value, but that reduces flexibility in arranging the text on
> the silkscreen.  I think the ideal would be to have separate text
> elements for each, which could also be done by the script I suppose,
> with some extra effort.  The extra text objects could then be
> positioned by hand or deleted for elements where the value is
> extraneous.
>
> And on that subject, I would just like to say -- to whomever decided
> that all of pcb's (and also gschem's) files should be human-readable
> (and easily script-modifiable) text -- THANK YOU SO MUCH.  I might
> actually prefer XML these days for the purpose of easy script
> processing (as there are now XML libraries for just about every
> language to eliminate the burden of writing a custom parser), but the
> current formats are probably better on the human-readability front.
>
> Randall
>


--
www.luciani.org