Al, This is similar to the issue that I was discussing about back annotation that lead me to write backnet. In my case I am modifying the netlist at layout time and desired to be able to merge these layout changes with schematic level changes. Eventually I hope to have a schematic capture program that allows me to attatch the changes to an instance of a complex symbol and then have the schematic capture program draw the corrected schematic image.
What would doing this take. 1) have backnet be able to read in the original schematic files. (Script file) 2) have backnet be able to read in an eco file and use it to update the (formerly libgeda) data structures. (pretty much already in place few bugs to be resolved) 3) have backnet capable of exporting the pages in the schematic file format with the back annotation attached. (not yet in progress) 4) for hierarchical reasons be able to fork a page that has had a different eco applied to it then other instances of that page. (not yet in progress) 5) complete the schematic capture programs code. (in progress, looking for first version to be running early August) With all of this in place I think that it would be very possible for a simulator to generate an eco file and then use backnet to update the schematic files. I am also thinking about adding front-end and back-end scripts for translating schematcs to and from my non-geda tools. Steve Meier On Mon, 2007-06-11 at 11:39 -0400, al davis wrote: > > al davis wrote: > > > One feature I would really like is a way to back-annotate > > > those changes, a way to update the schematic other than > > > manually changing the values. > > > On Monday 11 June 2007, John Griessen wrote: > > I like the idea of a separate place for commands to > > simulators via symbols on the schematic that are probes -- a > > pictorial symbol of a lab instrument. The separate place > > should be non-volatile and outside the schematic, so it's a > > file. If you are using DBUS or any IPC to do cross probing > > and back annotating that method should also update the file > > with every change, and take in every change to the file. In > > other words any IPC dealing with back annotation should poll > > the probes file and keep it in sync with the memory resident > > version of it. > > > > And so far, that probes file seems to be best made in > > resource file format. > > I was thinking of something much simpler and more portable, like > a way to back-translate a file, or back-annotate a file. > > How about ... > > You draw a schematic, save it, convert to a format for > simulation. > > You simulate, it isn't quite right, you modify through the > simulator, repeat until it works the way you want. You save > the revised circuit in the simulator's format. We have this. > > Now you want to update the schematic. If the changes are > simple, such as component values, it would be nice an easy way > to modify the schematic file to include the changes. The best > way is a stand-alone program, or maybe something like gnetlist > working backwards. > > I think DBUS or other IPC adds a lot of complexity across the > board, and will never happen. The complexity added to one > program might not be significant, but requiring everyone to > play that way probably means they just won't. Remember there > are lots of related programs we don't have yet, and lots of > people developing them that we don't know yet. > > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
