At first I got a bit worried, since I did a Search for zone, and found one, and there was no priority indicated anywhere … then I realized that maybe a priority 0, the default, is simply left unspecified (as it seems to be the case), so a Search for priority showed the above.
Have I mentioned lately that I love KiCAD?! I often end up taking the “hacker route” and fire the text editor — with gEDA pcb (which is what I used for a couple of years before moving to KiCAD), you just find a sequence of space-separated numbers for all parameters; need to go online to look up the reference and figure out what each number is — the verbosity in KiCAD’s files is certainly an amazingly good feature!! (transparent for most users, I know — but it is developer/debugger friendly, and it is also helpful for users with hacker instincts, which I’m sure there are many out there!)
I tested this. It works if clearances are small enough to allow connections. However, if the net tie footprint is too short and clearances too wide, zones can’t necessarily connect because they avoid the middle part of the net tie.
Zone clearance algorithm is often annoying. There shouldn’t be need to avoid going near another net if there’s something there already, usually a pad, which is nearer to the other net than the zone’s clearance. It often refuses to connect and sometimes I don’t even find a reason, like when I try to connect to one pad of a small package and try to set every possible clearance so that it could connect. Many times the copper is connected but the ratsnest is still there.
Lol. Don’t look in the schematic or symbol library files. They haven’t yet gotten the file format upgrade that the PCB files got, so are still a “sequence of space-separated numbers” for most parameters.
Right!! Had forgotten about that when I wrote that comment!
I also found it rather ugly and inconsistent the way the multiple items are stored in a library — for PCB, a library is a directory, and each footprint has its own file inside that directory; for symbols, a library is one file, and inside that file you have all components. *shudder*
However, just a few days ago I actually ended up doing just that (manually editing the symbol) — a symbol I was creating had pins D0 to D15, so I actually found it far easier and more convenient to just place the first two pins (needed two to be able to discern the pattern), and then just copied and pasted 14 times, then quickly edited the y-coordinate.
Really, far easier than dealing with the GUI and the annoying quirky mouse !!!
Incidentally, in gEDA this is also the case: the format of the symbols and schematics is absolutely horrific and cryptic. Their pcb format, though not nearly as nice(ly verbose) as KiCAD’s pcb format, is a delight by comparison (to their schematic file format, that is)… interesting pattern…
Huh. My situation is different — I placed the net-tie kind of “in the middle of nowhere” in the board (in a space where there were no traces or vias or anything), and the GNDREF zone covers the entire board (so, it completely surrounds the net-tie).
Another difference: you set it to Thermal Relief, instead of Solid in my case. (I’ll play with these settings when I have a chance)
The one file per footprint comes with drawbacks as well. Especially under windows it creates problems as you need many different file operations just to get a list of footprint names. (This is quite slow -> the reason why the new footprint editor takes quite some time to open as it needs all footprint names to generate the sidebar similar to the current symbol editor.)
I was more illustrating the connectivity problem rather than giving a solution for you.
But it should work all the same, here the GND zone covers everything and the zone priorities are changed, and the connection is solid. It just shows how zone filling is afraid of the net tie copper. If the clearance is larger than the radius of the endpoint pads there’s no copper connection at all.
This can be helped with a modified net tie footprint. The pads are longer ovals and the middle part doesn’t touch the centers of the pads. See how the zone copper gets closer to the net tie and the connectivity algorithm sees the zones and pads connected.
I just used vim to edit the pcb file to set my hole sizes.
Yes, I can change the symbol file footprints, but that is later down the road.
Then I used grep for all cases to make sure i got all cases.
Why not simply change the zone priority from an integer value to a floating point value. Then you can add a new priority between (almost) any two existing priorities. If you have existing priority 0 zones and existing priority 1 zones, you can add a new priority 0.5 zone between them.
This has the advantage of not requiring completely new dialogs etc. and only requires changing the data type of the field. Internal compares (<, >, =) should all still work with the new datatype, so there should be only minor internal code changes.
This idea is similar to the basis of the Dewey decimal system that lets libraries add new books without relabeling all the existing books.
Or do what we did when basic required numbered lines. Skip 10 places in the initial numbering so you had 10 spaces left. I don’t think we really need more than an integers worth of choices.
I wonder if a good wishlist would be to have the default priority be in the middle of the range of valid priorities instead of the bottom. Or are negative priority values accepted? I honestly haven’t tried.
I will start by apologizing for saying the following
Though I can now see some value in that suggestion, I have to confess that when I read it, I thought you were being sarcastic; that you were just poking fun at my suggestion; you know, implying that what I was suggesting was soooo crazy that “why not go all the way and do [[[ this other even more crazy idea ]]]”
The idea of being able to add a priority between virtually any two priorities is nice — but you have to agree that: com’on, a floating-point value for the priority???
It all comes down to the fact that there are an infinite number of real numbers between any two integers. With floating point there are only a large, but finite, number of values between integer values.
Starting off at, say, 10 rather than 0 and being able to list zones as a table and insert a row if necessary between two existing zones by shifting some of them would work, while avoiding cross platform problems with floating point numbers.
Can anybody think of a situation where two zones in a project SHOULD have the same priority?
It’s all the additional UI work required for the table display and updating, and the code to correctly update existing zone priorities etc that makes the integer approach harder to implement, and therefore less likely to be implemented quickly.
There should be no cross platform floating point issues. The KiCad files store the values as text strings not binary values. Each platform would convert the text string to/from its native floating point format internally. All the operations on these values are comparisons, there are no floating point calculations being done with these numbers.
