Mailing list archives : pcb-rnd

From:Nicklas SB Karlsson <>
Date:Tue, 2 Aug 2022 18:51:36 +0200
Subject:Re: [pcb-rnd] sch-rnd: a peek into the future: back annotation
in-reply-to:5762 from
Great you are working with it. Used back-annotation in other software: 
pin-swap, gate swap and update of refdes values.
Den 2022-07-16 kl. 17:11, skrev
> 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,
> Igor2

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