On Sun, 2008-12-21 at 11:41 -0500, Stuart Brorson wrote: > Hi -- > > >>> I guess the question here is this: > >>> > >>> Is the input which PCB reads a netlist + parts list with enough info to > >>> update the board? > >> > >> No. > > > > It should be possibly to describe the whole design enough to do that > > though. > > Hmmmm... why?
It just depends on where you want the demarcation between programs which understand the PCB file syntax. I think I favour DJ's position on that, in that gsch2pcb or gnetlist should not care - they should just be tools to get as much information out of the schematics as needed for PCB to do the rest. > >>> Or is it an action script which contains specific verbs, such as "place > >>> component X", "delete component Y"? > >> > >> Yes. Also, verbs like > >> > >> (set_trace_width <X>); > >> (route_trace <X1, Y1> <X2, Y2>); > >> > >> Just MHO. > > > > Fine, add to the description... but you'll need to think carefully what > > object / entity in the design those attributes apply to. > > That's true. But I suppose that if you do: > > AddElement(X, Y, rotatation, refdes, footprint, etc. etc. etc) Without knowing what's on the board, you really can't figure out an X,Y coordinate to place something (or route a net, as above). Its just not information in the schematics. Specifically w.r.t. trace widths, those aren't typically specified in the schematic. What I was getting at, was that the information would most logically be attached to a net. However, in many cases, not all of a given net is routed at a particular size. > then PCB would look to see if a component existed at (X, Y) with the > same rotation, refdes, footprint, etc. and if it did, then PCB would > just leave it alone. Otherwise, it would update the parameters which > are different. > > Or maybe if it found a component with one or more new parameters, then > PCB might have to do: > > DeleteElement(X, Y, refdes) > AddElement(refdes, etc.) Best just to define a format, either list based, or as DJ has with a series of verbs which form a list, and then ask PCB to make the updates. > Ummmm.... I'll let DJ comment on this. The exercise behind this > flurry of e-mails is to make sure everybody is on the same page > w.r.t. what the PCB changes will look like. And if I am wrong, that's > OK -- I'd like to know it! Actually, you could join us on IRC if you wanted.. > > The action syntax DJ is proposing does fit your incremental update > > suggestion better though, and would also form a good basis for live > > updates of connectivity between running programs (actions sent over > > DBus). You just have to be careful who is responsible for understanding > > the format at both ends and being able to create a list of actions to > > sync them. (You're proposing gsch2pcb, I think DJ and I are proposing > > PCB). > > I think we are all agreeing that the thing which understands the > format is inside the SOW. As such, it logically ends up in libpcb. > Then both PCB and gsch2pcb (and any other tool which wants it) can > link to libpcb to get the understanding. Perhaps libpcb might be useful in the future, but I don't think its the easiest way to get what we want here. Once an action syntax is defined (or netlist / partslist format), you can use that as a common interface. Otherwise, you don't get the benefit for any non gEDA flow. > I agree -- preventing PCB from trashing a design by running the same > action script twice is an important point. If the actions called out > by the script just "overlay" those already used to build/update the > board, then trashing shouldn't happen, right? Should be fine I guess. -- 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-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
