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

Re: gEDA-user: gsch2pcb deleting almost all elements



On Thu, 2008-09-11 at 12:12 +0100, Peter Clifton wrote:

> An interesting one:
> 
>  --empty-footprint name  See the project.sample file.
> 
> # If you assign a name other than "none" to empty-footprint, then components
> # with that name will be omitted instead and you will need to use the verbose
> # option to see any warnings.  This is just a convenience way to have symbols
> # in a schematic which will not be mounted on the PC board and to shut up
> # gsch2pcb warnings about it.  But note that if you make net connections
> # to these symbols, they will be in the netlist and PCB will warn if the
> # netlist is loaded.  So, maybe connections to such parts should be drawn
> # with a graphical line and not a net?

I missed the relevant quotation from project.sample:

# The default gsch2pcb behavior is to skip with a warning any components
# with a footprint=none attribute.  So the "none" footprint can serve as a
# generic place holder where multiple real footprints are candidates and the
# gsch2pcb warning serves as a reminder that some real footprint should
# be chosen.

The old behaviour could be handled in gsch2pcb with no special casing.
It would be interesting to have a multiple footprint choice offered in
PCB, but the existing schematics probably won't have any way to infer
that.


> So, I guess there are some options.
> 
> Teach PCB to perform the update logic from a series of action commands
> naming the components which are supposed to be in the layout. You might
> have to block around this a wrapper like "BeginUpdate" and "EndUpdate",
> so PCB can identify those elements which are ON the board, but shouldn't
> be. I don't really like this idea.
> 
> So, we may need the write-out of existing elements / properties on the
> board - and let gsch2pcb issue "DeleteComponent(...)" calls for items it
> doesn't want on the board.
> 
> I really (really) like this idea, and the idea of it being a VHDL like
> netlist is VERY exciting. PCB could also export its idea of connectivity
> - and this gets us very close to being able to do some clever
> back-annoation).

I forgot one..

Actions should be able to return strings / values / other data. It is
difficult to see how this could work with existing PCB actions, but with
DBus methods would be entirely possible to return the answers to various
queries about the layout directly to another running process.

Best wishes,

-- 
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user