배율 사고를 잡고 나니 다음 문제가 보였습니다. 저는 그때까지 PADS 라이브러리를 그때그때 변환해서 쓰고 있었습니다. 보드마다 필요한 것만 뽑아 쓰다 보니 같은 부품이 이름만 다르게 여러 벌 생기고, 변환 오류도 보드마다 따로 재현됐습니다.
그래서 갈아엎기로 했습니다. PADS 원본은 그대로 두고, KiCad 전용 라이브러리를 처음부터 새로 짓습니다.
- 풋프린트 1,214개 →
going.pretty - 심볼 857개 →
going.kicad_sym - 중복 제거, 부품 값·정격은 BOM 에 바로 쓸 수 있게 필드로
역슬래시 한 글자에 KiCad 라이브러리 전체가 안 읽혔다
KiCad 심볼 라이브러리를 다 만들고 열었더니 통째로 안 읽혔습니다. 심볼 하나가 깨진 게 아니라 전부.
원인은 핀 이름이었습니다. PADS 는 액티브 로우 신호를 \RESET\ 처럼 역슬래시로
감쌉니다. 이걸 그대로 KiCad S-expression 문자열에 넣으면, 역슬래시가 이스케이프
문자로 해석돼서 파일 전체의 괄호 균형이 깨집니다.
def esc(s):
# 역슬래시를 안 막으면 KiCad 가 라이브러리 전체를 못 읽는다
return str(s).replace("\\", "\\\\").replace('"', '\\"')
그리고 오버바 표기는 KiCad 문법으로 옮겼습니다. \RESET\ → ~{RESET}.
파일을 직접 생성하는 방식의 대가입니다. 한 글자가 파일 전체를 무효로 만듭니다.
그래서 라이브러리를 만든 뒤에는 반드시 kicad-cli 로 한 번 열어보게 했습니다.
PADS 패드 정의 필드가 하나 더 있었다
풋프린트 변환은 1,214개 중 264개가 이상하게 나왔습니다. 핑거 패드(길쭉한 패드)를 쓰는 부품들이었습니다.
PADS 패드 정의는 이렇게 생겼습니다.
OF(타원) 3필드 : <회전> <길이> <오프셋>
RF(사각) 4필드 : <코너반경> <회전> <길이> <오프셋>
RF 에는 맨 앞에 코너 반경이 하나 더 붙습니다. 같은 자리로 읽으니 회전값이
길이로, 길이가 오프셋으로 한 칸씩 밀렸습니다. 문서에 명시가 없어서, 5,000줄어치
값 분포를 뽑아 놓고 “이 자리에 오는 값의 범위가 무엇인가”로 역산했습니다.
3D 모델 — 추측을 세 번 틀렸다
3D 모델 정합은 풋프린트가 맞아도 어긋났습니다. 렌더에서 부품이 엉뚱한 데 붙어 있었고, 저는 원인을 오프셋이라고 봤습니다.
| 시도 | 가설 | 결과 |
|---|---|---|
| 1 | 패드 중심 기준이라 오프셋이 필요하다 | 틀림 |
| 2 | 오프셋 부호가 반대다 | 틀림 |
| 3 | 원점이 부품 외곽 기준이다 | 틀림 |
세 번 다 틀리고 나서야 방법을 바꿨습니다. 추측을 그만두고 렌더를 비교했습니다. 오프셋 0으로 렌더를 하나 뽑아 원본과 나란히 놓으니, 오프셋은 원래 0이 맞았습니다.
진짜 원인은 90° 회전이었습니다. 그리고 이건 패드 배치 패턴을 대조해서 찾았습니다. DIP16 부품을 0°/90°/180°/270° 네 방향으로 렌더해서 원본과 맞춰보니 답이 나왔습니다.
교훈이 하나 남았습니다.
3D 모델 정합은 추론하지 말고 패드 패턴으로 실측합니다. 그림으로 확인할 수 있는 문제를 머리로 풀려고 하면 시간만 갑니다.
16채널 IO 보드 배치 — 자를 대고 그은 것처럼
채널 배치는 반복이 전부입니다. 16채널 IO 보드는 같은 회로가 채널 수만큼 반복되고, 사람이 그릴 때도 한 채널을 그려놓고 복사해서 붙입니다. 자동화도 똑같이 했습니다.
한 채널 블록의 상대 배치를 원본에서 그대로 가져오고, 채널 간격만 일정하게 띄웁니다. 결과는 이렇습니다.
- 채널 피치 6.00mm 정확히 균일
- 입력 8채널 / 출력 8채널 서로 합동
- 채널 블록 밖으로 삐져나온 부품 0개

변환된 심볼이 실제로 쓰인 모습입니다. 릴레이·포토커플러·저항·커넥터가 전부 사내 라이브러리에서 넘어온 것이고, 핀 번호와 이름이 원본 데칼의 값 그대로입니다. 여기서 핀 하나가 밀리면 넷리스트가 조용히 달라집니다.

배치가 균일하면 그 다음이 편해집니다. 한 채널을 잘 배선하면 나머지 채널에 복사할 수 있기 때문이다 — 라고 생각했는데, 이게 생각만큼 안 됐습니다. 그 이야기가 4부입니다.
하드코딩한 상수는 설계가 바뀌면 반드시 물린다
하드코딩한 치수 상수에 이 단계에서 반복적으로 데었습니다. 터미널 블록 몸통 폭 28.35, LED 피치 9.0, 보드 확장량 계산식 같은 값을 코드에 그대로 박아뒀다가, 설계가 바뀔 때마다 배치가 통째로 어긋났습니다.
지금은 이런 값이 전부 한 군데(설계 의도 파일 또는 프로젝트 설정)에서만 옵니다. 나중에 선 굵기 규칙을 스크립트마다 따로 정해놨다가 크게 데는데, 그건 5부에서.
라이브러리는 보드마다 그때그때 변환하지 말고 한 벌로 지어야 하고, 치수 상수는 한 군데에서만 와야 합니다.
다음 편은 배선입니다. 45° 규칙, 계단 배선, 허공에 뜬 선 꼬리, 부품 패드 사이로 지나가는 선. 그리고 “직접 배선하고 나머지만 라우터에 주면 되지 않나?”를 세 가지 방법으로 시도해서 세 번 다 더 나빠진 기록.
▶️ 4부: 배선이 말을 안 듣는다 — 45°, 계단, 그리고 세 번의 실패
🔧 이전 편: 1부 — 자동화하기로 했다 · 2부 — 검증을 통과한 1.5배 보드
문의
- Email : [email protected]
- Insta : https://www.instagram.com/going.sen/
- Website : https://intosen.com/kr/consult/
댓글
닉네임만 입력하면 바로 댓글을 남길 수 있어요. Google/GitHub 로그인도 가능합니다.