| ID: | 5762 |
| From: | rn...@igor2.repo.hu |
| 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 <nk...@nksb.eu> |
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:
5762 [pcb-rnd] sch-rnd: a peek into the future: back annotation from rn...@igor2.repo.hu
5770 Re: [pcb-rnd] sch-rnd: a peek into the future: back annotation from Nicklas SB Karlsson <nk...@nksb.eu>