2_Board_State
Board state is a lot more complicated than schematic state. This has to do with complex geometry, intersection testing, rats nest calculation, zone filling, clearances, Hershey fonts, etc.
This section will give a brief overview of how each of the major functions works and where to look for further detail.
Units are in deci-thous (1/10000 of an inch). Hopefully we'll upgrade to the saner nanometer that KiCAD is presumably using but that's what it is for now.
Most of the heavy lifting of the geometry calculation is done by clipperlib. There are
auxiliary functions mostly located in bleepsix/js/brd/bleepsixBoard_aux.js and
bleepsix/js/bleepsixBoard_zone.js.
Helper functions of the form _clip_union, _clip_intersect, _clip_difference and _clip_xor
are in bleepsix/js/brd/bleepsixBoard_aux.js. Each of these take in arrays of clipperlib
polygons, which are themselves arrays of objects of the form { X:0, Y:0 }.
There are convenience functions _polygon2point and _pgn2pgn to convert from simple
array of polygons to what clipperlib expects. Simple polygons are just arrays of
two element arrays. For example [ [0,0], [1,1], ..., [30,30] ].
Note: clipperlib expects only integers.
Other auxiliary functions of the form _realize_circle, _realize_rect, _realize_oblong etc.
are helper functions to realize the various primitive shapes used in geometry calculations.
The geometry calculations are used in net highlighting (for the light overlay), collision testing and zone fill calculation.
clipperlib also provides polygon offsetting, which is used for clearance testing, zone filling, trace
layout and anything else that needs general polygon intersection testing.
Placed parts have a unique net associated with each of their pads. Net highlighting is complex and will be described in another section.
bleepsix/js/brdtool/toolBoardMove.js and bleepsix/js/brdtool/toolFootprintPlace.js have
logic to test for collisions in their canPlace functions.
This first does some crude testing to see if the bounding boxes intersect. If they do, then the complex task of assembling the union of the moving portions and then calculating the intersection of to see if theres a collision is done.
clipperlib is slow in JavaScript so it can slow down significantly if there is complex
geometry and/or large bounding boxes. To optimize, when moving the mouse, only
bounding box collisions are used to determine if a part can be placed. If there hasn't been
a mouse movement in some time interval (currently 100ms) then the full intersection test is
done.
In the case of intersections, the part will 'ghost' as shown below:
Most of the functionality for updating is held in bleepsix/js/brd/bleepsixBoard_ratsnest.js.
The rats nest is calculated from the implied nets from the schematic. The netcode passed into
e.g. updateRatsNest is used as the basis for the lookup in the sch_net_code_map. Nets connected
in the schematic will produce an 'airwire' in the board.
Once the group of elements that match the board netcodes implied by the schematic nets are found, calculation of the airwire positions is done.
Airwires are calculated by finding the Euclidean minimum spanning tree for approximations of the element group geometry. Tracks are approximated by points at intervals and the center point is used for pads.
Once the approximation is done, the EMST is calculated. The airwiares
are updated and put into the board.net_code_airwire_map object, which
is map of netcodes to an array of line segments.
Zone filling logic is mostly contained in bleepsix/js/brd/bleepsixBoard_zone.js.
Zone fills are in one big function called fillCZone. 'Zones' are right now limited
to a rectangular box. Zone fills are only allowed on board nets.
Zone fills are the intersection of the implied PCB edge polygon with the zone bounding rectangle, excluding geometry on different layers, minus all non-net polygons offsetted, union same net (same layer) polygons with bridging polygons.
The 'bridging' polygon policy is the thermal relief policy.
The fill strategy, along with the thermal relief, is hard to say but the strategy and all of it's complications are there to 'just do the right thing'. For example, fill if we don't have any PCB edges in the middle. Fill what you can if we only have a partial PCB edge. Fill only on the inside of a closed polygon from the PCB edge. Join the pads that are of the same net by some thermal relief policy, either completely connected or bridged. etc. etc.
The Hereshey Font is what's used in KiCAD. The relevant section in KiCAD that decoded the Hershey font was found converted to a JSON format.
JSON is verbose so in order to minimize load time for common usage, the Hershey font was split into two portions. The first being the ASCII portion and the second being the rest. In order to render, the Hershey fonts need to be loaded. For boards that use text that are mostly ASCII, having a smaller Hershey ASCII file to load first helps make load times faster.