KiPad (or PadDrillStencilSilk.py)

HiGreg · July 10, 2017, 10:05pm

This seems like the appropriate place to document progress on my python pads script. It’s not ready for deployment, but I wanted to share some capabilities I’m developing. Here are the comments in the code I shared on the Developer’s list. I haven’t posted the code anywhere yet, but I’d be glad to share snippets of code if you’re interested, just ask! My intent is to donate to the KiCAD project when I get it to conform to the style guidelines and fix some of the shortcomings (pad shapes, and front/back pads, in particular).

I also have decent references to drill sizes, and stencil rules of thumb (vs. aperture ratios, solder powder size/type).

If you are aware of other tools (including built-in KiCAD tools) that do the same tasks or similar, please let me know.

I’ve already begun fixing some of the bugs listed below (integrating via and pad holes, starting to recognize holes on multiple layers, fixing some of the unit conversions to pcbnew.IU_PER_MM and IU_PER_MILS) and will continue development.

I like the name “KiPad”. Is that indicative of what this script does? Is that name taken already?

# PadDrillStencilSilk.py
# Original Author: Greg Smith, June 2017
#
# ABOUT:
#    This python script provides additional basic DRC checks to KiCAD
#    and lists to make tweaking pads for stencil creation.
#    It adds a menu item to "Tools" called Pads/Vias/Stencils.
#
# This is VERY beta. Not thoroughly tested. Not well commented.
#
# Not conforming to style guides (neither Python nor KiCAD style guides).
# Inputs and outputs are in varying non-changable units (mils, inches, mm, nm)
# Only tested on KiCAD 4.06, Windows 7.
#
# Install: place file in C:\Program Files\KiCad\share\kicad\scripting\plugins\PadDrillStencilSilk.py
# in pcbnew, open scripting console (Tools > Scripting Console)
# type "import PadDrillStencilSilk"
#
# THERE ARE BUGS:
#
# Only handles 2-layer boards, only through vias, and pads are not verified for shape.
# Does not check pad drill DRC
# Assumes all pads are on the front.
# Does not mix via drill and pad drill checks.
# Does not check annular ring size.
#
# Pad Info: Produces two lists: 
#   1) detailed list of pads by footprint reference with paste/mask properties
#   2) quantity of pads by size
# Drill Info: Generates multiple lists:
#   1) Hole quantity by specified pad drill sizes
#   2) Quantity by closest larger standard drill size (future option to pick drill sets)
#   3) Drill list
#   4) Distance from each via to next closest via
#   5) Checks via drill to via drill clearance
#   6) Checks via drill to track clearance
# Stencil Info:
#   1) Lists quantity of apertures by aperture size
#   2) Summary of aperture ratios by stencil thickness
#   3) Checks AspectRatio and AreaRatio against a variety 
#      of stencil thicknesses (2 mil-7 mil, all currently hardcoded)
#
# EXAMPLES:
#
# Pad Info: Produces two lists: 
#   1) detailed list of pads by footprint reference with paste/mask properties
#      Number of pads: 293
#      
#        ***** Pads By Footprint Reference, Alphabetical *****
#      #    4	(BT1.) X=113.665086 Y=147.423648 P=CIRC (2.64, 2.64) D=CIRC
#             (2.64, 2.64) Layers=F.Cu,B.Cu,B.Mask,F.Mask lc=0.0000 c=0.1530
#             Paste: spm=0.0000,0.0000 lspm=0.0000 lspmr=0.0000 | Mask : smm=0.0000 lsmm=0.0000
#      ...
#   2) quantity of pads by size
#      ***** Quantity of Pads By Size *****
#      Size: 0.900 0.900, Quantity 4
#      Size: 0.875 1.250, Quantity 2
#      Size: 0.800 1.200, Quantity 2
#      Size: 0.900 1.700, Quantity 1
#      Size: 0.300 0.800, Quantity 24
#      ...
#
# Drill Info: Generates multiple lists:
#   1) Hole quantity by specified pad drill sizes
#      ***** Quantity of Pads By Specified Drill Size *****
#      Size: 1.020mm, Quantity 2
#      Size: 4.826mm, Quantity 6
#      Size: 1.000mm, Quantity 54
#      Size: 2.640mm, Quantity 2
#      Size: 1.097mm, Quantity 8
#      
#   2) Hole quantity by closest larger standard drill size (future option to pick drill sets)     
#      ***** Quantity of Pads By Standard Drill Size *****
#      Size: 1.020mm (25.908 mils), Drill: 0.041 (59), Quantity 2
#      Size: 4.826mm (122.580 mils), Drill: 0.191 (11), Quantity 6
#      Size: 1.000mm (25.400 mils), Drill: 0.04 (60), Quantity 54
#      Size: 2.640mm (67.056 mils), Drill: 0.104 (37), Quantity 2
#      Size: 1.097mm (27.871 mils), Drill: 0.0465 (56), Quantity 8
#
#   3) Drill list
#      ***** Drill Holes List (pad #, position (nm), Type, Drill, Drill Value, Via Width) *****
#      0 (152661291, 138048648) 3 294000 294000 600000
#      1 (113725000, 140800000) 3 294000 294000 600000
#      ...
#
#   4) Distance from each via to next closest via
#      ***** Distance to next closest via  ***** (looking only *forward* through the list)
#      
#      Minimum Via to Via = 20.000 mils (0.508 mm)
#      0 3.692 mm
#      1 1.205 mm
#      ...
#
#   5) Checks via drill to via drill clearance
#      ***** Vias too close to another via *****
#      29
#      44
#      ...

