PcbNew: changes from 5.0.2 to 5.1.0

Hi all,

Installed and tested V5.1.0 yesterday. Nice update. But a couple hiccups.
I opened an existing layout (created with V.5.0.2) in PcbNew and here are my first comments:

  1. Edge.Cuts layer: changes in how the polygon is considered closed. My design uses a footprint (midmount USB connector) which has 3 lines in the Edge.Cuts layer to form the required opening in the PCB outline (obviously those lines themselves do not form a closed polygon). In my design, those lines are connected to the polygon forming the board outline, thus forming an overall closed polygon. Up to V5.0.2, it used to work fine, and KiCad would indeed detect a closed polygon (and I’ve seen a few other layouts done this way). No error message, and correct outline in the 3D viewer. In V5.1.0, it doesn’t work anymore. It’s as though PcbNew didn’t include the lines in the fooprint to determine the overall polygon is closed or not. This is a big annoyance. I get an error message (DRC) stating the polygon is not closed, and the 3D viewer doesn’t show the right outline. The Gerber files seem to be generated correctly though, and the copper areas filled correctly as well (which looks like a discrepancy with the “closed polygon” test itself).

  2. The netlist import dialog has changed and it’s not that clear anymore (to me). There is a “selection method” that I don’t quite get. By default it opens with “keep footprint association”, but leaving it as this will completely screw up the layout (changes footprints/references association in a seemingly random manner) even though there is absolutely no association change in the netlist file. I don’t get it. You have to select the other option for the import to work properly (and incidentally, the “keep” option is selected back when you re-open the dialog instead of re-opening with the last checked option…). I hope the netlist import tool will not get abandoned in favor of the new “update from schematic”, since I generate netlists outside of KiCad’s Eeschema. If anyone can help understanding the new dialog and/or can confirm there is a bug (and also can reassure me the netlist import will not disappear in future versions)…

  3. Another issue with the import netlist function: if you change a net’s name in the netlist (but without changing any connection within said net), and import it in an exisiting design, PcbNew will consider the existing net and the “new” net to be different (even though they are connected to exactly the same vias/pins), and will either delete traces with the old net name or keep them and consider the new net unconnected to it (even though they have the same connections) depending on the option you select. I’m not 100% certain it behaved differently in older versions (I would have to check on another install), but I think it did and understood it was the same net with only a different name.

Just a heads up: The export/import netlist nonesense is now deprecated. Use the update pcb from schematic tool instead as it directly goes through the kicad internal datastructures.

And yes the names of the options have changed. I think the default option now is what was called “by timestamp” in the past.

regarding edge cuts: did you draw a real polygon for the edge cut or did you draw it from lines? (A real polygon is no longer valid as it has bad side-effects in all versions of kicad. One example is that zones do not fill properly if it is used. -> 5.1 automatically converts such a polygon to single lines now.)

And there is a DRC check for zone outlines now as well that will tell you where something went wrong. Previews versions did no checks at all meaning this might be the reason why you thought the outline was ok in the past. (The tolerance for detecting if a zone is properly closed has not changed. But in the past the only action that really checked it was the step exporter which you might not have used.)

Regarding the netlist import: as I said, I use it because I’m generating netlists outside of KiCad. This was a pretty useful functionality for that. You’re sort of confirming that it’s going to be deprecated as I was fearing. Does that mean we have to say goodbye to the possibility of using PcbNew as a standalone tool? That would be a pity.

Regarding the board outline: I just checked with V5.0.2 again and that’s right, the check was not done in DRC but it was done by the 3D viewer though. And the check was correct as far as I’ve used it. In V5.1.0, it’s done both by the 3D viewer and DRC, and gives the same result for both, but the check - the one done by the 3D viewer, but gives the same result now in DRC - has definitely changed. With the same project open in 5.0.2, the 3D viewer doesn’t complain and yields the correct outline. In 5.1.0, it complains the polygon is not closed. I have no clue why. It gives the vertex (line end) which is the culprit, but it’s definitely not open. As I said though, the outline is composed of a polygon AND a footprint, which as a whole form a closed polygon. They are connected together, but are individually composed of segments. As I said, even though DRC (and 3D viewer) now complain, the generated copper pours and Gerber files are still correct…

To help understand the matter, I’m pasting the footprint module I’m talking about (can’t upload the file as a new user), which contains Edge.cuts lines. The board outline is then connected to both ends.

