Donner à un pad une orientation indépendante de celle du footprint avec l'API Python de KiCad
Faites pivoter un seul pad sans toucher au reste du footprint — et le piège testé qui fait perdre ce réglage sur l'une des deux API KiCad.
Sur la plupart des footprints, tous les pads partagent l’orientation du composant : un connecteur tourné à 90° voit toutes ses broches tourner avec lui. Mais certains pads doivent garder un angle propre, indépendant du reste — un pad de forme allongée qui doit rester aligné avec une piste précise, par exemple. Les deux API exposent l’angle d’un pad comme une valeur absolue, pas comme un décalage par rapport au footprint — une distinction qui a des conséquences très différentes selon l’API au moment où le footprint tourne à nouveau.
Lire l’angle d’un pad
GetOrientationDegrees renvoie l’angle absolu du pad, footprint compris :
import pcbnew
board = pcbnew.GetBoard()
fp = board.FindFootprintByReference("U1")
pad = list(fp.Pads())[0]
print(fp.GetOrientationDegrees(), pad.GetOrientationDegrees())Testé : faire pivoter fp change la valeur renvoyée par pad.GetOrientationDegrees() d’autant, sur tous les pads du footprint — l’angle absolu suit automatiquement le footprint.
Même logique côté IPC, avec padstack.angle :
from kipy import KiCad
kicad = KiCad()
board = kicad.get_board()
fp = next(f for f in board.get_footprints() if f.reference_field.text.value == "U1")
pads = [p for p in board.get_pads() if p.parent and p.parent.value == fp.id.value]
print(fp.orientation.degrees, pads[0].padstack.angle.degrees)board.get_pads() renvoie tous les pads de la board ; il n’y a pas de méthode fp.pads dédiée, donc on filtre sur p.parent.value == fp.id.value.
Donner un angle personnalisé à un pad
Pour un pad tourné de extra degrés en plus du footprint, on part de l’orientation actuelle du footprint :
extra = 45
pad.SetOrientationDegrees(fp.GetOrientationDegrees() + extra)from kipy.geometry import Angle
extra = 45
pad.padstack.angle = Angle.from_degrees(fp.orientation.degrees + extra)
board.update_items(pad)⚠️ Piège testé : faire pivoter le footprint après coup
Une fois le pad personnalisé, on continue souvent à manipuler le footprint — le repositionner, le faire pivoter pour l’aligner sur un connecteur. Les deux API réagissent très différemment à ce moment-là.
Testé sur un footprint à deux pads : orientation initiale -90°, pad manuellement réglé à 315° (soit +45° par rapport au footprint). Un fp.SetOrientationDegrees(fp.GetOrientationDegrees() + 30) fait passer le footprint à -60° — et le pad personnalisé suit automatiquement à 345°, exactement -60+45. Le décalage de +45° est préservé, sans rien recalculer à la main ; fp.Rotate(centre, angle) se comporte de la même façon. pcbnew retient en interne l’angle du pad relatif au footprint, l’angle absolu n’est qu’une valeur calculée à la volée.
⚠️ Testé sur deux footprints différents (reproduit deux fois) : orientation initiale 0°, un pad réglé à 45° via update_items. Un fp.orientation = Angle.from_degrees(30); board.update_items(fp) fait passer le footprint à 30° — mais le pad personnalisé retombe à 30° pile (son décalage de +45° est perdu, pas seulement mal recalculé), et sa position ne bouge plus du tout. Le pad voisin, jamais touché individuellement, suit correctement le footprint à 30° avec sa position qui pivote normalement sur l’arc. Un board.save() derrière ne corrige rien : le fichier .kicad_pcb enregistre bien le pad figé, avec l’angle et la position faux par rapport au reste du footprint.
Dès qu’un pad reçoit un angle personnalisé via update_items, il perd le suivi automatique des rotations suivantes du footprint parent. Réglez l’angle personnalisé en tout dernier, une fois l’orientation finale du footprint fixée — ou recalculez-le vous-même après chaque rotation du footprint.
Pour aller plus loin
Le même calcul sert à recopier l’angle d’un pad d’un footprint de référence vers un autre placé à une orientation différente : nouvel_angle = ancien_angle_pad + (nouvelle_orientation_footprint - ancienne_orientation_footprint). C’est la même arithmétique sur les deux API puisqu’elle ne porte que sur des valeurs absolues — seul le comportement au moment de la rotation ultérieure du footprint diffère, comme vu ci-dessus.