#   6) Checks via drill to track clearance
#      ***** Vias too close to track *****
#      31 Via (/IOC_RB6) at (125934690, 138137006) is 306005 away from track (/IOC_RB5)
#         ((126280790, 137531001) ; (125660499, 137531001)). Shoud be 508000
#      23 Via (/GND) at (150540086, 141423648) is 307472 away from track (/RE2)
#         ((149487558, 140816176) ; (152110941, 140816176)). Shoud be 508000
#      ...
#      
# 
# Stencil Info:
#   1) Lists quantity of apertures by aperture size:
#      (Aperture size in mm, triplets of stencil mil thickness, area ratio, aspect ratio)
#      (qty 24)	Aperture=0.225,0.725 (2.0 1.69 4.43) (3.0 1.13 2.95) (4.0 0.85 2.21)
#         (5.0 0.68 1.77) (6.0 0.56 1.48) (7.0 0.48 1.27)
#	      Pads: [20, 45, 80, 98, 99, 100, 101, 109, 113, 121, 125, 140, 143, 165,
#         205, 208, 209, 210, 233, 234, 238, 239, 241, 244]
#         From: CONN_01X24
#      ...
#
#   2) Summary of aperture ratios by stencil thickness
#       ***** Aperture Ratio Ranges *****
#       2.0 mil Aspect: 4.429 14.764	 Area  : 1.471 4.318
#       3.0 mil Aspect: 2.953 9.843	 Area  : 0.981 2.879
#       4.0 mil Aspect: 2.215 7.382	 Area  : 0.735 2.159
#       5.0 mil Aspect: 1.772 5.906	 Area  : 0.588 1.727
#       6.0 mil Aspect: 1.476 4.921	 Area  : 0.490 1.439
#       7.0 mil Aspect: 1.265 4.218	 Area  : 0.420 1.234
#
#   3) Checks AspectRatio and AreaRatio against a variety 
#      of stencil thicknesses (2 mil-7 mil, all currently hardcoded):
#       ***** Failed Aperture Test *****
#       Failed 5.0 mil thickness:
#       	Failed Area  : 0.445 0.225
#       	Failed Area  : 0.300 0.350
#       Failed 6.0 mil thickness:
#       	Failed Area  : 0.555 0.245
#       	Failed Area  : 0.445 0.225
#       	Failed Area  : 0.300 0.350
#       	Failed Area  : 0.225 0.725
#       	Failed Aspect: 0.445 0.225
#       	Failed Aspect: 0.225 0.725
#       Failed 7.0 mil thickness:
#       	Failed Area  : 0.555 0.245
#       	Failed Area  : 0.325 0.725
#       	Failed Area  : 0.445 0.225
#       	Failed Area  : 0.300 0.350
#       	Failed Area  : 0.225 0.725
#       	Failed Aspect: 0.555 0.245
#       	Failed Aspect: 0.445 0.225
#       	Failed Aspect: 0.225 0.725
#
#
# Nevertheless, there are some examples of using python code to interact with KiCAD:
#    Install Tools menu, replace if already existing (allows reloading python file after changes)
#    Iterate over tracks, identify vias, get sizes of via copper, mask, and paste
#    Identify which layers a pad is on.
#    Generate basic interactive window.
#    Display  multi-threaded wx.Gauge (progress bar)
#    Get Paste (stencil) Aperture size calculated from pad properties.

