- docs/project-overview.md — 프로젝트 개요 - docs/solution-structure.md — 솔루션 구조 - docs/ptop-architecture.md — PTOP 아키텍처 - docs/aurora-devices.md — Aurora 디바이스 목록 - docs/build-output.md — 빌드 출력 경로 - docs/harness-ptop.md — PTOP 하네스 구성 수정된 파일: → CLAUDE.md — 기존 내용을 6개 문서로 분리, @import 방식으로 변경 → .gitignore — .claude/ 추가 삭제된 파일: - _기존md파일/ 디렉토리 (원본) 제안 커밋 메시지: docs: CLAUDE.md를 주제별 문서로 분리 및 @import 방식으로 재구성 - 프로젝트 개요, 솔루션 구조, PTOP 아키텍처, 디바이스 목록, 빌드 경로, 하네스 구성을 별도 문서로 분리 - 각 문서는 200줄 이하로 규칙 5번 준수 - CLAUDE.md에서 @import로 참조하는 라이브러리 형태로 변경 (규칙 6번 준수) 형태로 변경 (규칙 6번 준수) - .gitignore에 .claude/ 추가, .ubisam_agent는 제거
5.4 KiB
5.4 KiB
| name | description |
|---|---|
| analyze-ptop-implementation | ILSOS_PrismaticRD_PTOP의 구현 상세 분석. SeqAutoRunPTOP 시퀀스 로직, PLC/Laser/OCT/CellTracker 디바이스 호출 흐름, Rx.NET 메시지 체인, 상태 전이, 타이밍, 에러 처리를 분석하고 구현 개선안 제시. "PTOP 시퀀스 로직 분석", "PLC 통신 흐름 추적", "디바이스 호출 순서", "타이밍 다이어그램" 요청 시 사용. |
Analyze PTOP Implementation Skill
목표
ILSOS_PrismaticRD_PTOP의 구현 세부사항을 분석하고 최적화 기회를 식별한다.
분석 영역
1단계: SeqAutoRunPTOP.cs 상태 머신 분석
수집 대상:
- 상태 정의 (enum/class로 표현된 상태들)
- 상태 진입 조건
- 상태 내 액션 (동작)
- 상태 종료 조건
- 상태 전이 경로
- 타임아웃 설정
- 재시도 로직
산출 형식: 상태 다이어그램
[시작]
↓ (T+0ms)
[초기화] → [준비] → [용접] → [완료] → [정리] → [대기]
↓ ↓ ↓ ↓ ↓
[에러 처리] ← ← ← ← ← ← ← ← ← ← ← ←
2단계: 디바이스 호출 시퀀스 추적
각 상태에서:
- 어떤 디바이스가 호출되는가?
- 호출 순서는? (순차 vs 병렬)
- 예상 소요시간?
- 다음 상태로의 전이 신호는 어디서 오는가?
추적 대상:
-
PLC 호출
- 읽기: PLC.ReadBool("M10"), PLC.ReadInt("D20"), etc.
- 쓰기: PLC.WriteBool("M5", true), PLC.WriteInt("D15", 100), etc.
- 대기: PLC 상태 폴링, 신호 기다리기
-
Laser 제어
- 활성화 (SetPower, SetFrequency, etc.)
- 대기
- 정상 종료
-
OCT 스캔
- 스캔 시작
- 데이터 수집
- 스캔 종료
-
CellTracker
- 셀 추적 시작
- 위치 업데이트
- 추적 종료
산출 형식: 타이밍 다이어그램
Time(ms) 0 100 200 300 400 500
State [INIT][PREP][WELD..................][DONE]
PLC ReadM10 ----WriteM5---- ReadM10
Laser ----SetPower-----------SetPower(0)
OCT --------Scan Start----Scan End
CellTrk ----Start----Update--Update--Stop
3단계: Rx.NET 메시지 체인 분석
수집 대상:
- Observable 소스 (어디서 데이터가 나오는가?)
- 변환 (Select, Map, Filter)
- 구독자 (누가 소비하는가?)
- 에러 처리 (OnError, Catch)
예시:
// PLC 상태를 구독하여 Laser 제어
AuroraEnv.MessageQueue
.Where(msg => msg.Key == "PLC_Status")
.DistinctUntilChanged()
.Subscribe(msg =>
{
if (msg.Value == "Ready") {
Laser.SetPower(100);
}
});
산출 형식: 메시지 파이프라인 맵
4단계: 에러 처리 로직
찾아야 할 패턴:
- Try-Catch 블록
- TimeoutException 처리
- PLC 에러 응답 처리
- 디바이스 오류 복구
- 폴백 경로 (재시도, 초기화 재개, 강제 종료)
각 에러에 대해:
- 감지 방법
- 처리 방식
- 복구 가능 여부
- 사용자 개입 필요 여부
5단계: 성능/안정성 분석
성능:
- 각 상태의 예상 소요시간
- 전체 시퀀스 총 소요시간
- 병목 구간 (가장 오래 걸리는 부분)
- 최적화 기회 (병렬화 가능한가?)
안정성:
- 데드락 가능성 (두 디바이스가 서로 대기?)
- 타이밍 이슈 (신호 도착 순서 의존?)
- 리소스 누수 (구독 취소 안 됨?)
- 상태 불일치 (PLC와 소프트웨어 상태 차이?)
통합 산출물
최종 보고서: _workspace/02_ptop_implementation.md
# PTOP 구현 분석 보고서
## 1. 상태 머신
[다이어그램]
## 2. 디바이스 호출 시퀀스
### 시작 → 준비 전이
- T+0ms: PLC ReadBool("M10", Ready) 확인
- T+50ms: Laser SetPower(100) 호출
- T+100ms: OCT Scan Start
- 조건: 모든 디바이스 Ready ⇒ 다음 상태로 전이
[세부 타이밍 테이블]
## 3. Rx.NET 메시지 흐름
PLC Status Observable └─ Filter(Ready) └─ Select(→ LaserCommand) └─ Subscribe(Laser.Execute)
## 4. 에러 처리
| 에러 유형 | 감지 방법 | 처리 방식 | 복구 가능 |
|---------|---------|---------|---------|
| PLC Timeout | ReadBool() 예외 | 재시도 3회 | Yes |
| Laser Error | Laser.Status != OK | 전원 차단 후 재시작 | Yes |
| ... | ... | ... | ... |
## 5. 성능 프로파일
| 구간 | 소요시간 | 최적화 기회 |
|------|---------|----------|
| 준비 단계 | 200ms | 병렬화 불가 |
| 용접 단계 | 1500ms | OCT 스캔 시간 단축? |
| ... | ... | ... |
## 6. 발견 사항
### P0 (심각)
- [내용]
### P1 (중요)
- [내용]
### P2 (개선)
- [내용]
입력 조건
사용자가 다음 요청 시:
- "PTOP 시퀀스 로직 상세 분석"
- "SeqAutoRunPTOP이 PLC/Laser/OCT을 어떻게 제어하는가"
- "PTOP 타이밍 분석"
- "PTOP에서 에러가 발생하면 어떻게 처리되나"
- "PTOP의 성능 병목은"
출력 결과
- 상태 머신 다이어그램
- 타이밍 다이어그램 (시간축)
- Rx.NET 메시지 흐름도
- 에러 처리 매트릭스
- 성능 프로파일
- 최종 분석 보고서
주의사항
- 코드 라인 번호 기록 — "Line 245의 try-catch" 형식으로 정확한 위치 기록
- 데이터 흐름 추적 — 변수, 반환값을 따라가며 이해
- 시간 측정 — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
- 예외 처리 — Exception 타입별로 분류
- 불명확한 부분 기록 — 추측 금지, 명시적으로 "불명확함" 표시