As a developer of many large code bases, I appreciate your concern for the purity of the code. As a user, I just want it to work. Allowing thermals on pads would solve the problem. A separate clearance parameter for pads might be useful for other reasons but would not work well for my use case because I still want the DRC to catch other non-zero pad clearance violations.
Still, adding back the exception for zero clearance pads in the DRC seems like the simplest solution. I checked out the code and this change was all I needed:
@@ -637,7 +637,7 @@ drc_callback (DataType *data, LayerType *layer, PolygonType *polygon,
/* fall-through */
case PAD_TYPE:
case PIN_TYPE:
- if (clearance < 2 * PCB->Bloat)
+ if (clearance && clearance < 2 * PCB->Bloat)
{
/* The clearance is too small, but it could be cleared by other
* objects.
You could add a checkbox in the DRC config to toggle this behavior.
Chad,
As a developer of many large code bases, I appreciate your concern for the purity of the code. As a user, I just want it to work. Allowing thermals on pads would solve the problem. A separate clearance parameter for pads might be useful for other reasons but would not work well for my use case because I still want the DRC to catch other non-zero pad clearance violations.
Still, adding back the exception for zero clearance pads in the DRC seems like the simplest solution. I checked out the code and this change was all I needed:
@@ -637,7 +637,7 @@ drc_callback (DataType *data, LayerType *layer, PolygonType *polygon,
/* fall-through */
case PAD_TYPE:
case PIN_TYPE:
- if (clearance < 2 * PCB->Bloat)
+ if (clearance && clearance < 2 * PCB->Bloat)
{
/* The clearance is too small, but it could be cleared by other
* objects.
You could add a checkbox in the DRC config to toggle this behavior.
Thanks for all your hard work.
Joseph