# TODO list, aside from fixing the BUGS above.
#   Support front and back layers.
#	Support more than just through drills (i.e. buried/blind vias)
#   Label units and make consistent. Use KiCAD-provided "native unit" conversion
#   Mask Info: Checks solder mask dam sizes.
#   Silk Info: Checks silk screen character sizes.
#

Greg S.

HiGreg · July 17, 2017, 12:12am

A short update.

I’ve had to code a polygon intersection routine to handle rotated text silk over mask. In converting the prior orthogonal box overlap check to the new polygon check, I’m not extracting the exact pad rotation quite correctly. Still a work in progress:

I’m making good progress on intersecting polygon. I think it’s working. However, my identification of exact pad bounding box is getting ‘confused’ by orientation.

Note the highlighted pads are correctly identified as having silk screen over them (the large diagonal text). For testing, I’m creating the bounding boxes on Eco2.User layer to help identify errors in coding.

I’ve updated the code for PEP8 conformance, all except variable and function naming convention. Still need to add comments and doctext.

Oh, and I think I’m settling on the name KiPadCheck.

Thoughts?

dchisholm · July 17, 2017, 3:30am

I am impressed and amazed by your progress over just a few days!

In the past I used a layout program that did DRC checks for silkscreen clearance based on text bounding boxes, rather than actual strokes in the character. It was frustrating because the bounding boxes were always significantly larger than the actual characters. For example, to satisfy a design rule that required 6 mil clearance between silk and copper, you had to design with 8 mils or 10 mils of actual clearance from a text object.

Dale

HiGreg · July 17, 2017, 3:46am

Dale,

Thank you!!

I’m working on getting exact clearance from all text segments (individual strokes within the text). It will probably be an option, since I expect bounding box to be much faster). To do this, I have to retrieve the strokes from python, and the only function to do this requires an argument I don’t know how to generat (yet). I’ll post the specific question in one of the threads I’ve started on this forum (likely here).

I’ll build the checking based on the track checking code I already have.

I still have to figure out how to get the non-text graphical objects (circles, lines, and arcs) and check them. I’m not sure how to tackle silkscreen images. That may be far future, and a niche check only needed by some.

Thanks for tracking my project, and if you have any wish list items, I’d love to hear them.

I’m getting ever closer to releasing, but still have cleanup to do with variable/function names conforming to PEP8, and a lot of code comments and docstrings to add.

HiGreg · July 17, 2017, 4:38am

Well, I may not need to ask how to get the strokes from the text object

Just a little tweaking to figure out the letter breaks. Here, I’ve drawn thin segments on Eco2.User to denote the identified strokes:

Apologies for the misspelled “cools”

HiGreg · July 17, 2017, 5:00am

And there it is. Made an assumption that the point vector should be considered in pairs. And I looks like that’s correct:

You can barely see the Eco2.User layer strokes within the F.SilkS letters, but they’re there!

Apparently, I can’t spell “forum” either!

Should be pretty straightforward to check individual strokes vs. pad. Now I just have to decide whether to check against copper, mask, or larger of the two. I think it makes the most sense to check against mask, but may need options to meet PCB manufacturing rules that specify to copper. Thoughts on this?

hermit · July 17, 2017, 5:37am

Keep in mind, the ERC errors can be ignored. You’re only real goal need be to alert people to possible violations and let them decide. I think the ERC has levels so you could warn for a mask violation and error for copper. I’ll throw in a ‘like’ for your efforts here.

HiGreg · July 17, 2017, 5:49am

Thanks, hermit!!

I’m not sure what you mean by “can be ignored”. I’m familiar with what I’ve usually termed “false errors” where the nature of generating violation detection does not quite match a manufacturer’s method or rules. Some manufacturers will either hand modify a design or reject it outright for violating some rules. Mask dam is a common one (the space between pads, if it’s below a certain distance, then it can create mask pieces that flake off).