(module CX70M-24P1 (layer F.Cu) (tedit 5C0C0F34)
(fp_text reference J1 (at 0 -8.89) (layer F.SilkS)
(effects (font (size 0.8 0.8) (thickness 0.15)))
(fp_text value USB_C_Receptacle (at 0 8.89) (layer F.Fab)
(effects (font (size 1 1) (thickness 0.15)))
(fp_line (start 0 -4.67) (end 0 -7.62) (layer Edge.Cuts) (width 0.15))
(fp_line (start -6.65 -4.67) (end 0 -4.67) (layer Edge.Cuts) (width 0.15))
(fp_line (start -6.65 4.67) (end -6.65 -4.67) (layer Edge.Cuts) (width 0.15))
(fp_line (start 0 4.67) (end -6.65 4.67) (layer Edge.Cuts) (width 0.15))
(fp_line (start 0 7.62) (end 0 4.67) (layer Edge.Cuts) (width 0.15))
(fp_line (start -9.2 6.5) (end -0.3 6.5) (layer F.SilkS) (width 0.15))
(fp_line (start -9.2 -6.5) (end -9.2 6.5) (layer F.SilkS) (width 0.15))
(fp_line (start -0.3 -6.5) (end -9.2 -6.5) (layer F.SilkS) (width 0.15))
(pad S1 smd rect (at -2.6 5.2 90) (size 0.7 2.3) (layers F.Cu F.Mask))
(pad S1 smd rect (at -2.6 -5.2 90) (size 0.7 2.3) (layers F.Cu F.Mask))
(pad S1 thru_hole oval (at -7.65 5.55 90) (size 1.2 2.3) (drill oval 0.6 1.7) (layers *.Cu *.Mask))
(pad S1 thru_hole oval (at -7.65 -5.55 90) (size 1.2 2.3) (drill oval 0.6 1.7) (layers *.Cu *.Mask))
(pad S1 thru_hole oval (at -2.6 5.55 90) (size 1.2 2.3) (drill oval 0.6 1.7) (layers *.Cu *.Mask))
(pad S1 thru_hole oval (at -2.6 -5.55 90) (size 1.2 2.3) (drill oval 0.6 1.7) (layers *.Cu *.Mask))
(pad B9 thru_hole circle (at -7.2 2 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad B8 thru_hole circle (at -7.2 1.2 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad B7 thru_hole circle (at -7.2 0.4 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad B6 thru_hole circle (at -7.2 -0.4 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad B5 thru_hole circle (at -7.2 -1.2 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad B4 thru_hole circle (at -7.2 -2 90) (size 0.6 0.6) (drill 0.4) (layers *.Cu *.Mask))
(pad S1 smd rect (at -8.125 3.915 90) (size 0.46 0.85) (layers F.Cu F.Paste F.Mask))
(pad S1 smd rect (at -8.125 -3.915 90) (size 0.46 0.85) (layers F.Cu F.Paste F.Mask))
(pad B12 smd rect (at -8.125 3.4 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad B11 smd rect (at -8.125 3 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad B10 smd rect (at -8.125 2.6 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A1 smd rect (at -8.125 2.2 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A2 smd rect (at -8.125 1.8 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A3 smd rect (at -8.125 1.4 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A4 smd rect (at -8.125 1 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A5 smd rect (at -8.125 0.6 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad B1 smd rect (at -8.125 -3.4 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad B2 smd rect (at -8.125 -3 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad B3 smd rect (at -8.125 -2.6 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A12 smd rect (at -8.125 -2.2 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A11 smd rect (at -8.125 -1.8 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A10 smd rect (at -8.125 -1.4 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A9 smd rect (at -8.125 -1 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A8 smd rect (at -8.125 -0.6 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A7 smd rect (at -8.125 -0.2 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(pad A6 smd rect (at -8.125 0.2 90) (size 0.23 0.85) (layers F.Cu F.Paste F.Mask))
(model ${KISYS3DMOD}/Connector_USB.3dshapes/CX_4800304000.step
(offset (xyz -24.75 20 -0.5))
(scale (xyz 1 1 1))
(rotate (xyz -90 0 -90))

I’m surprised that ever worked, and it would never have occurred to me to try to make footprint info part of the outline. That requires KiCad to scan two datasets, so seems more accidental than ‘working’
If you simply clone the footprint info, and thus close one polygon, does that work ?

I would hope not, as many flows are netlist based, and deprecated here hopefully means ‘just not the preferred pathway from eeschema to pcbnew’

That sounds as-expected, as KiCad defines netnames via pin-lists and copper intersects.
ie if you change only the netnames, a netimport should simply over-write the older names on each connected pin.
It may not delete the old netname from the net-name list, as that is a separate part of the database, and Kicad seems to tolerate names in the net-name-list with no pins yet connected.

I very well may not understand what you mean, so the following is just a suggestion based up what I think you might be doing.

You can draw on the “Edge.Cuts” layer the outline of the Footprint along the board edge to make a contiguous board outline.

This might trip a DRC error, but if you are certain of the intent of your design you can ignore that particular error.

Yes it did work, and actually it still does. (I wouldn’t see a good reason it wouldn’t: you can use just any layer in a footprint, and layers in footprints should be considered as an integral part of the layout’s layers, otherwise that would be a recipe for bugs and headaches IMO.) That’s pretty handy especially for this kind of midmount connectors. (I borrowed the idea from someone else’s project, so I know I’m not the only one using it!)

I think I found out what has changed. It looks like the segments’ ends now need to lie exactly on the same point (at which precision, I have no clue about, but it seems pretty finicky), whereas it looks like it was a lot more tolerant in older versions. I think end segments could overlap and that would be considered as closed. That was a lot easier to deal with. Haven’t looked at the source code so I don’t know exactly what has changed but something has. Looks like you cannot just overlap segments anymore. (But again that’s just during checks: it still generates correct copper pours and Gerber files.)

I just had to set the ends of the segments that were connected to the footprint’s segments exactly on the same point (they were slightly overlapping before), and DRC passed. 3D view as well.

I hope you’re right. I’m just afraid “deprecated” would mean: not going to be maintained for much longer, and if anything breaks in the future, the feature would then be likely to get removed altogether instead of being updated/fixed. Really, I hope they keep the feature! Or at least give us another way to do the same with newer schematic files that we could generate just to include the netlist. I don’t mind too much having to update our tools as they are in-house ones.

1 Like

I’m impressed that works. Nice to know there is a workaround.
An exact vertex match will be faster & simplest to code, and that may be what DRC closed polygon uses ?

It must work that way as one could not design edge connectors otherwise.

But yes the devs are worried about this feature as they fear that there could be bugs this is why there is no direct way of drawing on the edge cut layer using the footprint editor (but at least v5.1 no longer moves such lines to a different layer. Sadly i could not get more from the devs in time for version 5.0.)
The full discussion is found here: https://bugs.launchpad.net/kicad/+bug/1251393

By the way even the official library contains footprints with outlines on the edge cuts layer.

the tolerance is hard-coded at 0.01mm (I am not sure if this is the radius or diameter of the tolerance circle. My guess is that if you draw on that grid then you can be off by one grid spacing but i have not tested it.)

The netlist import will stay but better kicad internal eeschema to pcb_new integration will mean that some features are only possible without going through a netlist file. (In the long run there might be some features that are only available for the internal datastructures not via the netlist.)

My plan (checked with 4.0.7), as connections can’t be selectively hidden, was that I will get netlist from schematic, then I will delete from it the GND net and then I will import it to PcbNew to use for placement (GND connected by bootom plane not influences placement). I am not using KiCad yet by I began to expect problems…

Configurable ratsnest display has been planned (for 6.0). It should help with that distracting ubiquitous GND net.

I know.
Last times I was using nightlies (just because library editing (what I was doing) was better than in 5.0.2) but now my plan is start to design PCBs and use stable version. As I understand V6 is to be in 2…3 years. I hope that if there are really any problems in netlist loading than they will be solved in 5.1.1

OK thanks for the info. On my layout the grid was set at 0.05mm so that’s probably why I had to set the coordinates manually.

I hope the possibility of having Edge.Cuts elements in a footprint doesn’t disappear. We can certainly do without but that saves time when dealing with edge connectors and limits mechanical errors.

Whatever the future direction is, I’d like to emphasize how useful a netlist import can be, so I hope developers keep that in mind. As I said, in the future, if that means having to generate schematic files instead of netlist files to do the same thing and benefit from the new features, that’s fine, as long as the new schematic file format is well documented and contains netlist info.

I hope the future of KiCad is not just to do the exact same as any other EDA but in open source form, but keep its “openness” intact, meaning open interoperability with other tools.

Yes, “deprecated” is really only descriptive when using Read Netlist between eeschema and pcbnew. We will be moving it to the import/export menus for 6.0, but it won’t be going away.

The original report is interesting. We default to “Keep existing associations” (ie: use timestamps) because that usually works best with Eeschema. However, for the import case, you probably won’t have any timestamps, and so the “Reassociate by reference” should be the default.

In fact, do any external tools generate timestamps in the netlist? Maybe we should remove the “Keep existing” option from import entirely…

1 Like

Sorry, could not find, which OS/bits do you use? How did you install it, compiled yourself or from the unofficial package? In case you use Ubuntu 18.04/64b is it available in ppa?

Yes, that’s exactly the issue. Our tools don’t generate timestamps, so the result with this option is… funky. :smiley: (and I got bitten because first I didn’t realize the “keep existing association” option was the same as the old “use timestamps”.

And yes, I guess very few external tools generate timestamps. I agree removing this option in the import dialog or at least not making it default would probably make more sense.

1 Like

Some tools might, for version control and blame audit paths etc.

I’d agree the default should be the simpler option, but I would certainly give users the choice.(not remove it entirely)

1 Like

OK, I’ve swapped the options and improved the text for the Import Netlist case:

The Update PCB From Schematic dialog stays the same.

(Note that these changes will appear in 6.0, not 5.1.)

1 Like

Based only on reading this thread I think it would be good to at least change text if 5.1.1 would be released.

The issue there is that for people who are still using Write/Read Netlist between Eeschema and PCBNew, the existing text makes more sense.

When we move Read Netlist to the Import menu in 6.0 it’s safer to assume it’s only being used with an externally-originated netlist.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.