pcb-rnd knowledge pool

Abstract: A common feature request is printing the net name on traces. It's not as easy as it sounds.

  Imported from the mailing list archives.

Update late 2020: with our new find.c, some caching and considering zoom levels, displaying network labels is now possible (from pcb-rnd 2.3.1), implemented as an optional plugin.

Problem: pins/pads are on the netlist, so it's just a simple netlist lookup to get the net name. Vias, lines, arcs and polygons do not have a refdes:pinnumber in the netlist. So if you show me a via in the middle of your PCB, I simply have no idea what net it is on or it should be on.

The only way to figure it would be to run the same search the 'f' key does. Unfortuntely this search uses a flag in each object while doing the search and the same flag is used to display the green highlight on the UI.

So if I just implemented it before the find.c rewrite, it would interfere with the 'f' find feature, which would be a rather annoying bug.

(Meanwhile, as of late 2018: find.c rewrite is done, so it is becoming possible to have such a feature!)

tagging vs. free editing

Another aspect of this problem is how we approach editing. There are mainly two approaches for any editing operation with software:

• A. the software lets the user do anything, even invalid things while editing, and offers a way to check whether the result is correct
• B. the software enforces the validity of the model being edited between any two editing steps, not allowing the user to have invalid state even temporarily

Approach A is how most of our editors work. When you write an email, you can type prorgam , and a spell checker may warn you about a potential typo that you may fix any time. You may want to fix the typo right after finishing that word or you may be in the middle of some real complex train of thoughts, wanting to finish the sentence or the paragraph first and then deal with the typos. Or in some situations it turns out it is not even a typo but what you really wanted to type, it's just that you didn't know your spell checker doesn't understand it and you either have to explain it to the software or ignore the false alarm.

In other words, the user has the freedom to reach the final, valid state through an arbitrary path that may even include invalid intermediate states. As long as there are specific points in time when the result is consistent and valid, it's all fine, and the software is only checking, not enforcing anything.

This happens in software development too: we are writing source code that are not compilable or executable most of the time until we finish, when we give it to a compiler (or interpreter) that will check for the errors. But our text editor or IDE won't block us from typing in broken code. We can write a function call first, then implement the function if that fits our way of thinking, we are not forced to first create the function and then go back to do the call.

In pcb editing, this method means the user can draw arbitrary copper objects without the software wondering why those objects are there until a DRC check is run when shorts and other potential problems are checked. In other words, newly created copper objects are not bound or tagged to networks, their purpose is not predefined.

Method B is less widespread generally, but more widespread among PCB editors. In that method, before a new copper object is placed, the user needs to tell the software what net it will be for, in one way or another. The purpose of each copper object ever placed on the board is strictly defined and saved.

The advantage of method A in pcb editing is that it makes it very easy to split up nets, extend nets, or even reuse some tracks as part of a different net while editing. As long as the final result is valid, the user is free to edit whichever way, using all the existing copper or freely placing new copper. However, showing shorts and other errors is possible only "at the end", so the user needs to understand operations done in the past by the time the errors are shown. This is the cost of the greater flexibility of editing.

The advantage of method B is that errors can be indicated right when the editing first makes the mistake. In return, when a multi-step editing operation could be carried out in multiple different ways, this usually limits the user to a few predefined ways invented by the programmers. If the user's own way of thinking is similar to the programer's this may be okay, but if not, it's a real hassle. It usally also means some extra adminstration while editing: the user often have to explain what's going to happen in advance. I have seen PCB editors where before placing a new via, a popup appears where the user has to select the network the via is bound to.

pcb-rnd and free editing

pcb-rnd picked method A. Thus copper objects in our data model are not bound to networks. This is why it's not trivial to print in which network a random trace line is: the line itself doesn't remember (so it doesn't have to enforce the user to do editing in a certain way).

All we could do is looking up the connection for each object. We have the code for that, but it's not trivial when to do this because such a lookup is expensive (in time). If we did it for every screen refresh, it would slow down drawing.

So the solution would most probably be some smart cache that tries to remember where each object belonged to last, and knows when and how much of the objects network affinities need to be recalculated. We do not yet have this, and it will take a lot of effort to develop.