Thanks again! and keep the ideas coming!

hermit · July 17, 2017, 2:53pm

What I mean is “can be ignored” by the person designing the board. You don’t have to come up with a perfect solution to all possible scenarios. Your software gives them warnings/errors and it is up to them to decide what to do with that information.

I pulled a footprint from the library that has silk screen on pads. I didn’t catch it before I sent the design off. Seems like a common part so how does the error persist? It is a through hole part so I guess no one complains about ink on the top side because it won’t be soldered?

Rene_Poschl · July 17, 2017, 3:05pm

There is an option in the gerber export dialog.
“Subtract soldermask from silkscreen.”
And i guess the manufacturer might do this themselves. (Maybe even with additional clearance to the solder mask.)

hermit · July 17, 2017, 9:43pm

[quote=“Rene_Poschl, post:10, topic:7018”]
And i guess the manufacturer might do this themselves.
[/quote]The board was delivered today. I got a cell phone picture and it appears the manufacturer did indeed do this themselves. How dare they change the design without consulting me?

dchisholm · July 17, 2017, 11:11pm

That practice (of “correcting” silkscreen errors by removing silkscreen from bare copper areas) seems to be moving toward a standard practice among fab houses. The motivation is to protect us from the consequences of our carelessness, which is understandable. It is disturbing when it’s done without notice. Just a two-line email is all I’d ask for - something like,

[quote]"While preparing your PCB order for fabrication we found and corrected the following conditions in accordance with our standard procedures:

Silkscreen overlaying bare copper
Your order is proceeding to fabrication. If you wish to cancel or re-submit your order, please notify us in the next hour." [/quote]

Deleting silkscreen from bare copper areas avoids the most egregious soldering failures but can leave a ratty-looking board. Even if the purchaser will not have a chance to correct his mistake (with, or without, additional charge), it seems like he should have fair warning that the job was not fabricated exactly as submitted.

Dale

Joan_Sparky · July 18, 2017, 1:23am

That’s probably the difference between economic and service-oriented manufacturers.

HiGreg · July 18, 2017, 10:56pm

Another update on progress. The previous update apparently only worked for text strokes that were not in a module (aka “free text” or TEXTE_PCB objects). It did not work for text within a module (aka TEXTE_MODULE objects). After a lot of futzing around, I’ve finally worked out how to get text strokes at any orientation and regardless of whether they are PCB or MODULE text objects. A more detailed update, including code, is here.

Now that I have segments, I will be writing the section that checks against the pads. Hopefully that will go better than the text rotation has .

Comments or questions (or Likes!) are welcome!

HiGreg · July 25, 2017, 11:50am

Update on progress:

As expected, checking silk text line segments against pads is fairly quick. However, when taking into account the thickness of the text, things slow down, similar to (or worse than) the tracks. It takes about 30 seconds on my test board. I’ve identified the time culprit, but will add an option (“detailed text check”) that will toggle the thickness check.

I’ve had to write “minimum distance” functions for lines and polygons as well as intersect functions.

It’s going well! Still have to add silk shape checks (at least line segments and circles). And still have to add comments, docstrings, and update variable and function naming.

On the plus side, I now have routines that do basic geometry checks in Python for wxPoint vectors (both line segment vectors, and polygon vectors).

LsDelancy · July 25, 2017, 12:55pm

Most of what you said makes no sense to me, but I understand what you are doing and would like to commend you for your effort and rapid progress. I think it’s great when open source projects work as well as KiCAD is!

HiGreg · July 26, 2017, 12:58pm

This image shows the check that does not incorporate text thickness:

The yellow lines are just guidelines to verify functionality.

Note that the silk layer “C7” stroke line segment touches only “NC_D4” pad, while the Silk layer incorporating thickness touches both “NC_D4” and “RESE”. Both the quick check and the full DRC will catch “NC_D4” overlap. The quick check will incorrectly pass “RESE”.

I hope that helps explain the difference between the two!

HiGreg · July 28, 2017, 11:49pm

First public version of KiPadCheck.py is available on Github

Please make comments or ask questions in this thread