X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Thu, 9 Jul 2015 14:15:31 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] Back annotation (was: developer excitement?)
In-Reply-To: <alpine.DEB.2.11.1507091329350.3444@nimbus>
Message-ID: <alpine.DEB.2.00.1507091404410.6924@igor2priv>
References: <CAM2RGhTpfbqM7zNn72TBOjeL7B7LPT1PxSEU3+9aDdChFrPFTg AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1507090507530 DOT 6924 AT igor2priv> <alpine DOT DEB DOT 2 DOT 11 DOT 1507091329350 DOT 3444 AT nimbus>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk



On Thu, 9 Jul 2015, Roland Lutz wrote:

> On Thu, 9 Jul 2015, gedau AT igor2 DOT repo DOT hu wrote:
>> Back annotation is something I'd love to have but the way I imagine that 
>> feature, it would require major changes, many of which would require UI 
>> changes.
>
> Could you explain how you imagine back annotation to work?

Same as forward annotation. It works in PCB because PCB has two concepts: 
current state of the board (actual connections) and desired connections 
(the netlist). When they don't match, PCB indicates that (rat lines, 
shorts) and the process is that the user tries to modify the current 
state to match the desired state.

The same thing backwards would be:

1. PCB validates some of the mismatches, marking them in the PCB file; 
e.g. if pins of a connector has been swapped during the layout, or a 0805 
resistor changed to 1206, it'd update the netlist and make some sort of 
machine parseable note about it. After the validation these are no longer 
errors in PCB.

2. There would be a glue script that'd read the PCB file to find out these 
changes; when they are such changes, it'd store them in a form gschem 
could parse. This is the same thing as gnetlist, just in the other 
direction (import instead of export). And it could have variants for 
different work flows, for example if point 1. is not PCB but some 
interactive spice simulation in which the user fine tuned some values that 
should be propagated back to gschem.

3. Gschem could import such a change set (e.g. just like PCB can import a 
new netlist or components for an existing PCB design).

4. And here comes the hard part: gschem would also have two concepts, the 
current state of the schematics and the desired state and would also 
indicate mismatches - for connections maybe with similar rat lines and 
shorts. This is the part that'd involve UI changes too.

5. The user then could resolve the changes in the schematics to reflect 
the state of the PCB.

There are the usual corner cases when two applications/threads/authors 
want to make modification on the same thing, e.g. what happens if i have a 
(pcb-gschem-wise) consistent design and then I change the same pinout in 
two different ways in the same time in PCB and in gschem and then do a 
forward annotation and a back annotation... But I think these could 
beworked around.


Regards,

Igor2