Mailing list archives : pcb-rnd

Date:Sat, 16 Jul 2022 17:11:21 +0200 (CEST)
Subject:[pcb-rnd] sch-rnd: a peek into the future: back annotation
replies: 5770 from Nicklas SB Karlsson <>
Hi all,
I recommend to read this even if you are not interested in back annotation 
because the scope is much wider and mid term implications deeper than this 
one feature.
I've indicated earlier in a long term roadmap that once we have a 
functional sch-rnd together with pcb-rnd, we can start working more on 
workflow-features instead of being trapped per-tool features. This is 
because we control the tools on both side of the feature, so we don't have 
to convince the developers of an external project and we don't have to 
wait for them.
I expect to be able to spend time on such things around next summer. But 
there was one feature that I had to do now, because it was to test 
important parts of the sch-rnd infra. And that is back annotation. Looking 
closer at back annotation is a peek into the future, into what we will be 
able to do on other features soon.
1. What is back annotation
In an sch-pcb relation forward annotation is when you draw (or update) 
your schematics and transfer the netlist and footprint info to the PCB 
layout tool. Back annotation is when you figure you want to change some 
detail differently while laying out the board in pcb-rnd, but:
- instead of interrupting your work going back to sch-rnd changing it 
there and then doing a new forward annotation
- you simply make the modifications in pcb-rnd (telling pcb-rnd about your 
intention so it doesn't think it's a mistake) and then annotate back these 
chages to sch-rnd later so you could update the schematics later.
2. How is it done?
Thanks to Majenko we have a great tutorial video:
3. Why should you care (directly)?
There are a many advantages of doing back annotation instead of switching 
back to sch-rnd and doing a forward annotation before making the changes 
on the board:
- less mental context switches, less distruption of the workflow, which 
usually means less room for errors
- sometimes you need to be experimenting on the board side; like if you 
have 6 pins of a connector to route and it doesn't matter which goes 
where, you are free to swap pins; but how you want to swap may be 
finalized only in multiple iterations of routing attempts and you don't 
want to go back and do a new forward annotation for each
- automation: you don't need to use paper, a manually written file, or a 
mental note to transfer changes from pcb to sch, it can be automated
- automation: and as you see on the video, in some common, simple cases, 
even the sch side fix can be automated!
- automation: ... but at least sch-rnd can _always_ check the result for 
you, no matter how complex your case is, so you can automate making sure 
when the modifications are done right!
4. Comparison on sch editors
This is a showcase on how far we can get if we control the sch editor's 
development as well. Let's see how this same feature works with geda:
Prior art: long ago there was an old back annotation file format; in 
theory it was supported by geda/pcb and gschem; in practice geda/pcb 
didn't have a strong enough data model to tell apart accidental deviation 
from the input netlist from intentional back-annotation material. This 
whole thing probably worked once, but I never have seen it working and 
it's a largely unknown feature. Around 2016 I fixed this up on 
pcb-rnd side and wrote a gschem patch to handle it on sch-side. This patch 
got merged in gschem a year or two later (but never made it to 
lepton-eda). Unfortunately it's only a partial solution because gschem's 
data model doesn't allow the editor to understand nets or 
components (there's no abstract model).
So let's see how far you can get with back annotation with different 
sch tools:
- you make a pin swap or footprint change in pcb-rnd
- you save the back annotation file
- you import it in your sch tool; we've already lost lepton-eda, xschem 
and other sch editors pcb-rnd supports: they can't import the file; only 
sch-rnd and gschem remains
- you get a list of things to do in the sch editor
- when you implement a change from the list, the editor figure; this is 
where we've lost gschem (lack of abstract model)
- the editor can help you navigate to the place where the modification is 
likely to be done (sch-rnd can do that)
- in some simple (but common) cases the editor can even do the 
modification for you (sch-rnd can do that)
5. Why should you care (indirectly): it's a big deal!
Even if you don't need this specific feature, back annotation, the above 
shows why it's a big deal:
- I've found a way to keep both "toolkit made of independent tools" _and_ 
"tools within the toolkit can cooperate, without integration"
- this example shows we can implement complex, workflow-level features 
that span code across tools
- this example shows the developer does understand the importance of such 
workflow-level features and is not trapped within the boundaries of a 
specific tool
- this example also demonstrated that with a stronger foundation on the 
sch side (e.g. explicit abstract model), such complex features can be 
implemented in a relatiely short time.
This means if you have other cross-tool, workflow-level feature requests, 
once sch-rnd becomes stable and once I can allocate the time, it has a 
very good chance to change from the previous "sorry, we can't do that 
because it depends on factors ourside of pcb-rnd" to "ok, we can do that 
in a few weeks/months". 
My personal favorite which I really want to implement the upcoming years 
is that if you pick a subcircuit or net in pcb-rnd and give an explicit 
command, an already open sch-rnd (and camv-rnd) on the same project 
navigate to the same object. Of course this could work triggered from 
sch-rnd or from camv-rnd (to some degree as on CAM level there are no 
nets normally). 
(And of course this will need communication between tools, again without 
integration, but I've already solved that problem too, many years ago, 
with genxproj. So the option of driving different tools of the suite in 
parallel does not require dbus, or other exotic/bloated IPC mechanisms, 
only project-oriented thinking and a small project manager software.)
Best regards,

Reply subtree:
5762 [pcb-rnd] sch-rnd: a peek into the future: back annotation from
  5770 Re: [pcb-rnd] sch-rnd: a peek into the future: back annotation from Nicklas SB Karlsson <>