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:
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).
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)âŚ
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.
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.
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.
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âŚ
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âŚ
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. (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.
(and I got bitten because first I didnât realize the âkeep existing associationâ option was the same as the old âuse timestampsâ.