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? >>> 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) 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.) to place the updated footprint in the area outside the board. To return to your point about an object ID, the question is: Does PCB need to have an object ID to know about each component, or is it enough to identify it by it's placement info? I dunno the answer, but I suspect it's enough to just use graphical info. Or am I wrong? >>> This is more like the current gsch2pcb, which needs to grok what's >>> already on the board, then issues instructions to make an update. >> >> My thought is that the forward annotation file would carry all info >> necessary to take the current .pcb file to whatever the new schematics >> call out. That is, the fwd anno file would represent a delta between >> the existing .pcb file and what's changed in the .sch files. That >> means: > > The I thought that part of the idea was that gsch2pcb shouldn't have to > understand the PCB file-format. (As well as not having to re-implement > code for looking up and placing footprints). I agree that my idea requires gsch2pcb to process and understand the .pcb file. However, my thought is that gsch2pcb can just link to libpcb.so to gain that understanding. >> * With the very first invocation of gsch2pcb, the output .fwd file >> (or whatever suffix is chosen) would emit all commands necessary to >> place all footprints outside the drawing area, create the netlist >> inside of PCB, and also emit any other necessary info. >> >> * Thereafter, gsch2pcb would read both the .pcb and the .sch files, >> and figure out what commands are necessary to update the .pcb file. > > I got the impression that this wasn't what DJ was doing, rather > exporting enough information to create the whole design inside PCB. > Which is IMO quite sensible. 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! > 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. >> This implies that gsch2pcb must be able to read and parse a .pcb file, >> as well as a .sch file. The .sch part is easy -- use gnetlist. To >> read & understand the .pcb file, gsch2pcb would probably be best off >> calling functions living an a libpcb, which would also be used by PCB >> itself to do its thing. >> >> Or am I completely off base? > > PCB can't export any sensible information at the moment. Right, but the forward annotation tool should only need the info present in the .pcb file, so export from PCB is not necessary. Or am I missing something? [.....] > Another variant.. PCB could look for an action script on disk, although > that is more dangerous... it would need to delete it after running if it > contained any actions which were harmful to execute twice on the same > board. 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? Stuart _______________________________________________ geda-dev mailing list geda-dev@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
