ID: | 5770 |
From: | Nicklas SB Karlsson <nk...@nksb.eu> |
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 rn...@igor2.repo.hu |
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 rnd2@igor2.repo.hu: > 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: > > https://archive.org/details/sch-rnd-tut-back-annotation > > > 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 <nk...@nksb.eu>