chore: 로컬 전용 문서·하네스 설정 git 추적 제외
docs·CLAUDE.md·README.md·rules.md·.claude·.ubisam_agent 를 추적에서 해제. 로컬 전용 문서와 에이전트 설정이 저장소에 올라와 있어 정리한다. 파일은 디스크에 그대로 유지되며 .gitignore 로 재추적을 막는다. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
to3796zw
parent
a43a531e00
commit
750aa81b51
@ -1,200 +0,0 @@
|
||||
---
|
||||
name: analyze-ptop-architecture
|
||||
description: ILSOS_PrismaticRD_PTOP의 3계층 아키텍처(UI → Machine Logic → Device)를 분석하고 검증. EquipDef.cs, EquipmentSetup.cs, Sequences/, Device/ 폴더의 관계를 맵핑하고 Rx.NET 이벤트 흐름을 추적. 디바이스 스택(PLC, Laser, OCT, CellTracker) 통합 여부 검증. "PTOP 아키텍처 분석", "PTOP 계층 구조 검토", "디바이스 스택 파악" 처럼 **구조·의존성 한 영역만** 볼 때 쓴다. 구분 — 아키텍처·구현·빌드를 함께 보려는 요청("PTOP 전체 점검", "종합 분석", "구조 파악")은 `orchestrate-ptop-harness`를 쓴다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
||||
---
|
||||
|
||||
# Analyze PTOP Architecture Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처 전체 그림**을 명확히 파악하고 문서화한다.
|
||||
|
||||
## 분석 단계
|
||||
> **소스 루트 = `Machines/ILSOS_PrismaticRD_PTOP/`.** 이 문서의 상대 경로(`Sequences/…`,
|
||||
> `Device/PLC/…`)는 모두 그 아래다. 저장소 루트의 동명 폴더 `ILSOS_PrismaticRD_PTOP/`은
|
||||
> 빌드 산출물(.pdb)이므로 거기서 소스를 찾지 말 것.
|
||||
|
||||
|
||||
### 1단계: EquipDef.cs & EquipmentSetup.cs 분석
|
||||
|
||||
**EquipDef.cs에서 수집할 항목:**
|
||||
- `DeviceIds : CommonDeviceIds`에 **직접 선언된** 상수 (`MassFlowMeter` 등) + base에서 상속된 것
|
||||
- `SequenceIds : CommonSequenceIds`에 **직접 선언된** 상수 —
|
||||
`SeqStreamTest`, `SeqEventQTest`, `SeqTestRun`, `SeqAutoRunComponentWeld`, `SeqAlarmMonitor`,
|
||||
`SeqStatusMonitor`, `SeqAutoRunTDC`, `SeqAutoRunPTOP` (8개)
|
||||
- 커스텀 `DeviceIds` / `SequenceIds` / `SettingIds` / `StreamMessageNames`
|
||||
(`MotorIds`·`RecipeIds` 클래스는 **없다** — base `Common*`·레시피 매니저가 관리)
|
||||
|
||||
**EquipmentSetup.cs에서 수집할 항목:**
|
||||
- `GetEquipmentName()` → 장비명 확인 ("ILSOS PrismaticRD_PTOP")
|
||||
- `BuildMainStatusView()` → 표시되는 디바이스 (CellTracker, OCT)
|
||||
- `OnSetAlarm()` 로직 → 알람 처리
|
||||
- `OnStartUp()` 로직 → 초기화 순서
|
||||
- SequenceBuilder 선언과 **실제 `register(...)` 여부는 다르다.** `EquipmentSetup.cs:206-218` 기준:
|
||||
- `_SeqAutoRunPrismatic_Builder` → **등록됨**(`:211`, `SequenceIds.SeqAutoRun`)
|
||||
- `_SeqAutoRunComponentWeld_Builder` → 대입은 되나 **등록 주석 처리**(`:212`)
|
||||
- `_SeqTestRun_Builder` → **선언만·대입 없음**, 등록도 주석(`:213`)
|
||||
- `_SeqAlarmMonitor_Builder` → **등록됨**(`:214`)
|
||||
- `SeqStatusMonitor.Builder()` → **필드 없이 직접 등록됨**(`:215`) — 빌더 필드만 보면 놓친다
|
||||
- `_SeqAutoRunPTOP_Builder` → **등록됨**(`:218`), 메인 시퀀스 (260605)
|
||||
|
||||
> 목록을 그대로 옮기지 말고 **작업 전 `register(` 호출부를 실제로 나열해 대조하라** —
|
||||
> 주석 처리 여부까지 확인해야 "빌드되는 시퀀스"를 정확히 말할 수 있다.
|
||||
|
||||
**출력:** `_workspace/01a_equipdef_analysis.md`
|
||||
|
||||
### 2단계: Sequences/ 폴더 구조 분석
|
||||
|
||||
**주요 파일들:**
|
||||
```
|
||||
Sequences/
|
||||
├── SeqAutoRunPTOP.cs ← 메인 (분석 우선순위 1, 260605)
|
||||
├── SeqAutoRunPrismatic.cs ← 기존 (2026-06-18에 SeqAutoRunPrismaticScanner에서 개명)
|
||||
├── SeqAutoRunComponentWeld.cs
|
||||
├── SeqTestRun.cs
|
||||
├── SeqStreamTest.cs
|
||||
├── SeqEventQTest.cs
|
||||
├── SeqWaitWeldOrChangePage.cs
|
||||
├── LaserAngleOffsetSelector.cs
|
||||
├── SequenceContextEx.cs ← 컨텍스트 정의
|
||||
├── SequenceManager.cs ← 시퀀스 관리
|
||||
├── Monitoring/
|
||||
└── Manual/
|
||||
```
|
||||
|
||||
> 트리는 참고용이다. **작업 전 `Sequences/`를 실제로 나열해 대조하라** — 이 목록이 낡았을 수 있다.
|
||||
|
||||
**각 시퀀스 분석 항목:**
|
||||
- 용도 (주 시퀀스? 테스트? 모니터링?)
|
||||
- 상태 머신 정의 (시작, 대기, 실행, 완료, 에러)
|
||||
- 타이밍 (예상 소요시간)
|
||||
- 호출하는 디바이스 목록
|
||||
- 의존성 (다른 시퀀스에 의존하는가?)
|
||||
|
||||
**특히 SeqAutoRunPTOP.cs:**
|
||||
- 상태 다이어그램 작성
|
||||
- 각 상태에서 호출되는 디바이스/API 추적
|
||||
- 타임아웃/재시도 로직
|
||||
|
||||
**출력:** `_workspace/01b_sequences_analysis.md`
|
||||
|
||||
### 3단계: Device/ 폴더 분석
|
||||
|
||||
**파일 구조:**
|
||||
```
|
||||
Device/
|
||||
├── PLC/
|
||||
│ ├── PLCContoller.Config.cs ← 생성자·접속 설정만. 18줄, 주소 0건 (Controller 아님 — 저장소 오탈자)
|
||||
│ ├── PLCController.Logic.cs ← 읽기/쓰기 로직
|
||||
│ └── PLCController.Address.cs ← PLC 주소 맵의 진실원. 신호 상수 enum
|
||||
└── IO/
|
||||
└── PAIX_PTOP.cs ← IO 제어 (2026-06-18 개명)
|
||||
```
|
||||
|
||||
> **동명 심볼 함정.** `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner`(공유)와
|
||||
> `WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Config.cs`(공유, 오탈자 없음)는
|
||||
> 개명되지 않고 그대로 존재한다. 머신 쪽 파일과 혼동하지 말 것.
|
||||
|
||||
**PLC 분석:** (모든 값은 `PLCController.Address.cs`의 enum에서 읽어 `파일:라인`과 함께 적는다)
|
||||
- 실제 사용되는 주소 범위 — 추정하지 말고 enum 정의에서 확인
|
||||
- 주요 신호 목록 (eBitInput/eBitOutput/eWordInput/eWordOutput)
|
||||
- 읽기·쓰기 주기, 타임아웃 — 코드 상수 기준. 못 찾으면 `불명확 — 확인 필요`
|
||||
|
||||
**IO 분석:**
|
||||
- 입력 신호 (센서, 스위치)
|
||||
- 출력 신호 (제어 신호)
|
||||
- 각 신호의 의미
|
||||
|
||||
**출력:** `_workspace/01c_device_analysis.md`
|
||||
|
||||
### 4단계: Rx.NET 이벤트 흐름 분석
|
||||
|
||||
**수집할 정보:**
|
||||
- System.Reactive 사용 패턴 (Observable, Subject, etc.)
|
||||
- 메시지 타입 (String/Double/Int/JSON/LBAD)
|
||||
- 구독자 목록 (누가 어떤 메시지를 구독?)
|
||||
- 백프레셔/에러 처리
|
||||
|
||||
**파이프라인 예시:**
|
||||
```
|
||||
[PLC Status] Observable
|
||||
├─→ Filter(Ready == true)
|
||||
├─→ Select(x => new LaserCommand())
|
||||
└─→ Subscribe(Laser.Execute())
|
||||
```
|
||||
|
||||
**출력:** `_workspace/01d_rxnet_analysis.md`
|
||||
|
||||
### 5단계: 외부 디바이스 통합 검증
|
||||
|
||||
**검증 대상:**
|
||||
- PLC (Mitsubishi)
|
||||
- Laser (AuroraLaser)
|
||||
- OCT Scanner (AuroraOCT)
|
||||
- CellTracker (AuroraCellTracker)
|
||||
- IO (PAIX)
|
||||
|
||||
**각 디바이스마다:**
|
||||
- 초기화 시점
|
||||
- 활성화 조건
|
||||
- 사용 방식 (동기/비동기)
|
||||
- 에러 처리
|
||||
- 정상 종료 절차
|
||||
|
||||
**출력:** `_workspace/01e_device_integration.md`
|
||||
|
||||
## 통합 산출물
|
||||
|
||||
### 최종 보고서: `_workspace/01_ptop_architecture.md`
|
||||
|
||||
보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
|
||||
모든 항목에 `파일:라인` 근거를 붙이고, 확인 못 한 내용은 `불명확 — 확인 필요`로 남긴다.
|
||||
|
||||
**단독 기동으로 `01`을 갱신했으면 stale 표기 의무는 여전히 네게 있다.** "아키텍처만 다시" 같은 요청은
|
||||
이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기해 줄 주체가 없다.
|
||||
`01`의 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, **이 파일에 의존하는 `02`·`03`이 이미 있으면**
|
||||
그 두 파일 첫 줄에 `이전 실행 결과 재사용 — 01 갱신으로 정합성 미확인(YYYY-MM-DD)` 을 남긴다
|
||||
(문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
|
||||
**코드로 확인하지 않은 인과·해석은 문장 앞에 `[추론]`을 붙인다** (`rules.md` #15·#16).
|
||||
`불명확 — 확인 필요`(값을 못 찾음)와 축이 다르니 대체하지 말고 필요하면 병기한다.
|
||||
확인한 뒤에는 `[추론]`을 떼고 `파일:라인`으로 바꾼다.
|
||||
|
||||
## 입력 조건
|
||||
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
|
||||
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
|
||||
|
||||
|
||||
사용자가 다음과 같이 요청할 때:
|
||||
- "PTOP 아키텍처 분석해줘"
|
||||
- "PTOP 계층 구조 검토"
|
||||
- "PTOP에서 PLC, Laser, OCT가 어떻게 연결되어있는지"
|
||||
- "PTOP 3계층 아키텍처 검증"
|
||||
|
||||
> "PTOP 전체 점검"·"종합 분석"처럼 **구현·빌드까지 함께** 보려는 요청은 이 스킬이 아니라
|
||||
> `orchestrate-ptop-harness`다. 시퀀스 내부 동작만이면 `analyze-ptop-implementation`,
|
||||
> 빌드/CI면 `optimize-ptop-build`.
|
||||
|
||||
## 출력 결과
|
||||
|
||||
- 5개 상세 분석 문서 (`_workspace/01a~01e_*.md`)
|
||||
- 통합 보고서 (`_workspace/01_ptop_architecture.md`)
|
||||
- 다이어그램 (3계층, 상태 머신, 이벤트 흐름)
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **코드 읽기 능력이 중요** — C#, WPF, Rx.NET 이해 필수
|
||||
2. **불명확한 부분은 기록** — "이 부분은 왜 이렇게?"라는 질문을 명시
|
||||
3. **Namespace** — 대부분 `ILSOS_PrismaticRD_PTOP.*`이고 옛 `ILSOS_PrismaticScanner`는 0건이다.
|
||||
단 **프로젝트 내 예외 3개**: `Sequences/SeqTestRun.cs:35`=`ILSOS_PrismaticRD_TDC.Sequences`,
|
||||
`Sequences/Monitoring/SeqAlarmMonitor.cs:22`·`SeqStatusMonitor.cs:11`=`WeldingCommon.Sequences`.
|
||||
네임스페이스로 grep하면 이 3개가 누락된다 — 파일 경로로 찾을 것.
|
||||
또한 **공유 프로젝트에는 `PAIX_PrismaticScanner` 같은 옛 이름 심볼이 그대로 남아 있으니** 머신 심볼과 혼동 금지
|
||||
4. **260605 변경 이후 상태 파악** — SeqAutoRunPTOP이 최신 메인 시퀀스
|
||||
5. **한글 주석 인코딩** — `docs/CODING_RULES.md` 확인
|
||||
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 위 3의 `PAIX_PrismaticScanner` 잔존이
|
||||
그 사례다. 이름이 계층·소속을 말해 주지 않으므로 등록부·구현 본문으로 확인한다.
|
||||
|
||||
> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
||||
>
|
||||
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
||||
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|
||||
@ -1,63 +0,0 @@
|
||||
# 보고서 템플릿 — `_workspace/01_ptop_architecture.md`
|
||||
|
||||
> 이 골격을 채워 통합 보고서를 만든다. **모든 항목에 `파일:라인` 근거를 붙인다.**
|
||||
> 코드에서 확인하지 못한 내용은 비워두지 말고 `불명확 — 확인 필요`로 적는다.
|
||||
|
||||
```markdown
|
||||
# ILSOS_PrismaticRD_PTOP 아키텍처 검토 보고서
|
||||
|
||||
## 1. 3계층 아키텍처
|
||||
|
||||
┌──────────────────────────────┐
|
||||
│ WPF UI Layer │
|
||||
│ (Views/, ViewModels/) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Machine Logic Layer │
|
||||
│ (EquipmentSetup, Sequences) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Device Abstraction │
|
||||
│ (AuroraDevices) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Hardware Layer │
|
||||
│ (PLC, Laser, OCT, etc.) │
|
||||
└──────────────────────────────┘
|
||||
|
||||
계층 경계 위반 지점: <파일:라인> — <어느 계층이 어느 계층을 건너뛰는가>
|
||||
|
||||
## 2. 핵심 컴포넌트
|
||||
|
||||
### EquipDef & EquipmentSetup
|
||||
- EquipDef 매핑 표 — 출처: `EquipDef.cs:<라인>`
|
||||
- 등록되는 시퀀스 목록 — 출처: `EquipmentSetup.cs:<라인>`
|
||||
|
||||
### Sequences
|
||||
- 시퀀스 관계도 (활성/비활성 표시)
|
||||
- SeqAutoRunPTOP 상태 머신 — 출처: `Sequences/SeqAutoRunPTOP.cs:<라인>`
|
||||
|
||||
### Device
|
||||
- PLC 신호 맵핑 — 출처: `Device/PLC/PLCController.Address.cs:<라인>`
|
||||
- IO 신호 맵핑 — 출처: `Device/IO/PAIX_PTOP.cs:<라인>`
|
||||
|
||||
## 3. Rx.NET 이벤트 흐름
|
||||
|
||||
<발행 지점 → 필터 → 구독 지점 파이프라인. 각 단계에 파일:라인>
|
||||
|
||||
## 4. 발견 사항 & 개선 사항
|
||||
|
||||
| 우선순위 | 항목 | 현황(근거 파일:라인) | 개선안 |
|
||||
|---------|------|------|--------|
|
||||
| P0 | | | |
|
||||
| P1 | | | |
|
||||
| P2 | | | |
|
||||
|
||||
## 5. 불명확 — 확인 필요
|
||||
|
||||
| 항목 | 왜 확인 못 했는가 | 무엇을 보면 확정되는가 |
|
||||
|---|---|---|
|
||||
```
|
||||
@ -1,183 +0,0 @@
|
||||
---
|
||||
name: analyze-ptop-implementation
|
||||
description: ILSOS_PrismaticRD_PTOP의 구현 상세 분석. SeqAutoRunPTOP 시퀀스 로직, PLC/Laser/OCT/CellTracker 디바이스 호출 흐름, Rx.NET 메시지 체인, 상태 전이, 타이밍, 에러 처리를 분석하고 구현 개선안 제시. "PTOP 시퀀스 로직 분석", "PLC 통신 흐름 추적", "디바이스 호출 순서", "타이밍 다이어그램" 요청 시 사용. 구분 — 계층·의존성 구조는 `analyze-ptop-architecture`, 빌드/CI는 `optimize-ptop-build`, 셋을 함께 보려는 종합 요청은 `orchestrate-ptop-harness`. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
||||
---
|
||||
|
||||
# Analyze PTOP Implementation Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **구현 세부사항**을 분석하고 최적화 기회를 식별한다.
|
||||
|
||||
## 분석 영역
|
||||
|
||||
### 1단계: SeqAutoRunPTOP.cs 상태 머신 분석
|
||||
|
||||
**수집 대상:**
|
||||
- 상태 정의 (enum/class로 표현된 상태들)
|
||||
- 상태 진입 조건
|
||||
- 상태 내 액션 (동작)
|
||||
- 상태 종료 조건
|
||||
- 상태 전이 경로
|
||||
- 타임아웃 설정
|
||||
- 재시도 로직
|
||||
|
||||
**산출 형식: 상태 다이어그램**
|
||||
```
|
||||
[시작]
|
||||
↓ (전이 순서 — 시간축은 코드 상수 확인 후 기입)
|
||||
[초기화] → [준비] → [용접] → [완료] → [정리] → [대기]
|
||||
↓ ↓ ↓ ↓ ↓
|
||||
[에러 처리] ← ← ← ← ← ← ← ← ← ← ← ←
|
||||
```
|
||||
|
||||
### 2단계: 디바이스 호출 시퀀스 추적
|
||||
|
||||
각 상태에서:
|
||||
- 어떤 디바이스가 호출되는가?
|
||||
- 호출 순서는? (순차 vs 병렬)
|
||||
- 예상 소요시간?
|
||||
- 다음 상태로의 전이 신호는 어디서 오는가?
|
||||
|
||||
**추적 대상:**
|
||||
1. **PLC 호출**
|
||||
- 실제 API·주소는 `Device/PLC/PLCController.Logic.cs`와 `PLCController.Address.cs`에서 확인한다.
|
||||
PTOP은 원시 주소 문자열이 아니라 **enum 기반**(eBitInput/eBitOutput/eWordInput/eWordOutput)이다.
|
||||
- 읽기 / 쓰기 / 폴링 지점을 각각 `파일:라인`과 함께 기록
|
||||
- 주소·API 이름을 기억이나 추측으로 쓰지 말 것 — 반드시 소스에서 확인한 것만 적는다.
|
||||
|
||||
2. **Laser 제어**
|
||||
- 활성화 (SetPower, SetFrequency, etc.)
|
||||
- 대기
|
||||
- 정상 종료
|
||||
|
||||
3. **OCT 스캔**
|
||||
- 스캔 시작
|
||||
- 데이터 수집
|
||||
- 스캔 종료
|
||||
|
||||
4. **CellTracker**
|
||||
- 셀 추적 시작
|
||||
- 위치 업데이트
|
||||
- 추적 종료
|
||||
|
||||
**산출 형식: 타이밍 다이어그램**
|
||||
```
|
||||
Time <코드 상수 기준 눈금 — 실측이 아니면 눈금 대신 순서만 표기>
|
||||
State [<상태1>][<상태2>][<상태3>]
|
||||
PLC <호출> <호출>
|
||||
Laser <호출>
|
||||
OCT <호출>
|
||||
CellTrk <호출>
|
||||
```
|
||||
|
||||
> 축의 숫자는 **코드에서 읽은 지연 상수**이거나 **실측값**일 때만 넣는다.
|
||||
> 둘 다 아니면 눈금을 빼고 호출 순서만 그린다 — 없는 시간축을 그리면 병목 판단이 오염된다.
|
||||
|
||||
### 3단계: Rx.NET 메시지 체인 분석
|
||||
|
||||
**수집 대상:**
|
||||
- Observable 소스 (어디서 데이터가 나오는가?)
|
||||
- 변환 (Select, Map, Filter)
|
||||
- 구독자 (누가 소비하는가?)
|
||||
- 에러 처리 (OnError, Catch)
|
||||
|
||||
**기록 형식:** 실제 소스에서 발췌한 구독 체인을 그대로 인용하고 `파일:라인`을 붙인다.
|
||||
|
||||
```
|
||||
<발행 지점> — 파일:라인
|
||||
└─ <연산자 체인> — 파일:라인
|
||||
└─ <구독 지점> — 파일:라인
|
||||
```
|
||||
|
||||
> 이 스킬은 예시 코드를 제공하지 않는다. Aurora의 실제 이벤트 API(`EventPublisher`/`EventObservable`)는
|
||||
> `docs/Aurora에이전트레퍼런스모음/01_concepts/event.md`에서 확인하고 저장소 코드로 대조하라.
|
||||
> **그 폴더는 `.gitignore` 제외(로컬 전용)라 없을 수 있다** — 없으면 `External/Aurora/Aurora2.0_Guide.pdf`와
|
||||
> 소스 코드를 직접 대조한다.
|
||||
> 그럴듯한 가짜 체인을 적으면 이후 분석이 통째로 그 위에 쌓인다.
|
||||
|
||||
**산출 형식: 메시지 파이프라인 맵**
|
||||
|
||||
### 4단계: 에러 처리 로직
|
||||
|
||||
**찾아야 할 패턴:**
|
||||
- Try-Catch 블록
|
||||
- TimeoutException 처리
|
||||
- PLC 에러 응답 처리
|
||||
- 디바이스 오류 복구
|
||||
- 폴백 경로 (재시도, 초기화 재개, 강제 종료)
|
||||
|
||||
**각 에러에 대해:**
|
||||
- 감지 방법
|
||||
- 처리 방식
|
||||
- 복구 가능 여부
|
||||
- 사용자 개입 필요 여부
|
||||
|
||||
### 5단계: 성능/안정성 분석
|
||||
|
||||
**성능:**
|
||||
- 각 상태의 예상 소요시간
|
||||
- 전체 시퀀스 총 소요시간
|
||||
- 병목 구간 (가장 오래 걸리는 부분)
|
||||
- 최적화 기회 (병렬화 가능한가?)
|
||||
|
||||
**안정성:**
|
||||
- 데드락 가능성 (두 디바이스가 서로 대기?)
|
||||
- 타이밍 이슈 (신호 도착 순서 의존?)
|
||||
- 리소스 누수 (구독 취소 안 됨?)
|
||||
- 상태 불일치 (PLC와 소프트웨어 상태 차이?)
|
||||
|
||||
## 통합 산출물
|
||||
|
||||
### 최종 보고서: `_workspace/02_ptop_implementation.md`
|
||||
(**필수 산출물 2종**: `_workspace/02_ptop_implementation.md` · `_workspace/03_device_integration.md`)
|
||||
|
||||
보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
|
||||
|
||||
> **타이밍·주소·소요시간을 지어내지 않는다.** 코드 상수에서 읽은 값(`파일:라인` 병기)이나
|
||||
> 실측값만 적고, 둘 다 아니면 `미측정`이라고 쓴다.
|
||||
> **상태 전이·경합·인과를 코드로 확인하지 않고 서술하면 문장 앞에 `[추론]`을 붙인다**
|
||||
> (`rules.md` #15·#16). `미측정`(값 없음)과 축이 다르니 대체하지 말고 병기한다.
|
||||
> 주석이 그렇게 쓰여 있다는 것은 확인이 아니다 (#1) — 실제 코드 경로를 따라가야 표기를 뗄 수 있다.
|
||||
|
||||
## 입력 조건
|
||||
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
|
||||
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
|
||||
|
||||
|
||||
사용자가 다음 요청 시:
|
||||
- "PTOP 시퀀스 로직 상세 분석"
|
||||
- "SeqAutoRunPTOP이 PLC/Laser/OCT을 어떻게 제어하는가"
|
||||
- "PTOP 타이밍 분석"
|
||||
- "PTOP에서 에러가 발생하면 어떻게 처리되나"
|
||||
- "PTOP의 성능 병목은"
|
||||
|
||||
## 출력 결과
|
||||
|
||||
- 상태 머신 다이어그램
|
||||
- 타이밍 다이어그램 (시간축)
|
||||
- Rx.NET 메시지 흐름도
|
||||
- 에러 처리 매트릭스
|
||||
- 성능 프로파일
|
||||
- 최종 분석 보고서
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **코드 라인 번호 기록** — "Line 245의 try-catch" 형식으로 정확한 위치 기록
|
||||
2. **데이터 흐름 추적** — 변수, 반환값을 따라가며 이해
|
||||
3. **시간 측정** — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
|
||||
4. **예외 처리** — Exception 타입별로 분류
|
||||
5. **불명확한 부분 기록** — 추측 금지, 명시적으로 "불명확함" 표시
|
||||
6. **주석·변수명·함수명을 맹신하지 않는다** (`rules.md` #1) — 이름이 말하는 동작과 실제 구현이
|
||||
다른 사례가 이 저장소에 실재한다. 판단 근거는 항상 구현 본문이다.
|
||||
|
||||
> **단독 기동으로 `02`·`03`을 갱신했으면 stale 표기 의무는 네게 있다.** "구현만 다시" 같은 요청은
|
||||
> 이 스킬로도, `orchestrate-ptop-harness`로도 들어올 수 있는데 오케스트레이터 경유가 아니면 표기할 주체가 없다.
|
||||
> 갱신한 파일 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)` 을 적고, 의존 관계인 `01`이 낡았으면
|
||||
> `01` 첫 줄에 `이전 실행 결과 재사용 — 정합성 미확인(YYYY-MM-DD)` 을 남긴다
|
||||
> (문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
|
||||
|
||||
> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
||||
>
|
||||
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
||||
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|
||||
@ -1,56 +0,0 @@
|
||||
# 보고서 템플릿 — `_workspace/02_ptop_implementation.md`
|
||||
|
||||
> 이 골격을 채워 통합 보고서를 만든다.
|
||||
>
|
||||
> **수치를 지어내지 않는다.** 타이밍·주소·소요시간은 두 가지만 허용한다 —
|
||||
> ① 코드 상수에서 읽은 값(반드시 `파일:라인` 병기), ② 실제 측정값(측정 방법 병기).
|
||||
> 둘 다 아니면 `미측정`이라고 쓴다. 아래 `<...>`는 전부 채워야 할 자리이며,
|
||||
> 그럴듯한 예시 숫자로 메우면 이후 최적화 판단이 오염된다.
|
||||
|
||||
```markdown
|
||||
# PTOP 구현 분석 보고서
|
||||
|
||||
## 1. 상태 머신
|
||||
|
||||
<상태 목록 · 전이 조건 · 전이 트리거. 각 항목에 파일:라인>
|
||||
|
||||
## 2. 디바이스 호출 시퀀스
|
||||
|
||||
### <상태A> → <상태B> 전이
|
||||
- <호출 순서 1>: <API> — 출처: `<파일>:<라인>`
|
||||
- <호출 순서 2>: <API> — 출처: `<파일>:<라인>`
|
||||
- 전이 조건: <조건> — 출처: `<파일>:<라인>`
|
||||
|
||||
| 단계 | 디바이스 | 호출 | 지연 상수 | 출처(파일:라인) |
|
||||
|---|---|---|---|---|
|
||||
| | | | 코드값 또는 `미측정` | |
|
||||
|
||||
## 3. Rx.NET 메시지 흐름
|
||||
|
||||
<발행 → 필터 → 변환 → 구독 파이프라인. 각 단계 파일:라인>
|
||||
|
||||
## 4. 에러 처리
|
||||
|
||||
| 에러 유형 | 감지 방법 | 처리 방식 | 복구 가능 | 출처(파일:라인) |
|
||||
|---------|---------|---------|---------|---|
|
||||
|
||||
## 5. 성능 프로파일
|
||||
|
||||
| 구간 | 소요시간 | 근거(코드 상수 / 실측 / 미측정) | 최적화 기회 |
|
||||
|------|---------|---|----------|
|
||||
|
||||
> 실제로 측정하지 않았다면 소요시간 칸에 `미측정`이라고 쓴다.
|
||||
|
||||
## 6. 발견 사항
|
||||
|
||||
### P0 (심각)
|
||||
- <내용> — 근거: `<파일>:<라인>`
|
||||
|
||||
### P1 (중요)
|
||||
### P2 (개선)
|
||||
|
||||
## 7. 불명확 — 확인 필요
|
||||
|
||||
| 항목 | 왜 확인 못 했는가 | 무엇을 보면 확정되는가 |
|
||||
|---|---|---|
|
||||
```
|
||||
Binary file not shown.
@ -1,49 +0,0 @@
|
||||
---
|
||||
name: doyeon_note
|
||||
description: 도연님의 작업일지를 기록합니다. "/doyeon_note <내용>" 형태로 호출하면 docs/작업일지/yyyy_mm_dd.md 파일에 오늘 날짜로 내용을 추가합니다. 작업일지 기록, 일지 작성, 노트 추가 요청 시 사용. 구분 — 결과를 PaJu todolist 사이트에 게시하는 것은 `todo-summary`, 이 스킬은 `docs/작업일지/` 로컬 md 기록 전용이다.
|
||||
---
|
||||
|
||||
# doyeon_note — 작업일지 기록 스킬
|
||||
|
||||
사용자가 말한 내용을 `docs/작업일지/yyyy_mm_dd.md` 파일에 기록합니다.
|
||||
|
||||
## 동작 절차
|
||||
|
||||
1. **오늘 날짜 확인**: 시스템의 현재 날짜를 `yyyy_mm_dd` 형식으로 만든다.
|
||||
(컨텍스트에 `currentDate`가 있으면 그 값을 사용. 없으면 `date +%Y_%m_%d` 실행)
|
||||
|
||||
2. **대상 파일 경로**: `docs/작업일지/<yyyy_mm_dd>.md`
|
||||
|
||||
3. **내용 정리**: 사용자가 `args`로 전달한 내용을 작업일지 항목으로 정리한다.
|
||||
- 단순 한 줄이면 그대로 한 항목으로.
|
||||
- 여러 작업/생각이 섞여 있으면 자연스럽게 불릿(`-`)으로 나눈다.
|
||||
- 사용자가 적은 의도/뉘앙스는 보존하고, 임의로 내용을 지어내지 않는다.
|
||||
|
||||
4. **파일 기록**:
|
||||
- 파일이 **없으면** 아래 템플릿으로 새로 만든다.
|
||||
- 파일이 **있으면** 기존 내용을 Read한 뒤, 맨 아래에 새 항목을 이어 붙인다(append). 기존 내용은 절대 지우지 않는다.
|
||||
- 같은 날 여러 번 호출되면 시각(`HH:MM`) 소제목을 붙여 구분한다.
|
||||
|
||||
5. 기록 후, 어떤 파일에 무엇을 추가했는지 한 줄로 사용자에게 알린다.
|
||||
|
||||
> **규약 바인딩.** **덮어쓰기가 되는 상황이면 먼저 승인받는다** (`rules.md` #2) — 정상 경로는 append라
|
||||
> 승인이 필요 없지만, 기존 파일을 재작성하거나 항목을 지우게 되면 무엇이 사라지는지 먼저 보고한다.
|
||||
> 파일은 **UTF-8**로 쓴다 — 한글이 깨지면 안 된다 (`rules.md` #3).
|
||||
> 작업일지 1건이 200줄을 넘으면 분할하고 상대경로로 링크한다 (`rules.md` #4).
|
||||
> 사용자가 말하지 않은 내용을 채우지 않는다 (#9). 사용자 발언을 옮긴 것과 **네가 해석한 것을 섞지 말고**,
|
||||
> 해석은 문장 앞에 `[추론]`을 붙인다 (#15·#16) — 작업일지는 나중에 사실 기록으로 인용된다.
|
||||
|
||||
## 새 파일 템플릿
|
||||
|
||||
```markdown
|
||||
# 작업일지 — yyyy-mm-dd
|
||||
|
||||
## HH:MM
|
||||
- (항목)
|
||||
```
|
||||
|
||||
## 주의
|
||||
|
||||
- `args`가 비어 있으면 무엇을 기록할지 사용자에게 한 줄로 물어본다.
|
||||
- 날짜/파일명 형식은 반드시 `yyyy_mm_dd`를 지킨다.
|
||||
- 작업일지는 사용자의 기록이므로, 내용을 요약·각색하지 말고 사용자의 표현을 최대한 살린다.
|
||||
@ -1,183 +0,0 @@
|
||||
---
|
||||
name: optimize-ptop-build
|
||||
description: ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 CI/CD 자동화. 멀티 구성 빌드(Debug/Release — Simulation·UserDefineUnit은 sln에서 Release로 매핑되어 별도 구성이 아니다) 분석, 의존성 최적화, 빌드 시간 단축, CI/CD 파이프라인 설계. "빌드 최적화", "PTOP 빌드 성능", "CI/CD 자동화 설계", "배포 파이프라인" 요청 시 사용. 구분 — 계층 구조는 `analyze-ptop-architecture`, 시퀀스 내부 로직은 `analyze-ptop-implementation`, 셋을 함께 보려는 종합 요청은 `orchestrate-ptop-harness`. 이 스킬은 분석·제안 전용이며 프로젝트 파일을 수정하지 않는다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
||||
---
|
||||
|
||||
# Optimize PTOP Build Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **빌드 성능 및 자동화**를 최적화한다.
|
||||
|
||||
## 분석 영역
|
||||
|
||||
### 1단계: 현재 빌드 상태 분석
|
||||
|
||||
**수집 대상:**
|
||||
- 솔루션 내 프로젝트 목록 (ILSOS_All.sln)
|
||||
- PTOP이 참조하는 프로젝트
|
||||
- 각 프로젝트의 빌드 시간 측정
|
||||
|
||||
**측정 방법:**
|
||||
|
||||
`msbuild`는 **PATH에 없을 수 있다.** 먼저 탐색하고, 못 찾으면 측정을 포기하되 그 사실을 명시한다.
|
||||
|
||||
```bash
|
||||
# 1) PATH 확인
|
||||
command -v msbuild MSBuild.exe
|
||||
|
||||
# 2) 없으면 vswhere로 탐색 (VS 2022 설치 시)
|
||||
"/c/Program Files (x86)/Microsoft Visual Studio/Installer/vswhere.exe" \
|
||||
-latest -products '*' -find 'MSBuild/**/Bin/MSBuild.exe'
|
||||
|
||||
# 3) 찾았으면 구성별 측정 (time으로 소요시간 확보)
|
||||
time "<MSBUILD>" ILSOS_All.sln -p:Configuration=Release -p:Platform=x64
|
||||
```
|
||||
|
||||
> **셋 다 실패하면** 2개 구성의 시간 칸을 전부 `미측정`으로 확정하고,
|
||||
> 보고서 "미측정·미검증"에 "MSBuild 미탐색 — 빌드 시간 측정 불가"를 사유와 함께 남긴다.
|
||||
> 추정치를 채우지 않는다. 이 하네스는 빌드를 **실행만** 하고 프로젝트 파일을 고치지 않는다.
|
||||
|
||||
**수집 항목:** (§3단계 참조 — PTOP의 실질 구성은 2개다)
|
||||
| 구성 | 총 소요시간 | 병목 프로젝트 (상위 3) | 캐시 효율 |
|
||||
|------|-----------|------------------|---------|
|
||||
| Debug\|x64 | ? | ? | ? |
|
||||
| Release\|x64 | ? | ? | ? |
|
||||
|
||||
> `Simulation|x64`·`UserDefineUnit|x64`는 `ILSOS_All.sln:413-416`에서 PTOP이 `Release|x64`로
|
||||
> 매핑되어 **바이너리가 동일**하다. 별도 측정 대상이 아니므로 표에 행을 만들지 않는다.
|
||||
|
||||
### 2단계: 의존성 분석
|
||||
|
||||
**PTOP의 최소 필수 의존성 파악:**
|
||||
|
||||
의존성 트리를 **소스에서 직접 만든다.** 미리 적힌 필수/선택 판정을 그대로 옮기지 않는다 —
|
||||
잘못된 판정을 따라 참조를 지우면 빌드가 깨진다.
|
||||
|
||||
1. `Machines/ILSOS_PrismaticRD_PTOP/*.csproj`의 `<ProjectReference>` / `<Reference>` 전수 수집
|
||||
2. 각 참조에 대해 **심볼이 실제로 쓰이는지 검색** (`using` 문만으로 판단하지 말 것 — 죽은 using이 있다)
|
||||
3. 판정 근거를 기록: `필수 — <어느 코드가 쓰는가 파일:라인>` / `미사용 후보 — <검색 결과>`
|
||||
|
||||
| 참조 | 종류 | 사용 근거(파일:라인) | 판정 | 제거 시 위험 |
|
||||
|---|---|---|---|---|
|
||||
| | ProjectReference / NuGet | | 필수 / 미사용 후보 / 불명확 | |
|
||||
|
||||
**분석 시 주의:**
|
||||
- 조건부 컴파일 심볼로만 쓰이는 참조가 있는지 확인한다. 단 **이 프로젝트의 `DefineConstants`는
|
||||
`DEBUG;TRACE` / `TRACE`뿐이고 `#if SIMULATION` 류는 0건**이므로(csproj 확인), 새 심볼을 가정하지 말 것.
|
||||
- 리플렉션·DI 등록으로만 쓰이면 정적 검색에 안 잡힌다. `EquipmentSetup.cs`의 디바이스 등록부를 반드시 확인한다.
|
||||
|
||||
**산출물:** `_workspace/04a_dependency_analysis.csv`
|
||||
|
||||
### 3단계: 빌드 구성별 최적화
|
||||
|
||||
#### Debug|x64 최적화
|
||||
- 기호 생성 필요 (유지)
|
||||
- 최적화 비활성화 (유지)
|
||||
- 증분 빌드 활용
|
||||
|
||||
#### Release|x64 최적화
|
||||
`.csproj`는 **legacy 형식 + .NET Framework 4.8.1**이다. `PublishTrimmed`·`TieredCompilation`·
|
||||
`DebugType=embedded` 같은 SDK 스타일(.NET Core/5+) 속성은 **동작하지 않는다.** 제안 전에
|
||||
해당 속성이 이 프로젝트 형식에서 유효한지 먼저 확인하라.
|
||||
|
||||
#### Simulation|x64 / UserDefineUnit|x64 — 별도 컴파일 구성이 아니다
|
||||
`ILSOS_All.sln:413-416`에서 PTOP(`{8BB07B4C-…}`)의 `Simulation|x64`·`UserDefineUnit|x64`가
|
||||
`Release|x64`로 매핑된다. 즉 PTOP은 **Release와 동일한 바이너리**이며 출력도 `x64-Release/`다.
|
||||
**다만 솔루션의 다른 프로젝트 상당수는 `Simulation|x64 → Debug|x64`이므로**
|
||||
최소 빌드 집합을 논할 때 프로젝트별 매핑을 각각 확인해야 한다.
|
||||
|
||||
시뮬레이션은 조건부 컴파일이 아니라 **런타임 플래그**로 갈린다 —
|
||||
`Device/PLC/PLCContoller.Config.cs`의 `isSimul` 계열. `Machines/` 전체에 `#if SIMULATION`은 0건이고
|
||||
`DefineConstants`는 `DEBUG;TRACE` / `TRACE`뿐이다(csproj 확인).
|
||||
|
||||
> 이 사실을 모르고 "Simulation 구성만 따로 최적화"를 제안하면 존재하지 않는 빌드를 대상으로
|
||||
> 삼게 된다. 구성별 차이를 논하기 전에 sln의 `ActiveCfg` 매핑을 먼저 읽어라.
|
||||
|
||||
### 4단계: CI/CD 파이프라인 설계
|
||||
|
||||
**목표:**
|
||||
- 자동 빌드 (commit, PR)
|
||||
- 자동 테스트 — **Simulation은 별도 구성이 아니므로**(§3단계) 테스트 잡을 Simulation 구성으로 나누지 않는다.
|
||||
시뮬 동작은 런타임 `isSimul` 플래그로 켠다.
|
||||
- 자동 배포 (수동 승인)
|
||||
|
||||
**추천 플랫폼:**
|
||||
- GitHub Actions (GitHub 저장소 사용 중 가정)
|
||||
- Azure Pipelines (Microsoft 클라우드)
|
||||
- Jenkins (온프레미스)
|
||||
|
||||
**파이프라인 구조:** [references/cicd-pipeline-template.yml](references/cicd-pipeline-template.yml)
|
||||
를 시작점으로 삼아 `_workspace/05_cicd_pipeline.yml`에 프로젝트 맞춤 버전을 쓴다.
|
||||
|
||||
> 템플릿은 **미검증 초안**이다. 실제로 러너에서 돌려본 적이 없으므로, 검증 없이
|
||||
> "CI/CD 설계 완료"라고 보고하지 않는다. 검증 여부를 보고서에 명시한다.
|
||||
|
||||
### 5단계: 배포 패키징
|
||||
|
||||
**산출물:**
|
||||
- 실행 가능 파일 (Aurora.exe)
|
||||
- 필수 DLL (AuroraDevices, WeldingComponents, etc.)
|
||||
- 설정 파일 (app.config)
|
||||
- 리소스 파일 (이미지, 데이터)
|
||||
- 배포 설명서
|
||||
|
||||
**패키징 형식:**
|
||||
- ZIP 아카이브 (간단)
|
||||
- NSIS 설치 프로그램 (사용자 친화적)
|
||||
- Chocolatey 패키지 (자동 업데이트)
|
||||
|
||||
## 통합 산출물
|
||||
|
||||
### 최종 보고서: `_workspace/06_ptop_build_optimization.md`
|
||||
(보조 산출물: `_workspace/04_build_analysis.md`, `_workspace/05_cicd_pipeline.yml`)
|
||||
|
||||
보고서 골격은 [references/report-template.md](references/report-template.md) 참조.
|
||||
|
||||
> **빌드 시간·크기·개선율을 지어내지 않는다.** 실제로 측정했을 때만 수치를 적고 측정 명령어를
|
||||
> 병기한다. 측정하지 않았으면 `미측정`이라고 쓴다.
|
||||
> **"이 의존은 제거 가능해 보인다" 같은 미검증 판단에는 `[추론]`을 붙인다** (`rules.md` #15·#16).
|
||||
> 심볼 참조를 실제로 검색해 확인한 뒤에만 표기를 떼고 근거를 병기한다.
|
||||
> `미측정`(측정 못 함)과 축이 다르니 대체하지 말고 필요하면 병기한다.
|
||||
|
||||
## 입력 조건
|
||||
> **단독 호출 시**: 생성할 `_workspace/` 파일 목록을 사용자에게 제시하고 승인받은 뒤 시작한다
|
||||
> (`rules.md` #2). 오케스트레이터(`orchestrate-ptop-harness`)를 통해 호출된 경우는 이미 승인을 받았으므로 생략한다.
|
||||
|
||||
|
||||
사용자 요청 시:
|
||||
- "PTOP 빌드 최적화"
|
||||
- "빌드 시간 단축"
|
||||
- "CI/CD 파이프라인 설계"
|
||||
- "배포 자동화"
|
||||
- "Release 빌드 성능"
|
||||
|
||||
## 출력 결과
|
||||
|
||||
- 빌드 성능 분석 보고서
|
||||
- 의존성 맵핑 CSV
|
||||
- CI/CD 파이프라인 (YAML/JSON)
|
||||
- 빌드 최적화 설정 (PropertyGroup)
|
||||
- 배포 패키징 스크립트
|
||||
- 최종 보고서
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **.NET Framework 4.8.1 호환성** — 최신 .NET 기능 사용 불가
|
||||
2. **Visual Studio 2022 기준** — MSBuild 경로 확인
|
||||
3. **Windows 플랫폼 전용** — x64 아키텍처 명시
|
||||
4. **빌드 머신 사양** — CI 환경의 OS/RAM 확인
|
||||
5. **라이선스 확인** — NuGet 패키지, 외부 도구의 라이선스
|
||||
6. **주석·프로퍼티명을 맹신하지 않는다** (`rules.md` #1) — 구성 이름(`Simulation`·`UserDefineUnit`)이
|
||||
별도 컴파일을 뜻하지 않는 것이 그 예다. 판단 근거는 `.sln`·`.csproj` 실제 매핑이다.
|
||||
|
||||
> **단독 기동으로 `04`~`06`을 갱신했으면 stale 표기 의무는 네게 있다.** "빌드 분석만 다시"는
|
||||
> `docs/harness-ptop.md` 가 후속 트리거로 열거한 발화라 이 스킬로 직접 들어올 수 있고,
|
||||
> 그때는 오케스트레이터가 표기해 주지 않는다. 갱신한 파일 첫 줄에 `이번 실행에서 갱신됨(YYYY-MM-DD)`,
|
||||
> 재사용한 기존 산출물 첫 줄에 `이전 실행 결과 재사용 — 정합성 미확인(YYYY-MM-DD)` 을 남긴다
|
||||
> (문구 3종 → `orchestrate-ptop-harness/references/data-protocol.md`).
|
||||
|
||||
> 이 스킬은 10분을 넘긴다 — **단계 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
||||
>
|
||||
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
||||
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|
||||
@ -1,47 +0,0 @@
|
||||
# .github/workflows/ptop-build.yml
|
||||
name: PTOP Build & Deploy
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main, develop]
|
||||
paths: ['Machines/ILSOS_PrismaticRD_PTOP/**']
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
config: [Debug, Release] # Simulation/UserDefineUnit은 sln에서 Release로 매핑되므로 중복
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
- name: Setup .NET Framework
|
||||
uses: microsoft/setup-msbuild@v2
|
||||
- name: Setup NuGet
|
||||
uses: nuget/setup-nuget@v2
|
||||
- name: Restore NuGet
|
||||
run: nuget restore ILSOS_All.sln
|
||||
- name: Build (${{ matrix.config }})
|
||||
run: msbuild ILSOS_All.sln /p:Configuration=${{ matrix.config }} /p:Platform=x64
|
||||
- name: Upload Artifacts
|
||||
uses: actions/upload-artifact@v4
|
||||
with:
|
||||
name: ptop-${{ matrix.config }}
|
||||
path: Machines/_out_prismatic_rd_ptop/x64-${{ matrix.config }}/
|
||||
# 주의: Simulation/UserDefineUnit을 matrix에 넣으면 출력은 x64-Release/ 이므로 경로가 어긋난다
|
||||
|
||||
deploy:
|
||||
needs: build
|
||||
runs-on: windows-latest
|
||||
if: github.ref == 'refs/heads/main'
|
||||
environment: production # 수동 승인 필수
|
||||
steps:
|
||||
- name: Download Release Artifact
|
||||
uses: actions/download-artifact@v4
|
||||
with:
|
||||
name: ptop-Release
|
||||
- name: Create Release Package
|
||||
run: echo 'TODO 패키징 스크립트'
|
||||
- name: Deploy to Server
|
||||
run: echo 'TODO 배포 스크립트'
|
||||
@ -1,57 +0,0 @@
|
||||
# 보고서 템플릿 — `_workspace/06_ptop_build_optimization.md`
|
||||
|
||||
> 이 골격을 채워 통합 보고서를 만든다.
|
||||
>
|
||||
> **빌드 시간·크기·개선율을 지어내지 않는다.** 실제로 빌드를 돌려 측정했을 때만 수치를 적고,
|
||||
> 측정 방법(명령어)을 함께 남긴다. 측정하지 않았으면 `미측정`이라고 쓴다.
|
||||
> 그럴듯한 숫자가 보고서에 남으면 이후 최적화 우선순위 판단이 통째로 오염된다.
|
||||
|
||||
```markdown
|
||||
# PTOP 빌드 최적화 보고서
|
||||
|
||||
## 1. 현재 빌드 성능
|
||||
|
||||
| 구성 | 시간 | 측정 방법 | 병목 | 개선 가능성 |
|
||||
|------|------|---|------|----------|
|
||||
| Debug\|x64 | <측정값 또는 미측정> | <명령어> | | |
|
||||
| Release\|x64 | | | | |
|
||||
|
||||
> `Simulation`·`UserDefineUnit`은 sln에서 `Release|x64` 매핑 — 별도 행을 만들지 않는다.
|
||||
|
||||
> 한 건도 측정하지 못했으면 표 전체를 `미측정`으로 두고, 그 사실을 §6에 명시한다.
|
||||
|
||||
## 2. 의존성 최적화
|
||||
|
||||
### 필수 의존성
|
||||
| 프로젝트 | 왜 필수인가 | 근거(파일:라인) |
|
||||
|---|---|---|
|
||||
|
||||
### 제거 가능 후보
|
||||
| 프로젝트 | 왜 불필요해 보이는가 | 근거 | 제거 시 위험 |
|
||||
|---|---|---|---|
|
||||
|
||||
> "참조되지 않는 것 같다"는 근거가 아니다. 실제로 심볼 참조를 검색해 확인한 결과만 적는다.
|
||||
|
||||
## 3. 빌드 구성별 최적화 전략
|
||||
|
||||
### Debug / Release
|
||||
- 현황: <근거와 함께>
|
||||
- 개선안: <구체적 설정 변경>
|
||||
- 예상 효과: <측정 기반이면 수치, 아니면 "미측정 — 적용 후 재측정 필요">
|
||||
|
||||
## 4. CI/CD 파이프라인
|
||||
|
||||
<`_workspace/05_cicd_pipeline.yml` 참조. 여기엔 설계 의도와 트리거 조건만 요약>
|
||||
|
||||
## 5. 배포 패키징
|
||||
|
||||
<포함 파일 목록 · 패키징 절차. 제안 단계이며 실제 스크립트 실행은 하지 않는다>
|
||||
|
||||
## 6. 미측정·미검증 항목
|
||||
|
||||
| 항목 | 왜 확인 못 했는가 | 무엇을 하면 확정되는가 |
|
||||
|---|---|---|
|
||||
```
|
||||
|
||||
> **이 스킬은 분석·제안 전용이다.** `.csproj`·`.sln`·소스를 수정하지 않는다.
|
||||
> 변경안은 diff 제안으로만 제시하고, 적용 여부는 사용자가 결정한다.
|
||||
@ -1,200 +0,0 @@
|
||||
---
|
||||
name: orchestrate-ptop-harness
|
||||
description: >-
|
||||
ILSOS_PrismaticRD_PTOP 분석 팀의 오케스트레이터. 3명(ptop-lead, ptop-developer,
|
||||
build-devops-engineer)을 기동해 3계층 아키텍처·구현 상세·빌드 최적화를 분석하고
|
||||
(lead·build는 병렬, developer는 lead 완료 후 순차)
|
||||
통합 보고서를 만든다. "PTOP 프로젝트 종합 분석", "PTOP 전체 점검", "PTOP 하네스 시작",
|
||||
"PTOP 팀 조율", "PTOP 구조 파악", 그리고 **PTOP 분석에 대한** 후속 표현("PTOP 재분석",
|
||||
"PTOP 다시 점검", "아키텍처만 다시", "빌드 분석만 다시", "이전 분석 결과 기반으로") 시 이 스킬을 쓴다.
|
||||
구분 — 단일 영역만 필요하면 개별 스킬(analyze-ptop-architecture / analyze-ptop-implementation /
|
||||
optimize-ptop-build)을, **산출물 문서**를 만들거나 갱신하는 요청("산출물 업데이트/재생산")은
|
||||
ptop-deliverables·ubisam-deliverable-rebuild·ubisam-deliverables를, 코드를 실제로 고치는 작업은
|
||||
code_Agent를 쓴다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상을 먼저 확인한다.
|
||||
---
|
||||
|
||||
# Orchestrate PTOP Harness
|
||||
|
||||
`ILSOS_PrismaticRD_PTOP`의 **아키텍처 · 구현 · 빌드**를 세 전문가가 병렬 분석해 통합 보고서를 만든다.
|
||||
이 하네스는 **읽기·분석 전용**이다. 소스 코드를 수정하지 않는다.
|
||||
|
||||
## 실행 모드
|
||||
|
||||
**서브 에이전트 병렬 + 의존 순차.** 이 환경에는 `TeamCreate`/`TeamDelete` 도구가 **없으므로**
|
||||
아래 도구로 팀을 구성한다.
|
||||
|
||||
| 목적 | 도구 |
|
||||
|---|---|
|
||||
| 팀원 기동 | `Agent` — `subagent_type`에 에이전트 이름, `model: "opus"`, 병렬 구간은 `run_in_background: true` |
|
||||
| 팀원 간 소통 | `SendMessage` — `to`에 에이전트 **이름**, `summary`(5~10단어)는 **필수**, `message`는 본문 |
|
||||
| 진행 공유 | `_workspace/_progress.md` (진실원) + `TaskCreate`/`TaskUpdate`(가용 시 보조) |
|
||||
| 산출물 전달 | 파일 — `_workspace/` |
|
||||
|
||||
```
|
||||
[오케스트레이터]
|
||||
Phase 1 컨텍스트 확인
|
||||
Phase 2 ptop-lead + build-devops-engineer 병렬 기동
|
||||
Phase 3 lead 산출 완료 → ptop-developer 기동 (아키텍처 결과 의존)
|
||||
Phase 4 결과 수집 · 상충 조정
|
||||
Phase 5 통합 보고서 작성
|
||||
```
|
||||
|
||||
## 팀 구성
|
||||
|
||||
| 에이전트 | 담당 | 사용 스킬 | 산출 (에이전트 정의와 일치) |
|
||||
|---|---|---|---|
|
||||
| `ptop-lead` | 3계층 아키텍처·디바이스 스택·시퀀스 의존성 | `analyze-ptop-architecture` | `01_ptop_architecture.md` |
|
||||
| `ptop-developer` | 시퀀스 상태머신·타이밍·Rx 체인·에러 처리 | `analyze-ptop-implementation` | `02_ptop_implementation.md`, `03_device_integration.md` |
|
||||
| `build-devops-engineer` | 멀티 구성 빌드·의존성·CI/CD | `optimize-ptop-build` | `04_build_analysis.md`, `05_cicd_pipeline.yml`, `06_ptop_build_optimization.md` |
|
||||
|
||||
모두 `_workspace/` 하위이며 `model: "opus"`로 기동한다. 파일명은 각 에이전트 정의의
|
||||
`입력/출력 프로토콜` 절이 진실원이며, 바꿀 때는 **에이전트 정의·담당 스킬·이 표를 함께** 고친다.
|
||||
|
||||
> **진행 원장은 `_workspace/_progress.md` 파일이다.** `TaskCreate`/`TaskUpdate`는 메인 루프에서는
|
||||
> 쓸 수 있지만 **서브에이전트 컨텍스트에는 없을 수 있어**, 도구 가용 여부와 무관하게 동작하도록
|
||||
> 파일을 진실원으로 둔다. 표 형식 → [references/data-protocol.md](references/data-protocol.md)
|
||||
|
||||
## Phase 1: 컨텍스트 확인
|
||||
|
||||
0. **대상 확인.** 발화에 **PTOP 분석 대상이 명시돼 있지 않으면** 어떤 Phase도 시작하지 말고 되묻는다.
|
||||
맨손 "다시 실행"·"업데이트"·"보완"처럼 대상 없는 발화와, "산출물" 같은 타 하네스 어휘가 섞인
|
||||
발화가 **각각 독립적으로** 걸린다(둘 다일 필요 없다). 그냥 진행하면 기존 산출물이 이동될 수 있다.
|
||||
1. `_workspace/`(**저장소 루트 기준.** Ubisam 하네스의 `docs/[Ubisam산출물]/_workspace/`와 다른 곳)의
|
||||
**산출물 `01`~`06` 존재 여부**와 **요청 범위** 두 축으로 판별한다(폴더만 보면 오판정한다):
|
||||
없음→**`초기`** / 일부+전체요청→**`이어서`** / 특정영역요청→**`부분`** / "처음부터 다시"→**`전면`**
|
||||
|
||||
네 모드의 이름은 **`초기` / `이어서` / `부분` / `전면`** 이며, 이 문자열 그대로 전달한다(§Phase 2).
|
||||
**판별 기준·기동 범위·생략의 파급 → [references/mode-rules.md](references/mode-rules.md)**
|
||||
2. **에이전트 가용성 확인.** `ptop-lead` / `ptop-developer` / `build-devops-engineer`가
|
||||
`Agent` 도구의 subagent_type 목록에 있는지 먼저 본다. 없으면 **어떤 Phase도 시작하지 말고**
|
||||
"프로젝트 에이전트 미등록 — 세션 재시작 필요"를 사용자에게 보고하고 중단한다.
|
||||
`.claude/agents/`에 파일을 새로 추가·이동한 직후에는 **세션이 재시작돼야 등록된다.**
|
||||
파일이 있다는 것과 호출 가능하다는 것은 다르다.
|
||||
3. `docs/architecture.md`로 프로젝트 사실을 확보한다.
|
||||
4. **승인 게이트.** 아래 **넷을 한 번에** 제시하고 승인받는다 (`rules.md` #2) —
|
||||
① **이동·삭제분**(전면 재실행이면 `_workspace/` → `_workspace_prev/` 이동. 1번에서 스스로
|
||||
"되돌리기 어려운 이동"이라 경고한 그 동작이다) ② 덮어쓰기분 ③ 생성분
|
||||
④ **작업공간 관리 파일**(`_workspace/` 폴더 생성, `_progress.md`, 단계별 중간 로그,
|
||||
**재사용 산출물의 stale 첫 줄 편집** — §후속 작업의 표기 의무가 기존 파일을 고치므로 승인 대상이다).
|
||||
④를 빼면 에이전트가 자기 작업 로그조차 승인 범위 밖이 되어 쓸 수 없다.
|
||||
모드 판별을 승인보다 먼저 하는 이유는, 그러지 않으면 승인 목록이 실제 변경 범위와 어긋나기 때문이다.
|
||||
생성분 목록은 —
|
||||
통합 산출 `01~06` + `00_PTOP_HARNESS_SUMMARY.md` + **부산출물** `01a~01e`(analyze-ptop-architecture)·
|
||||
`04a_dependency_analysis.csv`(optimize-ptop-build) —
|
||||
승인을 받은 뒤 Phase 2로 간다 (`rules.md` #2 — 수정은 무조건 승인받기).
|
||||
5. `_workspace/_progress.md`를 만들고 **에이전트 3인 전원의 행**을 초기화한다. 상태 enum은
|
||||
**`진행중`/`완료`/`실패`/`생략` 4종**(정의 → `references/data-protocol.md` §진행 원장).
|
||||
**이번 실행에서 기동하지 않는 에이전트는 모드와 무관하게 `생략 — 이전 산출물 재사용`** 으로
|
||||
적는다 — `이어서`의 건너뜀도, `부분`에서 지목되지 않은 것도 같다(§Phase 2·3·4가 이 값을 읽는다).
|
||||
`TaskCreate`가 가용하면 함께 등록하고 02는 01에 `addBlockedBy`를 건다 — 미지원이면
|
||||
**Phase 3의 파일 존재 판정으로 대체**한다(의존성 표현이 없어도 완료 판정은 관측 가능하다).
|
||||
|
||||
## Phase 2: 병렬 분석 (lead + build)
|
||||
|
||||
`ptop-lead`와 `build-devops-engineer`는 서로 의존이 없다 → `run_in_background: true`로 **동시** 기동.
|
||||
|
||||
먼저 `_workspace/`가 없으면 만든다. 각 에이전트에 전달할 것:
|
||||
- 담당 스킬을 **저장소 루트 기준 절대경로**로 전달한다 — `<REPO>/.claude/skills/<스킬명>/SKILL.md`.
|
||||
이름만 주면 서브에이전트가 경로를 스스로 찾아야 한다.
|
||||
- **산출 파일 경로**와 **진행 원장 `_workspace/_progress.md`** 를 모두 **저장소 루트 기준 절대경로**로 전달 —
|
||||
서브에이전트 셸 cwd는 호출마다 초기화되므로 상대경로는 엉뚱한 곳에 떨어진다. 산출물이 유실되면
|
||||
Phase 3 완료 판정이 "파일 없음 → 실패"로 오판하고, 원장이 흩어지면 "최대 2회" 상한이 무력화된다.
|
||||
- "모든 주장에 `파일:라인` 근거를 붙일 것"
|
||||
- **실행 모드(초기 / 이어서 / 부분 / 전면 — 4종).** 팀원은 이 값을 **기존 산출물을 재사용할지**
|
||||
판단에만 쓴다. **`_workspace_prev/` 이동은 오케스트레이터 전담이며 Phase 1에서 이미 끝났다** —
|
||||
팀원이 한 번 더 옮기면 병렬로 쓰이던 산출물이 딸려간다.
|
||||
|
||||
> **기동 축소 기준은 모드마다 다르다**(원장에 `생략` 을 적는 것은 §Phase 1-5 대로 공통):
|
||||
> **`이어서`**=담당 산출물이 이미 있으면 / **`부분`**=지목되지 않았으면 / **`초기`·`전면`**=전원 기동.
|
||||
> ⚠ `부분` 에서 **산출물 유무는 기준이 아니다** — 있다는 이유로 생략하면 재기동 대상이 곧 생략
|
||||
> 대상이 되어 **아무도 기동되지 않는다**.
|
||||
>
|
||||
> **생략한 에이전트는 완료 알림을 보내지 않으므로** `_progress.md`에 `생략 — 이전 산출물 재사용` 으로
|
||||
> 기록하고 §Phase 3·4의 판정을 바꾼다 → [references/mode-rules.md](references/mode-rules.md)
|
||||
|
||||
## Phase 3: 의존 분석 (developer)
|
||||
|
||||
`ptop-lead`의 `01_ptop_architecture.md` 완성 후 `ptop-developer`를 기동한다.
|
||||
구현 분석이 아키텍처가 정의한 계층 경계를 기준으로 이뤄져야 하기 때문이다.
|
||||
**단 developer 자신이 생략 대상이면 기동하지 않는다 — 아래 "developer 자신을 생략하는 경우"를 먼저 판정한다.**
|
||||
|
||||
**완료 판정(관측 가능해야 한다):** 먼저 lead의 **백그라운드 완료 알림을 기다린다.**
|
||||
알림이 온 뒤 `_workspace/01_ptop_architecture.md`가 존재하고 "불명확 — 확인 필요" 절까지
|
||||
채워져 있으면 완료로 본다. 알림은 왔는데 파일이 없으면 1회만 재확인하고, 그래도 없으면 실패로 처리한다.
|
||||
**알림 전에 파일 유무만으로 미완을 단정하지 않는다.**
|
||||
|
||||
> **예외 — lead를 생략한 경우**(`§Phase 2` 축소 규칙, `_progress.md`에 `생략` 으로 기록됨).
|
||||
> 생략된 에이전트는 **알림을 보내지 않는다.** 이때는 알림을 기다리지 말고 `01`의 **파일 존재만으로
|
||||
> 완료 판정**하고 곧바로 developer를 기동한다. 이 예외가 없으면 오지 않을 알림을 무기한 대기한다.
|
||||
|
||||
> **developer 자신을 생략하는 경우.** `이어서` 이고 `02`·`03`이 **둘 다 이미 있으면** developer를
|
||||
> 기동하지 않는다. `부분` 이면 developer가 **지목됐을 때만** 기동한다("아키텍처만 다시" → 기동 안 함).
|
||||
> 기동하지 않기로 했으면 `_progress.md`의 developer 행을 `생략 — 이전 산출물 재사용` 으로 적고
|
||||
> Phase 4로 넘어간다. 이 판단을 하지 않으면 재사용 대상인 `02`·`03`을 덮어쓴다
|
||||
> (`mode-rules.md` §기동 범위가 이 문장을 수신처로 지목한다).
|
||||
|
||||
developer에게도 **Phase 2와 동일한 항목 일체**를 전달한다(담당 스킬 = `analyze-ptop-implementation`, 산출 = `02`·`03`).
|
||||
**`run_in_background: true` 로 기동한다** — 순차 구간이라 불필요해 보이지만 `SendMessage`의
|
||||
`to: "main"` 회신은 **백그라운드 전용**이라, 전경으로 띄우면 Phase 4 회신 경로가 막힌다.
|
||||
|
||||
**폴백:** lead가 **2회 실패로 확정되면**(지연은 실패가 아니다 — `references/error-handling.md`)
|
||||
developer를 **소스 직접 참조 모드**로 기동하고 "아키텍처 선행 없이 수행됨"을 보고서에 명시한다.
|
||||
기동은 **오케스트레이터만** 한다 — `ptop-lead`는 범위 전달만 하고 팀원을 띄우지 않는다.
|
||||
|
||||
## Phase 4: 결과 수집 · 상충 조정
|
||||
|
||||
**이번 실행에서 기동한** 에이전트의 완료 알림을 받은 뒤 산출 파일 완성을 확인한다
|
||||
(알림 전 파일 유무로 실패를 단정하지 않는다). 그 다음 `SendMessage`로 핵심 발견 3건씩을 요청한다.
|
||||
|
||||
**원장 상태에 따라 3분기다** — `완료`=보낸다 / `실패`=`미검증` / **`생략`=산출물을 직접 읽어 답을 채운다**
|
||||
(`미검증`이 아니다). 둘을 묶으면 `부분`·`이어서` 실행이 매번 교차 질문을 통째로 잃는다.
|
||||
**대상 판별·교차 확인 질문 2건 → [references/collection-rules.md](references/collection-rules.md)**
|
||||
|
||||
상충하는 답이 나오면 어느 쪽도 지우지 않고 양쪽을 **근거(파일:라인)와 함께 병기**한다.
|
||||
|
||||
## Phase 5: 통합 보고서
|
||||
|
||||
`_workspace/00_PTOP_HARNESS_SUMMARY.md`를 작성한다.
|
||||
**필수 섹션 7종·표기 규약·중단 시 선작성 규칙 → [references/summary-template.md](references/summary-template.md)**
|
||||
(수치 추정 금지, `[추론]` 표기 `rules.md` #15·#16, `미검증·불명확` 절이 모든 누락의 종착지).
|
||||
|
||||
**보고 규약** — Phase 전환마다 진행 1줄 보고(`rules.md` #10), 출력 형식은 #11~13(수정 줄=초록
|
||||
화살표, 단어=주황, 미변경=기본색), 끝에 `docs/harness-ptop.md` 갱신 여부를 묻는다(#6).
|
||||
|
||||
## 데이터 전달 · 에러 핸들링
|
||||
|
||||
전달 = 파일(`_workspace/`) + `SendMessage`(이름) + `_progress.md`(진행 원장).
|
||||
상세 → [data-protocol.md](references/data-protocol.md) · [error-handling.md](references/error-handling.md)
|
||||
|
||||
**에러 핵심 3가지:**
|
||||
- 실패 = ①에러 종료 ②산출 파일 미생성 ③빈 파일·헤더만. **지연은 실패가 아니다.**
|
||||
- 재시도는 같은 `Agent` 재호출이며 `SendMessage` 독촉이 아니다. 횟수는 `_progress.md`에 `시도 N/2` 기록.
|
||||
- 1회 재시도 후 재실패하면 해당 영역 없이 진행하고 **누락을 `00_PTOP_HARNESS_SUMMARY.md`에 명시**한다.
|
||||
|
||||
## 테스트 시나리오
|
||||
|
||||
정상 · 에러 · 부분 재실행 · 전원 실패 **4흐름** → [references/test-scenarios.md](references/test-scenarios.md)
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] 통합 산출 6건(01~06)이 존재하거나, 없으면 누락 사유가 보고서에 명시됨
|
||||
(부산출물 `01a~01e`, `04a_dependency_analysis.csv`는 각 스킬이 만들며 필수는 아님)
|
||||
- [ ] 모든 발견에 `파일:라인` 근거가 붙어 있음
|
||||
- [ ] 측정하지 않은 수치가 보고서에 없음
|
||||
- [ ] 검증 전 서술이 전부 `[추론]`으로 표기됨 (`rules.md` #16)
|
||||
- [ ] 교차 확인 질문 2건에 답이 기록됨 — 답할 에이전트가 **실패**했으면 `미검증`과 사유로,
|
||||
**`생략`(미기동)** 이면 그 산출물을 읽어 `이전 실행 산출물에서 확인(YYYY-MM-DD)` 으로 대체 가능
|
||||
- [ ] 상충 사항이 양쪽 근거와 함께 병기됨
|
||||
- [ ] 권장사항이 P0/P1/P2로 분류됨
|
||||
- [ ] 부분 재실행이면 각 산출 파일과 보고서에 **stale 표기**가 있고, 연쇄 무효화 여부가 기록됨
|
||||
- [ ] 소스 코드가 수정되지 않음 (분석 전용)
|
||||
|
||||
## 후속 작업
|
||||
|
||||
- "아키텍처만 다시" → `ptop-lead`만 재기동, 나머지는 기존 `_workspace/` 파일 재사용
|
||||
- **stale 표기 의무.** 각 산출 파일(`01`~`06`)의 **첫 줄**과 보고서 각 영역 절 머리 **양쪽에**
|
||||
`이번 실행에서 갱신됨(YYYY-MM-DD)` / `이전 실행 결과 재사용(YYYY-MM-DD)` 를 적는다(§Phase 1-4 ④ 승인 대상).
|
||||
`01`을 갱신하면 의존하는 `02`·`03`은 재사용이 아니라 **정합성 미확인** — 함께 재실행할지 묻고
|
||||
거절하면 사유까지 표기한다. 날짜 규칙·문구 3종 → [data-protocol.md](references/data-protocol.md)
|
||||
- 부분 재실행에서는 `_workspace_prev/`로 옮기지 않는다(전면 재실행일 때만). 갱신 대상 파일만 덮어쓴다.
|
||||
- 주요 코드 변경 후 영향도 분석 필요 시 전면 재실행 (기존은 `_workspace_prev/`로 보존)
|
||||
@ -1,39 +0,0 @@
|
||||
# Phase 4 결과 수집 — 대상 판별 규칙
|
||||
|
||||
`SKILL.md` §Phase 4 에서 분리한 상세. **누구에게 `SendMessage` 를 보내고 누구에게 안 보내는가**를
|
||||
정한다. 판별 근거는 `_workspace/_progress.md` 의 상태 열이다(enum 4종 → `data-protocol.md` §진행 원장).
|
||||
|
||||
## 알림 대기 대상
|
||||
|
||||
**이번 실행에서 기동한** 백그라운드 에이전트의 완료 알림을 전부 받은 뒤 산출 파일 완성을 확인한다.
|
||||
알림 전 파일 유무로 실패를 단정하지 않는다.
|
||||
|
||||
**`생략` 으로 적힌 에이전트는 알림 대상이 아니다** — 기동하지 않았으므로 알림을 보내지 않는다.
|
||||
기다리지 말고 파일 존재로 판정한다.
|
||||
|
||||
## 상태별 처리 (3분기)
|
||||
|
||||
| 원장 상태 | `SendMessage` | 교차 확인 질문 답 |
|
||||
|---|---|---|
|
||||
| **`완료`** (= 살아 있는) | 보낸다 — 핵심 발견 3건 요청 | 회신 내용으로 채운다 |
|
||||
| **`실패`** | 보내지 않는다 | `미검증` + 사유 |
|
||||
| **`생략`** | 보내지 않는다 | **산출물 파일을 직접 읽어** 채우고 `이전 실행 산출물에서 확인(YYYY-MM-DD)` |
|
||||
|
||||
**`살아 있는` = 완료 알림을 정상 수신했고 산출 파일이 실패 판정 ①②③에 걸리지 않은 에이전트.**
|
||||
이 정의가 없으면 전부 죽었다고 보고 교차 질문 2건을 통째로 `미검증` 처리하게 된다.
|
||||
|
||||
> ⚠ **`실패` 와 `생략` 을 한 처리로 묶지 마라.** 묶으면 `부분`·`이어서` 실행이 **매번** 교차 질문
|
||||
> 2건을 `미검증` 으로 떨어뜨린다 — 산출물은 멀쩡히 있는데도 그렇다.
|
||||
> `실패` 는 답할 근거가 없는 것이고, `생략` 은 답할 근거가 **파일에 있는** 것이다.
|
||||
|
||||
## 교차 확인 질문 (반드시 물을 것)
|
||||
|
||||
- 아키텍처가 정의한 3계층 경계가 구현에서 실제로 지켜지는가? 위반 지점은 어디인가?
|
||||
- 런타임 시뮬 플래그(`isSimul`) 경로가 디바이스 시뮬 분기와 일관되는가?
|
||||
(`Simulation|x64`는 별도 빌드가 아니므로 "구성"으로 묻지 않는다 — `optimize-ptop-build` §3단계 참조)
|
||||
|
||||
상충하는 답이 나오면 어느 쪽도 지우지 않고 양쪽을 **근거(파일:라인)와 함께 병기**한다.
|
||||
|
||||
> 위 표의 분기를 늘리거나 상태 enum을 바꾸면 `data-protocol.md` §진행 원장(정의부)과
|
||||
> `SKILL.md` §성공 기준의 교차 질문 항목을 **같은 편집에서** 고친다
|
||||
> (`docs/harness-ptop.md` §소비처 확인 의무 ①~④).
|
||||
@ -1,45 +0,0 @@
|
||||
# 데이터 전달 프로토콜 — orchestrate-ptop-harness
|
||||
|
||||
| 대상 | 방식 |
|
||||
|---|---|
|
||||
| 아키텍처 → 구현 의존 | 파일 (`_workspace/01_ptop_architecture.md`) |
|
||||
| 실시간 질문·상충 | `SendMessage` (이름 지정) |
|
||||
| 진행 추적 | `_workspace/_progress.md`(진실원) + `TaskCreate`/`TaskUpdate`(가용 시 보조, 02는 01에 blockedBy) |
|
||||
| 최종 산출물 | `_workspace/00_PTOP_HARNESS_SUMMARY.md` |
|
||||
|
||||
## 진행 원장 `_workspace/_progress.md`
|
||||
|
||||
**진행 원장은 파일이다.** `TaskCreate`/`TaskUpdate`는 메인 루프에서는 쓸 수 있지만
|
||||
**서브에이전트 컨텍스트에는 없을 수 있다.** 도구 가용 여부와 무관하게 동작하도록,
|
||||
진행·재시도 기록의 **진실원은 `_workspace/_progress.md`** 로 둔다:
|
||||
|
||||
| 에이전트 | 상태 | 시도 | 갱신시각 |
|
||||
|---|---|---|---|
|
||||
| ptop-lead | 진행중 / 완료 / 실패 / **생략** | 1/2 | YYYY-MM-DD HH:MM |
|
||||
|
||||
**상태 enum은 4종이다.** `진행중`·`완료`·`실패` 는 이번 실행에서 **기동한** 에이전트의 상태이고,
|
||||
**`생략 — 이전 산출물 재사용`** 은 **이번 실행에서 기동하지 않은** 에이전트를 뜻한다
|
||||
(모드와 무관하다 — `이어서`에서 산출물이 이미 있어 건너뛴 경우든, `부분`에서 지목되지 않은
|
||||
경우든 똑같이 `생략` 으로 적는다).
|
||||
|
||||
> **`생략` 을 적지 않으면 19R의 교착이 재발한다.** Phase 3·4는 이 값으로
|
||||
> "완료 알림을 기다릴 대상"과 "파일 존재로 판정할 대상"을 가른다. `진행중` 으로 적으면
|
||||
> 오지 않을 알림을 무기한 기다린다. 소비처 → `mode-rules.md` §생략의 파급.
|
||||
|
||||
`TaskCreate`/`TaskUpdate`가 있으면 보조로 함께 쓰되, 없다고 해서 절차가 멈추지 않는다.
|
||||
|
||||
## stale 표기 — 날짜 규칙과 연쇄 무효화
|
||||
|
||||
표기 위치는 **각 산출 파일(`01`~`06`)의 첫 줄**과 통합 보고서의 각 영역 절 머리, **양쪽 모두**다.
|
||||
보고서에만 적으면 파일을 직접 여는 사람이 최신 여부를 알 수 없다.
|
||||
|
||||
| 상황 | 첫 줄 문구 |
|
||||
|---|---|
|
||||
| 이번 실행에서 새로 씀 | `이번 실행에서 갱신됨(YYYY-MM-DD)` |
|
||||
| 이전 판을 그대로 재사용 | `이전 실행 결과 재사용(YYYY-MM-DD)` |
|
||||
| 선행 산출이 갱신돼 정합성 미확인 | `이전 실행 결과 재사용 — 01 갱신으로 정합성 미확인(YYYY-MM-DD)` |
|
||||
|
||||
- 날짜는 **그 파일을 실제로 쓴 실행일**이다. 재사용할 때는 **그 파일에 이미 적힌 날짜를 그대로 옮긴다** —
|
||||
파일 mtime을 추정해 적지 않는다.
|
||||
- **연쇄 무효화:** `01`을 갱신하면 그것에 의존해 만들어진 `02`·`03`은 단순 "재사용"이 아니라
|
||||
**정합성 미확인** 상태다. 함께 재실행할지 사용자에게 묻고, 거절하면 3행 문구로 표기한다.
|
||||
@ -1,15 +0,0 @@
|
||||
# 에러 핸들링 — orchestrate-ptop-harness
|
||||
|
||||
| 상황 | 처리 |
|
||||
|---|---|
|
||||
| 에이전트 타입 미등록 | Phase 시작 전 중단 → "세션 재시작 필요" 보고 (Phase 1-2) |
|
||||
| **재시도 카운트** | 재시도 횟수는 **`_workspace/_progress.md`의 `시도` 칸**에 기록한다(가용하면 `TaskUpdate`에도 병행). 기록이 없으면 0회로 간주 — 대화 맥락에만 두면 3회째로 새거나 1회에서 조기 포기한다 |
|
||||
| **실패 판정 기준** | ① 에이전트가 에러로 종료 ② 지정 산출 파일이 생성되지 않음 ③ 산출 파일이 비었거나 헤더만 있음 — 셋 중 하나면 실패로 본다. **지연은 실패가 아니다.** 재시도는 같은 `Agent` 호출을 다시 하는 것이며 `SendMessage` 독촉이 아니다 |
|
||||
| 반쯤 쓰인 산출 파일 | 지우지 않고 파일 상단에 `(부분 — 미완)`을 표기해 보존. 통합 보고서에서 해당 영역을 `부분`으로 표시 |
|
||||
| 에이전트 실패 | 1회 재시도. 재실패 시 해당 영역 없이 진행하고 보고서에 **누락을 명시** |
|
||||
| lead **지연** → developer 대기 | `run_in_background`로 띄운 에이전트는 **완료 알림이 올 때까지 기다린다.** 알림 없이 미완을 판단하지 않는다(기동 직후 확인하면 당연히 미완이라 폴백으로 오인된다). 알림이 온 뒤에도 산출 파일이 없으면 1회 재확인하고, 그래도 없으면 실패로 처리한다 |
|
||||
| lead **2회 실패** (지연과 다름) | developer를 소스 직접 참조 모드로 기동(`ptop-developer.md` 재호출 지침). **부분 `01`이 남아 있으면 그것을 함께 전달하되 `(부분 — 미완)`임을 명시한다.** `01` 누락과 그 영향을 보고서에 적고, 아키텍처 관련 교차 질문은 `미검증` 처리 |
|
||||
| 죽은 에이전트에 SendMessage | 보내지 않는다. 해당 교차 질문을 `미검증`으로 기록 |
|
||||
| 코드 이해 불가 | 해당 지점을 "불명확 — 확인 필요"로 표기하고 진행. 추측으로 메우지 않는다 |
|
||||
| 에이전트 간 상충 | 양쪽 견해를 근거와 함께 병기 |
|
||||
| 근거 없는 주장 발견 | 해당 항목을 보고서에서 제외하거나 "근거 미확보"로 강등 |
|
||||
@ -1,72 +0,0 @@
|
||||
# 실행 모드 4종 — 판별 · 전달 · 기동 범위
|
||||
|
||||
`SKILL.md` §Phase 1·2 에서 분리한 상세 규약. 모드 이름은 **`초기` / `이어서` / `부분` / `전면`** 이며
|
||||
이 문자열 그대로 팀원에게 전달한다.
|
||||
|
||||
## 판별 (Phase 1)
|
||||
|
||||
`_workspace/`(**저장소 루트 기준**. Ubisam 하네스의 `docs/[Ubisam산출물]/_workspace/`와 다른 곳)의
|
||||
**분석 산출물 `01`~`06` 존재 여부**로 판별한다 — 폴더 존재만 보면 채점·로그 파일만 있어도 오판정한다.
|
||||
|
||||
**두 축을 각각 본 뒤 교차한다** — ① 산출물 `01`~`06`이 있는가 ② 요청이 전체인가 특정 영역인가.
|
||||
한 축만 보면 오판정한다.
|
||||
|
||||
| ① 산출물 상태 | ② 요청 | 모드 | 동작 |
|
||||
|---|---|---|---|
|
||||
| 하나도 없음 | 전체 / 특정 영역 **무관** | **`초기`** | Phase 2부터 전원 기동. 폴더가 있어도, 특정 영역만 요청받았어도 만들 것이 없으므로 전원이다 |
|
||||
| 일부만 있음 | 전체 | **`이어서`** | 있는 것 재사용, **없는 것만 생성**, 이동 없음 |
|
||||
| 일부·전부 있음 | 특정 영역("아키텍처만 다시") | **`부분`** | **지목된 에이전트를 다시 돌린다.** 나머지는 재사용, 이동 없음 |
|
||||
| 무관 | **"처음부터 다시" 명시** | **`전면`** | 기존을 `_workspace_prev/`로 이동. ②가 ①을 덮는 유일한 행 |
|
||||
|
||||
> **①이 "하나도 없음"이면 ②를 보지 않고 `초기`다.** 산출물 0건인데 "아키텍처만 다시"를 받으면
|
||||
> `부분`처럼 보이지만, 재사용할 것이 없으므로 `초기`로 처리하고 사용자에게 그 사실을 알린다.
|
||||
> 반대로 **`전면`은 ②가 우선**한다 — "처음부터 다시"는 산출물 상태와 무관한 명시적 지시다.
|
||||
>
|
||||
> 맨 "전체 분석"은 최초 실행과 같은 발화라 **이동 근거가 아니다** — 되돌리기 어려우니 확인 후 옮긴다.
|
||||
> `_workspace_prev/` 이동은 **오케스트레이터만** 한다. 팀원은 모드를 "재사용할지" 판단에만 쓴다
|
||||
> (에이전트 정의 6종에 같은 금지문이 있다 — 한쪽만 고치지 말 것).
|
||||
>
|
||||
> **`생략` 으로 적었는데 해당 산출물 파일이 실제로 없으면** 그 에이전트는 생략 대상이 아니다.
|
||||
> 원장을 `진행중` 으로 고치고 기동한다 — 파일 존재 판정(§생략의 파급 2)이 성립하지 않기 때문이다.
|
||||
|
||||
## 기동 범위 (Phase 2)
|
||||
|
||||
**기동 대상을 줄이는 기준은 모드마다 다르다**(아래 §모드별 기준 표). `이어서` 는 **담당 산출물이
|
||||
이미 있으면** 띄우지 않으며 **에이전트 3인 전원이 대상이다**:
|
||||
|
||||
| 에이전트 | 담당 산출물 | 전부 있으면 |
|
||||
|---|---|---|
|
||||
| `ptop-lead` | `01` | 생략 |
|
||||
| `build-devops-engineer` | `04`·`05`·`06` | 생략 |
|
||||
| `ptop-developer` | `02`·`03` | 생략 — 판단 시점만 Phase 3다 (`SKILL.md` §Phase 3 "developer 자신을 생략하는 경우") |
|
||||
|
||||
모드가 바꾸는 것이 이동 여부뿐이면 "있는 것 재사용, 없는 것만 생성"이라는 정의가 지켜지지 않는다.
|
||||
|
||||
⚠ **`부분`은 기준이 다르다 — 산출물 유무가 아니라 "지목됐는가"다.** `부분`은 지목된 에이전트를
|
||||
**다시 돌리는** 모드라, 산출물이 있다는 이유로 생략하면 **재기동 대상이 곧 생략 대상이 되어
|
||||
아무도 기동되지 않는다.** `부분`에서는 지목된 에이전트를 반드시 띄우고, 지목되지 않은 에이전트만
|
||||
재사용한다(그쪽이 `생략` 이다).
|
||||
|
||||
`초기`·`전면` 은 전원 기동이며 생략이 없다.
|
||||
|
||||
| 모드 | 기동하지 않는 조건 |
|
||||
|---|---|
|
||||
| `초기` · `전면` | 없음 (전원 기동) |
|
||||
| `이어서` | 담당 산출물이 **이미 있음** |
|
||||
| `부분` | **지목되지 않음** (산출물 유무 무관) |
|
||||
|
||||
## 생략의 파급 (Phase 3·4)
|
||||
|
||||
**생략된 에이전트는 완료 알림을 보내지 않는다.** 알림을 기다리면 무기한 대기한다.
|
||||
|
||||
> **`생략` 은 모드가 아니라 "이번 실행에서 기동하지 않음"을 뜻한다.** `이어서`에서 산출물이
|
||||
> 이미 있어 건너뛴 경우와 **`부분`에서 지목되지 않은 경우 둘 다** 여기에 해당한다.
|
||||
> 상태 enum 정의부 → `data-protocol.md` §진행 원장.
|
||||
|
||||
1. 기동하지 않는 에이전트를 `_progress.md`에 **`생략 — 이전 산출물 재사용`** 으로 먼저 기록한다.
|
||||
2. Phase 3·4는 그 에이전트를 **알림 대기 없이 파일 존재만으로 완료 판정**한다.
|
||||
3. 생략된 에이전트는 Phase 4의 "살아 있는" 대상이 **아니다** — 교차 확인 질문을 보내지 않는다.
|
||||
4. 그 산출물에는 `SKILL.md` §후속 작업의 **재사용 stale 문구**를 남긴다.
|
||||
|
||||
> 기동 대상을 늘리거나 줄이는 규칙을 고치면 **위 3개 소비처(Phase 2 기동 · Phase 3 완료 판정 ·
|
||||
> Phase 4 교차 질문)를 같은 편집에서 확인**한다 (`docs/harness-ptop.md` §소비처 확인 의무).
|
||||
@ -1,38 +0,0 @@
|
||||
# `00_PTOP_HARNESS_SUMMARY.md` 골격
|
||||
|
||||
오케스트레이터 Phase 5가 쓰는 통합 보고서의 필수 섹션이다.
|
||||
`_workspace/00_PTOP_HARNESS_SUMMARY.md` 한 파일로 만든다.
|
||||
|
||||
## 필수 섹션
|
||||
|
||||
| 섹션 | 내용 |
|
||||
|---|---|
|
||||
| Executive Summary | 3~5줄 |
|
||||
| 영역별 발견 | 아키텍처(01) / 구현(02·03) / 빌드(04·05·06) — 각 3건 이상, 모두 `파일:라인` 근거 포함 |
|
||||
| 상충 사항 | 에이전트 간 이견과 양쪽 근거 |
|
||||
| 권장사항 | P0/P1/P2 · 항목 · 근거 · 예상 공수 |
|
||||
| **산출물 stale** | 파일별 "이번 실행 갱신(YYYY-MM-DD)" / "이전 결과 재사용(YYYY-MM-DD)" + 연쇄 무효화 상태 |
|
||||
| 미검증·불명확 | 확인하지 못한 항목과 사유 |
|
||||
| 부록 | 산출 파일 목록 |
|
||||
|
||||
> 섹션을 늘리거나 줄이면 `SKILL.md` §성공 기준의 대응 항목도 **같은 편집에서** 고친다
|
||||
> (`docs/harness-ptop.md` §소비처 확인 의무).
|
||||
|
||||
## 표기 규약
|
||||
|
||||
**수치·상태를 추정으로 적지 않는다.** 빌드 시간·성능 수치는 실제 측정했을 때만 기재하고,
|
||||
측정하지 않았으면 `미측정`이라고 쓴다. 그럴듯한 숫자가 보고서에 남으면 이후 판단을 오염시킨다.
|
||||
|
||||
**검증 전 서술에는 `[추론]`을 붙인다** (`rules.md` #15·#16). `미측정`(측정했으나 값 없음)과 축이
|
||||
다르니 대체하지 말고 병기한다. 확인 후에는 `[추론]`을 떼고 `파일:라인` 근거로 바꾼다.
|
||||
|
||||
## 중단 시에도 먼저 쓴다
|
||||
|
||||
**`미검증·불명확` 절이 모든 누락의 종착지다.** 에이전트 전원 실패로 중단하는 경우에도
|
||||
이 파일을 그 1개 절만으로 **먼저 쓴 뒤** 보고한다 — 중단하면 흔적이 채팅에만 남아
|
||||
폴더를 여는 사람이 상황을 알 수 없다.
|
||||
|
||||
작성 후 산출 경로와 P0 항목을 요약 보고한다. `_workspace/`는 감사 추적용으로 보존한다.
|
||||
|
||||
> `.md` 200줄 상한(`rules.md` #4)은 이 보고서에도 적용된다. 넘으면 영역별로 분할하고
|
||||
> 요약 본문에서 상대경로로 링크한다.
|
||||
@ -1,42 +0,0 @@
|
||||
# 테스트 시나리오 — orchestrate-ptop-harness
|
||||
|
||||
## 정상 흐름 — "PTOP 전체 점검" 요청
|
||||
|
||||
1. Phase 1-0 대상 확인 통과 (PTOP 분석 대상이 발화에 있음)
|
||||
2. Phase 1-1 `_workspace/` 에 산출물 `01`~`06` 이 하나도 없음 → **초기 실행**
|
||||
(폴더 자체는 있어도 된다 — 채점·로그 파일만 있는 경우가 여기에 해당)
|
||||
3. Phase 1-2 에이전트 3인 가용성 확인 통과
|
||||
4. Phase 1-4 승인 4항 제시 → 승인 — ①이동·삭제분 ②덮어쓰기분 ③생성분(`01~06` + `00_PTOP_HARNESS_SUMMARY.md`
|
||||
+ 부산출물 `01a~01e`·`04a_dependency_analysis.csv`) ④작업공간 관리 파일(`_workspace/`, `_progress.md`)
|
||||
5. Phase 2 `ptop-lead`·`build-devops-engineer` 병렬 기동 (담당 스킬·산출 경로 모두 절대경로로 전달)
|
||||
6. Phase 3 lead **완료 알림 수신 후** `01_ptop_architecture.md` + "불명확 — 확인 필요" 절 확인 →
|
||||
`ptop-developer` 기동
|
||||
7. Phase 4 전원 완료 알림 후 교차 확인 질문 2건
|
||||
8. Phase 5 `00_PTOP_HARNESS_SUMMARY.md` 작성 → P0 요약 보고
|
||||
|
||||
## 에러 흐름 — `build-devops-engineer`가 `ILSOS_All.sln` 파싱 실패로 2회 연속 실패
|
||||
|
||||
1. 실패 판정 기준 ①(에러 종료) 성립 → `_progress.md`에 `시도 1/2` 기록
|
||||
2. 같은 `Agent` 재호출 → 또 실패 → `시도 2/2` → **실패 확정**
|
||||
3. 빌드 영역 없이 아키텍처·구현만으로 진행
|
||||
4. Phase 4에서 죽은 에이전트에는 `SendMessage`하지 않고, 빌드 관련 교차 질문을 `미검증`으로 기록
|
||||
5. Phase 5 `00_PTOP_HARNESS_SUMMARY.md`의 `미검증·불명확` 절에
|
||||
"빌드 분석 누락 — sln 파싱 실패 2회"를 명시
|
||||
6. 사용자에게 **누락을 먼저** 알림
|
||||
|
||||
## 부분 재실행 흐름 — "아키텍처만 다시"
|
||||
|
||||
1. Phase 1-1 `01`~`06` 중 하나 이상 있음 + 부분 수정 요청 → **부분 재실행**
|
||||
2. Phase 1-5 원장 초기화 — 지목된 `ptop-lead`는 `진행중`, **지목되지 않은 `ptop-developer`·
|
||||
`build-devops-engineer`는 `생략 — 이전 산출물 재사용`** 으로 적는다(상태 enum → `data-protocol.md`)
|
||||
3. `ptop-lead`만 재기동. `_workspace_prev/`로 옮기지 **않는다**
|
||||
4. Phase 3은 developer가 `생략` 이므로 기동하지 않고 넘어간다 (지목되지 않았다)
|
||||
5. Phase 4는 `생략` 인 두 에이전트에 `SendMessage`를 보내지 않고, 그 산출물을 **직접 읽어**
|
||||
교차 확인 질문에 답한다 → `이전 실행 산출물에서 확인(YYYY-MM-DD)`. `미검증`이 아니다
|
||||
6. `01` 갱신 후 `02`·`03` 연쇄 재실행 여부를 사용자에게 질의
|
||||
7. 거절 시 두 파일 첫 줄에 `이전 실행 결과 재사용 — 01 갱신으로 정합성 미확인(YYYY-MM-DD)` 표기
|
||||
|
||||
## 전원 실패 흐름
|
||||
|
||||
에이전트 3인이 모두 실패해도 `00_PTOP_HARNESS_SUMMARY.md`를 `미검증·불명확` **1개 절만으로 먼저 쓴 뒤**
|
||||
보고한다. 중단하면 흔적이 채팅에만 남아 폴더를 여는 사람이 상황을 알 수 없다.
|
||||
@ -1,113 +0,0 @@
|
||||
---
|
||||
name: ptop-deliverables
|
||||
description: >-
|
||||
LGES OC5 PtoP Welder 전용 산출물 자동 생성·갱신 스킬.
|
||||
프로젝트 소스를 분석해 docs/[Ubisam산출물]/ 하위 MD 산출물(색상 디자인 포함)을
|
||||
생성하거나 최신화한다. 다른 PC에서는 `ubisam-deliverables` 스캐폴딩을 먼저 돌린 뒤
|
||||
이 스킬로 전체 산출물을 재생산한다 (`docs/[Ubisam산출물]/`는 `.gitignore` 제외라 clone 직후 없다). "ptop 산출물", "PLC 신호정의서/기능명세서/시퀀스 인터락 정의서 갱신",
|
||||
"소스 기준으로 설계 산출물 최신화", "코드 보고 설계문서 다시 뽑아줘", "/ptop-deliverables", 그리고 **소스 기준 재생산 후속 표현**
|
||||
("설계 MD 다시 뽑아줘", "소스 갱신분 반영", "이전 산출물 기반으로") 시 사용.
|
||||
**입력이 PTOP 소스코드일 때만** 쓴다. 맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 —
|
||||
대상을 먼저 확인한다.
|
||||
구분 — 트리를 새로 까는 스캐폴딩은 `ubisam-deliverables`, 이미 있는 타사 문서를 Ubisam
|
||||
양식으로 재생산하는 것은 `ubisam-deliverable-rebuild`, enum 조회만이면 `ubisam-format-map`,
|
||||
**PTOP 아키텍처·구현·빌드 분석**은 `orchestrate-ptop-harness`.
|
||||
---
|
||||
|
||||
# PTOP 산출물 자동 생성 SKILL
|
||||
|
||||
LGES OC5 PtoP Welder(`ILSOS_PrismaticRD_PTOP`) 전용.
|
||||
소스를 분석해 6단계 산출물 MD를 **Ubisam 디자인 시스템**(배너·뱃지·진행률 포함) 기준으로 생성한다.
|
||||
|
||||
## 참조 맵
|
||||
|
||||
| # | 파일 | 용도 |
|
||||
|---|---|---|
|
||||
| D | [references/design-system.md](references/design-system.md) | 색상 팔레트·배너·뱃지 HTML 템플릿 |
|
||||
| S | [references/source-map.md](references/source-map.md) | 소스 파일 → 산출물 필드 매핑 |
|
||||
|
||||
## 소스 진실원 — 읽는 순서
|
||||
|
||||
다른 PC에서 실행 시 아래 파일을 순서대로 읽어 산출물을 채운다.
|
||||
|
||||
| 순서 | 파일 경로 | 추출 정보 |
|
||||
|---|---|---|
|
||||
| 1 | `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs` | BIT/WORD 신호 enum 전수 |
|
||||
| 2 | `Machines/ILSOS_PrismaticRD_PTOP/EquipmentSetup.cs` | 디바이스 등록·메뉴·뷰 목록 |
|
||||
| 3 | `Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPTOP.cs` | 시퀀스 노드·인터락·TactTime |
|
||||
| 4 | `Machines/ILSOS_PrismaticRD_PTOP/Device/IO/PAIX_PTOP.cs` | DI/DO 채널 맵 |
|
||||
| 5 | `docs/architecture.md` | 플랫폼·모션·디바이스 개요 |
|
||||
| 6 | `docs/[Ubisam산출물]/_meta/project.yaml` | 프로젝트 코드·팀 정보 |
|
||||
|
||||
## 진입 가드 (먼저 확인)
|
||||
|
||||
사용자 발화에 **대상이 무엇인지**(소스코드 / 특정 문서 파일 / 미지정) 드러나지 않으면
|
||||
**어떤 파일도 만들거나 고치지 말고 되묻는다.** "산출물 업데이트해줘"·"다시 실행해줘"·"보완해줘" 같은 발화는
|
||||
이 스킬·`ubisam-deliverable-rebuild`·`ubisam-deliverables` 중 무엇이든 될 수 있고,
|
||||
잘못 고르면 사용자가 원하지 않은 파일이 대량으로 덮어써진다.
|
||||
|
||||
되물을 것: "① 소스코드 기준으로 설계 MD를 다시 뽑을까요, ② 기존 xlsx/pptx 문서를 Ubisam 양식으로
|
||||
재생산할까요, ③ 산출물 폴더 트리를 새로 깔까요?"
|
||||
|
||||
생성·덮어쓸 파일 목록을 먼저 제시하고 승인을 받은 뒤 쓴다 (`rules.md` #2).
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### STEP 0 — 진입 체크
|
||||
`docs/[Ubisam산출물]/` 폴더 존재 여부 확인.
|
||||
없으면 `/ubisam-deliverables` 스캐폴딩을 먼저 실행 후 재진입.
|
||||
|
||||
### STEP 1 — 소스 분석
|
||||
소스 진실원 6개를 순서대로 읽어 추출한다:
|
||||
- PLC BIT/WORD 신호 목록 (eBitInput/Output, eWordInput/Output)
|
||||
- 등록 디바이스 (PLC·IO·Laser·Scanner·Motion·Vision)
|
||||
- 메뉴·뷰 트리 (`RegisterViews` — `AddSubMenu(CommonViewIds.*, UC)` 는 2인자라 권한이 없지만,
|
||||
**`MainMenu` 생성자 3번째 인자가 `PermissionLevel` 이다**. 메인메뉴 8건이 값을 가진다 —
|
||||
`EquipmentSetup.cs:261,266,289,302,310,318,323,330`. 기능명세서 §메뉴구조의 `권한` 열은 여기서 채운다)
|
||||
- 시퀀스 노드 흐름 + 인터락 조건 + 정지/에러 처리
|
||||
- TactTime 상수 (지연 ms, 타임아웃 s, 루프 슬립)
|
||||
- DI/DO 채널 번호·신호명·설명 (PAIX_PTOP.cs)
|
||||
|
||||
### STEP 2 — 산출물 MD 생성/갱신
|
||||
|
||||
[design-system.md](references/design-system.md) 배너·뱃지 템플릿을 적용해
|
||||
아래 파일을 **없으면 생성, 있으면 내용 갱신**한다.
|
||||
|
||||
| 산출물 | 경로 | 채움 소스 |
|
||||
|---|---|---|
|
||||
| PLC-PC 신호정의서 | `02.설계/IO_DB설계/PLC_PC_인터페이스_신호정의서.md` | PLCController.Address.cs |
|
||||
| 모션축·IO 맵 정의서 | `02.설계/IO_DB설계/모션축_IO맵_정의서.md` | EquipmentSetup + PAIX_PTOP |
|
||||
| 기능명세서 | `02.설계/UIUX_기능설계/기능명세서.md` | EquipmentSetup.RegisterViews |
|
||||
| 시퀀스·인터락 정의서 | `02.설계/시퀀스_인터록/제어시퀀스_인터락_정의서.md` | SeqAutoRunPTOP.Builder |
|
||||
| TactTime 산정서 | `02.설계/시퀀스_인터록/TactTime_산정서.md` | SeqAutoRunPTOP 지연 상수 |
|
||||
|
||||
각 파일 구조: **배너(진네이비) → 부제(파랑) → 내용 테이블/mermaid → enum 요약**
|
||||
|
||||
### STEP 3 — _task 카드 갱신
|
||||
`01~06` 각 `_task.md` 상태·진행률을 현황 반영해 갱신.
|
||||
적용 디자인: 상태 뱃지 + 유형 뱃지 + `<progress>` 진행률 바.
|
||||
|
||||
### STEP 4 — 분석 로그 기록
|
||||
`[분석]/YYYY_MM_DD_PTOP설계산출물-분석.md` 작성.
|
||||
내용: 소스→필드 매핑 표 + 미확정 항목 목록 + 진실원 인덱스.
|
||||
|
||||
## 불변 규칙
|
||||
- **비침습**: `docs/[Ubisam산출물]/` 밖은 읽기만. 소스·CLAUDE.md 수정 금지.
|
||||
- **MD 200줄 상한** (`rules.md` #4): 초과 시 분할 + 상대경로 링크.
|
||||
- **출처 명시**: 채운 값마다 `— 출처: 파일명:심볼` 주석.
|
||||
- **미확정 표기**: 주소·행정·속도 등 미확정값 → `(제안)`.
|
||||
- **추론 표기**: 소스에서 확인하지 않고 채운 값·해석은 `[추론]` 접두 (`rules.md` #15·#16).
|
||||
`(제안)`(진실원 자체가 없음)과 축이 다르다 — 확인 후에는 표기를 떼고 `— 출처: 파일:심볼`로 바꾼다.
|
||||
- **멱등**: 재실행 시 배너·뱃지는 교체, 테이블 데이터는 행 추가/갱신.
|
||||
- **md ↔ xlsx 공존 규칙**: 같은 슬롯에 `기능명세서.md`(이 스킬)와 `기능명세서.xlsx`
|
||||
(`ubisam-deliverables/references/build_02설계_xlsx.py`)가 공존할 수 있다. **소스 기준 최신값의 진실원은 `.md`**이고, `.xlsx`는 배포용 스냅샷이다.
|
||||
⚠ **md→xlsx 자동 동기화 수단은 없다.** `build_02설계_xlsx.py`는 데이터가 코드에 하드코딩된
|
||||
무인자 스크립트라 md를 입력으로 받지 못한다. 어긋나면 그 스크립트의 데이터 블록을 md 기준으로
|
||||
**함께 고친 뒤** 재실행한다.
|
||||
- **Aurora 고정 문구**: "운영 SW는 LG PRI의 Aurora 플랫폼으로 개발한다."
|
||||
|
||||
> 소스 진실원 6종 읽기 + MD 5종 생성 + `_task` 6장 갱신은 10분을 넘긴다 —
|
||||
> **STEP 전환마다 지금 어느 단계인지 한 줄로 보고한다**(`rules.md` #10).
|
||||
>
|
||||
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
||||
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|
||||
@ -1,134 +0,0 @@
|
||||
> **팔레트·뱃지 정의의 진실원은 `ubisam-deliverables/references/08-design-system.md`다.**
|
||||
> 값이 갈리면 그쪽이 맞다. 이 파일은 PTOP 전용 추가분과 사용 예시만 기술한다.
|
||||
|
||||
# PTOP 산출물 — Ubisam 디자인 시스템
|
||||
|
||||
> MD 산출물에 적용하는 HTML 색상 템플릿 모음.
|
||||
> VS Code Markdown Preview / Typora / GitLab 렌더링 기준.
|
||||
|
||||
---
|
||||
|
||||
## 색상 팔레트
|
||||
|
||||
| 구분 | 이름 | 색 코드 | 용도 |
|
||||
|---|---|---|---|
|
||||
| 배너 | 진네이비 | `#1F4E78` | 문서 최상단 제목 배너 |
|
||||
| 헤더 | 파랑 | `#2E75B6` | 배너 하단 부제 바, 섹션 강조 |
|
||||
| 연파랑 | — | `#DDEBF7` | 테이블 홀수 행 참조 (xlsx 전용, MD 생략 가능) |
|
||||
| 상태·해야 할 일 | 회색 | `#757575` | 미착수 |
|
||||
| 상태·분석 진행 | 청색 | `#1976D2` | 선택됨 |
|
||||
| 상태·업무 진행중 | 파랑 | `#1565C0` | 진행 중 |
|
||||
| 상태·진행 완료 | 연두 | `#689F38` | 완료 |
|
||||
| 유형·오류수정 | 빨강 | `#D32F2F` | — |
|
||||
| 유형·불합리 | 주황 | `#F57C00` | — |
|
||||
| 유형·미팅 | 청록 | `#00796B` | 1.분석/협의 |
|
||||
| 유형·설계 | 연두 | `#689F38` | 2.설계 |
|
||||
| 유형·개발 | 파랑 | `#1976D2` | — |
|
||||
| 유형·제작 | 남파랑 | `#283593` | 3.제작 |
|
||||
| 유형·입고셋업 | 보라 | `#7B1FA2` | 4.셋업 |
|
||||
| 유형·적용 및 모니터링 | 하늘 | `#0288D1` | 5.양산 |
|
||||
| 유형·요청대응 | 남색 | `#1A237E` | 6.CS |
|
||||
|
||||
---
|
||||
|
||||
## 1. 문서 배너 (최상단)
|
||||
|
||||
산출물 MD 파일 1번째 줄부터 적용.
|
||||
|
||||
```html
|
||||
<div style="background:#1F4E78;color:#fff;padding:8px 16px;border-radius:4px 4px 0 0;margin-bottom:0">
|
||||
<strong style="font-size:1.1em">문서 제목</strong>
|
||||
</div>
|
||||
<div style="background:#2E75B6;color:#fff;padding:4px 16px;border-radius:0 0 4px 4px;font-size:.85em;margin-bottom:12px">
|
||||
근거: 소스 경로 · Aurora 2.0 / .NET 4.8.1 / WPF
|
||||
</div>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 상태 뱃지
|
||||
|
||||
`_task.md` 상태 필드에 사용. 값에 맞춰 색 코드 교체.
|
||||
|
||||
```html
|
||||
<!-- 해야 할 일 -->
|
||||
<span style="background:#757575;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">해야 할 일</span>
|
||||
|
||||
<!-- 분석 진행 -->
|
||||
<span style="background:#1976D2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">분석 진행</span>
|
||||
|
||||
<!-- 업무 진행중 -->
|
||||
<span style="background:#1565C0;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">업무 진행중</span>
|
||||
|
||||
<!-- 진행 완료 -->
|
||||
<span style="background:#689F38;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">진행 완료</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 유형 뱃지
|
||||
|
||||
```html
|
||||
<span style="background:#D32F2F;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">오류수정</span>
|
||||
<span style="background:#F57C00;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">불합리</span>
|
||||
<span style="background:#00796B;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">미팅</span>
|
||||
<span style="background:#689F38;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">설계</span>
|
||||
<span style="background:#283593;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">제작</span>
|
||||
<span style="background:#7B1FA2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">입고셋업</span>
|
||||
<span style="background:#1976D2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">개발</span>
|
||||
<span style="background:#0288D1;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">적용 및 모니터링</span>
|
||||
<span style="background:#1A237E;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">요청대응</span>
|
||||
```
|
||||
|
||||
> 뱃지는 **9종**이며 `ubisam-format-map/SKILL.md` §2 의 일감 유형 enum과 1:1 대응한다.
|
||||
> enum을 늘리거나 줄이면 이 블록도 **같은 편집에서** 고친다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 진행률 바
|
||||
|
||||
`<progress>` 태그 + 텍스트 병기 (렌더러 호환).
|
||||
|
||||
```html
|
||||
<progress value="0" max="100" style="width:160px;vertical-align:middle"></progress> <strong>0%</strong>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. _task.md 전체 템플릿
|
||||
|
||||
```markdown
|
||||
<div style="background:#1F4E78;color:#fff;padding:8px 16px;border-radius:4px 4px 0 0">
|
||||
<strong>N.단계명</strong> — LGES OC5 PtoP Welder
|
||||
</div>
|
||||
<div style="background:#2E75B6;color:#fff;padding:3px 16px;border-radius:0 0 4px 4px;font-size:.85em;margin-bottom:12px">
|
||||
LGES_PTOP_01_20260605-XXXX
|
||||
</div>
|
||||
|
||||
| 필드 | 값 |
|
||||
|---|---|
|
||||
| 유형 | <span style="background:COLOR;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">유형명</span> |
|
||||
| 상태 | <span style="background:COLOR;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">상태명</span> |
|
||||
| 담당자 / 참조자 | {미정} / {미정} |
|
||||
| 진행률 | <progress value="N" max="100" style="width:160px;vertical-align:middle"></progress> **N%** |
|
||||
| Hashtag | 태그1 / 태그2 |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 산출물 섹션 헤더
|
||||
|
||||
산출물 MD 내 시트 구분 헤더.
|
||||
|
||||
```markdown
|
||||
## <span style="color:#2E75B6">시트① 제목</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 미확정·제안 강조
|
||||
|
||||
```markdown
|
||||
> [!NOTE]
|
||||
> 아래 값은 소스 enum offset 기반 `(제안)`. PLC 맵 CSV 입수 후 확정.
|
||||
```
|
||||
@ -1,141 +0,0 @@
|
||||
# PTOP 소스 → 산출물 필드 매핑
|
||||
|
||||
> 이 파일은 소스 파일과 산출물 필드 간 1:1 매핑 인덱스.
|
||||
> 다른 PC에서 스킬 실행 시 이 파일을 보고 어떤 소스를 읽어야 할지 판단한다.
|
||||
|
||||
---
|
||||
|
||||
## A. PLC-PC 인터페이스 신호정의서
|
||||
|
||||
출력: `02.설계/IO_DB설계/PLC_PC_인터페이스_신호정의서.md`
|
||||
|
||||
| 시트 | 소스 파일 | 읽어야 할 심볼 |
|
||||
|---|---|---|
|
||||
| 통신 사양 | `Device/PLC/PLCContoller.Config.cs` | `PLCControllerPTOP` 생성자 인자(`ePLCNetType`, `PLCMMapFileType`, `isSimul`) — 이 파일은 18줄이며 주소 정의는 없다 |
|
||||
| PC→PLC (Write) | `Device/PLC/PLCController.Address.cs` | `eBitOutput`, `eWordOutput` enum 전수 |
|
||||
| PLC→PC (Read) | `Device/PLC/PLCController.Address.cs` | `eBitInput`, `eWordInput` enum 전수 |
|
||||
| 핸드셰이크 시퀀스 | `Sequences/SeqAutoRunPTOP.cs` | `CheckPageNo`, `CheckRecipeNoComp`, `CheckPageNoComp`, `WaitWeldingStart`, `WriteWeldComplete` |
|
||||
|
||||
**PLC 주소 규칙** — ⚠ **소스에 없는 값이다.** `M70000`·`D70000`·`D70500`은 `.cs` 전체에서 0건이고,
|
||||
근거는 분석 문서(`docs/분석/2026/06/17/171312_plc_map_io_direction_and_enum_alignment.md`)뿐이며
|
||||
그 문서와 `docs/분석/2026/06/20/141528_산출물문서_분석_및_PTOP_채움안.md`(**06/20 폴더다 — 06/17에는 없다**)가
|
||||
서로 다르게 기술한다. **산출물에 옮기기 전 소스로 재확인하고 `파일:라인`을
|
||||
병기하라. 확인되지 않으면 `미확인`으로 남긴다** (`rules.md` §검증·표기 판정표의 토큰만 쓴다).
|
||||
|
||||
- `eBitOutput` offset → `M70000 + offset`
|
||||
- `eBitInput` offset → `M70500 + offset`
|
||||
- `eWordOutput` offset → `D70000 + offset`
|
||||
- `eWordInput` offset → `D70500 + offset`
|
||||
- 두 번째 블록(0x65~, 양극 P) → `M70600~` (현재 미사용)
|
||||
|
||||
---
|
||||
|
||||
## B. 모션축·IO 맵 정의서
|
||||
|
||||
출력: `02.설계/IO_DB설계/모션축_IO맵_정의서.md`
|
||||
|
||||
| 시트 | 소스 파일 | 읽어야 할 심볼 |
|
||||
|---|---|---|
|
||||
| 통신·제어 구성 | `EquipmentSetup.cs:138` | `RegisterDevices(IDeviceRegistry registry)` 내 `registry.Register(...)` 호출. **주석 처리된 것이 다수다**(OCT·LBAD·CellTracker 등) — 활성 등록만 센다(현재 3건) |
|
||||
| 모션축 정의 | `docs/architecture.md §4` | AuroraACS(X/Y), AuroraMotionBoard(Z). **`RTC`(Scanner)는 이 문서에 0건** — 출처는 `ubisam-format-map/SKILL.md` §6 `PTOP 채움 시 참고값` 의 주요 디바이스 문장이다 |
|
||||
| I/O 맵 DI | `Device/IO/PAIX_PTOP.cs` | `ePrismaticDIAddress` enum — 채널 번호·신호명 |
|
||||
| I/O 맵 DO | `Device/IO/PAIX_PTOP.cs` | `ePrismaticDOAddress` enum — 채널 번호·신호명 |
|
||||
|
||||
**모션축 주의사항**:
|
||||
- X/Y 행정·속도·Home 방식 = 소스에 없음 → 전부 `(제안)` 표기.
|
||||
- `AuroraACS` = EtherCAT SPiiPlus. `AuroraMotionBoard` = **Ajin 모션 보드**
|
||||
(`AuroraDevices/AuroraMotionBoard/Ajin/AJINDevice.cs`·`AJINMotor.cs` — 벤더 구현이 이것 하나뿐이다).
|
||||
- ⚠ **런타임 벤더 선택은 모션이 아니라 IO 보드 쪽이다.** `eIOBoardType`(`Ajin`·`PAIX`·`ACS`)은
|
||||
`AuroraDevices/AuroraIO/IODevice.cs:18` 정의이고 `:154-158`에서 `IOUnitConfig.BoardType` 으로 분기한다.
|
||||
**IO 보드 벤더를 `Ajin`으로 단정하지 말 것** — PTOP 실제 IO는 `PAIX_PTOP` 이다.
|
||||
모션 보드 벤더 주의문과 혼동하지 않는다(둘은 다른 디바이스다).
|
||||
|
||||
---
|
||||
|
||||
## C. 기능명세서 / UI 설계
|
||||
|
||||
출력: `02.설계/UIUX_기능설계/기능명세서.md`
|
||||
|
||||
| 탭 | 소스 파일 | 읽어야 할 심볼 |
|
||||
|---|---|---|
|
||||
| 메뉴 구조 | `EquipmentSetup.cs:256` | `RegisterViews(IViewManager manager)` 내 `AddSubMenu(CommonViewIds.*, UserControl)`. **총 26건 중 8건이 주석 처리** → **활성 18건만 센다**(위 `RegisterDevices` 행과 같은 규칙). ⚠ `MenuId`·`ViewType`·`AuthLevel` 은 **소스에 없는 심볼이다** — 지어내지 마라 |
|
||||
| 메뉴 권한 | `EquipmentSetup.cs:261,266,289,302,310,318,323,330` | **`AddSubMenu` 는 2인자라 권한이 없지만 `MainMenu` 생성자 3번째 인자가 `PermissionLevel` 이다.** 메인메뉴 8건이 값을 가진다 — NONE ×6 / `:318` Device=LEVEL3 / `:323` Setting=LEVEL1. (`:288` 주석의 LEVEL4는 비활성, `:337` StreamDevice는 2인자 오버로드이며 `UseStream` 조건부라 권한 인자가 없다) |
|
||||
| MainView | `Views/Main/UCMainAutoRun*.cs` | 버튼·이벤트·바인딩 목록 |
|
||||
| RecipeView | `EquipmentSetup.cs` 등록부 | `UCRecipe`, `UCRecipeChangeHistory` — **공유 컴포넌트**이며 PTOP `Views/` 아래에 없다 |
|
||||
| ManualView | `EquipmentSetup.cs` 등록부 | `UCManualScannerOperation`, `UCManualModelFinder` — 공유 컴포넌트 |
|
||||
| MonitoringView | `EquipmentSetup.cs` 등록부 | `UCIOInterfaceView` 등 — 공유 컴포넌트 |
|
||||
| DeviceView | `EquipmentSetup.cs:318-319`·`:310-314` | `CommonViewIds.Device`(`DeviceSettingView`) + **Monitoring 메뉴의** `PLCBitMonitoring`·`PLCWordMonitoring`·`IOInterfaceView`. 탭 내용 기준은 `05-form-schemas.md` 8탭 표의 `DeviceView` 행 (`StreamDevice`는 `:337` 별도 메인메뉴이며 SettingView 탭 소속) |
|
||||
| SettingView | `EquipmentSetup.cs` 등록부 | `CommonViewIds.Setting`·`LogSetting`·`AutoBackupView` 등록 항목 |
|
||||
| VisionView | `EquipmentSetup.cs:342-343` | **`(해당없음)` — AuroraVision 미사용.** `// Vision (미사용)` + `//VisionFactory.RegisterViews(manager);` 주석 처리. `CommonViewIds.Scanner`·`PixelResolution`(`:303`·`:306`)은 비전 탭이 아니라 **Calibration 메뉴**(`:302`) 소속이다 |
|
||||
| OverView | `docs/architecture.md` | `CommonViewIds` 에 대응 메뉴는 없다 — 이 탭은 등록부가 아니라 **SW 개요**(플랫폼·OS·.NET·모션·레이저·PLC·비전)로 채운다 |
|
||||
| Sequence 흐름 | `Sequences/SeqAutoRunPTOP.cs` | Builder() 노드 목록 순서대로 |
|
||||
|
||||
> PTOP의 `Views/` 하위는 **`Main/`과 `Model/` 둘뿐이다.** Recipe·Manual·Monitoring 화면은
|
||||
> 공유 컴포넌트라 `EquipmentSetup.cs`의 `AddSubMenu(...)` 등록부에서 타입을 확인해야 한다.
|
||||
|
||||
**8탭 고정** (xlsx ref 호환): OverView / MainView / RecipeView / ManualView / DeviceView / SettingView / VisionView / Sequence 흐름
|
||||
|
||||
> ⚠ **탭 목록·탭별 내용의 상위 진실원은 `ubisam-deliverables/references/05-form-schemas.md`
|
||||
> §`C. 기능명세서 / UI 설계` 의 8탭 표다.**
|
||||
> 위 표는 "그 탭을 채우려면 어느 소스를 읽는가"만 말한다. 두 문서가 어긋나면
|
||||
> `05-form-schemas.md` 를 기준으로 삼고 **같은 편집에서 이 표를 맞춘다** (`docs/harness-ptop.md` §소비처 확인 의무).
|
||||
|
||||
> 위 표는 이 8탭을 **전부** 담고 있다. 추가로 있는 `메뉴 구조`·`MonitoringView` 행은 탭이 아니라
|
||||
> **탭을 채우기 위해 읽을 진실원**이다. 탭 수를 셀 때 포함하지 않는다.
|
||||
|
||||
---
|
||||
|
||||
## D. 제어 시퀀스·인터락 정의서
|
||||
|
||||
출력: `02.설계/시퀀스_인터록/제어시퀀스_인터락_정의서.md`
|
||||
|
||||
| 섹션 | 소스 파일 | 읽어야 할 심볼 |
|
||||
|---|---|---|
|
||||
| 메인 시퀀스 노드 흐름 | `SeqAutoRunPTOP.cs` | `AddAction`(17)·`AddDecision`(4)·`AddSubsequence`(3)와 `Flows(...)`(6). ⚠ `AddNode`·`AddTransition` 은 **소스에 없는 심볼이다**(Aurora API가 아니다) |
|
||||
| 단계별 동작 요약 | `SeqAutoRunPTOP.cs` | 각 노드 메서드 구현 첫 줄 주석·로그 |
|
||||
| 인터락 정의 | `Settings/LaserInterlockSetting.cs` | `HeadThetaInterlockEnabled`, `HeadThetaTolerance` |
|
||||
| 인터락 정의 (추가) | `SeqAutoRunPTOP.cs` | `LaserInterlock` 처리 |
|
||||
| 중알람 감시 | `Sequences/Monitoring/SeqAlarmMonitor.cs` | `PLC_HEAVY_ALARM_STATUS` 처리 (정의는 `PLCController.Address.cs`) — `SeqAutoRunPTOP.cs`에는 없다 |
|
||||
| 정지/에러 처리 | `SeqAutoRunPTOP.cs` | `OnStopped`, `OnForceError`, `ResumeMode` |
|
||||
|
||||
**Resume(bit15) 흐름**: `PLC_WELD_READY_REQ(0x0F)` 수신 → 팝업 + Auto→Manual 전환 → `PC_WELD_READY_ACK(0x0F)` ON → 1사이클 후 OFF.
|
||||
> 출처 주의 — 네 곳으로 나뉜다. 시퀀스 파일만 뒤지면 못 찾는다.
|
||||
> `UCMainAutoRunViewModel.cs:209`=수신 · `:270`=ACK ON · `:271-277`=**1초 펄스 OFF(`DispatcherTimer`)** ·
|
||||
> `SeqAutoRunPTOP.cs:875`=사이클 종료 OFF. **OFF 경로가 둘이다** — 1초 타이머와 사이클 종료.
|
||||
|
||||
---
|
||||
|
||||
## E. TactTime 산정서
|
||||
|
||||
출력: `02.설계/시퀀스_인터록/TactTime_산정서.md`
|
||||
|
||||
> **아래 상수는 반드시 소스에서 재확인하고 `파일:라인`을 병기한다.** 표에 적힌 값은 마지막 확인 시점의
|
||||
> 것이고, 심볼이 사라지거나 값이 바뀌었을 수 있다. 찾지 못하면 지어내지 말고 `미확인`으로 남긴다.
|
||||
|
||||
| 단위동작 | 소스 파일 | 상수/값 | 최종 확인 |
|
||||
|---|---|---|---|
|
||||
| Gate ON delay | `SeqAutoRunPTOP.cs` | `laserEmissionGateDelayMs` | 실재 확인 (2026-08-03) |
|
||||
| Jump 복귀 | `SeqAutoRunPTOP.cs` | `Thread.Sleep(500)` | 실재 확인 (2026-08-03) |
|
||||
| Pre/Post Scout | `SeqAutoRunPTOP.cs` | `SCOUT_PROCEED_DELAY_MS` | 실재 확인 (2026-08-03) |
|
||||
| 실제 발진 | `SeqAutoRunPTOP.cs` | 로그 `"TactTime: [Nms]"` — **런타임 값. 실측 없이 기재 금지** | — |
|
||||
| Page 검증 지연 | `SeqAutoRunPTOP.cs` | 해당 상수를 소스에서 찾아 기입 | 미확인 |
|
||||
| 준비 응답 지연 | `SeqAutoRunPTOP.cs` | 해당 상수를 소스에서 찾아 기입 | 미확인 |
|
||||
| 완료비트 지연 | `SeqAutoRunPTOP.cs` | 해당 상수를 소스에서 찾아 기입 | 미확인 |
|
||||
|
||||
---
|
||||
|
||||
## F. _task.md 진행률 기준 (현황 기준)
|
||||
|
||||
> **이 표는 실행 시점에 재산출한다.** 아래 값은 작성 당시 스냅샷이며, 그대로 복사하면 안 된다.
|
||||
> 각 단계 폴더의 실제 산출물 존재 여부를 세어 진행률을 다시 계산하라.
|
||||
|
||||
| 단계 | 상태 | 진행률(스냅샷) | 근거 |
|
||||
|---|---|---|---|
|
||||
| 1.분석/협의 | 미산출 | 미산출 — 실행 시 계산 | 슬롯 폴더의 실제 산출물 수로 산정 |
|
||||
| 2.설계 | 미산출 | 미산출 — 실행 시 계산 | 〃 |
|
||||
| 3.제작 | 미산출 | 미산출 — 실행 시 계산 | 〃 |
|
||||
| 4.셋업 | 미산출 | 미산출 — 실행 시 계산 | 〃 |
|
||||
| 5.양산 | 미산출 | 미산출 — 실행 시 계산 | 〃 |
|
||||
| 6.CS | 미산출 | 미산출 — 실행 시 계산 | 〃 |
|
||||
|
||||
> 이 값은 스킬 실행 시점 기준. 재실행 시 소스·폴더 현황 재확인 후 갱신.
|
||||
@ -1,191 +0,0 @@
|
||||
---
|
||||
name: ubisam-deliverable-rebuild
|
||||
description: >-
|
||||
타사 양식으로 받은 기존 산출물(Doc/산출물문서의 xlsx·pptx·docx)을 Ubisam 협업관리
|
||||
양식으로 분석·재배치·재생산·검증하는 3에이전트 오케스트레이터. "이 문서 Ubisam 양식으로
|
||||
바꿔줘", "타사 산출물 재생산", "협업관리 양식으로 재배치", "산출물 채움",
|
||||
"이 xlsx를 Ubisam 단계로 매핑", 그리고 **재생산에 대한** 후속 표현("산출물 재실행",
|
||||
"재생산 다시", "이 문서만 다시", "재생산 결과 보완", "이전 재생산 기반으로") 시 이 스킬을 쓴다.
|
||||
구분 — 빈 트리를 새로 까는 스캐폴딩은 `ubisam-deliverables`, PTOP 소스코드를 읽어
|
||||
설계 MD를 뽑는 것은 `ptop-deliverables`, 양식 enum 조회만이면 `ubisam-format-map`,
|
||||
**PTOP 아키텍처·구현·빌드 분석**은 `orchestrate-ptop-harness`다.
|
||||
맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 대상 문서를 먼저 확인한다.
|
||||
---
|
||||
|
||||
# ubisam-deliverable-rebuild — 타사 양식 → Ubisam 양식 재생산 오케스트레이터
|
||||
|
||||
**입력이 이미 존재하는 문서일 때** 쓰는 하네스다. 그 문서를 해부해 Ubisam 6단계 슬롯으로 재배치하고
|
||||
Ubisam 양식으로 다시 찍어낸 뒤 검증한다.
|
||||
|
||||
- 실행 모드: **서브 에이전트 + 점진적 생성-검증 루프**
|
||||
- 팀원: `ubisam-analyst` → `ubisam-producer` ↔ `ubisam-qa` (모두 `model: "opus"`)
|
||||
- 공유 스킬: `ubisam-format-map` (enum·스키마·슬롯 — 모든 팀원이 먼저 읽음)
|
||||
- 작업공간: `docs/[Ubisam산출물]/_workspace/`, 최종 산출물은 6단계 폴더 또는 사용자 지정 경로
|
||||
(**사용자 지정 경로를 쓴 경우** `00_rebuild_summary.md`에 실제 배치 경로표를 남기고,
|
||||
qa는 검증항목 #1(슬롯 누락)을 그 표 기준으로 판정한다)
|
||||
|
||||
## 형제 스킬과의 경계
|
||||
|
||||
| 상황 | 쓸 스킬 |
|
||||
|---|---|
|
||||
| 산출물 트리가 아예 없음 → 폴더·`_meta`·일감 카드 스캐폴딩 | `ubisam-deliverables` |
|
||||
| **기존 타사 문서**를 Ubisam 양식으로 재생산 | **이 스킬** |
|
||||
| PTOP **소스코드**를 읽어 설계 산출물 MD 생성 | `ptop-deliverables` |
|
||||
| enum·슬롯 값만 조회 | `ubisam-format-map` |
|
||||
|
||||
## 도구 사용 규칙
|
||||
|
||||
이 환경에는 `TeamCreate`/`TeamDelete` 도구가 **없다**. 팀은 아래 방식으로 구성한다.
|
||||
|
||||
- 팀원 기동: `Agent` 도구 — `subagent_type`에 에이전트 이름, `model: "opus"`, 병렬 구간은 `run_in_background: true`
|
||||
- 팀원 간 소통: `SendMessage` (`to`에 에이전트 **이름** 지정)
|
||||
- 진행 공유: `docs/[Ubisam산출물]/_workspace/_progress.md` 파일(진실원). 태스크 도구는 가용 시 보조
|
||||
- 산출물 전달: 파일 (`docs/[Ubisam산출물]/_workspace/`)
|
||||
|
||||
## Phase 0: 컨텍스트 확인
|
||||
|
||||
> **경로 인용 주의.** `docs/[Ubisam산출물]/`의 대괄호는 `Glob`/`Grep` **패턴**에서 문자클래스로
|
||||
> 해석돼 **에러 없이 0건**을 낸다(실측). 존재 확인은 Bash에서 따옴표로 감싸거나,
|
||||
> `Grep`/`Glob`의 `path` 인자(리터럴)로 하거나, 패턴을 `docs/\[Ubisam산출물\]/…`로 이스케이프한다.
|
||||
> 상세 → `ubisam-deliverables/references/00-harness.md` §경로 인용 의무.
|
||||
|
||||
|
||||
0. **진입 가드 2건. 둘 다 통과해야 Phase 1로 간다.**
|
||||
- **대상 미지정** — 사용자 발화에 어떤 문서를 재생산할지 없으면(예: "산출물 업데이트해줘")
|
||||
**아무 파일도 만들지 말고 되묻는다.** `Doc/산출물문서/`에 후보가 여럿이므로 임의로 고르면
|
||||
원하지 않은 문서에 3에이전트 풀런이 돌아간다.
|
||||
- **에이전트 미등록** — `ubisam-analyst`/`ubisam-producer`/`ubisam-qa`가 `Agent` 도구의
|
||||
subagent_type 목록에 없으면 시작하지 말고 "프로젝트 에이전트 미등록 — 세션 재시작 필요"를
|
||||
보고하고 중단한다. `.claude/agents/`에 파일을 방금 추가했다면 세션 재시작 전까지 호출되지 않는다.
|
||||
|
||||
1. 대상 문서와 작업 디렉토리를 정한다. 기본 작업공간 `docs/[Ubisam산출물]/_workspace/`.
|
||||
|
||||
2. **실행 모드 판별** (승인 목록을 확정하기 위해 먼저 한다):
|
||||
`docs/[Ubisam산출물]/_workspace/` 의 **산출물(`01_analyst_*`·`02_producer_*`·`03_qa_*`) 존재 여부**로
|
||||
판별한다 — 폴더 존재만 보면 로그·메모만 있어도 오판정한다(PTOP 하네스와 동일 규칙).
|
||||
- 하나도 없음 → **초기 실행** (Phase 1부터. 폴더가 있어도 초기 실행이다)
|
||||
- 일부만 있음 + 전체 재생산 요청 → **이어서 실행.** 있는 것 재사용, 없는 것만 생성, 이동 없음
|
||||
- 부분 수정 요청("OO만 다시") → **부분 재실행** (해당 에이전트만 재호출)
|
||||
- **새 입력 문서** 또는 "처음부터 다시" 명시 → **`전면`** (기존을 `_workspace_prev/`로 이동)
|
||||
|
||||
네 모드의 이름은 **`초기` / `이어서` / `부분` / `전면`** 이며, Phase 1·2에서 팀원에게 이 문자열
|
||||
그대로 전달한다. `_workspace_prev/` 이동은 **오케스트레이터만** 하고 팀원은 하지 않는다 —
|
||||
팀원은 모드를 "기존 산출물을 재사용할지" 판단에만 쓴다.
|
||||
|
||||
3. **스캐폴딩 필요 여부 판정.** `docs/[Ubisam산출물]/`가 없으면 `ubisam-deliverables` 스캐폴딩이
|
||||
선행되어야 한다. 그 스킬이 만들 폴더·파일 목록도 아래 승인 대상에 **합산**한다.
|
||||
|
||||
4. **승인 게이트.** 아래 **넷**을 **한 번에** 제시하고 승인받는다 (`rules.md` #2) —
|
||||
① 스캐폴딩분 ② 모드별 이동·덮어쓰기분(`_workspace_prev/` 이동 포함) ③ 재생산분
|
||||
④ **작업공간 관리 파일**(`_workspace/` 생성, `_progress.md`, `01_analyst_*`·`02_producer_*`·`03_qa_*` 중간 로그).
|
||||
④를 빼면 `ubisam-producer.md`의 "승인 범위 밖 금지"와 충돌해 작업 로그조차 못 쓴다.
|
||||
모드 판별·스캐폴딩 판정을 승인보다 먼저 하는 이유는, 그러지 않으면 승인 목록이
|
||||
실제 변경 범위와 어긋나기 때문이다.
|
||||
|
||||
5. **스캐폴딩 실행** (3에서 필요하다고 판정된 경우에만). `ubisam-deliverables` 스킬의 A단계를
|
||||
호출한다 — 대상이 이미 명시됐으므로 그 스킬의 진입 가드는 통과한다.
|
||||
그 스킬의 **진입 가드 승인과 A단계 0번 승인 모두** 위 4에서 통합으로 받았으므로 생략한다
|
||||
(승인을 두 번 걸지 않는다).
|
||||
완료를 확인한 뒤 다음 단계로 간다. 이 단계를 건너뛰면 producer가
|
||||
`docs/[Ubisam산출물]/{NN.단계}/`·`_meta/build_scripts/`에 쓰려는 순간 부모 폴더가 없어 실패한다.
|
||||
|
||||
6. `docs/[Ubisam산출물]/_workspace/_progress.md`를 만든다. **행 단위는 `{에이전트}:{문서}` 다** —
|
||||
문서가 3건이면 analyst·producer·qa 각 3행씩 **9행**이다(Phase 2가 문서 1건당 producer 1기동이므로).
|
||||
문서별로 따로 세야 "같은 결함 2회" 상한이 문서 단위로 작동한다. 문서가 1건이면 3행이다.
|
||||
재시도 카운트(`시도 N/2`)의 **진실원이 이 파일**이다 — `TaskCreate`/`TaskUpdate`는 서브에이전트
|
||||
컨텍스트에 없을 수 있어 도구에만 의존하면 횟수가 대화 맥락에만 남는다. 도구가 가용하면 병행 등록해도 된다.
|
||||
7. `ubisam-format-map` 스킬을 로드해 양식 기준을 확보한다.
|
||||
|
||||
> **Phase 1(analyst)부터** 시작한다. analyst를 건너뛰고 producer로 가면 매핑표가 없어 즉시 멈춘다.
|
||||
|
||||
## Phase 1: 분석 (analyst)
|
||||
|
||||
`Agent(subagent_type: "ubisam-analyst", model: "opus", run_in_background: true)` 로 기동.
|
||||
**문서가 1건이어도 `run_in_background` 를 뺀다는 뜻이 아니다** — `to: "main"` 회신이 막힌다.
|
||||
(아래 "문서가 여러 개면 병렬 기동"은 **개수**에 관한 말이지 이 플래그의 조건이 아니다.)
|
||||
대상 문서별로 구조 해부 · 타설비 잔재 식별 · 6단계 슬롯 매핑을 요청한다.
|
||||
|
||||
- 산출: `docs/[Ubisam산출물]/_workspace/01_analyst_{문서}.md`
|
||||
- 산출 경로와 **진행 원장 `_progress.md` 경로**를 모두 **저장소 루트 기준 절대경로로 변환해서** 전달한다 — 서브에이전트의 셸 작업 디렉토리는
|
||||
호출마다 초기화되므로 상대경로를 그대로 주면 파일이 엉뚱한 곳에 떨어지고, 실패 판정 ②(파일 미생성)가
|
||||
오판한다. `_workspace/`가 없으면 먼저 만든다.
|
||||
- **실행 모드(`초기`/`이어서`/`부분`/`전면`) 를 문자열 그대로 전달한다.** 빼면 analyst가 기존
|
||||
`01_analyst_*`를 재사용할지 판단할 근거가 없어 모드 판별이 승인 목록 산정에만 쓰이고 죽는다.
|
||||
- 문서가 여러 개면 문서별로 병렬 기동(`run_in_background: true`)한다. 서로 의존이 없기 때문이다.
|
||||
|
||||
## Phase 2: 재생산 ↔ 검증 (producer ↔ qa, 점진적)
|
||||
|
||||
`Agent(subagent_type: "ubisam-producer", model: "opus", run_in_background: true)` 로 기동한다.
|
||||
**qa 도 같은 형태로 기동한다.** `run_in_background` 를 빼면 `SendMessage` 의 `to: "main"` 회신이
|
||||
막힌다 — 그 값은 **백그라운드 서브에이전트 전용**이고, 세 에이전트 모두 오케스트레이터에 `main` 으로 보고한다.
|
||||
**기동은 오케스트레이터 전담이다** — analyst·producer·qa는 서로를 띄우지 않는다.
|
||||
Phase 1과 동일하게 **매핑표·산출·`_progress.md` 경로를 전부 저장소 루트 기준 절대경로로**,
|
||||
그리고 **실행 모드(`초기`/`이어서`/`부분`/`전면`) 를 문자열 그대로** 전달한다
|
||||
(서브에이전트의 셸 작업 디렉토리는 호출마다 초기화된다).
|
||||
|
||||
**문서가 여러 개면 문서 1건당 producer를 하나씩 기동한다.** 한 번에 다 맡기면 "1건 끝날 때마다 qa"라는
|
||||
아래 루프의 관측점이 사라져 점진 검증이 성립하지 않는다(전부 끝난 뒤 한꺼번에 검증하게 된다).
|
||||
|
||||
producer는 매핑표대로 산출물을 재생산한다 —
|
||||
**xlsx = `xlsxfill.py` 기반 신규 스크립트**(`_meta/build_scripts/`. 번들 `build_02설계_xlsx.py`는 데이터가
|
||||
하드코딩돼 있어 이 하네스에서 쓰지 않는다), pptx = `ubisam-ppt-make`, docx = `ubisam-docx`, md = 디자인 템플릿.
|
||||
|
||||
**문서 1건이 끝날 때마다** `Agent(subagent_type: "ubisam-qa", model: "opus", run_in_background: true)` 를
|
||||
기동해 검증한다(`run_in_background` 는 위 규칙과 동일 — 빼면 `to: "main"` 회신이 막힌다).
|
||||
전체 완성 후 일괄 검증하지 않는 이유는, 구조적 결함이 늦게 발견되면 이후 산출물 전부를 되돌려야 하기 때문이다.
|
||||
qa에는 **원본·매핑표·산출물 3개 경로를 모두 절대경로로** 준다 — 하나라도 빠지면 교차 대조가 성립하지 않는다.
|
||||
|
||||
- Critical/Major → producer가 수정 후 재검증. **같은 결함은 최대 2회까지만** 재작업을 요청하고,
|
||||
3회째에는 "미해결"로 확정해 사용자 판단 항목으로 올린다(무한 루프 방지).
|
||||
- Minor → 로그에 기록만 하고 진행
|
||||
|
||||
## Phase 3: 종합·보고
|
||||
|
||||
`docs/[Ubisam산출물]/_workspace/00_rebuild_summary.md`를 작성한다 — 필수 섹션:
|
||||
산출물 목록(경로) · 산출물별 stale 표기 · qa 판정 · **누락/미검증 항목과 사유** · 출처.
|
||||
이 파일이 "보고서에 누락을 명시"의 종착지다.
|
||||
|
||||
그 내용을 사용자에게도 요약 보고한다.
|
||||
보고 시 `rules.md` #11~13 출력 형식을 따른다 — 수정 대상 줄은 초록 화살표(→), 단어 단위는 주황, 미변경은 기본색.
|
||||
보고 끝에 **`docs/harness-ubisam.md`를 갱신할 부분이 있는지 묻는다**(`rules.md` #6).
|
||||
문서 수가 많아 10분을 넘기므로 **Phase 전환마다 진행 상황을 한 줄로 보고한다**(`rules.md` #10).
|
||||
중간 산출물(`docs/[Ubisam산출물]/_workspace/`)은 지우지 않고 보존한다 — 사후 감사 추적에 쓴다.
|
||||
|
||||
## 데이터 전달 · 에러 핸들링
|
||||
|
||||
전달 = 파일(`_workspace/`) + `SendMessage`(`to`+`summary`+`message`) + `_progress.md`(진행 원장).
|
||||
상세 표 2종 → [references/protocol.md](references/protocol.md)
|
||||
|
||||
**에러 핵심 3가지:**
|
||||
- 실패 = ①에러 종료 ②산출 파일 미생성 ③빈 파일·헤더만. **지연은 실패가 아니다.**
|
||||
- 재시도는 같은 `Agent` 재호출이며 `SendMessage` 독촉이 아니다. 횟수는 `_progress.md`의 `시도` 칸이 진실원.
|
||||
- **analyst 2회 실패는 중단**(매핑표 부재 = 기준 부재). producer/qa 실패는 해당 문서만 건너뛰고 누락 명시.
|
||||
|
||||
## 테스트 시나리오
|
||||
|
||||
정상 흐름 1건(타사 xlsx 시트 10개 → 6단계 슬롯 매핑) + 에러 흐름 1건(원본 쓰기 잠김 → 부분 성공 보고)
|
||||
→ [references/test-scenarios.md](references/test-scenarios.md)
|
||||
|
||||
## 후속 작업
|
||||
|
||||
- "OO만 다시" → 해당 에이전트만 재호출하고 이전 `docs/[Ubisam산출물]/_workspace/` 산출물 기반으로 변경분만 갱신
|
||||
- 각 에이전트 정의의 `재호출 지침` 섹션이 이전 산출물 처리 방식을 규정한다
|
||||
- **연쇄 무효화 확인.** `01_analyst_*`가 갱신되면 그에 의존한 `02_producer_*`·산출물·`03_qa_*`는
|
||||
단순 "재사용"이 아니라 **정합성 미확인**이다. 함께 재실행할지 사용자에게 묻고, 거절하면
|
||||
`이전 실행 결과 재사용 — 매핑표 갱신으로 정합성 미확인(YYYY-MM-DD)`으로 표기한다.
|
||||
- **stale 표기 의무.** 산출물별로 "이번 실행에서 갱신됨(YYYY-MM-DD)" / "이전 실행 결과 재사용(YYYY-MM-DD)"을
|
||||
① 채팅 보고 ② `_workspace/00_rebuild_summary.md` ③ **산출물 파일 자체** — `.md`는 첫 줄, **xlsx는 첫 시트 배너 아래 셀, pptx는 `history` 슬라이드 최신 행**에
|
||||
같은 문구를 남긴다 — 세 곳에 남긴다
|
||||
(PTOP 하네스와 동일 규칙). 파일만 열어보는 사람이 최신 여부를 알 수 있어야 한다.
|
||||
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] 대상 문서의 모든 시트/슬라이드가 매핑표에 등장 (누락 0)
|
||||
- [ ] `01_analyst_*` → `02_producer_*` → `03_qa_*`가 전부 존재하거나, 없으면 사유가 요약에 명시됨
|
||||
- [ ] qa 판정이 통과/조건부 통과/실패 중 하나로 기록됨
|
||||
- [ ] 타설비 잔재가 전수 검색으로 확인됨
|
||||
- [ ] 창작(매핑표에 없는 내용) 0건
|
||||
- [ ] 매핑표의 `[추론]` 항목이 산출물에서 사실로 승격되지 않음 (`rules.md` #15·#16, qa 검증항목 11)
|
||||
- [ ] `00_rebuild_summary.md`가 존재하고 누락·미검증 항목이 적혀 있음
|
||||
- [ ] 한글이 깨지지 않음 (UTF-8)
|
||||
@ -1,38 +0,0 @@
|
||||
# 데이터 전달 · 에러 핸들링 (ubisam-deliverable-rebuild)
|
||||
|
||||
`SKILL.md` 본문에서 분리한 상세 규약이다. 오케스트레이터가 Phase 1~3 실행 중 참조한다.
|
||||
|
||||
## 데이터 전달 프로토콜
|
||||
|
||||
| 대상 | 방식 |
|
||||
|---|---|
|
||||
| 진행 추적 | `docs/[Ubisam산출물]/_workspace/_progress.md` (진실원) + `TaskCreate`/`TaskUpdate`(가용 시 보조) |
|
||||
| 산출물 전달 | 파일 — `docs/[Ubisam산출물]/_workspace/{phase}_{agent}_{artifact}.{ext}` (예: `01_analyst_sw점검결과.md`) |
|
||||
| 실시간 조율 | `SendMessage` — `to`(이름) + `summary`(5~10단어, **필수**) + `message`. 문서가 여러 건이면 **같은 이름의 에이전트가 여러 개** 뜬다. 그때는 이름 대신 **에이전트 ID**로 지정하고, ID를 `_progress.md` 행에 기록해 둔다 |
|
||||
| 결과 수집 | `Agent` 반환값 |
|
||||
|
||||
> 서브에이전트가 오케스트레이터(메인 대화)에 회신할 때는 `to: "main"` 이며,
|
||||
> 이는 **백그라운드로 기동된 서브에이전트만** 쓸 수 있다.
|
||||
|
||||
## 에러 핸들링
|
||||
|
||||
재시도 횟수는 **`docs/[Ubisam산출물]/_workspace/_progress.md`의 `시도` 칸**에 기록한다(없으면 0회).
|
||||
저장소 루트의 `_workspace/`(PTOP 하네스)와 **다른 곳이다** — 베어 경로로 쓰지 않는다.
|
||||
`TaskUpdate`가 가용하면 병행 기록해도 되나 판정 근거는 파일이다.
|
||||
|
||||
**실패 판정 기준(관측 가능해야 한다):** ① 에이전트가 에러로 종료 ② 지정 산출 파일이 생성되지 않음
|
||||
③ 산출 파일이 비었거나 헤더만 있음 — 셋 중 하나면 실패로 본다. **지연은 실패가 아니다.**
|
||||
재시도는 같은 `Agent` 호출을 다시 하는 것을 뜻한다(`SendMessage`로 독촉하는 것이 아니다).
|
||||
|
||||
| 상황 | 처리 |
|
||||
|---|---|
|
||||
| **analyst** 실패 (2회) | 매핑표가 없으면 재생산 기준이 없다 → **하네스를 중단**한다. 중단 **전에** `00_rebuild_summary.md`를 "중단 — analyst 2회 실패" 1섹션만으로 먼저 작성해 흔적을 파일에 남기고, 사용자에게 보고한다. 이 경우만 "진행" 규칙의 예외다 |
|
||||
| **producer/qa** 실패 | 1회 재시도. 재실패 시 해당 문서만 건너뛰고 나머지를 계속 진행, **보고서에 누락을 명시** |
|
||||
| **산출물** 파일 잠금 | 작업 사본으로 진행, "산출물 미갱신" 표시 후 사용자에게 파일 닫기 요청. (입력 원본은 읽기 전용이므로 애초에 쓰지 않는다) |
|
||||
| 에이전트 타입 미등록 | Phase 0 가드에서 중단 → "세션 재시작 필요" 보고 |
|
||||
| 슬롯 전용 xlsx 스크립트 부재 | producer가 `xlsxfill.py` 기반으로 신규 작성 (`ubisam-producer.md` 참조). 수작업 셀 편집은 금지 |
|
||||
| 데이터 상충 | 삭제하지 않고 출처를 병기 |
|
||||
| 결함 2회 재작업 후 잔존 | "미해결" 확정, 사용자 판단 항목으로 상신 |
|
||||
|
||||
> 표의 행을 늘리거나 줄이면 `SKILL.md` 본문의 요약 3줄도 **같은 편집에서** 확인한다
|
||||
> (`docs/harness-ptop.md` §소비처 확인 의무).
|
||||
@ -1,37 +0,0 @@
|
||||
# 테스트 시나리오 — `ubisam-deliverable-rebuild`
|
||||
|
||||
정상 흐름 1건 + 에러 흐름 1건. 하네스를 고친 뒤 이 두 경로를 따라가 완주 여부를 확인한다.
|
||||
|
||||
## 정상 흐름 — 타사 xlsx 재생산
|
||||
|
||||
대상: `Doc/산출물문서/23. SW 점검 결과_PTOP_UBISAM_260616_….xlsx`
|
||||
|
||||
1. **analyst** 가 `openpyxl` 로 시트 10개를 읽어 문서 전체의 **주(主) 단계를 1줄로 선언**하고,
|
||||
시트별로 근거와 함께 슬롯에 매핑한다:
|
||||
|
||||
| 시트 | 배치 슬롯 |
|
||||
|---|---|
|
||||
| FlowChart · Device · Sequence · IO List · Motor List | 2.설계 |
|
||||
| Overall | 3.제작 |
|
||||
| Pos Teaching | 4.셋업 (티칭 좌표는 HW 점검 슬롯) |
|
||||
| SW Version | 5.양산 |
|
||||
| Gantt | 01.분석협의·마스터플랜 (일정 산출물) |
|
||||
| `[작업일지]` | 작업일지 |
|
||||
|
||||
→ **10/10 배치, 누락 0.** 동시에 타설비 잔재를 식별한다.
|
||||
2. **producer** 가 Ubisam 양식 시트로 재배치하고 값마다 출처 주석을 기입한다.
|
||||
3. **qa** 가 enum · 슬롯 · 잔재 · 출처를 전수 대조 → Critical 0건 → 통과 보고.
|
||||
|
||||
> 검증 통과 기준은 "시트 수가 맞다"가 아니라 **매핑표 ↔ 산출물 ↔ 원본 3자 대조**다.
|
||||
> 검색으로 0건이 나오면 결함 없음이 아니라 검색식·`.gitignore` 를 먼저 의심한다
|
||||
> (`ubisam-qa.md` 작업 원칙 5 참조).
|
||||
|
||||
## 에러 흐름 — 대상 xlsx가 Excel에서 열려 쓰기 잠김
|
||||
|
||||
1. **producer** 가 잠금을 감지하고 작업 사본으로 생성한 뒤 **"원본 미반영"** 을 로그에 남긴다.
|
||||
2. **qa** 가 원본 미반영을 **Major** 로 표기한다 — 산출물은 만들어졌으나 반영되지 않았으므로
|
||||
침묵하면 통과로 오해된다.
|
||||
3. 사용자에게 **"원본을 닫고 재실행해야 함"** 을 명시해 보고한다.
|
||||
|
||||
> 이 흐름의 핵심은 "실패했다"가 아니라 **부분 성공을 부분 성공으로 보고하는 것**이다.
|
||||
> `00_rebuild_summary.md` 의 누락·미검증 절이 그 종착지다.
|
||||
@ -1,49 +0,0 @@
|
||||
---
|
||||
name: ubisam-deliverable
|
||||
description: Ubisam 산출물 재생산 하네스의 오케스트레이터. 타사 양식 산출물(Doc/산출물문서의 xlsx·pptx)을 Ubisam 협업관리 양식(상태4·유형9·6단계 슬롯·필드 스키마)으로 분석·재배치·재생산·검증하는 분석가·작성가·검증가 3에이전트 팀을 구동한다. "Ubisam 산출물 만들어/재생산/재배치", "협업관리 양식으로", "산출물 채움", "이 문서 Ubisam 단계로", 그리고 후속 표현("다시 실행", "재실행", "업데이트", "수정", "보완", "OO만 다시", "이전 결과 기반") 시 반드시 이 스킬을 사용할 것. 단순 양식 질문은 ubisam-format-map만으로 답할 수 있다.
|
||||
---
|
||||
|
||||
# ubisam-deliverable — Ubisam 산출물 재생산 오케스트레이터
|
||||
|
||||
타사 양식 산출물을 **Ubisam 양식으로 재생산**하는 3에이전트 팀(생성-검증 파이프라인)을 조율한다.
|
||||
|
||||
- 실행 모드: **에이전트 팀** (분석 → 재생산 ↔ 검증)
|
||||
- 팀원: `ubisam-analyst`, `ubisam-producer`, `ubisam-qa` (모두 `model: "opus"`)
|
||||
- 공유 스킬: `ubisam-format-map` (양식 enum·스키마·슬롯 매핑 — 모든 팀원이 먼저 읽음)
|
||||
- 작업공간: 대상별 `_workspace/`, 최종 산출물은 지정 경로 또는 `docs/[Ubisam산출물]/` 하위
|
||||
|
||||
## Phase 0: 컨텍스트 확인
|
||||
1. 대상 산출물과 작업 디렉토리를 정한다. 기본 작업공간: `docs/[Ubisam산출물]/_workspace/`.
|
||||
2. 실행 모드 판별:
|
||||
- `_workspace/` 없음 → **초기 실행**(Phase 1부터)
|
||||
- `_workspace/` 있음 + 부분 수정 요청 → **부분 재실행**(해당 에이전트만)
|
||||
- `_workspace/` 있음 + 새 입력 → **새 실행**(기존을 `_workspace_prev/`로 이동)
|
||||
3. `ubisam-format-map` 스킬을 로드해 양식 기준을 확보한다.
|
||||
|
||||
## Phase 1: 분석 (analyst)
|
||||
- `ubisam-analyst`에게 대상 문서를 주고 구조 분석·타설비 잔재 식별·6단계 슬롯 매핑을 요청한다.
|
||||
- 산출: `_workspace/01_analyst_{문서}.md`.
|
||||
|
||||
## Phase 2: 재생산 ↔ 검증 (producer ↔ qa, 점진적)
|
||||
- `ubisam-producer`가 매핑·채움 항목으로 산출물을 재생산한다(xlsx=openpyxl, pptx=`ubisam-ppt-make`, md).
|
||||
- 각 문서 완성 직후 `ubisam-qa`가 **점진적으로** 검증(enum·슬롯·스키마·잔재·출처·자동화).
|
||||
- Critical/Major는 producer가 수정 후 재검증. 통과까지 반복(최대 합리적 횟수, 1회 재시도 원칙).
|
||||
|
||||
## Phase 3: 종합·보고
|
||||
- 최종 산출물 경로, qa 통과 여부, 미정/TBD 항목, 출처를 사용자에게 요약 보고한다.
|
||||
- 중간 산출물(`_workspace/`)은 보존(감사 추적).
|
||||
|
||||
## 데이터 전달 프로토콜
|
||||
- 태스크 기반(`TaskCreate`/`TaskUpdate`)으로 진행 추적, 파일 기반(`_workspace/`)으로 산출물 전달, 메시지 기반(`SendMessage`)으로 실시간 조율.
|
||||
- 파일명: `{phase}_{agent}_{artifact}.{ext}` (예: `01_analyst_sw점검결과.md`).
|
||||
|
||||
## 에러 핸들링
|
||||
- 에이전트 실패 시 1회 재시도, 재실패하면 해당 결과 없이 진행하고 보고서에 누락을 명시한다.
|
||||
- 상충 데이터는 삭제하지 않고 출처를 병기한다.
|
||||
|
||||
## 테스트 시나리오
|
||||
- **정상 흐름**: `23. SW 점검 결과` xlsx → analyst가 SW Version/Gantt를 6단계 슬롯(제작/양산 등)에 매핑 → producer가 Ubisam 양식 시트로 재배치 → qa가 enum/스키마 검증 → 통과 보고.
|
||||
- **에러 흐름**: 대상 파일이 편집기 잠금 → producer가 잠금 경고·작업 사본 진행 → qa가 원본 미반영 표시 → 사용자에게 "원본 닫기 후 반영 필요" 보고.
|
||||
|
||||
## 후속 작업
|
||||
- 부분 수정 요청("OO만 다시")은 해당 에이전트만 재호출하고, 이전 `_workspace/` 산출물을 기반으로 변경분만 갱신한다.
|
||||
@ -1,41 +0,0 @@
|
||||
# ubisam-deliverables (Claude Code Skill)
|
||||
|
||||
Ubisam 협업관리 구조로 **어떤 프로젝트에서든 동일한 산출물 트리·양식**을 생성·관리하는 스킬.
|
||||
`ref/` 원본 파일 없이도 동작하도록 양식 골격을 MD에 내장(자기완결).
|
||||
|
||||
## 설치
|
||||
대상 프로젝트에 폴더째 복사:
|
||||
```
|
||||
<프로젝트>/.claude/skills/ubisam-deliverables/
|
||||
```
|
||||
(개인 전역으로 쓰려면 `~/.claude/skills/` 아래에 둬도 됨.)
|
||||
|
||||
## 사용
|
||||
- "Ubisam 산출물 구조 만들어줘" / "산출물 트리 스캐폴딩" → 트리 생성(A).
|
||||
- "이 양식 채워줘"(`docs/[Ubisam산출물]/산출물문서/양식/`에 파일 투입 후) → 양식 채움(B).
|
||||
|
||||
## 구성
|
||||
```
|
||||
SKILL.md # 인덱스 + 오케스트레이션(0 하네스 / A 스캐폴딩 / B 채움)
|
||||
references/
|
||||
00-harness.md # 호스트 레포 맞물림·비침습 계약
|
||||
01-tree.md # 목표 트리·배치 규칙
|
||||
02-enums.md # 상태4·유형9·티켓코드
|
||||
03-schema.md # 일감·프로젝트 스키마
|
||||
04-stage-deliverables.md# 6단계↔슬롯 매핑
|
||||
05-form-schemas.md # 설계 양식 시트·컬럼(ref 불필요)
|
||||
06-procedure.md # 분석→채움 절차
|
||||
07-fill-mapping.md # 프로젝트 분석→산출물 필드 자동 채움
|
||||
08-design-system.md # 색상 팔레트·배너·뱃지·진행률 HTML 템플릿
|
||||
09-pptx-integration.md # PPTX 생성 — ubisam-ppt-make 연동 절차
|
||||
xlsxfill.py # xlsx 스타일 상수 + scratch-build API
|
||||
build_02설계_xlsx.py # 02.설계 xlsx 4종 생성 (독립 실행)
|
||||
build_02설계_pptx.py # 02.설계 SW_설계서.pptx 생성 (독립 실행)
|
||||
templates/
|
||||
_task.template.md # 일감 카드 템플릿
|
||||
project.yaml.template # 프로젝트 메타 템플릿
|
||||
```
|
||||
|
||||
## 원칙
|
||||
- 모든 MD 200줄 이내 (`rules.md` #4), 상호 링크로 매핑.
|
||||
- enum 고정(상태/유형) · 출처 명시 · 조건부 서식 보존 · 레포 루트 보호.
|
||||
@ -1,106 +0,0 @@
|
||||
---
|
||||
name: ubisam-deliverables
|
||||
description: >-
|
||||
Ubisam 협업관리(칸반) 구조에 맞춰 프로젝트 산출물을 docs/[Ubisam산출물]/ 트리로
|
||||
구성·관리한다. "산출물 구조 만들기", "Ubisam 양식으로 채우기", "설계/셋업/양산 산출물
|
||||
정리", "산출물 트리 스캐폴딩" 같은 요청에 사용. 6단계(분석·설계·제작·셋업·양산·CS)
|
||||
폴더·_meta enum·일감 카드·LGPRI 양식 채움 절차를 제공.
|
||||
구분 — 이미 있는 타사 문서를 Ubisam 양식으로 재생산하는 것은 `ubisam-deliverable-rebuild`,
|
||||
PTOP 소스코드를 읽어 설계 MD를 뽑는 것은 `ptop-deliverables`, enum 조회만이면 `ubisam-format-map`,
|
||||
**PTOP 아키텍처·구현·빌드 분석**은 `orchestrate-ptop-harness`.
|
||||
맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 무엇을 만들지 먼저 확인한다.
|
||||
---
|
||||
|
||||
# Ubisam 산출물 관리 SKILL
|
||||
|
||||
UBISAM 협업관리는 *프로젝트(칸반 보드 1개) → 일감(6단계) → 단계별 산출물* 로 운영된다.
|
||||
이 스킬은 그 구조를 **소스 레포의 `docs/[Ubisam산출물]/` 하위 파일 트리로 미러링**하고,
|
||||
LGPRI 제공 양식을 프로젝트 내용으로 채워 관리한다.
|
||||
|
||||
## 언제 쓰나
|
||||
- 새 프로젝트에 산출물 트리를 깔 때(스캐폴딩).
|
||||
- `docs/[Ubisam산출물]/산출물문서/양식/`에 들어온 빈 양식을 프로젝트 내용으로 채울 때.
|
||||
(입력 원본은 저장소 루트 `Doc/산출물문서/` — 읽기 전용이며 이 스킬이 만들지 않는다)
|
||||
- 단계별 일감 상태/진행률을 갱신할 때.
|
||||
|
||||
## 참조 맵 (모두 200줄 이내, 필요한 것만 읽기)
|
||||
| # | 파일 | 용도 |
|
||||
|---|---|---|
|
||||
| 0 | [references/00-harness.md](references/00-harness.md) | **하네스**: 호스트 레포 맞물림·비침습 계약 (먼저 읽기) |
|
||||
| 1 | [references/01-tree.md](references/01-tree.md) | 목표 트리·배치 규칙·우선순위 |
|
||||
| 2 | [references/02-enums.md](references/02-enums.md) | 상태 4종·유형 9종·티켓코드 규칙 |
|
||||
| 3 | [references/03-schema.md](references/03-schema.md) | 일감 필드·프로젝트 메타 스키마 |
|
||||
| 4 | [references/04-stage-deliverables.md](references/04-stage-deliverables.md) | 6단계↔산출물 슬롯 매핑 |
|
||||
| 5 | [references/05-form-schemas.md](references/05-form-schemas.md) | 설계 양식 시트·컬럼 스키마 |
|
||||
| 6 | [references/06-procedure.md](references/06-procedure.md) | 분석→채움 절차·조건서식 보존 |
|
||||
| 7 | [references/07-fill-mapping.md](references/07-fill-mapping.md) | 프로젝트 분석→산출물 필드 자동 채움 매핑 |
|
||||
| **8** | [**references/08-design-system.md**](references/08-design-system.md) | **색상 팔레트·배너·뱃지·진행률 HTML 템플릿** |
|
||||
| **9** | [**references/09-pptx-integration.md**](references/09-pptx-integration.md) | **PPTX 생성 — ubisam-ppt-make 연동 절차·슬라이드 매핑** |
|
||||
| T | [templates/](templates/) | `_task` 카드·`project.yaml` 템플릿 |
|
||||
|
||||
## 진입 가드 (먼저 확인)
|
||||
|
||||
발화에 **무엇을 원하는지**가 없으면(예: "산출물 업데이트해줘"·"다시 실행해줘"·"보완해줘") 스캐폴딩을 바로 깔지 말고 되묻는다.
|
||||
이 스킬은 폴더·`_task.md`·`README.md`를 수십 개 만들므로, 오발동 시 되돌리는 비용이 크다.
|
||||
|
||||
되물을 것: "① 트리를 새로 깔까요, ② 소스 기준으로 설계 MD를 뽑을까요(`ptop-deliverables`),
|
||||
③ 기존 문서를 Ubisam 양식으로 재생산할까요(`ubisam-deliverable-rebuild`)?"
|
||||
|
||||
생성할 폴더·파일 목록을 제시하고 승인을 받은 뒤 A단계를 시작한다 (`rules.md` #2).
|
||||
|
||||
## 실행 순서 (오케스트레이션)
|
||||
|
||||
### 0. 하네스 진입 (항상 먼저)
|
||||
[00-harness.md](references/00-harness.md)의 비침습 계약 확인 → 호스트 `CLAUDE.md`·소스에서 프로젝트 사실 읽기 → `project_code`/`project_name` 자동 추정(실패 시 질문).
|
||||
|
||||
### A. 스캐폴딩 (트리 생성)
|
||||
0. **생성할 폴더·파일 목록을 사용자에게 제시하고 승인을 받는다** (`rules.md` #2).
|
||||
이 단계는 수십 개 파일을 만들므로 되돌리는 비용이 크다.
|
||||
1. 소스 레포 루트의 `.claude/`·`CLAUDE.md`·`rules.md`는 **건드리지 않는다**.
|
||||
2. `docs/[Ubisam산출물]/` 아래에 [01-tree.md](references/01-tree.md)의 트리를 생성:
|
||||
- `_meta/`(enum·스키마) ← [02](references/02-enums.md)·[03](references/03-schema.md) 내용으로 채움.
|
||||
- `01.분석협의 ~ 06.CS/` 6단계 폴더 + 각 `_task.md`(템플릿: [templates/_task.template.md](templates/_task.template.md)).
|
||||
- 각 단계 산출물 슬롯 하위폴더 + `.gitkeep` ← [04](references/04-stage-deliverables.md).
|
||||
- `docs/[Ubisam산출물]/산출물문서/`(+`양식/` 드롭존), `ref/`, `[분석]/`, `[작업일지]/`.
|
||||
> **저장소 루트 `Doc/산출물문서/`와 다른 곳이다.** 전자는 스캐폴딩이 만드는 트리 내부,
|
||||
> 후자는 **입력 원본 드롭존**(스캐폴딩 대상이 아니며 읽기 전용).
|
||||
3. `RULES.MD`(산출물 영역 규칙) + `README.md`(트리 한눈에 + 단계별 현황 뱃지 표)를 루트에 작성.
|
||||
4. `_meta/project.yaml`의 `{...}` 토큰은 프로젝트 정보로 교체. 모르면 그대로 두고 사용자에게 질문.
|
||||
5. **디자인 적용**: [08-design-system.md](references/08-design-system.md) —
|
||||
`_task.md`는 **§7 완성 템플릿**을 그대로 적용하고, `README.md`는 **§7 템플릿이 없으므로**
|
||||
§1 배너 + §2·§3 뱃지 + §4 진행률 바를 조합해 단계별 현황 표를 만든다.
|
||||
|
||||
### B. 양식 채움 (산출물 생성)
|
||||
[06-procedure.md](references/06-procedure.md) 절차를 따른다: 분석 → 타설비 잔재 식별 → 프로젝트 내용 채움(출처 명시) → 슬롯 배치 → `_task.md` 진행률 갱신 → `[작업일지]` 기록.
|
||||
- **자동 채움**: 호스트 분석 사실을 [07-fill-mapping.md](references/07-fill-mapping.md) 매핑으로 산출물 필드에 기입.
|
||||
- **디자인 적용**: 생성하는 모든 MD에 [08-design-system.md](references/08-design-system.md) 배너·뱃지·섹션헤더 삽입.
|
||||
- 양식의 시트·컬럼 골격은 [05-form-schemas.md](references/05-form-schemas.md) 참조(ref 불필요).
|
||||
- 상태/유형 값은 [02-enums.md](references/02-enums.md) enum만 사용(임의 신규값 금지).
|
||||
|
||||
### C. PPTX 생성 — ubisam-ppt-make 스킬에 위임 (직접 생성 금지)
|
||||
> **이 스킬은 PPTX를 직접 생성하지 않는다.**
|
||||
> PPTX 렌더링은 반드시 `ubisam-ppt-make` 스킬의 `build_deck.py`를 통해서만 수행한다.
|
||||
> 이 스킬의 역할은 ① 슬라이드 spec JSON 준비 ② `build_deck.py` 호출 ③ 결과 슬롯 배치.
|
||||
|
||||
상세 절차 → [09-pptx-integration.md](references/09-pptx-integration.md)
|
||||
|
||||
- **2.설계 완료** → `SW_설계서.pptx`: `PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_pptx.py`
|
||||
- **5.양산 완료 or 명시 요청** → `<설비명>_HMI_매뉴얼.pptx`: MD → spec JSON → `ubisam-ppt-make/build_deck.py`
|
||||
- 레이아웃·디자인 토큰은 **ubisam-ppt-make/SKILL.md 기준**. 이 스킬에서 재정의 금지.
|
||||
|
||||
## 불변 규칙 (항상 지킴)
|
||||
- **MD 200줄 상한** (`rules.md` #4): 새 문서가 길어지면 분할하고 상호 링크(`[[...]]`/상대경로)로 매핑.
|
||||
- **enum 고정**: 상태·유형은 회사 공통 마스터. 새 값 발견 시 `_meta/*.enum.md` 먼저 갱신.
|
||||
- **출처 명시**: 채운 내용은 원본 파일·코드 경로를 문서에 남긴다.
|
||||
- **추론 표기**: 원본을 확인하지 않고 판단으로 채운 값·해석은 문장 앞에 `[추론]` (`rules.md` #15·#16).
|
||||
자동 채움 단계가 게이트 없이 값을 만들 수 있는 유일한 경로이므로 여기서 표기가 빠지면 이후 검증가가 잡을 근거가 없다.
|
||||
확인 후에는 표기를 떼고 출처로 바꾼다. 검색은 **`\[추론\]`** 로 이스케이프한다(대괄호=문자클래스).
|
||||
- **디자인 의무**: 생성하는 모든 산출물 MD에 [08-design-system.md](references/08-design-system.md) 배너·뱃지 적용. 텍스트 단독 표기 금지.
|
||||
- **xlsx 재생산** (**`ptop-deliverables` 경로 한정** — rebuild 경로는 `xlsxfill` 기반 신규 스크립트):
|
||||
`references/build_02설계_xlsx.py` + `xlsxfill.py`로 완전 독립 생성(ref 불필요). 스타일 상수는 xlsxfill.py에 하드코딩. 저장소 루트에서 `PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_xlsx.py` 한 줄 실행 (`cd` 금지 — 출력 경로가 어긋난다).
|
||||
- **pptx 재생산**: `references/build_02설계_pptx.py`로 완전 독립 생성(ref 불필요). 슬라이드 스펙 내장, `build_deck.py` 자동 호출. `PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_pptx.py` 한 줄 실행.
|
||||
이 스크립트는 `__file__` 기준 절대경로를 쓰므로 cwd와 무관하다 (xlsx 쪽은 상대경로라 반드시 저장소 루트에서 실행).
|
||||
- **루트 보호**: 레포 루트 `rules.md` > 본 산출물 `RULES.MD`(스코프 하위).
|
||||
|
||||
> 단독 호출로 마무리할 때: 보고는 `rules.md` #11~13 출력 형식(수정 줄=초록 화살표, 단어=주황, 미변경=기본색)을
|
||||
> 따르고, 끝에 관련 `.md`를 갱신할 부분이 있는지 묻는다(`rules.md` #6).
|
||||
@ -1,68 +0,0 @@
|
||||
# 00 · 하네스 (호스트 프로젝트 맞물림 설계)
|
||||
|
||||
> 이 스킬이 **이미 CLAUDE.md·.claude가 있는 임의의 소스 레포**에 들어가 기존 에이전트와
|
||||
> 충돌 없이 맞물려 동작하기 위한 계약. SKILL.md가 가장 먼저 참조한다.
|
||||
|
||||
## 비침습 계약 (절대 규칙)
|
||||
- **읽기만**: 호스트의 `CLAUDE.md`, `.claude/`, `RULES.md`, `src/`·소스코드는 입력으로만 읽는다.
|
||||
- **쓰기 격리**: 모든 생성/수정은 `docs/[Ubisam산출물]/` 하위로 한정.
|
||||
- **경로 인용 의무 — 수단마다 방법이 다르다.** 이 경로의 대괄호는 문자클래스로 해석된다.
|
||||
**틀리면 에러가 아니라 조용히 0건**이 나오므로 검증이 통째로 헛돈다. (실측 확인)
|
||||
|
||||
| 수단 | 올바른 방법 |
|
||||
|---|---|
|
||||
| 셸(bash) | 따옴표로 감싼다 — `"docs/[Ubisam산출물]/…"` |
|
||||
| `Glob` 도구의 `pattern` | **백슬래시 이스케이프** — `docs/\[Ubisam산출물\]/**/*.xlsx` (따옴표는 무효) |
|
||||
| `Grep` 도구의 `glob` | 동일하게 이스케이프하거나, 아래처럼 `path`로 분리 |
|
||||
| `Grep`/`Glob`의 `path` | **리터럴로 취급되므로 그대로** 쓴다 — `path: "docs/[Ubisam산출물]"` + `pattern: "**/*"` |
|
||||
| Python `os.path` | 무관 (그대로) |
|
||||
- **임시 파일**: `py`는 네이티브 Windows 바이너리다. Git Bash(MSYS)가 POSIX 절대경로를 Windows
|
||||
경로로 **자동 변환**하므로 대개 동작하지만(실측 확인), 변환이 암묵적이라 파일이 어디에 떨어졌는지
|
||||
추적하기 어렵다. 임시 파일은 **저장소 상대경로**(`docs/[Ubisam산출물]/_workspace/`)에 만들어
|
||||
위치를 확정한다.
|
||||
- **우선순위**: 호스트 루트 `rules.md`/`CLAUDE.md` > 본 산출물 규칙. 충돌 시 호스트 우선.
|
||||
- **멱등**: 폴더·`.gitkeep`·`_task.md`는 "없으면 생성, 있으면 유지".
|
||||
**산출물 파일(xlsx·pptx·md)은 재생산 스크립트가 덮어쓴다** — 스크립트가 진실원이므로 매번 같은 결과가 나온다.
|
||||
손으로 편집한 산출물은 다음 재생산에서 사라지므로, 내용 변경은 스크립트·매핑표 쪽을 고친다.
|
||||
|
||||
## 입력 (호스트에서 읽는 진실원)
|
||||
| 입력 | 용도 |
|
||||
|---|---|
|
||||
| 루트 `CLAUDE.md` | 설비·플랫폼·디바이스·시퀀스 등 프로젝트 사실 |
|
||||
| 소스코드(`src/`,`Machines/` 등) | PLC/모션/IO/Vision 구성, 메인 시퀀스 추출 |
|
||||
| `README*`, 설계 문서 | 보조 컨텍스트 |
|
||||
| git 원격/폴더명 | 프로젝트 코드·명 자동 추정 |
|
||||
|
||||
추출 사실 → 산출물 필드 매핑은 [07-fill-mapping.md](07-fill-mapping.md).
|
||||
|
||||
## 데이터 흐름 (호스트 에이전트와 맞물림)
|
||||
```
|
||||
[호스트 CLAUDE.md + 소스] ──읽기──▶ (분석) ──▶ 사실 추출
|
||||
│ │
|
||||
▼ ▼
|
||||
docs/[Ubisam산출물]/ 트리 생성 ◀── 매핑(07) ── 산출물 필드 채움
|
||||
│
|
||||
▼
|
||||
_task.md 진행률 갱신 + [작업일지] 기록
|
||||
```
|
||||
- 스킬은 **온디맨드** 호출(트리거 문구). 호스트 에이전트 루프를 가로채지 않는다.
|
||||
- 분석/검색은 호스트 에이전트의 도구(Grep/Read)를 그대로 활용.
|
||||
|
||||
## 프로젝트 자동 인식
|
||||
1. `project_code`: git 원격명·폴더명·`CLAUDE.md`에서 추정 → 실패 시 사용자에게 질문.
|
||||
2. `project_name`: `CLAUDE.md` 제목/설비명에서 추정.
|
||||
3. 추정값은 `_meta/project.yaml`에 기록하고 **`[추론]`** 표기 (`rules.md` #15·#16 — 구 `(추정)` 대체).
|
||||
확정 전까지 문서에 `(제안)` 유지. 두 표기는 축이 다르다 — `[추론]`=확인 전 서술, `(제안)`=진실원 부재.
|
||||
|
||||
## 트리거 문구
|
||||
- 생성: "산출물 구조 만들어줘", "Ubisam 트리 스캐폴딩".
|
||||
- 채움: "설계 산출물 채워줘", "IO 맵 정의서 생성", "프로젝트 분석해서 산출물 채움".
|
||||
- 갱신: "2.설계 진행률 갱신", "양산 단계 산출물 추가".
|
||||
|
||||
## 안전장치
|
||||
- 호스트 파일 수정 요청이 들어오면 거부하고 `docs/` 내 대안 제시.
|
||||
- 양식 엑셀은 **ref 파일 없이 from-scratch로 생성**한다([05-form-schemas.md](05-form-schemas.md)·[06-procedure.md](06-procedure.md)).
|
||||
**스타일 상수**(색·폰트·테두리)는 `xlsxfill.py`에 내장돼 있다. (원본 템플릿 복제 방식은 폐기됨 — ref 파일에 의존하지 않기 위함)
|
||||
⚠ **조건부서식은 `xlsxfill.py`에 없다**(관련 API 0건). 필요하면 `openpyxl.formatting`을 직접 쓰되
|
||||
색·폰트는 `xlsxfill` 상수를 쓰고, 재현 불가하면 지어내지 말고 **"조건부서식 미이관"** 을 로그에 명시한다
|
||||
(`ubisam-producer.md` §에러 핸들링과 같은 규칙).
|
||||
@ -1,44 +0,0 @@
|
||||
# 01 · 목표 트리 & 배치 규칙
|
||||
|
||||
> 이 스킬만으로(ref 없이) 어떤 프로젝트에서도 동일 트리를 생성한다.
|
||||
|
||||
## 배치 원칙
|
||||
- 산출물은 **소스 루트가 아니라 `docs/[Ubisam산출물]/` 하위**에 둔다.
|
||||
- 루트의 `.claude/`·`CLAUDE.md`·`rules.md`는 손대지 않는다.
|
||||
- 우선순위: 레포 루트 `rules.md` > 본 산출물 `RULES.MD`(스코프 하위).
|
||||
|
||||
## 트리
|
||||
|
||||
```
|
||||
<소스레포루트>/
|
||||
├─ .claude/ CLAUDE.md RULES.md # (기존) 손대지 않음
|
||||
└─ docs/
|
||||
└─ [Ubisam산출물]/
|
||||
├─ RULES.MD # 산출물 영역 규칙(이 스킬이 생성)
|
||||
├─ README.md # 트리 한눈에 + 시작하기
|
||||
├─ _workspace/ # 하네스 중간 산출물(_progress.md, 01_analyst~03_qa)
|
||||
├─ _meta/
|
||||
│ ├─ project.yaml # → templates/project.yaml.template
|
||||
│ ├─ status.enum.md # → 02-enums §상태
|
||||
│ ├─ task-type.enum.md # → 02-enums §유형
|
||||
│ ├─ task-schema.md # → 03-schema §일감
|
||||
│ ├─ ticket-code.rule.md # → 02-enums §티켓코드
|
||||
│ └─ build_scripts/ # producer가 만든 슬롯별 xlsx 빌더 (xlsxfill 임포트)
|
||||
├─ 01.분석협의/ _task.md + 사양서/ 회의록_CR/ 마스터플랜/
|
||||
├─ 02.설계/ _task.md + UIUX_기능설계/ 시퀀스_인터록/ IO_DB설계/ 설계리뷰_DR/
|
||||
├─ 03.제작/ _task.md + 테스트결과_CheckList/
|
||||
├─ 04.셋업/ _task.md + HW_IO모션점검/ 파라미터_레시피백업/ 이슈로그_IssueLog/ SAT_인수검사보고서/
|
||||
├─ 05.양산/ _task.md + 운영매뉴얼_HMI/ 최종SW_마스터백업/ 프로젝트완료보고서/
|
||||
├─ 06.CS/ _task.md
|
||||
├─ 산출물문서/ README.md + 양식/(빈 양식 드롭존)
|
||||
│ ※ 저장소 루트 `Doc/산출물문서/`(입력 원본, 읽기 전용)와 다른 곳
|
||||
├─ ref/ # 참고자료(읽기전용) — 비어 있어도 무방
|
||||
├─ [분석]/ # 에이전트 분석 산출물(날짜_주제.md)
|
||||
└─ [작업일지]/ # 일자별 로그(yyyy_mm_dd.md)
|
||||
```
|
||||
|
||||
산출물 슬롯 폴더는 비어 있으면 `.gitkeep`을 둔다. 슬롯 상세 매핑은 [04-stage-deliverables.md](04-stage-deliverables.md).
|
||||
|
||||
## 폴더명 규칙
|
||||
- 단계: `NN.단계명`(2자리 zero-pad). 협업관리 일감 제목과 동일 어휘.
|
||||
- 산출물 슬롯: 한글_영문 혼합 가능, 공백 대신 `_`.
|
||||
@ -1,59 +0,0 @@
|
||||
# 02 · enum & 티켓코드 (회사 공통 마스터)
|
||||
|
||||
> 임의 신규값 금지. 새 값 발견 시 이 파일을 먼저 갱신 후 사용.
|
||||
> 스캐폴딩 시 §상태→`status.enum.md`, §유형→`task-type.enum.md`, §티켓코드→`ticket-code.rule.md`로 복사.
|
||||
|
||||
## §상태(Status) — 4종 (전이 순서)
|
||||
|
||||
```
|
||||
해야 할 일 → 분석 진행 → 업무 진행중 → 진행 완료
|
||||
```
|
||||
|
||||
아래 **HEX는 MD·HTML 뱃지용**이다. xlsx 셀 채우기 ARGB는 `ubisam-format-map` §1을 쓴다.
|
||||
|
||||
| 코드(한글) | 색 | HEX | 칸반 컬럼 |
|
||||
|---|---|---|---|
|
||||
| 해야 할 일 | 회색 | `#757575` | Todo |
|
||||
| 분석 진행 | 청색 | `#1976D2` | Select For dev |
|
||||
| 업무 진행중 | 파랑 | `#1565C0` | InProgress |
|
||||
| 진행 완료 | 연두 | `#689F38` | Done |
|
||||
|
||||
컬럼 옵션: "상태 없으면 게시판 비표시", "WIP 초과 강조".
|
||||
|
||||
## §유형(Type) — 9종
|
||||
|
||||
| 유형 | 색 | HEX | 6단계 매핑(관례) |
|
||||
|---|---|---|---|
|
||||
| 오류수정 | 빨강 | `#D32F2F` | — |
|
||||
| 불합리 | 주황 | `#F57C00` | — |
|
||||
| 미팅 | 청록 | `#00796B` | 1.분석/협의 |
|
||||
| 설계 | 연두 | `#689F38` | 2.설계 |
|
||||
| 개발 | 파랑 | `#1976D2` | — |
|
||||
| 제작 | 남파랑 | `#283593` | 3.제작 |
|
||||
| 입고셋업 | 보라 | `#7B1FA2` | 4.셋업 |
|
||||
| 적용 및 모니터링 | 하늘 | `#0288D1` | 5.양산 |
|
||||
| 요청대응 | 남색 | `#1A237E` | 6.CS |
|
||||
|
||||
> 뱃지 HTML 템플릿은 [08-design-system.md](08-design-system.md) § 2·3 참조.
|
||||
|
||||
## §우선순위
|
||||
- 확인값: `보통`(Normal). 그 외 등급 미확인 — 발견 시 보강.
|
||||
|
||||
## §티켓코드 규칙
|
||||
|
||||
```
|
||||
{프로젝트코드}-{일련번호}
|
||||
```
|
||||
- 프로젝트코드: `_meta/project.yaml › project_code` 에서 읽는다. **여기에 특정 프로젝트 값을 적지 않는다**
|
||||
(`ubisam-format-map` §5 — 하네스가 잡아야 할 타설비 잔재를 스스로 공급하게 된다).
|
||||
- 일련번호: 4자리 권장, 생성 순 증가.
|
||||
- 전체 형식: `{project_code}-{NNNN}`
|
||||
|
||||
| 일감 | 일련번호 |
|
||||
|---|---|
|
||||
| 1.분석/협의 | `{N}` |
|
||||
| 2.설계 | `{N+1}` |
|
||||
| 3.제작 | `{N+2}` |
|
||||
| 4.셋업 | `{N+3}` |
|
||||
| 5.양산 | `{N+4}` |
|
||||
| 6.CS | `{N+5}` |
|
||||
@ -1,39 +0,0 @@
|
||||
# 03 · 일감 & 프로젝트 스키마
|
||||
|
||||
> 스캐폴딩 시 §일감→`task-schema.md`, 프로젝트 메타→`project.yaml`(템플릿 사용).
|
||||
|
||||
## §일감(Task) 필드
|
||||
|
||||
| 필드 | 비고 |
|
||||
|---|---|
|
||||
| 제목 | `N.단계명` (예: `2.설계`) |
|
||||
| 티켓번호 | `{프로젝트코드}-{일련번호}` → [02-enums §티켓코드](02-enums.md) |
|
||||
| 유형 | [02-enums §유형](02-enums.md) (9종) |
|
||||
| 상태 | [02-enums §상태](02-enums.md) (4종) |
|
||||
| 우선순위 | `보통` 등 |
|
||||
| 담당자 / 참조자 | 이름(직급) 표기 (예: 홍길동(사원)) |
|
||||
| 진행률 | % |
|
||||
| Hashtag | 자유 태그 (예: 분석/검토/협의) |
|
||||
| 등록일 / 수정일 / 종료일 | `yyyy/mm/dd` |
|
||||
| 예상시간 | `2w 4d 6h 45m` 형식 |
|
||||
| 수정 버전 | None 가능 |
|
||||
| 첨부파일 | 최대 2.93GB |
|
||||
| 체크리스트 | 의견글 / 시간변경이력 / 타임 트래킹 |
|
||||
|
||||
`_task.md` 카드 양식은 [templates/_task.template.md](../templates/_task.template.md).
|
||||
|
||||
## §프로젝트 메타
|
||||
|
||||
| 필드 | 예시/형식 |
|
||||
|---|---|
|
||||
| 프로젝트명 | `{사업부}_{고객사}_{설비명} 운영SW` |
|
||||
| 종류 | Software / Hardware |
|
||||
| 프로젝트 형식 | Kanban |
|
||||
| 코드명 | `{CUST}_{TYPE}_{NN}_{YYYYMMDD}` |
|
||||
| 사업부 / 팀 | `{사업부}` / `{팀}` |
|
||||
| PL / 등록자 | `{이름}({직급})` |
|
||||
| 계약일 / 납기 | `yyyy-mm-dd` |
|
||||
| 권한 | 책임자 → 참여자 → 열람자 (3단계) |
|
||||
| 알람 | 실시간 티켓 / 메일 / 댓글 |
|
||||
|
||||
전체 템플릿(토큰 포함): [templates/project.yaml.template](../templates/project.yaml.template).
|
||||
@ -1,39 +0,0 @@
|
||||
# 04 · 6단계 ↔ 산출물 슬롯 매핑
|
||||
|
||||
> 각 단계 폴더 = 협업관리 일감 1개. 슬롯 = 산출물 보관 하위폴더. 비면 `.gitkeep`.
|
||||
|
||||
| # | 폴더 | 유형 | 슬롯(하위폴더) | 산출물 |
|
||||
|---|---|---|---|---|
|
||||
| 1 | `01.분석협의/` | 미팅 | `사양서/` `회의록_CR/` `마스터플랜/` | 사양서(URS)·CR회의록·마스터플랜 |
|
||||
| 2 | `02.설계/` | 설계 | `UIUX_기능설계/` `시퀀스_인터록/` `IO_DB설계/` `설계리뷰_DR/` | 기능명세서·시퀀스/인터록·통신/IO맵·DB스키마·D/R회의록 |
|
||||
| 3 | `03.제작/` | 제작 | `테스트결과_CheckList/` | 단위/통합 테스트 결과 보고서 |
|
||||
| 4 | `04.셋업/` | 입고셋업 | `HW_IO모션점검/` `파라미터_레시피백업/` `이슈로그_IssueLog/` `SAT_인수검사보고서/` | IO/모션 점검·파라미터/레시피 백업·이슈로그·SAT 결과서 |
|
||||
| 5 | `05.양산/` | 적용 및 모니터링 | `운영매뉴얼_HMI/` `최종SW_마스터백업/` `프로젝트완료보고서/` | 운영매뉴얼(HMI/알람)·최종SW 백업·완료 보고서 / **`*.pptx`** (ubisam-ppt-make Step C) |
|
||||
| 6 | `06.CS/` | 요청대응 | (슬롯 없음, 건별 누적) | CS 대응 이력 |
|
||||
|
||||
## 단계별 세부 산출물 정의(채움 기준)
|
||||
|
||||
### 1.분석/협의
|
||||
- 요구사항 분석: 고객 사양서(URS) 분석 / 제어 시나리오 검토 → CR회의록 / 마스터플랜.
|
||||
|
||||
### 2.설계
|
||||
- UI/UX·기능: HMI 화면 정의서·UI 스토리보드·기능 명세서.
|
||||
- 시퀀스·인터록: 제어 시퀀스 다이어그램 & 인터록 정의서.
|
||||
- I/O·DB: 통신 맵(Memory/IO/Register)·DB 스키마 정의서.
|
||||
- 설계 리뷰: D/R 회의록.
|
||||
- 양식 시트 골격 → [05-form-schemas.md](05-form-schemas.md).
|
||||
|
||||
### 3.제작
|
||||
- 개발 환경 구축 / 핵심 모듈 / UI·메인 시퀀스 / 시뮬레이션 검증 / 단위·통합 테스트(Check-List).
|
||||
|
||||
### 4.셋업
|
||||
- HW IO/모션 점검 시트 · 파라미터/레시피 백업 · 이슈 로그(Issue Log) · 호스트(MES) 연동 · SAT 결과서.
|
||||
|
||||
### 5.양산
|
||||
- Ramp-up 교육 · 안정화 모니터링(운영 매뉴얼·알람 조치서) · S/W 최적화 · 최종 버전 동결(마스터 백업) · 프로젝트 완료 보고서.
|
||||
|
||||
### 6.CS
|
||||
- 운영 단계 요청 대응 이력(요청/조치/결과) 누적.
|
||||
|
||||
## 타사 산출물 이관 가이드(예)
|
||||
- 제작사양서·시퀀스 → `01`, IO/PLC 인터페이스·기능명세서·FlowChart → `02`, HMI Manual·알람조치 → `05`.
|
||||
@ -1,109 +0,0 @@
|
||||
# 05 · 설계 양식 시트·컬럼 스키마
|
||||
|
||||
> **재생산 방식 (2026-06-29 확정): 완전 독립 (ref 파일 불필요)**
|
||||
> xlsx는 `xlsxfill.py` 의 하드코딩 스타일 상수와 `build_02설계_xlsx.py` 의 PtoP 데이터만으로 처음부터(`from scratch`) 생성한다. ref 원본 xlsx 없이도 동일한 외형을 재현한다.
|
||||
>
|
||||
> **재생산 도구 (영구 보존)**
|
||||
> - `xlsxfill.py` — 같은 폴더. xlsxfill.py 내장 스타일 상수 + `make_workbook / write_banner / write_header_row / write_data_rows / group_merge` scratch-build API.
|
||||
> - `build_02설계_xlsx.py` — 같은 폴더. PtoP 데이터 내장, 단독 실행으로 4개 xlsx 재생산.
|
||||
> ```
|
||||
> PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_xlsx.py
|
||||
> ```
|
||||
> 저장소 루트에서 한 줄로 실행한다. `PYTHONUTF8`을 별도 줄에 두면 적용되지 않는다.
|
||||
>
|
||||
> **⚠ 이 스크립트는 PTOP 소스 유래 재생산(`ptop-deliverables`) 전용이다.**
|
||||
> 타사 문서를 재생산하는 `ubisam-deliverable-rebuild` 경로에서는 쓰지 않는다 —
|
||||
> 데이터가 코드에 하드코딩돼 있어 매핑표를 반영할 수 없다(`ubisam-producer.md` §2).
|
||||
> - 전제조건: Python 3.9+, openpyxl >= 3.1 (`pip install openpyxl`)
|
||||
>
|
||||
> **공통 관례**: ① 배너 B2=제목, B3=근거/부제 ② 미확정 값은 `(제안)` 표기 ③ 플랫폼 문구는 `_meta/project.yaml`에서 읽는다 (특정 문구를 여기에 하드코딩하지 않는다)
|
||||
|
||||
---
|
||||
|
||||
## 스타일 상수 (xlsxfill.py 하드코딩값)
|
||||
|
||||
| 구분 | 폰트 | 색상(fgColor) | 테두리 |
|
||||
|---|---|---|---|
|
||||
| 배너 행(B2) | 맑은 고딕 13pt Bold White(FFFFFF) | FF1F4E78 (진네이비) | medium all |
|
||||
| 부제 행(B3) | 맑은 고딕 9pt | 없음 | medium L/R/T |
|
||||
| 헤더 행 | 맑은 고딕 11pt Bold White(FFFFFF) | FF2E75B6 (파랑) | medium 좌우, thin 상하 |
|
||||
| 데이터 행(홀수) | 맑은 고딕 10pt | FFDDEBF7 (연파랑) | medium 좌우, thin 상하 |
|
||||
| 데이터 행(짝수) | 맑은 고딕 10pt | FFFFFFFF (흰색) | medium 좌우, thin 상하 |
|
||||
| 기능명세서 배너 | 맑은 고딕 14pt Bold | 없음 | medium all |
|
||||
| 기능명세서 헤더 | 맑은 고딕 11pt Bold | **없음** | thin all |
|
||||
| 기능명세서 데이터 | 맑은 고딕 11pt | 없음 | thin all |
|
||||
| TactTime 헤더 | 맑은 고딕 11pt | **없음** | thin all |
|
||||
| TactTime 데이터 | 맑은 고딕 11pt | 없음 | thin all |
|
||||
|
||||
> `write_header_row(fill=None)` — 배경 없음(기능명세서·TactTime 계열). 인자 생략 시 파랑(HEADER_FILL) 기본값. `fill=_UNSET` sentinel으로 구분.
|
||||
> `TODAY = datetime.date.today()` — 실행일 자동 반영. 이력 셀(Update 컬럼)에 삽입.
|
||||
> **`xlsxfill.py` 가 아니라 `build_02설계_xlsx.py:41` 의 모듈 상수다** — 새 빌드 스크립트를 쓸 때는
|
||||
> `xlsxfill` 에서 임포트되지 않으므로 직접 정의해야 한다.
|
||||
|
||||
---
|
||||
|
||||
## A. 모션축·IO 맵 정의서 (슬롯 `02.설계/IO_DB설계/모션축_IO맵_정의서.xlsx`)
|
||||
**3탭 고정**
|
||||
|
||||
| 탭명 | 헤더(B4~) | 데이터 시작행 | PtoP 특이사항 |
|
||||
|---|---|---|---|
|
||||
| 통신·제어 구성 | 구분\|대상\|컨트롤러/디바이스\|통신/버스\|수량·범위\|비고 | B5 | PLC=MXComponent, IO=**보드타입 런타임 설정(미확정)**, Laser=IOGate, Scanner=RTC |
|
||||
| 모션축 정의(ACS) | Axis\|축명(논리)\|용도\|컨트롤러/통신\|구동\|행정/범위\|최대속도\|Home방식\|Soft Limit\|동기/단축\|비고 | B5 | X/Y=ACS EtherCAT, Z=AuroraMotionBoard(보드타입 미확정), Scanner θ/XY=RTC. 행정·속도·Home=(제안) |
|
||||
| I-O 맵(DI-DO) | No\|신호명\|Type\|권장모듈\|슬롯/CH\|Active\|설명/인터락\|비고 | B5 | DI 9~23 / DO 9~17 (`PAIX_PTOP.cs` — 채널 번호만. **벤더명은 이 파일에 없다**) |
|
||||
|
||||
## B. PLC-PC 인터페이스 신호 정의서 (슬롯 `02.설계/IO_DB설계/PLC_PC_인터페이스_신호정의서.xlsx`)
|
||||
**4탭 고정**
|
||||
|
||||
| 탭명 | 헤더(B4~) | 데이터 시작행 |
|
||||
|---|---|---|
|
||||
| 통신 사양 | 항목\|내용 | B5 |
|
||||
| PC→PLC (Write) | No\|Seq/구분\|신호명\|방향\|디바이스(제안)\|Type\|의미 / 트리거\|응답·완료\|비고 | B5 |
|
||||
| PLC→PC (Read) | 동일 | B5 |
|
||||
| 핸드셰이크 시퀀스 | No\|Seq\|Step\|주체\|동작 / 신호\|디바이스(제안)\|비고 | B5 |
|
||||
|
||||
- Seq 구분 enum: Status · Alarm · Process · Request · Info · Control · Model · Interlock
|
||||
- 디바이스: 비트 `M70000~`(PC Write), `M70500~`(PLC Read). 워드 `D70000~`/`D70500~`.
|
||||
**⚠ 전부 `(제안)` 값이다** — 이 주소들은 `.cs` 소스에 0건이고 근거는 분석 문서뿐이다
|
||||
(`ptop-deliverables/references/source-map.md` §A 참조). 산출물에 확정값처럼 적지 말 것.
|
||||
- PtoP 핸드셰이크: `PLC_PAGE_CHANGE_REQ` 단일 게이트 → Recipe 확정 → **Page 3회 검증**(200ms×3) → 리스트 업로드 → 발진 → 완료.
|
||||
출처: `SeqAutoRunPTOP.cs` `CheckPageNoComp` — `checknum > 2`에서 break하므로 정확히 3회이고
|
||||
각 회차에 `Thread.Sleep(200)`이 있다. `plcPageNoList[0]/[1]/[2]` 로그가 3회를 확증한다.
|
||||
⚠ 같은 함수의 `260618` 주석은 "상한 하드코딩(>2) 제거 → Recipe 페이지 수로 가변 검증"이라고
|
||||
적혀 있으나 **코드는 아직 `>2` 고정**이다(`recipePageCount`는 값 범위 검증에만 쓰인다).
|
||||
주석을 근거로 "가변"이라 적지 말 것 (`rules.md` #1).
|
||||
|
||||
## C. 기능명세서 / UI 설계 (슬롯 `02.설계/UIUX_기능설계/기능명세서.xlsx`)
|
||||
**8탭 고정** (우리 설비에 없는 탭도 양식 유지)
|
||||
|
||||
| 탭명 | 헤더(행5~) | G3 배너 | PtoP 내용 |
|
||||
|---|---|---|---|
|
||||
| OverView | no.\|Content | — | SW 개요(Aurora·Win11·.NET·설비·모션·레이저·PLC·비전) |
|
||||
| MainView | Update\|Funtion Area\|Funtion Name\|NO\|Sub\|Content | "다음은 Main 화면…" | AutoRun 시작/정지·페이지·Resume(bit15)·스캐너캔버스 |
|
||||
| RecipeView | 동일 | "다음은 Recipe 화면…" | ActivateRecipe·변경이력·모델 편집 |
|
||||
| ManualView | 동일 | "다음은 Manual 화면…" | ScannerOperation·ModelFinder·Calibration |
|
||||
| DeviceView | 동일 | "다음은 Device 화면…" | DeviceSetting·PLCBit/Word·IOInterface |
|
||||
| SettingView | 동일 | "다음은 Setting 화면…" | Equipment·Log·AutoBackup·Alarm·Stream |
|
||||
| VisionView | 동일 | "다음은 Vision 화면…" | `(해당없음)` — AuroraVision 미사용 |
|
||||
| Sequence 흐름 | Update\|Funtion Area\|Processing Name\|NO\|Content | — | `PLC_PAGE_CHANGE_REQ` 게이트→Recipe→Page→ListUpload→발진→완료→루프백 |
|
||||
|
||||
## D. TactTime 산정서 (슬롯 `02.설계/시퀀스_인터록/TactTime_산정서.xlsx`)
|
||||
**2탭 고정**
|
||||
|
||||
| 탭명 | 좌측 컬럼 | 우측 컬럼 | PtoP 내용 |
|
||||
|---|---|---|---|
|
||||
| PC TactTime | 공정\|Unit\|단위동작\|T/T | Working Process\|상세합계\|기준/참조합계 | SeqAutoRunPTOP.cs 타이밍 (Page gate·Recipe·발진·완료) |
|
||||
| PLC TactTime | 동일 구조 | — | 미입수 → `(제안)` |
|
||||
|
||||
## E. Flow Chart (슬롯 `02.설계/시퀀스_인터록/`)
|
||||
- 형식: PPTX 흐름도. 메인 시퀀스: `PLC_PAGE_CHANGE_REQ` 단일게이트 → 리스트 업로드 → 발진 → 완료비트. 분기·인터락 표현.
|
||||
|
||||
## enum 요약(양식 고정값)
|
||||
- I/O Type: DI · DO · AI · AO
|
||||
- 신호 Type: BIT · INT · INT32
|
||||
- PLC Seq 구분: Status · Alarm · Process · Request · Info · Control · Model · Interlock
|
||||
- 운영 모드: 수동 · 반자동 · 자동
|
||||
|
||||
> **재생산 도구 선택은 이 문서 상단의 ⚠ 박스를 따른다.**
|
||||
> `ptop-deliverables`(소스 유래) 경로에서만 `build_02설계_xlsx.py`를 저장소 루트에서 실행한다.
|
||||
> `ubisam-deliverable-rebuild`(타사 문서 재생산) 경로에서는 이 스크립트를 쓰지 않고
|
||||
> `xlsxfill.py` 기반 신규 스크립트를 작성한다(`ubisam-producer.md` §2).
|
||||
@ -1,46 +0,0 @@
|
||||
# 06 · 분석 → 채움 절차
|
||||
|
||||
> 입력: `docs/[Ubisam산출물]/산출물문서/양식/`(빈 양식) 또는 타설비 산출물. 출력: 단계 슬롯에 채운 산출물 + 갱신된 `_task.md` + 로그.
|
||||
|
||||
## 절차
|
||||
1. **분석**: 원본 구조 파악(시트/슬라이드/컬럼). 결과를 `[분석]/<yyyy_mm_dd>_<주제>-분석.md`에 기록.
|
||||
- 엑셀 구조 추출(파이썬·Office 없이): `unzip -p file.xlsx xl/workbook.xml`(시트명), `xl/sharedStrings.xml`(라벨).
|
||||
2. **양식 식별**: 타설비 템플릿 잔재 분리. 채울 슬롯 결정 → [04-stage-deliverables.md](04-stage-deliverables.md).
|
||||
- 시트·컬럼 골격은 [05-form-schemas.md](05-form-schemas.md) 기준(ref 없어도 재현 가능).
|
||||
3. **채움**: 이 프로젝트 사실로 값 작성. **출처(원본 파일·코드 경로) 명시**.
|
||||
- 미확정 디바이스주소·축범위는 `(제안)` 표기.
|
||||
4. **디자인 적용**: [08-design-system.md](08-design-system.md) 배너·뱃지·섹션헤더를 삽입한다.
|
||||
- MD 최상단: 배너(§1) → 부제 바 순.
|
||||
- 상태·유형 필드: 텍스트 대신 뱃지(§2·3) 사용.
|
||||
- 진행률: `<progress>` 바(§4) 병기.
|
||||
- 산출물 시트 구분 `##` 헤더: `<span style="color:#2E75B6">` 적용(§5).
|
||||
5. **배치**: 해당 `NN.단계명/<슬롯>/`에 저장.
|
||||
6. **PPTX 생성**: [09-pptx-integration.md](09-pptx-integration.md) 참고.
|
||||
- 2.설계 채움 완료 → `SW_설계서.pptx` (선택)
|
||||
- 5.양산 채움 or 명시 요청 → `<설비명>_HMI_매뉴얼.pptx` (필수)
|
||||
- MD 내용 → JSON spec → `ubisam-ppt-make/build_deck.py` → 슬롯에 저장
|
||||
- 임시 spec JSON 생성 후 pptx 완성 즉시 삭제
|
||||
7. **카드 갱신**: `_task.md`의 상태·진행률·첨부 매핑 갱신(PPTX 파일명 포함, [02-enums.md](02-enums.md)).
|
||||
8. **기록**: `[작업일지]/<오늘>.md`에 한 일·다음 TODO.
|
||||
|
||||
## xlsx 재생산 (from scratch · ref 불필요)
|
||||
- `references/xlsxfill.py` — 스타일 상수 하드코딩 + scratch-build API.
|
||||
- `references/build_02설계_xlsx.py` — PtoP 데이터 내장, 4종 xlsx 자동 생성.
|
||||
**`ptop-deliverables` 경로 한정.** 타사 문서 재생산(rebuild)에는 쓰지 않는다 — 데이터가 하드코딩돼 매핑표를 반영할 수 없다.
|
||||
- 실행: cwd=repo root, `PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_xlsx.py`
|
||||
- ref xlsx 없어도 동일 외형 재현. 스타일 상수 변경 시 xlsxfill.py만 수정.
|
||||
|
||||
## pptx 재생산 (from scratch · ref 불필요)
|
||||
- `references/build_02설계_pptx.py` — 슬라이드 스펙(22슬라이드) 내장, `ubisam-ppt-make/build_deck.py` 자동 호출.
|
||||
- 실행: cwd=repo root, `PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_pptx.py`
|
||||
- 출력: `docs/[Ubisam산출물]/02.설계/설계리뷰_DR/SW_설계서.pptx`
|
||||
- 임시 spec JSON 자동 생성·삭제. 표 높이 상한 5.3" 적용 — 푸터 비침범 보장.
|
||||
|
||||
## MD 분할 규칙
|
||||
- 모든 산출/분석 MD는 **200줄 이내** (`rules.md` #4). 초과 시 주제별 분할 + 상호 링크(상대경로)로 매핑.
|
||||
- 인덱스 문서(예: [분석] 폴더 README)에 1줄 포인터로 목록 유지.
|
||||
|
||||
## 자기완결 보장 (ref 없이 동작)
|
||||
- 이 스킬은 양식 골격을 [05-form-schemas.md](05-form-schemas.md)에 내장한다.
|
||||
- `ref/`가 비어 있어도 트리·enum·양식 골격을 동일하게 생성한다.
|
||||
- 새 양식 입수 시: 골격을 추출해 05 파일에 추가 → 이후 ref 없이 재현 가능.
|
||||
@ -1,40 +0,0 @@
|
||||
# 07 · 자동 채움 매핑 (프로젝트 분석 → 산출물 필드)
|
||||
|
||||
> "산출물 양식 필드 ← 호스트 레포의 진실원" 규칙. 프로젝트 비종속(휴리스틱) + PTOP 예시.
|
||||
> 양식 시트·컬럼 골격은 [05-form-schemas.md](05-form-schemas.md), 절차는 [06-procedure.md](06-procedure.md).
|
||||
|
||||
## 추출 휴리스틱 (어떤 프로젝트든)
|
||||
| 추출 대상 | 탐색 방법(예) |
|
||||
|---|---|
|
||||
| 플랫폼/프레임워크 | `CLAUDE.md`, `*.csproj`/`*.sln`, `*.config` |
|
||||
| PLC 기종·통신 | `grep -ri "melsec\|mx ?component\|slmp\|modbus\|ethernet/ip"` |
|
||||
| 모션 컨트롤러·축 | `grep -ri "acs\|ajin\|axis\|ethercat\|servo"` |
|
||||
| I/O 디바이스 | `grep -ri "beckhoff\|EL1\|EL2\|digital ?io\|io ?gate"` |
|
||||
| Vision | `grep -ri "matrox\|MIL\|halcon\|cognex\|keyence"` |
|
||||
| 메인 시퀀스 | `grep -ri "Seq\|Sequence\|Recipe\|Auto ?Run"` → 클래스/메서드 |
|
||||
| 주소/메모리맵 | `*Address*.cs`, `*Map*`, `*.csv` 주소표 |
|
||||
|
||||
## 설계 산출물 채움 매핑 (02.설계)
|
||||
| 양식·필드 | 진실원(호스트) |
|
||||
|---|---|
|
||||
| 통신·제어 구성: 컨트롤러/통신 | 위 휴리스틱(PLC/모션/IO/Vision/Laser) |
|
||||
| 모션축 정의: Axis·용도·범위 | 모션 설정·축 enum·파라미터 파일 |
|
||||
| I/O 맵: 신호명·Type·모듈 | IO 정의/매핑 소스, 주소표 |
|
||||
| PLC-PC 신호: 디바이스(M/D)·트리거 | PLC 인터페이스 주소 클래스(`*PLCController*Address*`) |
|
||||
| 기능명세서: View·Function | UI/뷰모델 구조, 화면 클래스 |
|
||||
| TactTime: Unit·단위동작 | 시퀀스 단계·동작 메서드 |
|
||||
|
||||
미발견 값은 `(제안)` 표기 후 "최종 합의/소스 확인 시 확정" 단서.
|
||||
|
||||
## PTOP 예시 (참고값)
|
||||
- 설비: 각형 배터리 레이저 용접기(ILSOS OC5 PtoP Welder), Aurora 2.0 / .NET 4.8.1 / WPF
|
||||
- PLC: Mitsubishi Melsec(MX Component) · Laser Scanner: RTC · Laser: IO Gate · Digital IO — 구현 클래스 `PAIX_PTOP`(`EquipmentSetup.cs:153`), 보드 타입은 `IOUnitConfig` 런타임 설정(단정 금지)
|
||||
- 메인 시퀀스: `SeqAutoRunPTOP`(Recipe/Page 핸드셰이크 → 용접리스트 업로드 → 발진 → 완료비트)
|
||||
- PLC 주소: `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs`
|
||||
|
||||
> 이 예시는 PTOP 한정. 다른 프로젝트에선 위 휴리스틱으로 동일 절차를 적용해 값만 교체.
|
||||
|
||||
## 채움 원칙
|
||||
- 모든 채운 값에 **출처 주석**(파일·심볼 경로) 부기.
|
||||
- 상태/유형은 [02-enums.md](02-enums.md) enum 고정.
|
||||
- 새 디바이스 종류 발견 시 [05-form-schemas.md](05-form-schemas.md) enum에 추가 후 사용.
|
||||
@ -1,126 +0,0 @@
|
||||
# 08 · Ubisam 산출물 디자인 시스템
|
||||
|
||||
> 모든 프로젝트의 산출물 MD에 공통 적용하는 HTML 색상 템플릿.
|
||||
> VS Code Markdown Preview / Typora / GitLab 렌더링 기준.
|
||||
> 스캐폴딩·채움 어느 단계에서든 이 파일을 참조해 배너·뱃지·진행률을 적용한다.
|
||||
|
||||
---
|
||||
|
||||
## 색상 팔레트
|
||||
|
||||
| 구분 | 이름 | 색 코드 | 용도 |
|
||||
|---|---|---|---|
|
||||
| 배너 | 진네이비 | `#1F4E78` | 문서 최상단 제목 배너 |
|
||||
| 헤더 | 파랑 | `#2E75B6` | 배너 하단 부제 바, 섹션 헤더 강조 |
|
||||
| 상태·해야 할 일 | 회색 | `#757575` | 미착수 |
|
||||
| 상태·분석 진행 | 청색 | `#1976D2` | 선택됨 |
|
||||
| 상태·업무 진행중 | 파랑 | `#1565C0` | 진행 중 |
|
||||
| 상태·진행 완료 | 연두 | `#689F38` | 완료 |
|
||||
| 유형·오류수정 | 빨강 | `#D32F2F` | — |
|
||||
| 유형·불합리 | 주황 | `#F57C00` | — |
|
||||
| 유형·미팅 | 청록 | `#00796B` | 1.분석/협의 |
|
||||
| 유형·설계 | 연두 | `#689F38` | 2.설계 |
|
||||
| 유형·개발 | 파랑 | `#1976D2` | — |
|
||||
| 유형·제작 | 남파랑 | `#283593` | 3.제작 |
|
||||
| 유형·입고셋업 | 보라 | `#7B1FA2` | 4.셋업 |
|
||||
| 유형·적용 및 모니터링 | 하늘 | `#0288D1` | 5.양산 |
|
||||
| 유형·요청대응 | 남색 | `#1A237E` | 6.CS |
|
||||
|
||||
> xlsx 색상과 동일 계열: 배너=`FF1F4E78`(진네이비), 헤더=`FF2E75B6`(파랑), 데이터 홀수=`FFDDEBF7`(연파랑).
|
||||
|
||||
---
|
||||
|
||||
## 1. 문서 배너 (모든 산출물 MD 1번째 줄)
|
||||
|
||||
```html
|
||||
<div style="background:#1F4E78;color:#fff;padding:8px 16px;border-radius:4px 4px 0 0">
|
||||
<strong>문서 제목</strong> — 설비명
|
||||
</div>
|
||||
<div style="background:#2E75B6;color:#fff;padding:3px 16px;border-radius:0 0 4px 4px;font-size:.85em;margin-bottom:12px">
|
||||
근거: 소스 파일 경로 · 플랫폼 정보
|
||||
</div>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 상태 뱃지 (값에 맞춰 색 코드 교체)
|
||||
|
||||
```html
|
||||
<span style="background:#757575;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">해야 할 일</span>
|
||||
<span style="background:#1976D2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">분석 진행</span>
|
||||
<span style="background:#1565C0;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">업무 진행중</span>
|
||||
<span style="background:#689F38;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">진행 완료</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 유형 뱃지
|
||||
|
||||
```html
|
||||
<span style="background:#00796B;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">미팅</span>
|
||||
<span style="background:#689F38;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">설계</span>
|
||||
<span style="background:#1976D2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">개발</span>
|
||||
<span style="background:#283593;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">제작</span>
|
||||
<span style="background:#7B1FA2;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">입고셋업</span>
|
||||
<span style="background:#0288D1;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">적용 및 모니터링</span>
|
||||
<span style="background:#1A237E;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">요청대응</span>
|
||||
<span style="background:#D32F2F;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">오류수정</span>
|
||||
<span style="background:#F57C00;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">불합리</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 진행률 바
|
||||
|
||||
```html
|
||||
<progress value="0" max="100" style="width:160px;vertical-align:middle"></progress> **0%**
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 섹션 헤더 강조 (산출물 MD 내 시트 구분)
|
||||
|
||||
```markdown
|
||||
## <span style="color:#2E75B6">시트① 제목</span>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 미확정 경고 (GitHub Alerts)
|
||||
|
||||
```markdown
|
||||
> [!NOTE]
|
||||
> 아래 값은 소스 분석 기반 `(제안)`. 현장 확인 후 확정.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. _task.md 완성 템플릿 (디자인 포함)
|
||||
|
||||
단계명·프로젝트명·코드·유형·상태·진행률 토큰 교체 후 사용.
|
||||
|
||||
```markdown
|
||||
<div style="background:#1F4E78;color:#fff;padding:8px 16px;border-radius:4px 4px 0 0">
|
||||
<strong>{N}.{단계명}</strong> — {프로젝트명}
|
||||
</div>
|
||||
<div style="background:#2E75B6;color:#fff;padding:3px 16px;border-radius:0 0 4px 4px;font-size:.85em;margin-bottom:12px">
|
||||
{프로젝트코드}-{일련번호}
|
||||
</div>
|
||||
|
||||
| 필드 | 값 |
|
||||
|---|---|
|
||||
| 유형 | <span style="background:{유형색};color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">{유형명}</span> |
|
||||
| 상태 | <span style="background:#757575;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">해야 할 일</span> |
|
||||
| 담당자 / 참조자 | {담당자} / {참조자} |
|
||||
| 진행률 | <progress value="0" max="100" style="width:160px;vertical-align:middle"></progress> **0%** |
|
||||
| Hashtag | {태그1} / {태그2} |
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 적용 규칙
|
||||
- **항상 배너 먼저**: 산출물 MD 생성 시 본문 앞에 배너 블록을 삽입한다.
|
||||
- **뱃지 > 텍스트**: 상태·유형은 텍스트가 아닌 뱃지 HTML로 표기한다.
|
||||
- **진행률 bar 병기**: `<progress>` 태그 + bold 숫자를 함께 쓴다(텍스트 렌더러 폴백).
|
||||
- **섹션 헤더**: 산출물 내 시트 구분 `##` 제목은 `<span style="color:#2E75B6">` 적용.
|
||||
- **README·_meta enum**: 동일 색상 체계를 그대로 적용한다.
|
||||
@ -1,109 +0,0 @@
|
||||
# 09 · PPTX 통합 — ubisam-ppt-make 연동
|
||||
|
||||
> **역할 분리 원칙**
|
||||
> - `ubisam-deliverables`: spec JSON 준비 + 슬롯 배치 담당 (PPTX 직접 생성 금지)
|
||||
> - `ubisam-ppt-make`: PPTX 렌더링 엔진 (`build_deck.py`) — 레이아웃·디자인 토큰 정의 소유자
|
||||
>
|
||||
> PPTX 생성은 항상 `.claude/skills/ubisam-ppt-make/build_deck.py`를 호출한다.
|
||||
> 레이아웃 타입·디자인 규칙은 `ubisam-ppt-make/SKILL.md`가 단일 진실 소스(SSoT).
|
||||
> 표 높이 상한 `_TABLE_MAX_H=5.3"` 등 렌더링 규칙은 `build_deck.py` 내부에서 보장.
|
||||
|
||||
---
|
||||
|
||||
## 생성 타이밍
|
||||
|
||||
| 트리거 | 생성 PPTX | 저장 슬롯 |
|
||||
|---|---|---|
|
||||
| 2.설계 채움 완료 | SW 설계서 (선택) | `02.설계/설계리뷰_DR/SW_설계서.pptx` |
|
||||
| 5.양산 채움 or 명시 요청 | 운영매뉴얼_HMI | `05.양산/운영매뉴얼_HMI/<설비명>_HMI_매뉴얼.pptx` |
|
||||
| 명시 요청 ("pptx 만들어줘") | 해당 단계 산출물 | 해당 슬롯 |
|
||||
|
||||
---
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 2.설계 SW 설계서 — 자동 재생산 (권장)
|
||||
```
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_pptx.py
|
||||
```
|
||||
- 슬라이드 스펙 내장 · 임시 JSON 자동 생성/삭제 · `build_deck.py` 호출 · 출력까지 자동
|
||||
- 출력: `docs/[Ubisam산출물]/02.설계/설계리뷰_DR/SW_설계서.pptx`
|
||||
|
||||
### 신규 단계 PPTX — 수동 절차
|
||||
```
|
||||
1. 해당 단계 MD 파일 읽기
|
||||
2. 아래 매핑표로 slide 오브젝트 목록 작성
|
||||
3. JSON spec 생성 → 스크래치 파일(임시)로 저장
|
||||
4. 저장소 루트에서 실행 (`PYTHONUTF8=1`은 반드시 같은 줄 접두 — 별도 줄이면 적용되지 않는다):
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-ppt-make/build_deck.py \
|
||||
--input <spec>.json --output <슬롯경로>.pptx
|
||||
5. 임시 spec 파일 삭제
|
||||
6. _task.md 첨부 목록 갱신
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## A. 2.설계 → SW 설계서 (선택)
|
||||
|
||||
소스 MD → slide 타입 매핑:
|
||||
|
||||
| MD 소스 | slide type | 비고 |
|
||||
|---|---|---|
|
||||
| — | `cover` | `tag="SW DESIGN DOCUMENT"` (키 이름은 `tag` — `doc_tag`는 무시된다) |
|
||||
| — | `history` | 버전/변경이력 (사용자 입력 or 빈 행) |
|
||||
| 각 산출물 목록 | `agenda` | 최대 6항목 |
|
||||
| 기능명세서 §메뉴구조 | `table` | headers: 메인메뉴/권한/서브뷰/기능 |
|
||||
| 기능명세서 §View별기능 | `table` | View별 1슬라이드씩 |
|
||||
| 제어시퀀스_인터락_정의서.md §mermaid 노드 | `flow` | steps: 노드명+코드+kind |
|
||||
| PLC신호정의서 §PC→PLC | `table` | headers: No/신호명/디바이스/Type/의미 |
|
||||
| PLC신호정의서 §PLC→PC | `table` | 동일 구조 |
|
||||
| 모션축_IO맵 §통신구성 | `table` | |
|
||||
| 모션축_IO맵 §I/O맵 DI/DO | `table` | |
|
||||
| TactTime §PC TactTime | `table` | |
|
||||
| — | `closing` | |
|
||||
|
||||
---
|
||||
|
||||
## B. 5.양산 → 운영매뉴얼_HMI (필수)
|
||||
|
||||
| MD/소스 | slide type | 비고 |
|
||||
|---|---|---|
|
||||
| — | `cover` | `tag="HMI OPERATION MANUAL"` |
|
||||
| — | `history` | |
|
||||
| View 목록 | `agenda` | AutoRun/Recipe/Manual/Calibration/Monitoring/Alarm |
|
||||
| 각 View | `divider` | View명 섹션 구분 |
|
||||
| 각 View §기능목록 | `screen_guide` | image 없으면 caption만 |
|
||||
| 각 View §조작절차 | `procedure` | steps: title+desc |
|
||||
| 알람 목록 | `alarm` | rows: 코드/알람명/원인/조치 |
|
||||
| — | `closing` | |
|
||||
|
||||
---
|
||||
|
||||
## spec JSON 최소 골격
|
||||
|
||||
```json
|
||||
{
|
||||
"doc_title": "{설비명} SW 설계서",
|
||||
"slides": [
|
||||
{"type": "cover", "tag": "SW DESIGN DOCUMENT",
|
||||
"title": "{설비명} SW 설계서",
|
||||
"subtitles": ["{설비 설명}"],
|
||||
"team": "{조직}",
|
||||
"contacts": ["{담당자}"]},
|
||||
{"type": "history", "rows": []},
|
||||
{"type": "agenda", "items": []},
|
||||
{"type": "closing", "title": "Thank You",
|
||||
"team": "{조직}", "contacts": []}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
> 캔버스 배경은 `build_deck.py:55-73`이 **`WHITE`** 로 고정한다(`BG_SOFT`는 패널·표 fill 전용).
|
||||
> spec JSON으로 바꿀 수 없다.
|
||||
|
||||
---
|
||||
|
||||
## 불변 규칙
|
||||
- spec JSON은 임시파일로 생성 후 pptx 완성 즉시 삭제 (작업 완료 시 정리).
|
||||
- PPTX 저장 후 `_task.md` 첨부 목록에 파일명 추가.
|
||||
- `ubisam-ppt-make/SKILL.md` §Verification — PowerPoint COM 가능 시 PNG 렌더 검증, 불가 시 폰트 감사만 하고 `미수행` 명시.
|
||||
@ -1,355 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
ILSOS PrismaticRD PTOP — 2.설계 SW_설계서.pptx 자동 생성 스크립트.
|
||||
|
||||
실행:
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_pptx.py
|
||||
|
||||
출력: docs/[Ubisam산출물]/02.설계/설계리뷰_DR/SW_설계서.pptx
|
||||
"""
|
||||
import os, io, json, subprocess, sys, tempfile
|
||||
|
||||
HERE = os.path.dirname(os.path.abspath(__file__))
|
||||
REPO = os.path.abspath(os.path.join(HERE, "..", "..", "..", ".."))
|
||||
BUILDER = os.path.join(REPO, ".claude", "skills", "ubisam-ppt-make", "build_deck.py")
|
||||
OUTPUT = os.path.join(REPO, "docs", "[Ubisam산출물]", "02.설계", "설계리뷰_DR", "SW_설계서.pptx")
|
||||
|
||||
# 프로젝트 메타의 유일 진실원은 _meta/project.yaml 이다 (ubisam-format-map §5).
|
||||
# 이 스크립트에 조직·담당자를 하드코딩하면 다른 프로젝트로 재사용할 때 타사 값이 그대로 새어 나간다.
|
||||
_PROJECT_YAML = os.path.join(REPO, "docs", "[Ubisam산출물]", "_meta", "project.yaml")
|
||||
_META_CACHE = None
|
||||
|
||||
|
||||
def _meta(path, default="미정 — 확인 필요"):
|
||||
"""project.yaml에서 점 경로(예: "people.pl")를 읽는다.
|
||||
|
||||
파일·키가 없거나 값이 미치환 토큰("{PL}")이면 default를 그대로 렌더링해
|
||||
'미정'임이 산출물에 드러나게 한다 — 조용히 남의 값이 찍히는 것보다 낫다.
|
||||
"""
|
||||
global _META_CACHE
|
||||
if _META_CACHE is None:
|
||||
try:
|
||||
import yaml
|
||||
with io.open(_PROJECT_YAML, encoding="utf-8") as f:
|
||||
_META_CACHE = yaml.safe_load(f) or {}
|
||||
except Exception:
|
||||
_META_CACHE = {} # 파일 부재·파싱 실패는 정상 — default가 쓰인다
|
||||
cur = _META_CACHE
|
||||
for k in path.split("."):
|
||||
if not isinstance(cur, dict) or k not in cur:
|
||||
return default
|
||||
cur = cur[k]
|
||||
v = str(cur).strip() if cur is not None else ""
|
||||
return default if (not v or v.startswith("{")) else v
|
||||
|
||||
|
||||
SPEC = {
|
||||
"doc_title": "ILSOS PrismaticRD PTOP SW 설계서",
|
||||
"slides": [
|
||||
{
|
||||
"type": "cover",
|
||||
"tag": "SW DESIGN DOCUMENT",
|
||||
"title": "ILSOS PrismaticRD PTOP\nSW 설계서",
|
||||
"subtitles": [
|
||||
"LGES OC5 PtoP Welder — Prismatic 전지 점 용접 자동화 SW",
|
||||
"Aurora 2.0 / .NET 4.8.1 / WPF · MX Component · ACS EtherCAT · Digital IO(보드타입 런타임 설정 — 미확정)"
|
||||
],
|
||||
# 조직·담당자는 docs/[Ubisam산출물]/_meta/project.yaml 이 유일 진실원이다.
|
||||
# 파일이 없으면 아래 자리표시자를 그대로 렌더링해 "미정"임이 드러나게 한다.
|
||||
"team": _meta("org.team"),
|
||||
"contacts": [_meta("people.pl")]
|
||||
},
|
||||
{
|
||||
"type": "history",
|
||||
"no": "00.",
|
||||
"title": "변경 이력",
|
||||
"subtitle": "Revision History",
|
||||
"rows": [
|
||||
["01", "0.1", _meta("schedule.contract_date", "미정"), _meta("people.registrant"),
|
||||
"소스 기반 최초 작성 (기능명세·시퀀스·신호정의·IO맵·TactTime)"],
|
||||
["02", "0.2", _meta("schedule.contract_date", "미정"), _meta("people.registrant"),
|
||||
"SW_설계서.pptx 최초 생성 (build_02설계_pptx.py)"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "agenda",
|
||||
"title": "Contents",
|
||||
"subtitle": "목차",
|
||||
"items": [
|
||||
{"no": "01", "title": "기능명세서", "sub": "메뉴 구조 · View별 기능"},
|
||||
{"no": "02", "title": "제어 시퀀스 / 인터록", "sub": "SeqAutoRunPTOP · 인터록 정의"},
|
||||
{"no": "03", "title": "PLC-PC 신호 정의", "sub": "통신 사양 · PC↔PLC 신호 목록"},
|
||||
{"no": "04", "title": "모션축 / IO 맵", "sub": "축 정의 · DI/DO 맵"},
|
||||
{"no": "05", "title": "TactTime 산정서", "sub": "자동 1사이클 단위동작별 T/T"}
|
||||
]
|
||||
},
|
||||
# ── 01. 기능명세서 ──────────────────────────────────────────────
|
||||
{"type": "divider", "no": "01", "title": "기능명세서", "subtitle": "UI / Function Specification"},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "01.", "title": "메뉴 구조",
|
||||
"subtitle": "RegisterViews — 메인 메뉴 · 권한 · 서브뷰 · 기능 요약",
|
||||
"headers": ["메인 메뉴", "권한", "서브뷰", "기능"],
|
||||
"widths": [1.6, 1.2, 3.4, 5.2], "center_cols": [0, 1],
|
||||
"rows": [
|
||||
["AutoRun", "NONE", "UCMainAutoRun", "자동 운전 메인(SeqAutoRun 연동), 페이지/상태 표시"],
|
||||
["Recipe", "NONE", "UCRecipe / UCRecipeChangeHistory / UCModel", "레시피 편집·변경이력·모델"],
|
||||
["Manual", "NONE", "UCManualScannerOperation / UCManualModelFinder", "스캐너 수동조작·모델 파인더"],
|
||||
["Calibration","NONE", "UCScannerCalibration / UCCameraPixelResolution", "스캐너 보정·픽셀 해상도"],
|
||||
["Monitoring", "NONE", "UCPLCBit / UCPLCWord / UCIOInterfaceView", "PLC 비트(M)·워드(D)·IO 모니터링"],
|
||||
["Device", "LEVEL3", "DeviceSettingView", "디바이스 설정"],
|
||||
["Setting", "LEVEL1", "EquipSettingView / LogSettingView / AutoBackupView2", "장비·로그·자동백업 설정"],
|
||||
["Alarm", "NONE", "AlarmHistoryView / AlarmDescView", "알람 이력·설명"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "01.", "title": "View별 기능 (1/2)",
|
||||
"subtitle": "MainView · RecipeView · ManualView",
|
||||
"headers": ["View", "no", "기능 영역", "기능명", "연동"],
|
||||
"widths": [1.6, 0.6, 1.8, 2.8, 4.6], "center_cols": [0, 1],
|
||||
"rows": [
|
||||
["MainView", "1", "운전", "StartSequence / Stop", "SeqAutoRunPTOP"],
|
||||
["MainView", "2", "상태", "UpdatePageNum", "EVENT_AUTO_RUN_UPDATE_PAGENUM"],
|
||||
["MainView", "3", "상태", "WorkingPosition", "eWorkingPosition"],
|
||||
["MainView", "4", "운전", "Auto→Manual+Resume", "bit15(PLC_WELD_READY_REQ)"],
|
||||
["MainView", "5", "표시", "ScannerCanvasCtrlTeaching", "레이어/오브젝트"],
|
||||
["RecipeView", "1", "레시피", "ActivateRecipe", "RecipeManager"],
|
||||
["RecipeView", "2", "레시피", "RecipeChangeHistory", "RchHandler"],
|
||||
["RecipeView", "3", "모델", "UCModel / EquipmentSpecificModel", "EquipmentSpecificModel_PTOP"],
|
||||
["ManualView", "1", "수동", "ScannerOperation", "CommonDeviceIds.Scanner"],
|
||||
["ManualView", "2", "수동", "ModelFinder", "UCManualModelFinder"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "01.", "title": "View별 기능 (2/2)",
|
||||
"subtitle": "MonitoringView · CalibrationView · SettingView · AlarmView",
|
||||
"headers": ["View", "no", "기능 영역", "기능명", "연동"],
|
||||
"widths": [1.8, 0.6, 1.8, 2.8, 4.4], "center_cols": [0, 1],
|
||||
"rows": [
|
||||
["MonitoringView", "1", "모니터링", "PLCBitMonitoring", "ePLCDevice.M"],
|
||||
["MonitoringView", "2", "모니터링", "PLCWordMonitoring", "ePLCDevice.D"],
|
||||
["MonitoringView", "3", "모니터링", "IOInterfaceView", "IODevice"],
|
||||
["CalibrationView", "1", "보정", "UCScannerCalibration", "스캐너 보정"],
|
||||
["CalibrationView", "2", "보정", "UCCameraPixelResolution","카메라 픽셀 해상도"],
|
||||
["SettingView", "1", "설정", "EquipSettingView", "장비 설정"],
|
||||
["SettingView", "2", "설정", "LogSettingView / AutoBackupView2", "로그·자동백업"],
|
||||
["AlarmView", "1", "알람", "AlarmHistoryView", "AlarmCode_PTOP"],
|
||||
["AlarmView", "2", "알람", "AlarmDescView", "AlarmManager_PTOP"]
|
||||
]
|
||||
},
|
||||
# ── 02. 제어 시퀀스 / 인터록 ────────────────────────────────────
|
||||
{"type": "divider", "no": "02", "title": "제어 시퀀스 / 인터록", "subtitle": "Control Sequence & Interlock"},
|
||||
{
|
||||
"type": "flow",
|
||||
"no": "02.", "title": "SeqAutoRunPTOP — 자동 시퀀스 (초기화 ~ 업로드)",
|
||||
"subtitle": "Sequences/SeqAutoRunPTOP.cs — Builder() 노드 흐름 (1/2)",
|
||||
"steps": [
|
||||
{"title": "Sequence_Enter", "code": "레시피/장비 초기화 · PC_AUTO_STATUS ON", "kind": "proc"},
|
||||
{"title": "CheckInitCondition", "code": "초기 조건 판단", "kind": "dec"},
|
||||
{"title": "CheckPageNo", "code": "PLC_PAGE_CHANGE_REQ(0x08) 대기", "kind": "proc"},
|
||||
{"title": "CheckRecipeNoComp", "code": "PLC_RECIPE_NO 확정/전환 · PC_RECIPE_NO 에코", "kind": "proc"},
|
||||
{"title": "CheckPageNoComp", "code": "PLC_PAGE_NO 3회 검증 · PC_PAGE_CHANGE_COMPLETE ACK", "kind": "proc"},
|
||||
{"title": "SeqUploadWeldingList","code": "레이어 선택 → 용접리스트 업로드 · offset(D70510) 적용", "kind": "proc"}
|
||||
],
|
||||
"branch": {"title": "Resume", "sub": "핸드셰이크 스킵"}
|
||||
},
|
||||
{
|
||||
"type": "flow",
|
||||
"no": "02.", "title": "SeqAutoRunPTOP — 자동 시퀀스 (발진 ~ 완료)",
|
||||
"subtitle": "Sequences/SeqAutoRunPTOP.cs — Builder() 노드 흐름 (2/2)",
|
||||
"steps": [
|
||||
{"title": "WeldingStartReadBit", "code": "PLC_WELD_TRIGGER_REQ(0x10) 대기", "kind": "proc"},
|
||||
{"title": "PreScoutCheck", "code": "M70509 ON → PreScout 실행", "kind": "dec"},
|
||||
{"title": "WaitWeldingStart", "code": "PC_WELD_TRIGGER_ACK ON / WELD_COMPLETE OFF", "kind": "proc"},
|
||||
{"title": "ExecuteWelding", "code": "HeadTheta 인터락 → Gate ON(15ms) → ExecuteList → Gate OFF", "kind": "proc"},
|
||||
{"title": "WriteWeldComplete", "code": "PC_WELD_TRIGGER_ACK OFF · PC_WELD_COMPLETE ON", "kind": "proc"},
|
||||
{"title": "CheckCycleStop", "code": "루프백 or SaveResult → WriteCompletionPLCBit", "kind": "dec"}
|
||||
],
|
||||
"branch": {"title": "PostScout", "sub": "M70509 ON 시 실행"}
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "02.", "title": "인터록 정의",
|
||||
"subtitle": "LaserInterlockSetting.cs · SeqAutoRunPTOP.cs",
|
||||
"headers": ["#", "인터록", "조건", "동작"],
|
||||
"widths": [0.5, 2.3, 4.0, 4.6], "center_cols": [0],
|
||||
"rows": [
|
||||
["1", "Head Theta 발진 게이트", "LaserInterlockSetting.HeadThetaInterlockEnabled ON · Front/Down ±tol 벗어남", "발진 차단 (ALARM_LASER_HEAD_THETA_INTERLOCK). PLC 미연결 시 fail-closed"],
|
||||
["2", "레시피별 방향 차단", "RecipeLaserInterlock.Front/Down 체크", "해당 방향 구역이면 발진 차단"],
|
||||
["3", "중알람(Heavy)", "PLC_HEAVY_ALARM_STATUS(0x05)", "AlarmManager_PTOP.StopSequenceByAlarm → 시퀀스 정지"],
|
||||
["4", "Door / EMO", "PLC_DOOR_INTERLOCK(0x06) / PLC_EMO_STATUS(0x07)", "안전 정지"],
|
||||
["5", "업로드 실패", "용접 오브젝트 0개 / Upload Success=false", "시퀀스 중단 (return null)"]
|
||||
]
|
||||
},
|
||||
# ── 03. PLC-PC 신호 정의서 ──────────────────────────────────────
|
||||
{"type": "divider", "no": "03", "title": "PLC-PC 신호 정의서", "subtitle": "PLC Interface Signal Definition"},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "03.", "title": "통신 사양",
|
||||
"subtitle": "EquipmentSetup.cs · PLCController.Address.cs",
|
||||
"headers": ["항목", "내용"],
|
||||
"widths": [2.8, 8.6], "center_cols": [],
|
||||
"rows": [
|
||||
["PLC 기종", "Mitsubishi Melsec"],
|
||||
["통신 방식", "MX Component (ePLCNetType.MXComponent) — EquipmentSetup.RegisterDevices()"],
|
||||
["맵 파일", "CSV (PLCMMapFileType.CSV)"],
|
||||
["데이터 갱신", "폴링(10ms 주기 ReadBit/ReadWord) + 이벤트 비트(REQ/ACK)"],
|
||||
["디바이스 영역", "비트=M, 워드=D (입력 M70500/D70500 · 출력 M70000/D70000 — 제안)"],
|
||||
["핸드셰이크 규칙", "요청(REQ)→처리→완료(ACK/COMPLETE). 단일 트리거 PLC_PAGE_CHANGE_REQ(0x08)"],
|
||||
["인터락", "Door(0x06)·EMO(0x07)·Heavy알람(0x05) → 시퀀스 정지. HeadTheta(D70510) 발진 게이트"],
|
||||
["Watchdog", "PLC_LIVE_STATUS(0x00) ↔ PC_LIVE_STATUS(0x00) Alive 토글"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "03.", "title": "PC → PLC 신호 목록",
|
||||
"subtitle": "eBitOutput / eWordOutput (Write) — 주요 신호",
|
||||
"headers": ["No", "신호명(enum)", "디바이스", "Type", "의미"],
|
||||
"widths": [0.7, 3.3, 1.4, 0.8, 5.2], "center_cols": [0, 2, 3],
|
||||
"rows": [
|
||||
["0x00", "PC_LIVE_STATUS", "M70000(제안)", "BIT", "PC Alive 토글 (Watchdog)"],
|
||||
["0x01", "PC_AUTO_STATUS", "M70001", "BIT", "Auto 상태 — Enter 시 ON"],
|
||||
["0x05", "PC_HEAVY_ALARM_STATUS", "M70005", "BIT", "중알람"],
|
||||
["0x06", "PC_DOOR_INTERLOCK", "M70006", "BIT", "Door 인터락"],
|
||||
["0x07", "PC_EMO_STATUS", "M70007", "BIT", "EMO"],
|
||||
["0x08", "PC_PAGE_CHANGE_COMPLETE", "M70008", "BIT", "페이지 확정 ACK — PageNo 일치 시 ON"],
|
||||
["0x0F", "PC_WELD_READY_ACK", "M70015", "BIT", "Resume ACK (bit15, 260621)"],
|
||||
["0x10", "PC_WELD_TRIGGER_ACK", "M70016", "BIT", "용접 트리거 ACK"],
|
||||
["0x11", "PC_WELD_BUSY", "M70017", "BIT", "Laser On 표시(발진중)"],
|
||||
["0x12", "PC_WELD_COMPLETE", "M70018", "BIT", "용접 완료"],
|
||||
["D0x01", "PC_PAGE_NO", "D70001", "INT", "페이지 번호 에코"],
|
||||
["D0x02", "PC_RECIPE_NO", "D70002", "INT", "레시피 번호 에코"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "03.", "title": "PLC → PC 신호 목록",
|
||||
"subtitle": "eBitInput / eWordInput (Read) — 주요 신호",
|
||||
"headers": ["No", "신호명(enum)", "디바이스", "Type", "의미"],
|
||||
"widths": [0.7, 3.3, 1.4, 0.8, 5.2], "center_cols": [0, 2, 3],
|
||||
"rows": [
|
||||
["0x00", "PLC_LIVE_STATUS", "M70500(제안)", "BIT", "PLC Alive (Watchdog)"],
|
||||
["0x05", "PLC_HEAVY_ALARM_STATUS", "M70505", "BIT", "중알람 → 시퀀스 정지"],
|
||||
["0x06", "PLC_DOOR_INTERLOCK", "M70506", "BIT", "Door 인터락"],
|
||||
["0x07", "PLC_EMO_STATUS", "M70507", "BIT", "EMO"],
|
||||
["0x08", "PLC_PAGE_CHANGE_REQ", "M70508", "BIT", "단일 게이트 트리거 — PageNo+RecipeNo 확정"],
|
||||
["0x09", "PLC_SCOUT_ENABLE", "M70509", "BIT", "Scout 상시 ON → 용접 전/후 Scout"],
|
||||
["0x0F", "PLC_WELD_READY_REQ", "M70515", "BIT", "Weld_01 Ready → Resume 트리거 (bit15)"],
|
||||
["0x10", "PLC_WELD_TRIGGER_REQ", "M70516", "BIT", "용접 발진 요청"],
|
||||
["D0x01", "PLC_PAGE_NO", "D70501", "INT", "페이지 번호 (1-base, 3회 검증)"],
|
||||
["D0x02", "PLC_RECIPE_NO", "D70502", "INT", "레시피 번호 (11/21/22/31/32)"],
|
||||
["D0x0A", "HEAD_THETA_POSITION", "D70510", "INT", "Laser1 Head Theta — 발진 인터락"]
|
||||
]
|
||||
},
|
||||
# ── 04. 모션축 / IO 맵 ──────────────────────────────────────────
|
||||
{"type": "divider", "no": "04", "title": "모션축 / IO 맵", "subtitle": "Motion Axis & I/O Map"},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "04.", "title": "통신·제어 구성",
|
||||
"subtitle": "EquipmentSetup.cs · PAIX_PTOP.cs · architecture.md §4",
|
||||
"headers": ["구분", "대상", "컨트롤러/디바이스", "통신/버스", "수량·범위"],
|
||||
"widths": [1.8, 1.8, 2.8, 2.0, 3.0], "center_cols": [0],
|
||||
"rows": [
|
||||
["PLC통신", "외부 신호 제어", "Mitsubishi Melsec", "MX Component", "1"],
|
||||
["I/O", "디지털 IO", "(제안) IOUnitConfig.BoardType 확인 필요", "필드버스", "DI/DO"],
|
||||
["Laser", "Core/Ring 레이저", "IO Gate(TruPulse nano 계열)", "DO 게이트", "2(Core+Ring)"],
|
||||
["Scanner", "레이저 스캐너", "RTC LaserScanner", "RTC", "1"],
|
||||
["모션(Servo)", "X/Y 축", "ACS SPiiPlus", "EtherCAT", "2축 (제안)"],
|
||||
["모션(Servo)", "Z 축", "(제안) AuroraMotionBoard", "보드", "1축 (제안)"],
|
||||
["Vision", "카메라/측정", "MIL 기반 AuroraVision", "—", "(현재 미사용)"],
|
||||
["상/하위(MES)", "호스트 연동", "Stream(LBAD/RPC)", "TCP", "옵션"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "04.", "title": "모션축 정의",
|
||||
"subtitle": "ACS SPiiPlus(EtherCAT) · AuroraMotionBoard(보드타입 미확정) — 파라미터 미확정(제안)",
|
||||
"headers": ["Axis", "축명", "용도", "컨트롤러/통신", "행정/범위", "최대속도", "Home방식"],
|
||||
"widths": [0.7, 0.8, 1.7, 2.5, 1.7, 1.5, 2.5], "center_cols": [0, 1],
|
||||
"rows": [
|
||||
["0", "X", "셀 위치 X", "ACS SPiiPlus / EtherCAT", "(제안)", "(제안)", "(제안)"],
|
||||
["1", "Y", "셀 위치 Y", "ACS SPiiPlus / EtherCAT", "(제안)", "(제안)", "(제안)"],
|
||||
["2", "Z", "포커스/높이", "(제안) AuroraMotionBoard", "(제안)", "(제안)", "(제안)"],
|
||||
["—", "Scanner θ/XY", "빔 편향(갈바노)", "RTC LaserScanner", "List 기반 Jump/Mark", "—", "보정테이블"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "04.", "title": "I/O 맵 — DI / DO",
|
||||
"subtitle": "PAIX_PTOP.ePrismaticDIAddress / ePrismaticDOAddress (보드타입 런타임 설정)",
|
||||
"headers": ["구분", "CH(No)", "신호명", "Active", "설명"],
|
||||
"widths": [0.8, 1.0, 3.2, 1.0, 5.4], "center_cols": [0, 1, 3],
|
||||
"rows": [
|
||||
["DI", "9", "CoreLaser_Laser_Ready", "High", "Core 레이저 Ready"],
|
||||
["DI", "10", "CoreLaser_Error_State", "High", "Core 레이저 에러"],
|
||||
["DI", "11", "CoreLaser_Laser_Output_State", "High", "Core 발진 출력 상태"],
|
||||
["DI", "12", "CoreLaser_Control_Status", "High", "Core 제어 상태"],
|
||||
["DI", "13", "RingLaser_Laser_Ready", "High", "Ring 레이저 Ready"],
|
||||
["DI", "14", "RingLaser_Error_State", "High", "Ring 레이저 에러"],
|
||||
["DI", "15", "RingLaser_Laser_Output_State", "High", "Ring 발진 출력 상태"],
|
||||
["DI", "23", "RingLaser_Control_Status", "High", "Ring 제어 상태"],
|
||||
["DO", "9", "CoreLaser_Control", "High", "Core 레이저 게이트(발진 ON/OFF)"],
|
||||
["DO", "10", "CoreLaser_ErrorClearing", "High", "Core 에러 클리어"],
|
||||
["DO", "13", "RingLaser_Control", "High", "Ring 레이저 게이트(발진 ON/OFF)"],
|
||||
["DO", "14", "RingLaser_ErrorClearing", "High", "Ring 에러 클리어"],
|
||||
["DO", "17", "EX_Red_Control", "High", "EX Red(가이드/표시등) 제어"]
|
||||
]
|
||||
},
|
||||
# ── 05. TactTime 산정서 ─────────────────────────────────────────
|
||||
{"type": "divider", "no": "05", "title": "TactTime 산정서", "subtitle": "Tact Time Analysis"},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "05.", "title": "PC TactTime — 자동 1사이클 (음극 1페이지 기준)",
|
||||
"subtitle": "SeqAutoRunPTOP.cs 지연·로그 상수 기준 (제안 — 현장 실측 시 확정)",
|
||||
"headers": ["Unit", "단위동작", "T/T(ms)", "PC", "PLC", "출처"],
|
||||
"widths": [0.7, 3.0, 1.3, 0.6, 0.6, 5.2], "center_cols": [0, 2, 3, 4],
|
||||
"rows": [
|
||||
["1", "Page Change 요청 대기", "가변", "●", "●", "CheckPageNo (폴링 10ms, timeout 60s)"],
|
||||
["2", "Recipe 확정/전환", "~0~수백","●", "—", "CheckRecipeNoComp (동일이면 ~0, 전환 시 Activate+reload)"],
|
||||
["3", "Page 3회 검증", "~600", "●", "●", "CheckPageNoComp (200ms×3)"],
|
||||
["4", "용접리스트 업로드", "가변", "●", "—", "SeqUploadWeldingList (라인수 의존)"],
|
||||
["5", "발진 요청 대기", "가변", "●", "●", "WeldingStartReadBit"],
|
||||
["6", "준비 응답", "~205", "●", "●", "WaitWeldingStart (200+5ms)"],
|
||||
["7", "Gate ON delay", "15", "●", "—", "laserEmissionGateDelayMs (TruPulse 매뉴얼 ≥10ms)"],
|
||||
["8", "실제 발진(ExecuteList)", "미측정", "—", "—", "런타임 값 — 실측 필요(로그 TactTime, 라인수 의존)"],
|
||||
["9", "Gate OFF + BUSY OFF", "~50", "●", "—", "ExecuteWelding 후미"],
|
||||
["10", "Jump+CorrectionTable 복귀", "~500", "—", "—", "Thread.Sleep(500)"],
|
||||
["11", "완료비트 송신", "~55", "●", "●", "WriteWeldComplete (50+5ms)"],
|
||||
["(옵션)","Pre/Post Scout", "+100/회","●","Vision","SCOUT_PROCEED_DELAY_MS, M70509 ON 시"]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "closing",
|
||||
"title": "Thank You",
|
||||
"message": "본 설계서는 소스코드 분석 기반 0.2버전입니다. 파라미터 확정 후 갱신 예정.",
|
||||
"team": _meta("org.team"),
|
||||
"contacts": [_meta("people.pl")]
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
|
||||
def main():
|
||||
os.makedirs(os.path.dirname(OUTPUT), exist_ok=True)
|
||||
fd, spec_path = tempfile.mkstemp(suffix=".json", prefix="sw_spec_")
|
||||
try:
|
||||
with os.fdopen(fd, "w", encoding="utf-8") as f:
|
||||
json.dump(SPEC, f, ensure_ascii=False, indent=2)
|
||||
result = subprocess.run(
|
||||
[sys.executable, BUILDER, "--input", spec_path, "--output", OUTPUT],
|
||||
capture_output=True, text=True, encoding="utf-8"
|
||||
)
|
||||
if result.stdout:
|
||||
print(result.stdout.strip())
|
||||
if result.returncode != 0:
|
||||
print("[ERROR]", result.stderr.strip(), file=sys.stderr)
|
||||
sys.exit(result.returncode)
|
||||
finally:
|
||||
if os.path.exists(spec_path):
|
||||
os.remove(spec_path)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@ -1,481 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
build_02설계_xlsx.py — PtoP Welder(가접용접기) 02.설계 산출물 재생산
|
||||
────────────────────────────────────────────────────────────────────
|
||||
LG PRI 표준 양식(ref 파일 불필요 · 완전 독립 실행).
|
||||
스타일은 xlsxfill.py 에 하드코딩된 상수를 사용.
|
||||
|
||||
전제조건:
|
||||
- Python 3.9+
|
||||
- openpyxl >= 3.1 (pip install openpyxl)
|
||||
|
||||
실행 (저장소 루트에서 한 줄. PYTHONUTF8은 반드시 같은 줄 접두 — 별도 줄이면 적용되지 않는다):
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_xlsx.py
|
||||
|
||||
출력:
|
||||
docs/[Ubisam산출물]/02.설계/IO_DB설계/PLC_PC_인터페이스_신호정의서.xlsx
|
||||
docs/[Ubisam산출물]/02.설계/IO_DB설계/모션축_IO맵_정의서.xlsx
|
||||
docs/[Ubisam산출물]/02.설계/UIUX_기능설계/기능명세서.xlsx
|
||||
docs/[Ubisam산출물]/02.설계/시퀀스_인터록/TactTime_산정서.xlsx
|
||||
"""
|
||||
import sys, os, datetime
|
||||
sys.path.insert(0, os.path.dirname(__file__))
|
||||
from xlsxfill import (
|
||||
make_workbook, set_col_widths, set_row_height,
|
||||
write_banner, write_header_row, write_data_rows, group_merge,
|
||||
BANNER_FONT, BANNER_FILL, BANNER_BORDER, BANNER_ALIGN,
|
||||
SUBBANNER_FONT, SUBBANNER_BORDER, SUBBANNER_ALIGN,
|
||||
HEADER_FONT, HEADER_FILL, HEADER_BORDER_FIRST, HEADER_BORDER_MID, HEADER_BORDER_LAST,
|
||||
DATA_FONT, DATA_FILL_ODD, DATA_FILL_EVEN,
|
||||
DATA_BORDER_FIRST, DATA_BORDER_MID, DATA_BORDER_LAST,
|
||||
DATA_ALIGN_L, DATA_ALIGN_C,
|
||||
FUNC_BANNER_FONT, FUNC_HEADER_FONT, FUNC_HEADER_BORDER,
|
||||
FUNC_DATA_FONT, FUNC_DATA_BORDER, FUNC_DATA_ALIGN,
|
||||
TACT_FONT, TACT_BORDER, TACT_ALIGN, TACT_ALIGN_L,
|
||||
_apply, _border,
|
||||
)
|
||||
from openpyxl.styles import Font, PatternFill, Alignment
|
||||
from openpyxl.utils import get_column_letter as GL
|
||||
|
||||
OUT_DIR = "docs/[Ubisam산출물]/02.설계/"
|
||||
TODAY = datetime.date.today() # 실행일 자동 반영
|
||||
|
||||
|
||||
# ══════════════════════════════════════════════════════
|
||||
# 1. PLC-PC 인터페이스 신호 정의서
|
||||
# 탭: 통신 사양 | PC→PLC (Write) | PLC→PC (Read) | 핸드셰이크 시퀀스
|
||||
# ══════════════════════════════════════════════════════
|
||||
def build_plcpc():
|
||||
wb = make_workbook()
|
||||
OUT = OUT_DIR + "IO_DB설계/PLC_PC_인터페이스_신호정의서.xlsx"
|
||||
|
||||
# ── 통신 사양 ──────────────────────────────────
|
||||
ws = wb.create_sheet("통신 사양")
|
||||
set_col_widths(ws, {"A":"3.7","B":24,"C":106})
|
||||
write_banner(ws, 2, 2, 3,
|
||||
"PtoP Welder(가접용접기) ↔ PLC 인터페이스 통신 사양",
|
||||
"PtoP Welder(가접용접기) — MX Component / 단일 게이트(PAGE_REQ) 핸드셰이크 · 디바이스 주소=제안(M70000/M70500 베이스)")
|
||||
write_header_row(ws, 4, 2, ["항목", "내용"])
|
||||
comm = [
|
||||
["PLC 기종", "Mitsubishi Melsec"],
|
||||
["통신 방식", "MX Component (ePLCNetType.MXComponent)"],
|
||||
["맵 파일", "CSV (PLCMMapFileType.CSV)"],
|
||||
["데이터 갱신", "폴링(10ms) + 이벤트 비트(REQ/ACK)"],
|
||||
["디바이스 영역","비트=M, 워드=D (PC Write M70000~/D70000~, PLC Read M70500~/D70500~)"],
|
||||
["핸드셰이크", "REQ→처리→ACK/COMPLETE. 단일 트리거 PLC_PAGE_CHANGE_REQ"],
|
||||
["좌표·실수", "워드 INT(short). Offset/변위 INT. 스케일 ×1(필요시 ×1000)"],
|
||||
["Watchdog", "PLC_LIVE_STATUS(0x00) ↔ PC_LIVE_STATUS(0x00)"],
|
||||
["인터락", "Door(0x06)/EMO(0x07)/Heavy(0x05)→정지, HeadTheta(D70510) 발진 인터락"],
|
||||
["주의", "주소=제안. 2nd 블록(0x65~)은 양극(P) 예비, 현재 음극만 사용"],
|
||||
]
|
||||
write_data_rows(ws, 5, 2, comm, center_cols={0})
|
||||
|
||||
# ── PC→PLC (Write) ─────────────────────────────
|
||||
ws = wb.create_sheet("PC→PLC (Write)")
|
||||
set_col_widths(ws, {"A":3.7,"B":8,"C":14,"D":28,"E":10,"F":14,"G":8,"H":36,"I":28,"J":22})
|
||||
write_banner(ws, 2, 2, 10,
|
||||
"PC → PLC 신호 (PC Write)",
|
||||
"PC(Aurora)가 PLC로 보내는 요청·결과·보정값")
|
||||
HDR = ["No","Seq/구분","신호명","방향","디바이스(제안)","Type","의미 / 트리거","응답·완료","비고"]
|
||||
write_header_row(ws, 4, 2, HDR)
|
||||
write_rows = [
|
||||
["0x00","Status","PC_LIVE_STATUS","PC→PLC","M70000(제안)","BIT","PC Alive","","Watchdog"],
|
||||
["0x01","Status","PC_AUTO_STATUS","PC→PLC","M70001","BIT","Auto 상태","","Enter시 true"],
|
||||
["0x02","Status","PC_AUTO_COMPLETE","PC→PLC","M70002","BIT","Auto 완료","",""],
|
||||
["0x03","Status","PC_MANUAL_COMPLETE","PC→PLC","M70003","BIT","Manual 완료","",""],
|
||||
["0x04","Alarm","PC_LIGHT_ALARM_STATUS","PC→PLC","M70004","BIT","경알람","",""],
|
||||
["0x05","Alarm","PC_HEAVY_ALARM_STATUS","PC→PLC","M70005","BIT","중알람","",""],
|
||||
["0x06","Status","PC_DOOR_INTERLOCK","PC→PLC","M70006","BIT","Door 인터락","",""],
|
||||
["0x07","Status","PC_EMO_STATUS","PC→PLC","M70007","BIT","EMO","",""],
|
||||
["0x08","Process","PC_PAGE_CHANGE_COMPLETE","PC→PLC","M70008","BIT","페이지 확정 ACK","","PageNo 일치시 ON"],
|
||||
["0x09","Process","PC_RECIPE_CHANGE_COMPLETE","PC→PLC","M70009","BIT","레시피 변경 완료(미감시)","","260618"],
|
||||
["0x0F","Process","PC_WELD_READY_ACK","PC→PLC","M70015","BIT","Resume ACK/run","","bit15,260621"],
|
||||
["0x10","Process","PC_WELD_TRIGGER_ACK","PC→PLC","M70016","BIT","용접 트리거 ACK","",""],
|
||||
["0x11","Status","PC_WELD_BUSY","PC→PLC","M70017","BIT","Laser On 표시","","260626"],
|
||||
["0x12","Process","PC_WELD_COMPLETE","PC→PLC","M70018","BIT","용접 완료","",""],
|
||||
["0x14","Process","PC_WELD_NG_JUDGE","PC→PLC","M70020","BIT","용접 NG 판정","",""],
|
||||
["0x25","Request","PC_RMS_PARAMETER_READ_REQUEST_ACK","PC→PLC","M70037","BIT","RMS read ACK","",""],
|
||||
["D0x00","Info","PC_ERROR_CODE","PC→PLC","D70000(제안)","INT","에러코드 에코","",""],
|
||||
["D0x01","Info","PC_PAGE_NO","PC→PLC","D70001","INT","페이지 에코","",""],
|
||||
["D0x02","Info","PC_RECIPE_NO","PC→PLC","D70002","INT","레시피 에코","","260618"],
|
||||
["D0x08","Process","PC_WELD_OFFSET_X","PC→PLC","D70008","INT","용접 보정 X","",""],
|
||||
["D0x0A","Process","PC_WELD_OFFSET_Y","PC→PLC","D70010","INT","용접 보정 Y","",""],
|
||||
["D0x0C","Process","PC_DISPLACEMENT1_MEASUREMENT","PC→PLC","D70012","INT","변위 측정1","",""],
|
||||
["D0x0E","Process","PC_DISPLACEMENT2_MEASUREMENT","PC→PLC","D70014","INT","변위 측정2","",""],
|
||||
["D0x14~","Info","PC_CELL_ID_01~10","PC→PLC","D70020~","INT(ASCII)","Cell ID 에코","",""],
|
||||
["D0x1E~","Info","PC_LOT_ID_01~08","PC→PLC","D70030~","INT(ASCII)","Lot ID 에코","",""],
|
||||
["D0x28~","Info","PC_FDC_PAGE1~3_POWER/VELOCITY","PC→PLC","D70040~","INT","FDC 파워/속도","",""],
|
||||
["D0x3C~","Info","PC_RMS_ALLOC_START~END","PC→PLC","D70060~97","INT","RMS 할당","",""],
|
||||
]
|
||||
write_data_rows(ws, 5, 2, write_rows, center_cols={0,3,5})
|
||||
n = len(write_rows)
|
||||
group_merge(ws, 3, 5, n, [r[1] for r in write_rows])
|
||||
ws.merge_cells(f"E5:E{4+n}")
|
||||
|
||||
# ── PLC→PC (Read) ──────────────────────────────
|
||||
ws = wb.create_sheet("PLC→PC (Read)")
|
||||
set_col_widths(ws, {"A":3.7,"B":8,"C":14,"D":28,"E":10,"F":14,"G":8,"H":36,"I":28,"J":22})
|
||||
write_banner(ws, 2, 2, 10,
|
||||
"PLC → PC 신호 (PC Read)",
|
||||
"PLC가 PC로 보내는 요청·상태·완료")
|
||||
write_header_row(ws, 4, 2, HDR)
|
||||
read_rows = [
|
||||
["0x00","Status","PLC_LIVE_STATUS","PLC→PC","M70500(제안)","BIT","PLC Alive","Watchdog",""],
|
||||
["0x01","Status","PLC_AUTO_STATUS","PLC→PC","M70501","BIT","Auto 상태","",""],
|
||||
["0x02","Request","PLC_AUTO_REQ","PLC→PC","M70502","BIT","Auto 요청","PC_AUTO_STATUS",""],
|
||||
["0x03","Request","PLC_MANUAL_REQ","PLC→PC","M70503","BIT","Manual 요청","",""],
|
||||
["0x04","Alarm","PLC_LIGHT_ALARM_STATUS","PLC→PC","M70504","BIT","경알람","",""],
|
||||
["0x05","Alarm","PLC_HEAVY_ALARM_STATUS","PLC→PC","M70505","BIT","중알람","시퀀스 정지",""],
|
||||
["0x06","Status","PLC_DOOR_INTERLOCK","PLC→PC","M70506","BIT","Door","인터락",""],
|
||||
["0x07","Status","PLC_EMO_STATUS","PLC→PC","M70507","BIT","EMO","인터락",""],
|
||||
["0x08","Request","PLC_PAGE_CHANGE_REQ","PLC→PC","M70508","BIT","단일 게이트 트리거","Page+Recipe 확정",""],
|
||||
["0x09","Request","PLC_SCOUT_ENABLE","PLC→PC","M70509","BIT","Scout Enable","","260622"],
|
||||
["0x0F","Request","PLC_WELD_READY_REQ","PLC→PC","M70515","BIT","Weld_01 Ready→Resume","","bit15,260621"],
|
||||
["0x10","Request","PLC_WELD_TRIGGER_REQ","PLC→PC","M70516","BIT","용접 발진 요청","READY_ACK/BUSY",""],
|
||||
["0x11","Status","PLC_WELD_WAIT","PLC→PC","M70517","BIT","용접 대기","",""],
|
||||
["0x12","Process","PLC_WELD_COMPLETE_ACK","PLC→PC","M70518","BIT","용접 완료 ACK","",""],
|
||||
["0x1E","Alarm","PLC_ALARM_RESET","PLC→PC","M70530","BIT","알람 리셋","",""],
|
||||
["0x25","Request","PLC_RMS_PARAMETER_READ_REQUEST","PLC→PC","M70537","BIT","RMS read 요청","ACK",""],
|
||||
["D0x00","Info","PLC_ERROR_CODE","PLC→PC","D70500(제안)","INT","에러코드","",""],
|
||||
["D0x01","Info","PLC_PAGE_NO","PLC→PC","D70501","INT","페이지(1-base)","3회 검증",""],
|
||||
["D0x02","Info","PLC_RECIPE_NO","PLC→PC","D70502","INT","레시피(11/21/22/31/32)","","260618"],
|
||||
["D0x03","Info","PLC_CURRENT_SLOT_NO","PLC→PC","D70503","INT","현재 슬롯","EL/CLEAN",""],
|
||||
["D0x0A","Process","HEAD_THETA_POSITION","PLC→PC","D70510","INT","Laser1 Head Theta","발진 인터락",""],
|
||||
["D0x14~","Info","PLC_CELL_ID_01~10","PLC→PC","D70520~","INT(ASCII)","Cell ID","",""],
|
||||
["D0x1E~","Info","PLC_LOT_ID_01~08","PLC→PC","D70530~","INT(ASCII)","Lot ID","",""],
|
||||
]
|
||||
write_data_rows(ws, 5, 2, read_rows, center_cols={0,3,5})
|
||||
n = len(read_rows)
|
||||
group_merge(ws, 3, 5, n, [r[1] for r in read_rows])
|
||||
ws.merge_cells(f"E5:E{4+n}")
|
||||
|
||||
# ── 핸드셰이크 시퀀스 ─────────────────────────
|
||||
ws = wb.create_sheet("핸드셰이크 시퀀스")
|
||||
set_col_widths(ws, {"A":3.7,"B":6,"C":16,"D":6,"E":8,"F":48,"G":36,"H":40})
|
||||
write_banner(ws, 2, 2, 8,
|
||||
"PLC ↔ PC 핸드셰이크 시퀀스 (Seq별)",
|
||||
"요청 → 처리 → 완료/응답 흐름 │ PtoP Welder 단일 게이트(PLC_PAGE_CHANGE_REQ) 기준")
|
||||
write_header_row(ws, 4, 2, ["No","Seq","Step","주체","동작 / 신호","디바이스(제안)","비고"])
|
||||
hs = [
|
||||
[1,"PageGate",1,"PLC","Page Change 요청(단일 게이트)","PLC_PAGE_CHANGE_REQ(M70508) Set","Page+Recipe 확정 트리거"],
|
||||
[2,"PageGate",2,"PC","Recipe 확정/전환","PLC_RECIPE_NO(D70502)→ActivateRecipe→PC_RECIPE_NO(D70002) 에코","0/동일이면 전환 생략"],
|
||||
[3,"PageGate",3,"PC","Page 3회 검증·확정","PLC_PAGE_NO(D70501) 3회→PC_PAGE_NO 에코→PC_PAGE_CHANGE_COMPLETE(M70008) Set","200ms×3"],
|
||||
[4,"PageGate",4,"PC","용접 리스트 업로드","레이어 선택 + SeqUploadWeldingList","-"],
|
||||
[5,"Weld",1,"PLC","발진 요청","PLC_WELD_TRIGGER_REQ(M70516) Set","PreScout(M70509) 옵션"],
|
||||
[6,"Weld",2,"PC","발진 ACK · BUSY","PC_WELD_TRIGGER_ACK(M70016) Set → PC_WELD_BUSY(M70017) ON","HeadTheta(D70510) 인터락"],
|
||||
[7,"Weld",3,"PC","실제 발진(Gate ON/OFF)","Scanner.ExecuteList → Gate ON/OFF","laserEmissionGateDelay 15ms"],
|
||||
[8,"Weld",4,"PC","완료 통지","PC_WELD_BUSY OFF → PC_WELD_COMPLETE(M70018) Set","PostScout(M70509) 옵션"],
|
||||
[9,"Weld",5,"양측","완료 ACK · Clear","PLC_WELD_COMPLETE_ACK(M70518) → TRIGGER_ACK OFF","루프백(PLC_PAGE_CHANGE_REQ) 대기"],
|
||||
[10,"Resume",1,"PLC","Weld_01 Ready → Resume 요청","PLC_WELD_READY_REQ(M70515) Set","bit15, Auto→Manual+Resume(가변용접)"],
|
||||
[11,"Resume",2,"PC","Resume ACK / run","PC_WELD_READY_ACK(M70015) Set","Resume 시 READY_ACK OFF"],
|
||||
[12,"Interlock",1,"PLC","Door/EMO/Heavy 상태 공유","PLC_DOOR(M70506)/EMO(M70507)/HEAVY(M70505)","이상 시 시퀀스 정지"],
|
||||
[13,"Status",1,"양측","Alive Watchdog 토글","PC_LIVE(M70000) ↔ PLC_LIVE(M70500)","단절 시 안전정지"],
|
||||
[14,"Alarm",1,"PC","PC 알람 통지","PC_LIGHT_ALARM(M70004)/HEAVY_ALARM(M70005) Set","중알람 시 시퀀스 정지"],
|
||||
]
|
||||
write_data_rows(ws, 5, 2, hs, center_cols={0,2,3})
|
||||
group_merge(ws, 3, 5, len(hs), [r[1] for r in hs])
|
||||
|
||||
os.makedirs(os.path.dirname(OUT), exist_ok=True)
|
||||
wb.save(OUT); print("✓ PLC-PC:", OUT)
|
||||
|
||||
|
||||
# ══════════════════════════════════════════════════════
|
||||
# 2. 모션축·IO 맵 정의서
|
||||
# 탭: 통신·제어 구성 | 모션축 정의(ACS) | I-O 맵(DI/DO)
|
||||
# ══════════════════════════════════════════════════════
|
||||
def build_motio():
|
||||
wb = make_workbook()
|
||||
OUT = OUT_DIR + "IO_DB설계/모션축_IO맵_정의서.xlsx"
|
||||
|
||||
# ── 통신·제어 구성 ─────────────────────────────
|
||||
ws = wb.create_sheet("통신·제어 구성")
|
||||
set_col_widths(ws, {"A":4.4,"B":16,"C":24.8,"D":26,"E":20,"F":22,"G":34})
|
||||
write_banner(ws, 2, 2, 7,
|
||||
"PtoP Welder(가접용접기) 통신 · 제어 구성 (PC / Aurora)",
|
||||
"근거: EquipmentSetup.RegisterDevices() / PAIX_PTOP.cs / architecture.md §4 │ 주소·수량=제안")
|
||||
write_header_row(ws, 4, 2, ["구분","대상","컨트롤러 / 디바이스","통신 / 버스","수량·범위","비고"])
|
||||
write_data_rows(ws, 5, 2, [
|
||||
["PLC통신","외부 신호 제어","Mitsubishi Melsec","MX Component","1","ePLCNetType.MXComponent"],
|
||||
["I/O","디지털 IO","(제안) 보드타입 런타임 설정 — IOUnitConfig.BoardType 확인 필요","필드버스","DI/DO","PAIX_PTOP:IODevice"],
|
||||
["Laser","Core/Ring 레이저","IO Gate(TruPulse nano)","DO 게이트","2","ExecuteWelding Gate"],
|
||||
["Scanner","레이저 스캐너","RTC LaserScanner","RTC","1","Scanner.ExecuteList"],
|
||||
["모션(Servo)","X/Y 축","ACS SPiiPlus","EtherCAT","2축 (제안)","AuroraACS"],
|
||||
["모션(Servo)","Z 축","(제안) AuroraMotionBoard — 보드타입 확인 필요","보드","1축 (제안)","AuroraMotionBoard"],
|
||||
["Vision","카메라/측정","MIL 기반","-","-","AuroraVision(현재 미사용)"],
|
||||
["상/하위(MES)","호스트 연동","Stream(LBAD/RPC)","TCP","옵션","UseStream 시"],
|
||||
], center_cols={0,4})
|
||||
|
||||
# ── 모션축 정의(ACS) ────────────────────────────
|
||||
ws = wb.create_sheet("모션축 정의(ACS)")
|
||||
set_col_widths(ws, {"A":4.4,"B":7,"C":12,"D":18,"E":22,"F":8,"G":12,"H":10,"I":10,"J":10,"K":10,"L":20})
|
||||
write_banner(ws, 2, 2, 12,
|
||||
"PtoP Welder(가접용접기) 모션축 구성표 (ACS · MotionBoard) — 제안",
|
||||
"각 축 Init / 단축·동기축 / Jog·Relative·Absolute │ 행정·속도·Home은 모듈 소스 미보유 → (제안)")
|
||||
write_header_row(ws, 4, 2,
|
||||
["Axis","축 명(논리)","용도","컨트롤러/통신","구동","행정/범위","최대속도","Home 방식","Soft Limit","동기/단축","비고"])
|
||||
write_data_rows(ws, 5, 2, [
|
||||
["0","X","셀 위치 X","ACS SPiiPlus/EtherCAT","Servo","(제안)","(제안)","(제안)","(제안)","단축",""],
|
||||
["1","Y","셀 위치 Y","ACS SPiiPlus/EtherCAT","Servo","(제안)","(제안)","(제안)","(제안)","단축",""],
|
||||
["2","Z","포커스/높이","(제안) AuroraMotionBoard","Servo","(제안)","(제안)","(제안)","(제안)","단축",""],
|
||||
["-","Scanner θ/XY","빔 편향(갈바노)","RTC LaserScanner","Galvano","List Jump/Mark","-","-","보정테이블","-",""],
|
||||
], center_cols={0,1,4,5,6,7,8,9})
|
||||
ws.cell(12, 3).value = "※ ACS = PC가 EtherCAT으로 직접 제어하는 Servo 축(X/Y). Z는 AuroraMotionBoard(보드타입 미확정), Scanner θ/XY는 RTC 갈바노. 행정/속도/Home 미확정."
|
||||
ws.cell(12, 3).font = Font(name="맑은 고딕", size=9, italic=True)
|
||||
|
||||
# ── I-O 맵 (DI/DO) ───────────────────────────────
|
||||
ws = wb.create_sheet("I-O 맵(DI-DO)")
|
||||
set_col_widths(ws, {"A":4.4,"B":6,"C":30,"D":6,"E":10,"F":10,"G":8,"H":36,"I":20})
|
||||
write_banner(ws, 2, 2, 9,
|
||||
"PtoP Welder(가접용접기) I/O 맵 (DI/DO) — 근거: PAIX_PTOP.cs ePrismaticDI/DOAddress · 보드 벤더 미확정",
|
||||
"근거: PAIX_PTOP.cs ePrismaticDIAddress / ePrismaticDOAddress · DI 9~23 / DO 9~17")
|
||||
write_header_row(ws, 4, 2, ["No","신호명","Type","권장 모듈","슬롯/CH","Active","설명/인터락","비고"])
|
||||
raw_io = [
|
||||
(9,"CoreLaser_Laser_Ready","DI","DI","High","Core 레이저 Ready"),
|
||||
(10,"CoreLaser_Error_State","DI","DI","High","Core 레이저 에러"),
|
||||
(11,"CoreLaser_Laser_Output_State","DI","DI","High","Core 발진 출력 상태"),
|
||||
(12,"CoreLaser_Control_Status","DI","DI","High","Core 제어 상태"),
|
||||
(13,"RingLaser_Laser_Ready","DI","DI","High","Ring 레이저 Ready"),
|
||||
(14,"RingLaser_Error_State","DI","DI","High","Ring 레이저 에러"),
|
||||
(15,"RingLaser_Laser_Output_State","DI","DI","High","Ring 발진 출력 상태"),
|
||||
(23,"RingLaser_Control_Status","DI","DI","High","Ring 제어 상태"),
|
||||
(9,"CoreLaser_Control","DO","DO","High","Core 레이저 게이트(발진)"),
|
||||
(10,"CoreLaser_ErrorClearing","DO","DO","High","Core 에러 클리어"),
|
||||
(13,"RingLaser_Control","DO","DO","High","Ring 레이저 게이트(발진)"),
|
||||
(14,"RingLaser_ErrorClearing","DO","DO","High","Ring 에러 클리어"),
|
||||
(17,"EX_Red_Control","DO","DO","High","EX Red 표시등 제어"),
|
||||
]
|
||||
io_rows = [[i+1, name, typ, mod, f"{typ} Ch{ch}", act, desc, ""]
|
||||
for i,(ch,name,typ,mod,act,desc) in enumerate(raw_io)]
|
||||
write_data_rows(ws, 5, 2, io_rows, center_cols={0,2,3,4,5})
|
||||
|
||||
os.makedirs(os.path.dirname(OUT), exist_ok=True)
|
||||
wb.save(OUT); print("✓ 모션축·IO:", OUT)
|
||||
|
||||
|
||||
# ══════════════════════════════════════════════════════
|
||||
# 3. 기능명세서
|
||||
# 탭: OverView | MainView | RecipeView | ManualView |
|
||||
# DeviceView | SettingView | VisionView | Sequence 흐름
|
||||
# ══════════════════════════════════════════════════════
|
||||
def build_funcspec():
|
||||
wb = make_workbook()
|
||||
OUT = OUT_DIR + "UIUX_기능설계/기능명세서.xlsx"
|
||||
|
||||
# FUNC 계열은 배경 없이 thin border만 사용
|
||||
tb = lambda: FUNC_DATA_BORDER
|
||||
|
||||
# ── OverView ────────────────────────────────────
|
||||
ws = wb.create_sheet("OverView")
|
||||
set_col_widths(ws, {"A":4.1,"B":7.8,"C":66,"D":18.2,"E":19.3})
|
||||
set_row_height(ws, 2, 43.5)
|
||||
c = ws.cell(2, 2, "PtoP Welder(가접용접기) SW 기능명세서")
|
||||
_apply(c, FUNC_BANNER_FONT, border=_border("medium","medium","medium","medium"),
|
||||
alignment=Alignment(horizontal="center",vertical="center",wrap_text=True))
|
||||
ws.merge_cells("B2:E2")
|
||||
# FUNC 헤더: 배경 없음(None), thin border
|
||||
write_header_row(ws, 4, 2, ["no.","Content"], font=FUNC_HEADER_FONT, fill=None)
|
||||
ov_items = [
|
||||
"운영 SW는 LG PRI의 Aurora 플랫폼으로 개발",
|
||||
"운영 환경 : Windows 11, .NET Framework",
|
||||
"개발 환경 : Windows 11, Visual Studio",
|
||||
"설비 : PtoP Welder(가접용접기) — 셀 P2P 레이저 가접(Tack) 용접",
|
||||
"모션 : ACS SPiiPlus(X/Y, EtherCAT) + AuroraMotionBoard(Z, 보드타입 미확정), 빔 편향 = RTC 갈바노 스캐너",
|
||||
"레이저 : Core / Ring 2계통, IO Gate(TruPulse nano) 발진",
|
||||
"PLC : Mitsubishi MELSEC / MX Component, 단일 게이트(PAGE_REQ) 핸드셰이크",
|
||||
"비전 : MIL 기반(현재 AuroraVision 미사용)",
|
||||
]
|
||||
for i, txt in enumerate(ov_items):
|
||||
r = 5 + i
|
||||
ws.cell(r, 2, i+1).font = FUNC_DATA_FONT
|
||||
ws.cell(r, 2).border = tb()
|
||||
ws.cell(r, 2).alignment = Alignment(horizontal="center", vertical="center")
|
||||
ws.cell(r, 3, txt).font = FUNC_DATA_FONT
|
||||
ws.cell(r, 3).border = tb()
|
||||
ws.cell(r, 3).alignment = Alignment(horizontal="left", vertical="center", wrap_text=True)
|
||||
ws.merge_cells(f"C{r}:E{r}")
|
||||
|
||||
# ── View 시트 공통 헬퍼 ──────────────────────────
|
||||
# 헤더: Update|Funtion Area|Funtion Name|NO|Sub|Content
|
||||
VIEW_HDR = ["Update","Funtion Area","Funtion Name","NO","Sub","Content"]
|
||||
def make_view(name, banner_text, rows):
|
||||
ws = wb.create_sheet(name)
|
||||
set_col_widths(ws, {"A":4,"B":14,"C":16,"D":24,"E":6,"F":14,"G":48})
|
||||
set_row_height(ws, 3, 28)
|
||||
ws.cell(3, 7, banner_text).font = FUNC_DATA_FONT
|
||||
ws.cell(3, 7).alignment = Alignment(horizontal="left", vertical="center")
|
||||
set_row_height(ws, 5, 20)
|
||||
for j, h in enumerate(VIEW_HDR):
|
||||
c = ws.cell(5, 2+j, h)
|
||||
c.font = FUNC_HEADER_FONT
|
||||
c.border = tb()
|
||||
c.alignment = Alignment(horizontal="center", vertical="center")
|
||||
for i, row in enumerate(rows):
|
||||
r = 6 + i
|
||||
vals = [TODAY] + row
|
||||
for j, v in enumerate(vals):
|
||||
c = ws.cell(r, 2+j, v)
|
||||
c.font = FUNC_DATA_FONT
|
||||
c.border = tb()
|
||||
c.alignment = Alignment(
|
||||
horizontal="center" if j in {0,3} else "left",
|
||||
vertical="center", wrap_text=True)
|
||||
|
||||
make_view("MainView","다음은 Main 화면에서 보여야 하는 기능이다.",[
|
||||
["운전","StartSequence/Stop", 1,"SeqAutoRunPTOP", "자동운전 시작/정지"],
|
||||
["상태","UpdatePageNum", 2,"EVENT_AUTO_RUN_UPDATE_PAGENUM","현재 페이지 표시"],
|
||||
["상태","WorkingPosition", 3,"eWorkingPosition", "용접 진행 위치 표시"],
|
||||
["운전","Auto→Manual+Resume", 4,"bit15(PLC_WELD_READY_REQ)", "Resume(가변용접) 기능"],
|
||||
["표시","ScannerCanvasCtrlTeaching", 5,"레이어/오브젝트", "스캐너 캔버스"],
|
||||
])
|
||||
make_view("RecipeView","다음은 Recipe 화면에서 보여야 하는 기능이다.",[
|
||||
["레시피","ActivateRecipe", 1,"RecipeManager", "레시피 선택/활성"],
|
||||
["레시피","RecipeChangeHistory", 2,"RchHandler", "변경 이력"],
|
||||
["모델", "UCModel", 3,"EquipmentSpecificModel_PTOP","모델 편집"],
|
||||
])
|
||||
make_view("ManualView","다음은 Manual 화면에서 보여야 하는 기능이다.",[
|
||||
["Manual", "ScannerOperation", 1,"ScannerOperationView","스캐너 수동 조작(발진/Jump/Mark)"],
|
||||
["Manual", "ModelFinder", 2,"ModelFinderView", "모델 파인더"],
|
||||
["Calibration","ScannerCalibration",3,"(제안)", "스캐너 보정"],
|
||||
["Calibration","PixelResolution", 4,"(제안)", "픽셀 해상도"],
|
||||
])
|
||||
make_view("DeviceView","다음은 Device 화면에서 보여야 하는 기능이다.",[
|
||||
["Device", "DeviceSettingView", 1,"LEVEL3", "디바이스 설정(활성/비활성)"],
|
||||
["Monitoring","PLCBitMonitoring", 2,"ePLCDevice.M","PLC 비트 모니터"],
|
||||
["Monitoring","PLCWordMonitoring", 3,"ePLCDevice.D","PLC 워드 모니터"],
|
||||
["Monitoring","IOInterfaceView", 4,"IODevice", "IO 인터페이스"],
|
||||
])
|
||||
make_view("SettingView","다음은 Setting 화면에서 보여야 하는 기능이다.",[
|
||||
["Setting","Equipment", 1,"LEVEL1", "장비 설정"],
|
||||
["Setting","Log", 2,"-", "로그 설정"],
|
||||
["Setting","AutoBackup", 3,"-", "자동 백업"],
|
||||
["Alarm", "History/Desc", 4,"-", "알람 이력·설명"],
|
||||
["Stream", "ServiceSettingView",5,"UseStream","Stream(상/하위) 사용 시"],
|
||||
])
|
||||
make_view("VisionView","다음은 Vision 화면에서 보여야 하는 기능이다.",[
|
||||
["Vision","(해당없음)",1,"AuroraVision 미사용","MIL 기반 — 현재 미사용(제안)"],
|
||||
])
|
||||
|
||||
# ── Sequence 흐름: Update|Funtion Area|Processing Name|NO|Content
|
||||
ws = wb.create_sheet("Sequence 흐름")
|
||||
set_col_widths(ws, {"A":4,"B":14,"C":16,"D":24,"E":6,"F":60})
|
||||
SEQ_HDR = ["Update","Funtion Area","Processing Name","NO","Content"]
|
||||
set_row_height(ws, 5, 20)
|
||||
for j,h in enumerate(SEQ_HDR):
|
||||
c = ws.cell(5, 2+j, h)
|
||||
c.font = FUNC_HEADER_FONT; c.border = tb()
|
||||
c.alignment = Alignment(horizontal="center",vertical="center")
|
||||
seq_data = [
|
||||
["AutoRun","PAGE_REQ Gate", 1,"PLC_PAGE_CHANGE_REQ(M70508) 단일 게이트 트리거"],
|
||||
["AutoRun","Recipe 확정", 2,"PLC_RECIPE_NO→ActivateRecipe→PC_RECIPE_NO 에코(0/동일 생략)"],
|
||||
["AutoRun","Page 확정", 3,"PLC_PAGE_NO 3회 검증→PC_PAGE_CHANGE_COMPLETE"],
|
||||
["AutoRun","List Upload", 4,"레이어 선택 + SeqUploadWeldingList"],
|
||||
["AutoRun","발진 요청", 5,"PLC_WELD_TRIGGER_REQ→PC_WELD_TRIGGER_ACK/BUSY(HeadTheta 인터락)"],
|
||||
["AutoRun","발진", 6,"Gate ON(15ms)→Scanner.ExecuteList→Gate OFF"],
|
||||
["AutoRun","완료", 7,"PC_WELD_COMPLETE→PLC_WELD_COMPLETE_ACK"],
|
||||
["AutoRun","루프백", 8,"CheckCycleStop→PAGE_REQ 대기(Resume 시 READY_ACK OFF)"],
|
||||
]
|
||||
for i, row in enumerate(seq_data):
|
||||
r = 6 + i
|
||||
vals = [TODAY] + row
|
||||
for j,v in enumerate(vals):
|
||||
c = ws.cell(r, 2+j, v)
|
||||
c.font = FUNC_DATA_FONT; c.border = tb()
|
||||
c.alignment = Alignment(horizontal="center" if j in {0,3} else "left",
|
||||
vertical="center", wrap_text=True)
|
||||
|
||||
os.makedirs(os.path.dirname(OUT), exist_ok=True)
|
||||
wb.save(OUT); print("✓ 기능명세서:", OUT)
|
||||
|
||||
|
||||
# ══════════════════════════════════════════════════════
|
||||
# 4. TactTime 산정서
|
||||
# 탭: PLC TactTime | PC TactTime
|
||||
# ══════════════════════════════════════════════════════
|
||||
def build_tact():
|
||||
wb = make_workbook()
|
||||
OUT = OUT_DIR + "시퀀스_인터록/TactTime_산정서.xlsx"
|
||||
|
||||
def tact_cell(ws, r, c, v, align="center"):
|
||||
cell = ws.cell(r, c, v)
|
||||
cell.font = TACT_FONT; cell.border = TACT_BORDER
|
||||
cell.alignment = Alignment(horizontal=align, vertical="center", wrap_text=True)
|
||||
return cell
|
||||
|
||||
# ── PLC TactTime (미입수) ──────────────────────
|
||||
ws = wb.create_sheet("PLC TactTime")
|
||||
set_col_widths(ws, {"B":18,"C":19.5,"D":49.6,"E":10,"F":10.8})
|
||||
set_row_height(ws, 3, 53)
|
||||
tact_cell(ws, 3, 2, "PLC Main 동작 (PtoP Welder) — 미입수")
|
||||
ws.merge_cells("B3:E3")
|
||||
write_header_row(ws, 4, 2, ["공정","Unit","단위동작","T/T"], font=TACT_FONT, fill=None)
|
||||
set_row_height(ws, 4, 22)
|
||||
set_row_height(ws, 5, 40)
|
||||
tact_cell(ws, 5, 2, "(미입수)", "center")
|
||||
tact_cell(ws, 5, 3, "PLC 시퀀스 사양 입수 후 작성", "left")
|
||||
tact_cell(ws, 5, 4, "셀 로딩 / 언로딩 / 페이지 인덱싱 T/T — PLC 측 단위동작 미보유(제안)", "left")
|
||||
tact_cell(ws, 5, 5, "미입수", "center")
|
||||
|
||||
# ── PC TactTime ────────────────────────────────
|
||||
ws = wb.create_sheet("PC TactTime")
|
||||
set_col_widths(ws, {"A":11.7,"B":18,"C":38.1,"D":75.8,"E":8,"F":10.9,"G":12.2,"H":42,"I":12,"J":13})
|
||||
set_row_height(ws, 3, 53)
|
||||
tact_cell(ws, 3, 2, "Main 동작 (PtoP Welder · 자동, 값=제안 / 출처: SeqAutoRunPTOP.cs)", "left")
|
||||
ws.merge_cells("B3:E3")
|
||||
tact_cell(ws, 3, 8, "구간 합계")
|
||||
ws.merge_cells("H3:J3")
|
||||
# 헤더 행 높이
|
||||
set_row_height(ws, 4, 22)
|
||||
for col, h in zip([2,3,4,5], ["공정","Unit","단위동작","T/T"]):
|
||||
tact_cell(ws, 4, col, h)
|
||||
for col, h in zip([8,9,10], ["Working Process","상세합계","기준/참조합계"]):
|
||||
tact_cell(ws, 4, col, h)
|
||||
|
||||
L = [
|
||||
("Page/Recipe 게이트","핸드셰이크","Page Change 요청 대기","가변"),
|
||||
("Page/Recipe 게이트","핸드셰이크","Recipe 확정/전환","~0~수백"),
|
||||
("Page/Recipe 게이트","핸드셰이크","Page 3회 검증 (200ms×3)","~600"),
|
||||
("Page/Recipe 게이트","핸드셰이크","용접리스트 업로드","가변"),
|
||||
("발진 준비","WeldingStart","발진 요청 대기","가변"),
|
||||
("발진 준비","WeldingStart","준비 응답 WaitWeldingStart(200+5)","~205"),
|
||||
("발진","ExecuteWelding","Gate ON delay(laserEmissionGateDelayMs)","15"),
|
||||
("발진","ExecuteWelding","실제 발진 Scanner.ExecuteList","~285"),
|
||||
("발진","ExecuteWelding","Gate OFF + BUSY OFF","~50"),
|
||||
("발진","ExecuteWelding","Jump+Correction 복귀 Thread.Sleep(500)","~500"),
|
||||
("완료","WeldComplete","완료비트 송신 WriteWeldComplete(50+5)","~55"),
|
||||
("옵션","Scout","Pre/Post Scout (M70509 ON 시)","+100/회"),
|
||||
]
|
||||
R = [
|
||||
("Page/Recipe 게이트","가변(폴링 10ms, timeout 60s)","-"),
|
||||
("발진 준비","~205",""),
|
||||
("발진(1발 기준)","~850 (15+285+50+500)",""),
|
||||
("완료","~55",""),
|
||||
("Scout(옵션)","+100/회",""),
|
||||
("1 사이클(가변 제외)","≈1110+","제안"),
|
||||
]
|
||||
for i, (grp, unit, action, tt) in enumerate(L):
|
||||
r = 5 + i
|
||||
set_row_height(ws, r, 30)
|
||||
tact_cell(ws, r, 2, grp, "left")
|
||||
tact_cell(ws, r, 3, unit, "left")
|
||||
tact_cell(ws, r, 4, action, "left")
|
||||
tact_cell(ws, r, 5, tt, "center")
|
||||
for i, (proc, detail, ref_) in enumerate(R):
|
||||
r = 5 + i
|
||||
tact_cell(ws, r, 8, proc, "left")
|
||||
tact_cell(ws, r, 9, detail, "center")
|
||||
tact_cell(ws, r, 10, ref_, "center")
|
||||
# 공정 그룹 병합
|
||||
group_merge(ws, 2, 5, len(L), [r[0] for r in L])
|
||||
group_merge(ws, 3, 5, len(L), [r[0]+"|"+r[1] for r in L])
|
||||
|
||||
os.makedirs(os.path.dirname(OUT), exist_ok=True)
|
||||
wb.save(OUT); print("✓ TactTime:", OUT)
|
||||
|
||||
|
||||
# ══════════════════════════════════════════════════════
|
||||
if __name__ == "__main__":
|
||||
build_plcpc()
|
||||
build_motio()
|
||||
build_funcspec()
|
||||
build_tact()
|
||||
print("\n✅ 02.설계 xlsx 4종 재생산 완료 (ref 파일 불필요).")
|
||||
@ -1,204 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
xlsxfill.py — LG PRI 표준 양식 xlsx 헬퍼 (ref 파일 불필요 · 완전 독립)
|
||||
|
||||
스타일 상수는 LG PRI 표준 양식에서 추출한 값으로 하드코딩됨(원본 ref 파일에 의존하지 않는다).
|
||||
모든 파일 구조(배너·헤더·데이터·그룹병합)를 openpyxl만으로 재현한다.
|
||||
|
||||
사용법:
|
||||
import sys
|
||||
sys.path.insert(0, os.path.dirname(__file__))
|
||||
from xlsxfill import (
|
||||
make_workbook, set_col_widths, set_row_height,
|
||||
write_banner, write_header_row, write_data_rows, group_merge,
|
||||
BANNER_FONT, BANNER_FILL, HEADER_FONT, HEADER_FILL,
|
||||
DATA_FONT, DATA_FILL_ODD, DATA_FILL_EVEN,
|
||||
FUNC_BANNER_FONT, FUNC_HEADER_FONT, FUNC_DATA_FONT,
|
||||
TACT_FONT, TACT_BORDER, _apply, _border,
|
||||
)
|
||||
|
||||
전제조건: Python 3.9+, openpyxl >= 3.1
|
||||
실행(저장소 루트에서, 맨 파일명 금지 — 셸 cwd는 호출마다 초기화된다):
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-deliverables/references/build_02설계_xlsx.py
|
||||
"""
|
||||
import openpyxl
|
||||
from openpyxl import Workbook
|
||||
from openpyxl.styles import Font, PatternFill, Border, Side, Alignment, GradientFill
|
||||
from openpyxl.utils import get_column_letter
|
||||
from openpyxl.utils.cell import range_boundaries
|
||||
|
||||
# ─────────────────────────────────────────────
|
||||
# 스타일 상수 (ref 파일 직접 추출값)
|
||||
# ─────────────────────────────────────────────
|
||||
_F = Font
|
||||
_P = PatternFill
|
||||
_B = Border
|
||||
_S = Side
|
||||
_A = Alignment
|
||||
|
||||
def _border(left=None, right=None, top=None, bottom=None):
|
||||
def s(v): return _S(border_style=v) if v else _S()
|
||||
return _B(left=s(left), right=s(right), top=s(top), bottom=s(bottom))
|
||||
|
||||
# 배너 행 (B2) — 진네이비 배경, 흰 굵은 글자
|
||||
BANNER_FONT = _F(name="맑은 고딕", size=13, bold=True, color="FFFFFFFF")
|
||||
BANNER_FILL = _P("solid", fgColor="FF1F4E78")
|
||||
BANNER_BORDER = _border("medium","medium","medium","medium")
|
||||
BANNER_ALIGN = _A(horizontal="center", vertical="center", wrap_text=True)
|
||||
|
||||
# 부제 행 (B3) — 테두리만
|
||||
SUBBANNER_FONT = _F(name="맑은 고딕", size=9)
|
||||
SUBBANNER_BORDER = _border("medium","medium",None,None)
|
||||
SUBBANNER_ALIGN = _A(horizontal="left", vertical="center", wrap_text=True)
|
||||
|
||||
# 헤더 행 (B4/B5 등) — 파랑 배경, 흰 굵은 글자
|
||||
HEADER_FONT = _F(name="맑은 고딕", size=11, bold=True, color="FFFFFFFF")
|
||||
HEADER_FILL = _P("solid", fgColor="FF2E75B6")
|
||||
HEADER_BORDER_FIRST = _border("medium","thin","thin","thin")
|
||||
HEADER_BORDER_MID = _border("thin","thin","thin","thin")
|
||||
HEADER_BORDER_LAST = _border("thin","medium","thin","thin")
|
||||
HEADER_ALIGN = _A(horizontal="center", vertical="center", wrap_text=True)
|
||||
|
||||
# 데이터 행 — 교대 배경(연파랑) + 흰 배경
|
||||
DATA_FONT = _F(name="맑은 고딕", size=10)
|
||||
DATA_FILL_ODD = _P("solid", fgColor="FFDDEBF7") # 연파랑 (홀수행)
|
||||
DATA_FILL_EVEN = _P("solid", fgColor="FFFFFFFF") # 흰색 (짝수행)
|
||||
DATA_BORDER_FIRST = _border("medium","thin","thin","thin")
|
||||
DATA_BORDER_MID = _border("thin","thin","thin","thin")
|
||||
DATA_BORDER_LAST = _border("thin","medium","thin","thin")
|
||||
DATA_ALIGN_L = _A(horizontal="left", vertical="center", wrap_text=True)
|
||||
DATA_ALIGN_C = _A(horizontal="center", vertical="center", wrap_text=True)
|
||||
|
||||
# 기능명세서 전용 스타일 (FUNC ref: 맑은 고딕, 14pt 배너)
|
||||
FUNC_BANNER_FONT = _F(name="맑은 고딕", size=14, bold=True)
|
||||
FUNC_HEADER_FONT = _F(name="맑은 고딕", size=11, bold=True)
|
||||
FUNC_HEADER_BORDER = _border("thin","thin","thin","thin")
|
||||
FUNC_DATA_FONT = _F(name="맑은 고딕", size=11)
|
||||
FUNC_DATA_BORDER = _border("thin","thin","thin","thin")
|
||||
FUNC_DATA_ALIGN = _A(horizontal="left", vertical="center", wrap_text=True)
|
||||
|
||||
# TactTime 전용 (단순 thin 테두리, 색상 없음)
|
||||
TACT_FONT = _F(name="맑은 고딕", size=11)
|
||||
TACT_BORDER = _border("thin","thin","thin","thin")
|
||||
TACT_ALIGN = _A(horizontal="center", vertical="center", wrap_text=True)
|
||||
TACT_ALIGN_L= _A(horizontal="left", vertical="center", wrap_text=True)
|
||||
|
||||
|
||||
# ─────────────────────────────────────────────
|
||||
# 헬퍼 함수
|
||||
# ─────────────────────────────────────────────
|
||||
|
||||
_UNSET = object() # write_header_row fill/font 기본값 sentinel
|
||||
|
||||
|
||||
def make_workbook():
|
||||
wb = Workbook()
|
||||
wb.remove(wb.active) # 기본 Sheet 제거
|
||||
return wb
|
||||
|
||||
|
||||
def set_col_widths(ws, widths: dict):
|
||||
"""widths: {'A':4.4, 'B':16.0, ...}"""
|
||||
for col, w in widths.items():
|
||||
ws.column_dimensions[col].width = w
|
||||
|
||||
|
||||
def set_row_height(ws, row, height):
|
||||
ws.row_dimensions[row].height = height
|
||||
|
||||
|
||||
def _apply(cell, font=None, fill=None, border=None, alignment=None):
|
||||
if font: cell.font = font
|
||||
if fill: cell.fill = fill
|
||||
if border: cell.border = border
|
||||
if alignment: cell.alignment = alignment
|
||||
|
||||
|
||||
def write_banner(ws, row, col_start, col_end, title, subtitle=None,
|
||||
banner_h=26, sub_h=24):
|
||||
"""배너 2행(제목+부제)을 쓰고 병합한다."""
|
||||
set_row_height(ws, row, banner_h)
|
||||
# 제목
|
||||
c = ws.cell(row, col_start, title)
|
||||
_apply(c, BANNER_FONT, BANNER_FILL, BANNER_BORDER, BANNER_ALIGN)
|
||||
L = get_column_letter
|
||||
if col_end > col_start:
|
||||
ws.merge_cells(f"{L(col_start)}{row}:{L(col_end)}{row}")
|
||||
# 우측 셀 border 유지
|
||||
ws.cell(row, col_end).border = _border(right="medium", top="medium", bottom="medium")
|
||||
if subtitle is not None:
|
||||
set_row_height(ws, row+1, sub_h)
|
||||
c2 = ws.cell(row+1, col_start, subtitle)
|
||||
_apply(c2, SUBBANNER_FONT, border=SUBBANNER_BORDER, alignment=SUBBANNER_ALIGN)
|
||||
if col_end > col_start:
|
||||
ws.merge_cells(f"{L(col_start)}{row+1}:{L(col_end)}{row+1}")
|
||||
ws.cell(row+1, col_end).border = _border(right="medium")
|
||||
|
||||
|
||||
def write_header_row(ws, row, col_start, headers, height=22,
|
||||
font=_UNSET, fill=_UNSET):
|
||||
"""헤더 행 작성. 첫/마지막 열 medium 테두리.
|
||||
fill=None 을 넘기면 배경 없음(흰색). 생략하면 HEADER_FILL(파랑) 적용.
|
||||
font=None 을 넘기면 폰트 미설정. 생략하면 HEADER_FONT 적용.
|
||||
"""
|
||||
set_row_height(ws, row, height)
|
||||
_font = HEADER_FONT if font is _UNSET else font
|
||||
_fill = HEADER_FILL if fill is _UNSET else fill
|
||||
n = len(headers)
|
||||
for i, h in enumerate(headers):
|
||||
col = col_start + i
|
||||
c = ws.cell(row, col, h)
|
||||
if i == 0:
|
||||
border = HEADER_BORDER_FIRST
|
||||
elif i == n-1:
|
||||
border = HEADER_BORDER_LAST
|
||||
else:
|
||||
border = HEADER_BORDER_MID
|
||||
_apply(c, _font, _fill, border, HEADER_ALIGN)
|
||||
|
||||
|
||||
def write_data_rows(ws, data_start, col_start, rows,
|
||||
center_cols=None, height=None,
|
||||
font=None, odd_fill=True):
|
||||
"""
|
||||
rows: list[list] 각 행의 값.
|
||||
center_cols: set of 0-based 인덱스 → center align. 나머지 left.
|
||||
odd_fill: True=홀/짝 교대 배경, False=배경 없음.
|
||||
"""
|
||||
n_cols = max((len(r) for r in rows), default=0)
|
||||
center_cols = center_cols or set()
|
||||
for i, rowvals in enumerate(rows):
|
||||
r = data_start + i
|
||||
if height:
|
||||
set_row_height(ws, r, height)
|
||||
is_odd = (i % 2 == 0)
|
||||
fill = (DATA_FILL_ODD if is_odd else DATA_FILL_EVEN) if odd_fill else None
|
||||
for j in range(n_cols):
|
||||
col = col_start + j
|
||||
c = ws.cell(r, col)
|
||||
c.value = rowvals[j] if j < len(rowvals) else None
|
||||
if j == 0:
|
||||
border = DATA_BORDER_FIRST
|
||||
elif j == n_cols-1:
|
||||
border = DATA_BORDER_LAST
|
||||
else:
|
||||
border = DATA_BORDER_MID
|
||||
align = DATA_ALIGN_C if j in center_cols else DATA_ALIGN_L
|
||||
_apply(c, font or DATA_FONT, fill, border, align)
|
||||
|
||||
|
||||
def group_merge(ws, col, data_start, n, key_rows):
|
||||
"""동일 key_rows 값의 연속 행을 col열에서 수직 병합."""
|
||||
i = 0
|
||||
while i < n:
|
||||
k = key_rows[i]
|
||||
if k is None:
|
||||
i += 1
|
||||
continue
|
||||
j = i + 1
|
||||
while j < n and key_rows[j] == k:
|
||||
j += 1
|
||||
if j - i > 1:
|
||||
L = get_column_letter(col)
|
||||
ws.merge_cells(f"{L}{data_start+i}:{L}{data_start+j-1}")
|
||||
i = j
|
||||
@ -1,32 +0,0 @@
|
||||
<div style="background:#1F4E78;color:#fff;padding:8px 16px;border-radius:4px 4px 0 0">
|
||||
<strong>{N}.{단계명}</strong> — {프로젝트명}
|
||||
</div>
|
||||
<div style="background:#2E75B6;color:#fff;padding:3px 16px;border-radius:0 0 4px 4px;font-size:.85em;margin-bottom:12px">
|
||||
{프로젝트코드}-{일련번호}
|
||||
</div>
|
||||
|
||||
| 필드 | 값 |
|
||||
|---|---|
|
||||
| 유형 | <span style="background:{유형색};color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">{유형명}</span> |
|
||||
| 상태 | <span style="background:#757575;color:#fff;padding:1px 10px;border-radius:3px;font-size:.85em">해야 할 일</span> |
|
||||
| 담당자 / 참조자 | {담당자} / {참조자} |
|
||||
| 진행률 | <progress value="0" max="100" style="width:160px;vertical-align:middle"></progress> **0%** |
|
||||
| Hashtag | {태그1} / {태그2} |
|
||||
|
||||
## 산출물 정의
|
||||
> 세부 × 산출물 × 슬롯 표. 단계별 산출물은 04-stage-deliverables 참조.
|
||||
|
||||
| 세부 | 산출물 | 슬롯 |
|
||||
|---|---|---|
|
||||
| {세부} | {산출물} | `{슬롯}/` |
|
||||
|
||||
## 첨부 / 템플릿
|
||||
- {파일명 또는 양식 템플릿 위치}
|
||||
|
||||
<!--
|
||||
사용법:
|
||||
- {…} 토큰을 프로젝트 값으로 교체.
|
||||
- 유형색: 08-design-system.md §색상 팔레트에서 해당 유형 색 코드 사용.
|
||||
- 상태/유형 값은 02-enums.md enum만 사용.
|
||||
- 양식 시트 골격이 필요하면 05-form-schemas.md 참조.
|
||||
-->
|
||||
@ -1,31 +0,0 @@
|
||||
# 프로젝트 메타 (템플릿) — {...} 토큰을 실제 값으로 교체
|
||||
# 출처: UBISAM 협업관리 › 프로젝트 설정 › 기본정보 / 대상자
|
||||
|
||||
project_name: "{사업부}_{고객사}_{설비명} 운영SW"
|
||||
project_kind: "Software" # Software | Hardware
|
||||
project_code: "{CUST}_{TYPE}_{NN}_{YYYYMMDD}" # 예: CUST_TYPE_01_20260101
|
||||
board_type: "Kanban"
|
||||
status: "업무 진행중" # ubisam-format-map §1 enum 4종만 사용 (임의 변형 금지)
|
||||
|
||||
org:
|
||||
division: "{사업부}"
|
||||
team: "{팀}"
|
||||
|
||||
people:
|
||||
registrant: "{등록자} ({직급})"
|
||||
pl: "{PL} ({직급})"
|
||||
|
||||
schedule:
|
||||
contract_date: "{YYYY-MM-DD}"
|
||||
due_date: "{YYYY-MM-DD}"
|
||||
|
||||
# 권한 3단계: 책임자 → 참여자 → 열람자
|
||||
roles:
|
||||
owners: ["{책임자}"]
|
||||
participants: ["{참여자1}", "{참여자2}"]
|
||||
viewers: ["{열람자…}"]
|
||||
|
||||
alarm:
|
||||
realtime_ticket: true
|
||||
mail: true
|
||||
comment: true
|
||||
@ -1,108 +0,0 @@
|
||||
---
|
||||
name: ubisam-format-map
|
||||
description: Ubisam 협업관리 양식의 공통 enum·스키마·단계↔산출물 슬롯 매핑 레퍼런스. 상태(4종)·일감유형(9종)·진행 6단계(분석/협의·설계·제작·셋업·양산·CS)·일감/프로젝트 필드 스키마·티켓 코드 규칙을 제공. Ubisam 양식으로 산출물을 재생산·재배치·검증하거나, 타사 양식 문서를 Ubisam 단계로 매핑할 때 반드시 이 스킬을 먼저 읽을 것. "Ubisam 양식", "협업관리", "일감 6단계", "산출물 슬롯", "상태/유형 enum" 언급 시 사용. 구분 — 이 스킬은 **조회 전용 사전**이다. 실제로 산출물을 만들거나 고치는 것은 `ubisam-deliverables`(트리 생성)·`ubisam-deliverable-rebuild`(기존 문서 재생산)·`ptop-deliverables`(소스 기준 MD)다.
|
||||
---
|
||||
|
||||
# Ubisam 협업관리 양식 맵 (Format Map)
|
||||
|
||||
타사 양식 산출물을 Ubisam 협업관리 양식으로 **재생산·재배치·검증**할 때의 단일 기준 사전이다.
|
||||
근거 원본(스크린샷 분석)은 아래를 참조하며, 값이 갱신되면 **이 파일과 원본을 함께** 고친다.
|
||||
|
||||
- `docs/[Ubisam산출물]/[분석]/_ubisam-협업관리-용어집(skill-ref).md` — enum 사전(원본)
|
||||
- `docs/[Ubisam산출물]/[분석]/2026_06_29_협업관리-프로젝트관리-분석.md` — 단계별 산출물 정의 상세
|
||||
- `docs/[Ubisam산출물]/ref/` — 화면 캡처
|
||||
|
||||
> ⚠ 위 3개 경로는 **`ubisam-deliverables` 스캐폴딩 이후에만 존재**하며, `docs/[Ubisam산출물]/`은
|
||||
> `.gitignore` 제외 대상이라 clone 직후에는 없다. 없으면 **본문 §1~§5를 유일 기준으로 삼고**,
|
||||
> 본문이 답하지 못하는 항목은 `미정 — 확인 필요`로 남긴다. 없는 파일을 찾다 멈추지 말 것.
|
||||
|
||||
## 1. 상태(Status) enum — 4종 (전이 순서)
|
||||
|
||||
```
|
||||
해야 할 일 → 분석 진행 → 업무 진행중 → 진행 완료
|
||||
```
|
||||
아래 **ARGB는 xlsx 셀 채우기용**이다. MD·HTML 뱃지 색은
|
||||
`ubisam-deliverables/references/02-enums.md`의 HEX 표를 쓴다 (같은 상태, 다른 용도).
|
||||
|
||||
| 상태 | 색(ARGB · xlsx) | 칸반 컬럼 |
|
||||
|---|---|---|
|
||||
| 해야 할 일 | `FFD9D9D9` (회색) | Todo |
|
||||
| 분석 진행 | **미확인** — 원본 스크린샷에서 확인 후 기입 | Select For dev |
|
||||
| 업무 진행중 | `FF8FAADC` (파랑) | InProgress |
|
||||
| 진행 완료 | `FFA9D08E` (연두) | Done |
|
||||
|
||||
> `분석 진행`은 이전 판에서 `업무 진행중`과 **같은 ARGB(`FF8FAADC`)로 잘못 적혀 있었다.**
|
||||
> 같은 색이면 조건부서식이 두 상태를 구분하지 못한다. 실제 값을 확인하기 전까지 지어내지 말고
|
||||
> `미확인`으로 두고, 확인되면 이 표를 고친다. 실제 파일 색이 표와 다르면 **파일이 진실원이다.**
|
||||
|
||||
상태 문자열은 위 4개만 사용한다. 임의 변형(예: "완료", "진행중") 금지 — 칸반/조건부서식 매칭이 깨진다.
|
||||
|
||||
> ARGB가 `미확인`인 상태는 **셀 채우기 없이 문자열만 기입**하고 그 사실을 작업 로그에 남긴다.
|
||||
> 색을 지어내면 조건부서식이 잘못 매칭된다.
|
||||
|
||||
## 2. 일감 유형(Type) enum — 9종
|
||||
|
||||
오류수정 · 불합리 · 미팅 · 설계 · 개발 · 제작 · 입고셋업 · 적용 및 모니터링 · 요청대응
|
||||
|
||||
## 3. 진행 6단계 ↔ 기본 일감유형 ↔ 산출물 슬롯
|
||||
|
||||
| # | 단계 | 기본 유형 | 핵심 산출물(슬롯) |
|
||||
|---|---|---|---|
|
||||
| 1 | 분석/협의 | 미팅 | 사양서, CR회의록, 마스터플랜, URS 분석/제어 시나리오 검토 |
|
||||
| 2 | 설계 | 설계 | HMI 화면정의서·UI 스토리보드·기능명세서 / 시퀀스 다이어그램·인터록 정의서 / 통신맵(Memory·IO·Register)·DB 스키마 / D/R 회의록 |
|
||||
| 3 | 제작 | 제작 | 개발환경·핵심모듈·UI/메인 시퀀스·시뮬레이션 / 단위·통합 테스트 결과 보고서(Check-List) |
|
||||
| 4 | 셋업 | 입고셋업 | HW IO/모션 점검 시트 / 파라미터·레시피 백업 / 이슈 로그(Dry Run·Tack Time) / MES 연동 / SAT 결과서 |
|
||||
| 5 | 양산 | 적용 및 모니터링 | 운영 가이드·매뉴얼(HMI·알람조치) / S/W 최적화 / 최종 버전 동결·마스터 백업 / 프로젝트 완료 보고서 |
|
||||
| 6 | CS | 요청대응 | 요청대응 이력(가동 후 CS) |
|
||||
|
||||
**타사 양식 → 슬롯 매핑 원칙**: 원본 문서의 목적(요구분석/설계정의/테스트/셋업/운영매뉴얼)을 위 슬롯 키워드와 대조해 단계를 결정한다. 한 문서가 여러 단계에 걸치면 단일 슬롯 배치가 기본값이며 보조 단계를 비고에 병기한다.
|
||||
**단 분할 여부의 최종 판정은 `ubisam-analyst.md` §4가 소유한다** — 시트/슬라이드 단위로 서로 다른
|
||||
슬롯에 배치하는 것이 적절한 문서가 있기 때문이다. 이 절과 충돌하면 analyst §4를 따른다.
|
||||
|
||||
## 4. 일감 필드 스키마
|
||||
|
||||
| 필드 | 규칙 |
|
||||
|---|---|
|
||||
| 제목 | `N.단계명` (예: `2.설계`) |
|
||||
| 티켓번호 | `{프로젝트코드}-{일련번호}` — 프로젝트코드는 `_meta/project.yaml`에서 읽는다 |
|
||||
| 유형 | §2 enum 1개 |
|
||||
| 상태 | §1 enum 1개 |
|
||||
| 우선순위 | 보통(=Normal) 기본 |
|
||||
| 담당자/참조자 | `이름(직급)` |
|
||||
| 진행률 | % |
|
||||
| 등록일/수정일/종료일 | yyyy/mm/dd (또는 yyyy-mm-dd) |
|
||||
| 예상시간 | `2w 4d 6h 45m` 형식 |
|
||||
| Hashtag | 자유 태그 |
|
||||
| 첨부파일 | 최대 2.93GB |
|
||||
|
||||
## 5. 프로젝트 메타 스키마
|
||||
|
||||
프로젝트명 · 종류(Software) · 프로젝트형식(Kanban) · 코드명 · 사업부/팀 · PL · 등록자 · 계약일/납기 · 권한(책임자→참여자→열람자).
|
||||
|
||||
**프로젝트 메타의 유일 진실원은 `docs/[Ubisam산출물]/_meta/project.yaml`이다.**
|
||||
이 스킬에 특정 프로젝트의 값을 적어두지 않는다 — 다른 프로젝트에서 복사해 온 값이 여기 남아 있으면,
|
||||
그것을 읽은 작성가가 산출물에 그대로 기입하고 검증가는 그 값을 정답으로 대조하게 된다.
|
||||
즉 **하네스가 잡아야 할 "타설비 잔재"를 하네스 스스로 공급하는 꼴**이 된다.
|
||||
|
||||
`project.yaml`이 없으면 값을 지어내지 말고 `미정 — 확인 필요`로 남기고 사용자에게 묻는다.
|
||||
|
||||
## 6. PTOP 채움 시 참고값 (검증 기준 아님)
|
||||
|
||||
> 아래는 **이 저장소 한정 참고값**이다. §5 원칙대로 프로젝트 메타의 진실원은 `_meta/project.yaml`이며,
|
||||
> qa는 이 절을 정답으로 대조하지 않는다. `project.yaml`과 어긋나면 `project.yaml`이 우선한다.
|
||||
|
||||
|
||||
설비: 각형 배터리 레이저 용접기(ILSOS OC5 PtoP Welder), Aurora 2.0 / .NET 4.8.1 / WPF.
|
||||
주요 디바이스: PLC(Mitsubishi Melsec·MX Component), Laser Scanner(RTC), Laser(IO Gate),
|
||||
Digital IO — 구현 클래스는 `PAIX_PTOP`(`EquipmentSetup.cs:153` 등록), 보드 타입은 런타임
|
||||
`IOUnitConfig.BoardType` 설정값이다. "Ajin"으로 단정하지 말고 설정을 확인할 것.
|
||||
메인 시퀀스: `SeqAutoRunPTOP`. PLC 인터페이스: `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs`.
|
||||
|
||||
> 재생산 산출물의 **출처(코드 경로/커밋)**를 항상 명시한다 — 검증가가 근거 추적에 사용한다.
|
||||
|
||||
> **규약 바인딩.** 이 스킬은 enum·양식의 **단일 기준**이라 여기서 새는 추측은 하류 전체를 오염시킨다.
|
||||
> - 확인하지 않은 값·해석은 문장 앞에 `[추론]` 을 붙인다 (`rules.md` #15·#16). 확인 후 표기를 떼고
|
||||
> `파일:심볼` 로 바꾼다. 검색은 **`\[추론\]`** 로 이스케이프한다(대괄호=정규식 문자클래스).
|
||||
> - `미확인`(값을 못 찾음)과 `[추론]`(확인 전 서술)은 축이 다르다 — 대체하지 말고 필요하면 병기한다.
|
||||
> - 주석·클래스명을 근거로 삼지 않는다 (#1). 위 `BoardType` 이 그 사례다.
|
||||
> - 모르면 지어내지 말고 모른다고 한다 (#9).
|
||||
@ -1,162 +0,0 @@
|
||||
---
|
||||
name: ubisam-ppt-make
|
||||
description: >-
|
||||
Ubisam SW 설계서 디자인 시스템으로 .pptx 덱을 만든다. 모든 페이지에 UbiSam 로고,
|
||||
고정 폰트(한글=굴림 / 영문=Arial), 파란 accent 컬러. JSON spec을 받아 python-pptx로 렌더링한다.
|
||||
"Ubisam 설계서 PPT 만들어줘", "유비삼 스타일 덱", "이 양식으로 발표자료", "/ubisam-ppt-make"
|
||||
요청 시 사용. `ubisam-deliverables`·`ubisam-deliverable-rebuild`가 PPTX 렌더링을 위임할 때도
|
||||
반드시 이 스킬을 쓴다 — 다른 곳에서 python-pptx로 **덱을 새로 만들지** 않는다.
|
||||
(예외: `ui_layout_image`가 **기존 pptx에 이미지를 삽입·교체**하는 것은 렌더링이 아니므로 허용.)
|
||||
구분 — 기획·조사부터 필요한 일반 발표자료는 `ppt_Agent`, 이 스킬은 **Ubisam 브랜드 spec→pptx 렌더링 전용**.
|
||||
맨손 "업데이트"·"다시 실행"만으로는 이 스킬을 고르지 않는다 — 무엇을 만들지 먼저 확인한다.
|
||||
---
|
||||
|
||||
# ubisam-ppt-make — Ubisam SW 설계서 deck builder
|
||||
|
||||
Deterministic PPT builder following the design system extracted from
|
||||
`P-PRJ_BFHB_UBISAM_Ver1.4.pptx` and the user's edited layout showcase
|
||||
(UbiSam logo placed on every page). Takes a JSON spec and emits a `.pptx`
|
||||
via python-pptx.
|
||||
|
||||
## When to use
|
||||
|
||||
- The user types `/ubisam-ppt-make`
|
||||
- Requests like "Ubisam 설계서 PPT 만들어줘" / "유비삼 스타일 덱" / "this format으로"
|
||||
- New design-document presentations that must keep Ubisam branding
|
||||
- **`ubisam-deliverables` 스킬이 PPTX 생성을 위임할 때** — deliverables는 spec JSON만 준비하고 렌더링은 반드시 이 스킬의 `build_deck.py`로 위임한다
|
||||
|
||||
> **역할 경계**: `ubisam-ppt-make`는 PPTX 렌더링 엔진. JSON spec → `.pptx` 변환만 담당.
|
||||
> 산출물 구조·MD·xlsx 관리는 `ubisam-deliverables` 스킬이 담당.
|
||||
|
||||
## Design system (fixed)
|
||||
|
||||
- Slide: 16:9 (13.333 × 7.5 in)
|
||||
- **슬라이드 마스터 배경** (모든 pptx 자동 적용):
|
||||
- 캔버스: **`WHITE`** — `_apply_master_background()`가 마스터와 전 레이아웃에 흰색을 적용한다
|
||||
(`build_deck.py:55-73`). `BG_SOFT`(#F4F7FA)는 **패널·표 짝수행 fill 전용**이지 배경색이 아니다
|
||||
- 하단 accent 바: `#4A8DCB` h=0.15in @ y=7.35in (마스터 공통)
|
||||
- cover·divider·closing은 자체 full rect로 덮음
|
||||
- 캔버스 배경은 `_apply_master_background()`가 `WHITE`로 고정한다. spec JSON으로 재정의할 수 없다
|
||||
- Accent: `#4A8DCB` (blue), dark `#2F5E8C`; warn `#E53E3E`
|
||||
- Ink `#262A2E`, sub-gray `#6B7278`, soft panel `#F4F7FA`
|
||||
- **Font rule (do not change): 한글=굴림, 영문=Arial** — applied to every run
|
||||
- **UbiSam logo on every page**: cover = bottom-right, all others = top-right
|
||||
- Header pattern: `0X.` badge + title + KO subtitle + split accent bar
|
||||
- Footer: `Ubisam | <doc_title>` + page number (content pages only)
|
||||
|
||||
## 12 layout types (`slide.type`)
|
||||
|
||||
Document layouts:
|
||||
|
||||
| type | purpose | key fields |
|
||||
|------|---------|-----------|
|
||||
| `cover` | 표지 | `tag, title, subtitles[], team, contacts[]` |
|
||||
| `history` | 변경 이력 표 | `rows[] = [No,Version,날짜,변경자,내용]` |
|
||||
| `agenda` | 목차 그리드(≤6) | `items[] = {no,title,sub}` |
|
||||
| `divider` | 섹션 간지(큰 숫자) | `no, title, subtitle` |
|
||||
| `content` | 4분할 패널 | `no, title, subtitle, panels[] = {title,body}` |
|
||||
| `flow` | 시퀀스 플로우차트 | `no, title, subtitle, steps[]={title,code,kind}, branch{title,sub}` |
|
||||
| `table` | 스펙/IO 표 | `no, title, headers[], widths[], center_cols[], rows[][]` |
|
||||
| `closing` | 마무리 | `title, message, team, contacts[]` |
|
||||
|
||||
Manual layouts (HMI Manual / 27번):
|
||||
|
||||
| type | purpose | key fields |
|
||||
|------|---------|-----------|
|
||||
| `screen_guide` | 화면 설명(캡처+번호 콜아웃) | `no, title, caption, image(PNG경로), items[]={title,desc,pos:[x,y]}` |
|
||||
| `procedure` | 조작 절차(번호 단계) | `no, title, steps[]={title,desc}` |
|
||||
| `icon_ref` | 버튼/아이콘 설명(3열 카드, ≤6) | `no, title, items[]={icon,name,func}` |
|
||||
| `alarm` | 알람·조치(주의 배너+표) | `no, title, notice, rows[]=[코드,알람명,원인,조치]` |
|
||||
|
||||
`kind` for flow steps: `"proc"` (process box) or `"dec"` (decision, blue outline).
|
||||
`pos` in `screen_guide` items = callout marker offset (inch) inside the capture box.
|
||||
Page numbers auto-increment over content/manual pages; cover/divider/closing excluded.
|
||||
`divider`/`closing` use a white background with a `#0070C0` / `#2F5E8C` block.
|
||||
|
||||
## Choosing a layout for each piece of data
|
||||
|
||||
Match every chunk of source/analysis data to the layout whose intent fits it —
|
||||
do not force everything into `table`. Full rules + disambiguation in
|
||||
[`reference/layout_selection.md`](reference/layout_selection.md). Cheat sheet:
|
||||
|
||||
- ordered **human** steps → `procedure` · machine sequence **with branches** → `flow`
|
||||
- 2–4 facets, one line each → `content` · repeating rows/cols → `table`
|
||||
- annotate ONE screenshot → `screen_guide` · button/icon legend → `icon_ref`
|
||||
- fault → cause → action (+safety) → `alarm` · revision log → `history`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Gather info** — topic, doc title, sections, slide contents, contacts.
|
||||
내용이 없으면 **무엇을 만들지 되묻는다.** 샘플 showcase는 사용자가 **명시적으로 샘플/레이아웃
|
||||
예시를 요청했을 때만** 만든다 — 그냥 만들면 원하지 않은 13장 덱이 나온다.
|
||||
2. **Classify each data chunk → layout** using the guide above, then
|
||||
**write the spec JSON** — see `examples/showcase.json` and the type tables.
|
||||
Reuse the original BFHB sample text only when the user wants the showcase.
|
||||
3. **Run the builder**:
|
||||
저장소 루트에서 한 줄로 실행한다 (`cd` 하지 않는다 — 출력이 스킬 폴더로 새는 것을 막기 위함):
|
||||
```bash
|
||||
PYTHONUTF8=1 py .claude/skills/ubisam-ppt-make/build_deck.py --input <spec.json> --output <출력 .pptx 절대·상대 경로>
|
||||
```
|
||||
`PYTHONUTF8=1`은 반드시 **같은 줄** 접두로 둔다. 별도 줄에 두면 적용되지 않아 한글이 깨진다.
|
||||
4. **Verify** — render to PNG and eyeball every slide (see Verification).
|
||||
5. **Report** — output path + slide summary.
|
||||
|
||||
## Spec schema (minimal)
|
||||
|
||||
```json
|
||||
{
|
||||
"doc_title": "{문서 제목}",
|
||||
"slides": [
|
||||
{ "type": "cover", "title": "...", "subtitles": ["..."],
|
||||
"team": "{조직명}", "contacts": ["{이름} {직급} {email}"] },
|
||||
{ "type": "divider", "no": "01", "title": "...", "subtitle": "..." },
|
||||
{ "type": "content", "no": "02.", "title": "...", "subtitle": "...",
|
||||
"panels": [ {"title": "...", "body": "..."} ] }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
A full working spec is in [`examples/showcase.json`](examples/showcase.json).
|
||||
|
||||
## Verification
|
||||
|
||||
**가용성을 먼저 확인한다.** PNG 렌더 검증은 PowerPoint COM이 있어야 한다 —
|
||||
`powershell -c "New-Object -ComObject PowerPoint.Application"` 이 실패하면 렌더 검증을 생략하고
|
||||
보고에 **`PNG 검증 미수행 — PowerPoint 부재`** 로 명시한다(검증했다고 하지 않는다).
|
||||
이 경우 아래 **폰트 감사**만 수행한다 — 그건 zipfile만으로 되므로 항상 가능하다.
|
||||
|
||||
PowerPoint가 있으면: Export every slide to PNG and inspect; check no overflow/overlap, logo on
|
||||
every page, and 한글=굴림 / 영문=Arial on all runs.
|
||||
|
||||
```powershell
|
||||
# PowerPoint COM export (Windows, PowerPoint installed)
|
||||
$ppt = New-Object -ComObject PowerPoint.Application
|
||||
$pres = $ppt.Presentations.Open($pptx, $true, $false, $false)
|
||||
$i=1; foreach ($s in $pres.Slides) { $s.Export("$dir/slide$i.png","PNG",1280,720); $i++ }
|
||||
$pres.Close(); $ppt.Quit()
|
||||
```
|
||||
|
||||
Font audit (every `rPr` must show `ea=굴림`, `latin=Arial`):
|
||||
```bash
|
||||
PYTHONUTF8=1 py -c "import zipfile,re,sys;from collections import Counter;z=zipfile.ZipFile(sys.argv[1]);\
|
||||
[print(Counter(re.findall(r'<a:ea typeface=\"([^\"]*)\"',z.read(n).decode('utf-8','ignore')))) \
|
||||
for n in z.namelist() if re.match(r'ppt/slides/slide\\d+',n)]"
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- python-pptx sets only the latin font via `run.font.name`; `_set_font()` also
|
||||
writes `<a:ea>`/`<a:cs>` so Korean renders in 굴림. Always go through it.
|
||||
- Logo asset: `assets/Ubisam_logo_transparent.png`. On dark divider/closing the
|
||||
colored logo has lower contrast but matches the user's original placement.
|
||||
- Keep `.md` files under 200 lines (`rules.md` #4); split if it grows.
|
||||
- **생성·덮어쓸 `.pptx` 경로를 먼저 제시하고 승인받는다** (`rules.md` #2). 같은 이름이 이미 있으면
|
||||
덮어쓰기 전에 무엇이 사라지는지 한 줄로 알린다 — 렌더링은 되돌릴 수 없다.
|
||||
- ⚠ **`build_deck.py` 의 `__main__` 데모와 `examples/showcase.json` 은 타 프로젝트(P-PRJ BFHB) 실데이터다.**
|
||||
조직명·담당자·이력 행을 **그대로 복사하지 않는다.** 값은 `_meta/project.yaml` 또는 사용자 입력에서 온다.
|
||||
- **`table` 높이 상한**: 표는 `_TABLE_MAX_H = 5.3"` (y 1.7" ~ 7.0")로 자동 제한.
|
||||
행이 많아도 푸터(`Ubisam | <doc_title>`, y=7.05")를 절대 침범하지 않는다.
|
||||
행 높이는 `min(0.5×rows, 5.3) / rows`로 균등 압축된다.
|
||||
|
||||
> 보고는 `rules.md` #11~13 출력 형식을 따르고(수정 줄=초록 화살표, 단어=주황, 미변경=기본색),
|
||||
> 단계 전환마다 진행을 한 줄로 알리며(#10), 끝에 관련 `.md` 갱신 필요 여부를 묻는다(#6).
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 6.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.1 KiB |
@ -1,752 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""
|
||||
ubisam-ppt-make — Ubisam SW 설계서 deck builder.
|
||||
|
||||
Design system extracted from P-PRJ_BFHB_UBISAM_Ver1.4.pptx and the user's
|
||||
edited layout_showcase (UbiSam logo on every page).
|
||||
|
||||
Font rule (fixed): 한글=굴림, 영문=Arial.
|
||||
|
||||
Usage:
|
||||
python build_deck.py # build sample showcase
|
||||
python build_deck.py --input spec.json --output deck.pptx
|
||||
"""
|
||||
import os
|
||||
import json
|
||||
import argparse
|
||||
from pptx import Presentation
|
||||
from pptx.util import Inches, Pt
|
||||
from pptx.dml.color import RGBColor
|
||||
from pptx.enum.text import PP_ALIGN, MSO_ANCHOR
|
||||
from pptx.enum.shapes import MSO_SHAPE
|
||||
from pptx.oxml.ns import qn
|
||||
from pptx.parts.image import ImagePart
|
||||
from pptx.opc.constants import RELATIONSHIP_TYPE as RT
|
||||
from pptx.opc.packuri import PackURI
|
||||
from lxml import etree
|
||||
|
||||
HERE = os.path.dirname(os.path.abspath(__file__))
|
||||
LOGO = os.path.join(HERE, "assets", "Ubisam_logo_transparent.png")
|
||||
|
||||
# ---- design tokens ----
|
||||
ACCENT = RGBColor(0x4A, 0x8D, 0xCB)
|
||||
ACCENT_D = RGBColor(0x2F, 0x5E, 0x8C)
|
||||
INK = RGBColor(0x26, 0x2A, 0x2E)
|
||||
SUB = RGBColor(0x6B, 0x72, 0x78)
|
||||
LINE = RGBColor(0xD9, 0xDD, 0xE1)
|
||||
BG_SOFT = RGBColor(0xF4, 0xF7, 0xFA)
|
||||
WHITE = RGBColor(0xFF, 0xFF, 0xFF)
|
||||
WARN = RGBColor(0xE5, 0x3E, 0x3E)
|
||||
PALE = RGBColor(0xDD, 0xEA, 0xF6)
|
||||
BLUE2 = RGBColor(0x00, 0x70, 0xC0) # divider/closing block blue
|
||||
|
||||
KFONT = "굴림"
|
||||
EFONT = "Arial"
|
||||
|
||||
EMU_W = Inches(13.333)
|
||||
EMU_H = Inches(7.5)
|
||||
|
||||
_NS_P = "http://schemas.openxmlformats.org/presentationml/2006/main"
|
||||
_NS_A = "http://schemas.openxmlformats.org/drawingml/2006/main"
|
||||
_NS_R = "http://schemas.openxmlformats.org/officeDocument/2006/relationships"
|
||||
|
||||
|
||||
# ---------- master background ----------
|
||||
def _apply_master_background(prs):
|
||||
"""슬라이드 마스터에 흰 배경 + Ubisam 로고 워터마크 + 하단 accent 바 적용.
|
||||
모든 슬라이드가 상속. cover·divider·closing은 자체 rect로 덮음."""
|
||||
master = prs.slide_master
|
||||
spTree = master.shapes._spTree
|
||||
|
||||
# 1. 배경: WHITE
|
||||
try:
|
||||
master.background.fill.solid()
|
||||
master.background.fill.fore_color.rgb = WHITE
|
||||
except Exception:
|
||||
pass
|
||||
for layout in prs.slide_layouts:
|
||||
try:
|
||||
layout.background.fill.solid()
|
||||
layout.background.fill.fore_color.rgb = WHITE
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
# 2. Ubisam 로고 워터마크 (하단 전체 폭, 15% 투명도)
|
||||
if os.path.exists(LOGO):
|
||||
try:
|
||||
with open(LOGO, "rb") as f:
|
||||
blob = f.read()
|
||||
pkg = master.part._package
|
||||
img_part = ImagePart(
|
||||
PackURI("/ppt/media/ubisam_master_wm.png"), "image/png", pkg, blob
|
||||
)
|
||||
rId = master.part.relate_to(img_part, RT.IMAGE)
|
||||
W, H = int(EMU_W), int(Inches(2.5))
|
||||
T = int(EMU_H) - H
|
||||
wm_xml = (
|
||||
f'<p:pic xmlns:p="{_NS_P}" xmlns:a="{_NS_A}" xmlns:r="{_NS_R}">'
|
||||
f'<p:nvPicPr>'
|
||||
f'<p:cNvPr id="9002" name="UbisamWatermark"/>'
|
||||
f'<p:cNvPicPr><a:picLocks noChangeAspect="1"/></p:cNvPicPr>'
|
||||
f'<p:nvPr/></p:nvPicPr>'
|
||||
f'<p:blipFill>'
|
||||
f'<a:blip r:embed="{rId}"><a:alphaModFix amt="15000"/></a:blip>'
|
||||
f'<a:stretch><a:fillRect/></a:stretch>'
|
||||
f'</p:blipFill>'
|
||||
f'<p:spPr>'
|
||||
f'<a:xfrm><a:off x="0" y="{T}"/>'
|
||||
f'<a:ext cx="{W}" cy="{H}"/></a:xfrm>'
|
||||
f'<a:prstGeom prst="rect"><a:avLst/></a:prstGeom>'
|
||||
f'<a:noFill/>'
|
||||
f'</p:spPr>'
|
||||
f'</p:pic>'
|
||||
)
|
||||
spTree.append(etree.fromstring(wm_xml.encode("utf-8")))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
# 3. 하단 accent 바
|
||||
hex_c = f"{ACCENT[0]:02X}{ACCENT[1]:02X}{ACCENT[2]:02X}"
|
||||
bar_xml = (
|
||||
f'<p:sp xmlns:p="{_NS_P}" xmlns:a="{_NS_A}" xmlns:r="{_NS_R}">'
|
||||
f'<p:nvSpPr><p:cNvPr id="9001" name="AccentBar"/>'
|
||||
f'<p:cNvSpPr><a:spLocks noGrp="1"/></p:cNvSpPr><p:nvPr/></p:nvSpPr>'
|
||||
f'<p:spPr>'
|
||||
f'<a:xfrm><a:off x="0" y="{int(Inches(7.35))}"/>'
|
||||
f'<a:ext cx="{int(EMU_W)}" cy="{int(Inches(0.15))}"/></a:xfrm>'
|
||||
f'<a:prstGeom prst="rect"><a:avLst/></a:prstGeom>'
|
||||
f'<a:solidFill><a:srgbClr val="{hex_c}"/></a:solidFill>'
|
||||
f'<a:ln><a:noFill/></a:ln>'
|
||||
f'</p:spPr>'
|
||||
f'<p:txBody><a:bodyPr/><a:lstStyle/><a:p/></p:txBody>'
|
||||
f'</p:sp>'
|
||||
)
|
||||
try:
|
||||
spTree.append(etree.fromstring(bar_xml.encode("utf-8")))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
|
||||
# ---------- text / shape helpers ----------
|
||||
def _set_font(run, size=None, bold=None, color=None, italic=None):
|
||||
f = run.font
|
||||
if size is not None:
|
||||
f.size = Pt(size)
|
||||
if bold is not None:
|
||||
f.bold = bold
|
||||
if italic is not None:
|
||||
f.italic = italic
|
||||
if color is not None:
|
||||
f.color.rgb = color
|
||||
f.name = EFONT
|
||||
rPr = run._r.get_or_add_rPr()
|
||||
for tag in ("a:ea", "a:cs"):
|
||||
el = rPr.find(qn(tag))
|
||||
if el is None:
|
||||
el = rPr.makeelement(qn(tag), {})
|
||||
rPr.append(el)
|
||||
el.set("typeface", KFONT if tag == "a:ea" else EFONT)
|
||||
|
||||
|
||||
def add_text(slide, l, t, w, h, lines, align=PP_ALIGN.LEFT, anchor=MSO_ANCHOR.TOP):
|
||||
tb = slide.shapes.add_textbox(l, t, w, h)
|
||||
tf = tb.text_frame
|
||||
tf.word_wrap = True
|
||||
tf.vertical_anchor = anchor
|
||||
for m in ("margin_left", "margin_right", "margin_top", "margin_bottom"):
|
||||
setattr(tf, m, 0)
|
||||
for i, spec in enumerate(lines):
|
||||
text, size, bold, color = spec[0], spec[1], spec[2], spec[3]
|
||||
a = spec[4] if len(spec) > 4 else align
|
||||
p = tf.paragraphs[0] if i == 0 else tf.add_paragraph()
|
||||
p.alignment = a
|
||||
r = p.add_run()
|
||||
r.text = text
|
||||
_set_font(r, size=size, bold=bold, color=color)
|
||||
return tb
|
||||
|
||||
|
||||
def rect(slide, l, t, w, h, fill=None, line_color=None, line_w=None,
|
||||
shape=MSO_SHAPE.RECTANGLE):
|
||||
sp = slide.shapes.add_shape(shape, l, t, w, h)
|
||||
sp.shadow.inherit = False
|
||||
if fill is None:
|
||||
sp.fill.background()
|
||||
else:
|
||||
sp.fill.solid()
|
||||
sp.fill.fore_color.rgb = fill
|
||||
if line_color is None:
|
||||
sp.line.fill.background()
|
||||
else:
|
||||
sp.line.color.rgb = line_color
|
||||
sp.line.width = Pt(line_w or 0.75)
|
||||
if sp.has_text_frame:
|
||||
sp.text_frame.word_wrap = True
|
||||
return sp
|
||||
|
||||
|
||||
def blank_slide(prs):
|
||||
return prs.slides.add_slide(prs.slide_layouts[6])
|
||||
|
||||
|
||||
def add_logo(slide, where="top", left=None, top=None, height=None):
|
||||
"""UbiSam logo on every page. cover=bottom-right, others=top-right.
|
||||
left/top/height override the top-right default (in inches)."""
|
||||
if not os.path.exists(LOGO):
|
||||
return
|
||||
if where == "bottom":
|
||||
slide.shapes.add_picture(LOGO, Inches(10.55), Inches(6.35), height=Inches(0.62))
|
||||
else:
|
||||
slide.shapes.add_picture(LOGO, Inches(10.55 if left is None else left),
|
||||
Inches(0.5 if top is None else top),
|
||||
height=Inches(0.55 if height is None else height))
|
||||
|
||||
|
||||
def header(slide, no, title_en, title_ko=None):
|
||||
if no:
|
||||
rect(slide, Inches(0.55), Inches(0.42), Inches(0.62), Inches(0.46), fill=ACCENT)
|
||||
add_text(slide, Inches(0.55), Inches(0.42), Inches(0.62), Inches(0.46),
|
||||
[(no, 16, True, WHITE, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
tx = 1.32 if no else 0.55
|
||||
add_text(slide, Inches(tx), Inches(0.40), Inches(8.6), Inches(0.5),
|
||||
[(title_en, 22, True, INK)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
if title_ko:
|
||||
add_text(slide, Inches(tx + 0.02), Inches(0.86), Inches(8.6), Inches(0.32),
|
||||
[(title_ko, 12, False, SUB)])
|
||||
rect(slide, Inches(0.55), Inches(1.22), Inches(11.4), Inches(0.035), fill=ACCENT)
|
||||
rect(slide, Inches(0.55), Inches(1.22), Inches(2.2), Inches(0.035), fill=ACCENT_D)
|
||||
|
||||
|
||||
def footer(slide, page, doc_title):
|
||||
add_text(slide, Inches(0.55), Inches(7.05), Inches(7.0), Inches(0.3),
|
||||
[("Ubisam | " + doc_title, 9, False, SUB)])
|
||||
if page is not None:
|
||||
add_text(slide, Inches(11.0), Inches(7.05), Inches(1.78), Inches(0.3),
|
||||
[(str(page), 9, False, SUB, PP_ALIGN.RIGHT)])
|
||||
|
||||
|
||||
def num_badge(slide, l, t, dia, n, fill=ACCENT, color=WHITE, size=14):
|
||||
rect(slide, Inches(l), Inches(t), Inches(dia), Inches(dia), fill=fill, shape=MSO_SHAPE.OVAL)
|
||||
add_text(slide, Inches(l), Inches(t), Inches(dia), Inches(dia),
|
||||
[(str(n), size, True, color, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
|
||||
|
||||
# ---------- layouts ----------
|
||||
def L_cover(prs, d):
|
||||
s = blank_slide(prs)
|
||||
rect(s, 0, 0, EMU_W, EMU_H, fill=WHITE)
|
||||
rect(s, 0, 0, Inches(0.28), EMU_H, fill=ACCENT)
|
||||
rect(s, Inches(0.28), 0, Inches(0.06), EMU_H, fill=ACCENT_D)
|
||||
rect(s, Inches(0.9), Inches(1.7), Inches(2.4), Inches(0.42), fill=BG_SOFT)
|
||||
add_text(s, Inches(0.9), Inches(1.7), Inches(2.4), Inches(0.42),
|
||||
[(d.get("tag", "SW DESIGN DOCUMENT"), 11, True, ACCENT, PP_ALIGN.CENTER)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_text(s, Inches(0.9), Inches(2.35), Inches(10.0), Inches(1.2),
|
||||
[(d["title"], 40, True, INK)])
|
||||
subs = d.get("subtitles", [])
|
||||
add_text(s, Inches(0.92), Inches(3.55), Inches(10.5), Inches(0.9),
|
||||
[(t, 15 if i == 0 else 12, False, SUB) for i, t in enumerate(subs)])
|
||||
rect(s, Inches(0.92), Inches(4.7), Inches(3.2), Inches(0.03), fill=LINE)
|
||||
contacts = d.get("contacts", [])
|
||||
cl = [(d.get("team", "미정 — 확인 필요"), 13, True, INK)]
|
||||
cl += [(c, 11, False, SUB) for c in contacts]
|
||||
add_text(s, Inches(0.92), Inches(4.95), Inches(8.0), Inches(1.4), cl)
|
||||
add_logo(s, "bottom")
|
||||
return s
|
||||
|
||||
|
||||
def L_history(prs, d):
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "00."), d.get("title", "변경 이력"), d.get("subtitle", "Revision History"))
|
||||
cols = [("No.", 0.55, 0.55), ("Version", 1.4, 1.1), ("변경일자", 2.5, 1.5),
|
||||
("변경자", 4.0, 1.3), ("변경 내용", 5.3, 6.65)]
|
||||
rows = d.get("rows", [])
|
||||
top, rh = 1.7, 0.5
|
||||
rect(s, Inches(0.55), Inches(top), Inches(11.4), Inches(rh), fill=ACCENT)
|
||||
for label, x, w in cols:
|
||||
add_text(s, Inches(x), Inches(top), Inches(w), Inches(rh),
|
||||
[(label, 12, True, WHITE, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
for i, row in enumerate(rows):
|
||||
y = top + rh + i * rh
|
||||
if i % 2 == 1:
|
||||
rect(s, Inches(0.55), Inches(y), Inches(11.4), Inches(rh), fill=BG_SOFT)
|
||||
for (label, x, w), val in zip(cols, row):
|
||||
al = PP_ALIGN.LEFT if label == "변경 내용" else PP_ALIGN.CENTER
|
||||
xx = x + 0.1 if label == "변경 내용" else x
|
||||
add_text(s, Inches(xx), Inches(y), Inches(w), Inches(rh),
|
||||
[(str(val), 11, False, INK, al)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
rect(s, Inches(0.55), Inches(y + rh), Inches(11.4), Inches(0.012), fill=LINE)
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_agenda(prs, d):
|
||||
s = blank_slide(prs)
|
||||
header(s, "", d.get("title", "Contents"), d.get("subtitle", "목차"))
|
||||
items = d.get("items", [])
|
||||
cw, ch = 5.55, 1.45
|
||||
gx, gy = 0.55, 1.75
|
||||
for i, it in enumerate(items[:6]):
|
||||
r, c = divmod(i, 2)
|
||||
x = gx + c * (cw + 0.3)
|
||||
y = gy + r * (ch + 0.25)
|
||||
rect(s, Inches(x), Inches(y), Inches(cw), Inches(ch), fill=BG_SOFT)
|
||||
rect(s, Inches(x), Inches(y), Inches(0.08), Inches(ch), fill=ACCENT)
|
||||
add_text(s, Inches(x + 0.25), Inches(y + 0.18), Inches(1.2), Inches(1.0),
|
||||
[(it.get("no", ""), 34, True, ACCENT)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_text(s, Inches(x + 1.55), Inches(y + 0.3), Inches(cw - 1.7), Inches(0.9),
|
||||
[(it.get("title", ""), 17, True, INK), (it.get("sub", ""), 11, False, SUB)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_divider(prs, d):
|
||||
s = blank_slide(prs)
|
||||
rect(s, 0, 0, EMU_W, EMU_H, fill=WHITE)
|
||||
rect(s, 0, Inches(3.88), EMU_W, Inches(3.62), fill=BLUE2)
|
||||
add_text(s, Inches(0.9), Inches(1.3), Inches(6.0), Inches(2.2),
|
||||
[(d.get("no", "01"), 130, True, BLUE2)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
rect(s, Inches(0.95), Inches(4.05), Inches(2.4), Inches(0.06), fill=WHITE)
|
||||
add_text(s, Inches(0.95), Inches(4.25), Inches(10.0), Inches(0.84),
|
||||
[(d.get("title", ""), 30, True, WHITE), (d.get("subtitle", ""), 20, False, PALE)])
|
||||
add_logo(s, left=11.3, top=0.55, height=0.5)
|
||||
return s
|
||||
|
||||
|
||||
def L_content(prs, d):
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "02."), d.get("title", ""), d.get("subtitle"))
|
||||
panels = d.get("panels", [])
|
||||
pw, ph = 5.55, 2.35
|
||||
gx, gy = 0.55, 1.65
|
||||
for i, p in enumerate(panels[:4]):
|
||||
r, c = divmod(i, 2)
|
||||
x = gx + c * (pw + 0.3)
|
||||
y = gy + r * (ph + 0.25)
|
||||
rect(s, Inches(x), Inches(y), Inches(pw), Inches(ph), fill=WHITE, line_color=LINE, line_w=1.0)
|
||||
rect(s, Inches(x), Inches(y), Inches(pw), Inches(0.42), fill=BG_SOFT)
|
||||
add_text(s, Inches(x + 0.2), Inches(y), Inches(pw - 0.4), Inches(0.42),
|
||||
[(p.get("title", ""), 13, True, ACCENT_D)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_text(s, Inches(x + 0.2), Inches(y + 0.42), Inches(pw - 0.4), Inches(ph - 0.42),
|
||||
[("〔 " + p.get("body", "") + " 〕", 11, False, SUB, PP_ALIGN.CENTER)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_flow(prs, d):
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "03."), d.get("title", "Sequence Flowchart"), d.get("subtitle"))
|
||||
steps = d.get("steps", [])
|
||||
branch = d.get("branch")
|
||||
cx, bw = 4.55, 3.0
|
||||
y, gap = 1.6, 0.46
|
||||
prev_bottom, dec_y = None, None
|
||||
for title, code, kind in [(s2.get("title", ""), s2.get("code", ""), s2.get("kind", "proc")) for s2 in steps]:
|
||||
h = 0.58 if kind == "dec" else 0.52
|
||||
if kind == "dec" and dec_y is None:
|
||||
dec_y = y
|
||||
lc = ACCENT if kind == "dec" else SUB
|
||||
rect(s, Inches(cx), Inches(y), Inches(bw), Inches(h), fill=WHITE,
|
||||
line_color=lc, line_w=1.5 if kind == "dec" else 1.0,
|
||||
shape=MSO_SHAPE.ROUNDED_RECTANGLE)
|
||||
add_text(s, Inches(cx), Inches(y + 0.04), Inches(bw), Inches(h - 0.04),
|
||||
[(title, 12, True, INK, PP_ALIGN.CENTER), (code, 9, False, ACCENT_D, PP_ALIGN.CENTER)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
if prev_bottom is not None:
|
||||
ln = s.shapes.add_connector(2, Inches(cx + bw / 2), Inches(prev_bottom),
|
||||
Inches(cx + bw / 2), Inches(y))
|
||||
ln.line.color.rgb = ACCENT
|
||||
ln.line.width = Pt(1.5)
|
||||
prev_bottom = y + h
|
||||
y += h + gap
|
||||
if branch and dec_y is not None:
|
||||
bh = 0.58
|
||||
by = dec_y
|
||||
rect(s, Inches(1.7), Inches(by), Inches(1.9), Inches(bh), fill=BG_SOFT,
|
||||
line_color=SUB, line_w=1.0, shape=MSO_SHAPE.ROUNDED_RECTANGLE)
|
||||
add_text(s, Inches(1.7), Inches(by), Inches(1.9), Inches(bh),
|
||||
[(branch.get("title", ""), 11, True, WARN, PP_ALIGN.CENTER),
|
||||
(branch.get("sub", ""), 9, False, SUB, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
ln = s.shapes.add_connector(2, Inches(cx), Inches(by + bh / 2), Inches(3.6), Inches(by + bh / 2))
|
||||
ln.line.color.rgb = WARN
|
||||
ln.line.width = Pt(1.25)
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def _fill_cell(cell, text, size, bold, color, center=False):
|
||||
cell.vertical_anchor = MSO_ANCHOR.MIDDLE
|
||||
cell.margin_left = Inches(0.08)
|
||||
cell.margin_right = Inches(0.08)
|
||||
cell.margin_top = Inches(0.02)
|
||||
cell.margin_bottom = Inches(0.02)
|
||||
tf = cell.text_frame
|
||||
tf.word_wrap = True
|
||||
p = tf.paragraphs[0]
|
||||
p.alignment = PP_ALIGN.CENTER if center else PP_ALIGN.LEFT
|
||||
r = p.add_run()
|
||||
r.text = str(text)
|
||||
_set_font(r, size=size, bold=bold, color=color)
|
||||
|
||||
|
||||
_TABLE_TOP = 1.7 # table body starts here (inches)
|
||||
_TABLE_MAX_H = 5.3 # max table height: footer y(7.05) - table top(1.7) - margin(0.05)
|
||||
|
||||
def L_table(prs, d):
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "06."), d.get("title", ""), d.get("subtitle"))
|
||||
headers = d.get("headers", [])
|
||||
widths = d.get("widths") or [11.4 / len(headers)] * len(headers)
|
||||
data = d.get("rows", [])
|
||||
center_cols = set(d.get("center_cols", []))
|
||||
rows = len(data) + 1
|
||||
tbl_h = min(0.5 * rows, _TABLE_MAX_H)
|
||||
tbl = s.shapes.add_table(rows, len(headers), Inches(0.55), Inches(_TABLE_TOP),
|
||||
Inches(11.4), Inches(tbl_h)).table
|
||||
for c, w in enumerate(widths):
|
||||
tbl.columns[c].width = Inches(w)
|
||||
for c, hd in enumerate(headers):
|
||||
cell = tbl.cell(0, c)
|
||||
cell.fill.solid()
|
||||
cell.fill.fore_color.rgb = ACCENT
|
||||
_fill_cell(cell, hd, 12, True, WHITE, center=True)
|
||||
for r, row in enumerate(data, start=1):
|
||||
for c, val in enumerate(row):
|
||||
cell = tbl.cell(r, c)
|
||||
cell.fill.solid()
|
||||
cell.fill.fore_color.rgb = BG_SOFT if r % 2 == 0 else WHITE
|
||||
_fill_cell(cell, val, 11, False, INK, center=(c in center_cols))
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_closing(prs, d):
|
||||
s = blank_slide(prs)
|
||||
rect(s, 0, 0, EMU_W, EMU_H, fill=WHITE)
|
||||
rect(s, 0, Inches(5.0), EMU_W, Inches(2.5), fill=ACCENT_D)
|
||||
add_text(s, Inches(0.83), Inches(1.8), Inches(11.0), Inches(1.62),
|
||||
[(d.get("title", "Thank You"), 96, True, BLUE2)])
|
||||
if d.get("message"):
|
||||
add_text(s, Inches(0.95), Inches(3.5), Inches(11.0), Inches(0.5),
|
||||
[(d["message"], 14, False, INK)])
|
||||
cl = [(d.get("team", "미정 — 확인 필요"), 14, True, WHITE)]
|
||||
cl += [(c, 12, False, PALE) for c in d.get("contacts", [])]
|
||||
add_text(s, Inches(0.95), Inches(5.35), Inches(11.0), Inches(1.4), cl)
|
||||
add_logo(s, left=10.55, top=0.55, height=0.6)
|
||||
return s
|
||||
|
||||
|
||||
# ---------- manual layouts ----------
|
||||
REGION = RGBColor(0xFF, 0x00, 0x00) # red region-highlight border (matches manual edit)
|
||||
|
||||
|
||||
def _img_px_size(path):
|
||||
try:
|
||||
from PIL import Image
|
||||
with Image.open(path) as im:
|
||||
return im.size
|
||||
except Exception:
|
||||
return None
|
||||
|
||||
|
||||
def _fit_image(slide, path, bx, by, bw, bh):
|
||||
"""Add picture fitted (aspect-preserved, centered) inside box (inches).
|
||||
Returns the placed rect (left, top, w, h) in inches."""
|
||||
pic = slide.shapes.add_picture(path, Inches(bx), Inches(by), width=Inches(bw))
|
||||
if pic.height > Inches(bh):
|
||||
sp = pic._element
|
||||
sp.getparent().remove(sp)
|
||||
pic = slide.shapes.add_picture(path, Inches(bx), Inches(by), height=Inches(bh))
|
||||
pic.left = Inches(bx) + (Inches(bw) - pic.width) // 2
|
||||
pic.top = Inches(by) + (Inches(bh) - pic.height) // 2
|
||||
return (pic.left / 914400.0, pic.top / 914400.0,
|
||||
pic.width / 914400.0, pic.height / 914400.0)
|
||||
|
||||
|
||||
def _norm_boxes(it):
|
||||
"""Return list of [x,y,w,h] pixel boxes from item's box/boxes field."""
|
||||
b = it.get("boxes") or it.get("box")
|
||||
if not b:
|
||||
return []
|
||||
return b if isinstance(b[0], (list, tuple)) else [b]
|
||||
|
||||
|
||||
def L_screen_guide(prs, d):
|
||||
"""화면 설명: 캡처 영역(좌) + 번호 콜아웃(우). 이미지 위 영역 박스+번호 마커 지원."""
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "07."), d.get("title", "화면 설명"), d.get("subtitle"))
|
||||
sx, sy, sw, sh_ = 0.55, 1.7, 7.3, 5.0
|
||||
rect(s, Inches(sx), Inches(sy), Inches(sw), Inches(sh_), fill=BG_SOFT, line_color=LINE, line_w=1.0)
|
||||
items = d.get("items", [])
|
||||
img = d.get("image")
|
||||
if img and os.path.exists(img):
|
||||
il, it_, iw, ih = _fit_image(s, img, sx + 0.05, sy + 0.05, sw - 0.1, sh_ - 0.1)
|
||||
px = _img_px_size(img)
|
||||
if px:
|
||||
scale = iw / px[0] # inches per pixel (aspect preserved)
|
||||
mdia = 0.30
|
||||
for i, item in enumerate(items):
|
||||
for j, bx in enumerate(_norm_boxes(item)):
|
||||
rl, rt = il + bx[0] * scale, it_ + bx[1] * scale
|
||||
rw, rh = bx[2] * scale, bx[3] * scale
|
||||
rect(s, Inches(rl), Inches(rt), Inches(rw), Inches(rh),
|
||||
fill=None, line_color=REGION, line_w=1.5)
|
||||
if j == 0: # number marker at first box's top-left corner
|
||||
num_badge(s, rl, rt, mdia, i + 1, size=12)
|
||||
else:
|
||||
add_text(s, Inches(sx), Inches(sy), Inches(sw), Inches(sh_),
|
||||
[("〔 " + d.get("caption", "화면 캡처 영역") + " 〕", 12, False, SUB, PP_ALIGN.CENTER)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
rx, rw = 8.15, 4.65
|
||||
n = max(len(items), 1)
|
||||
rh = min(1.0, (sh_ + 0.0) / n)
|
||||
for i, it in enumerate(items):
|
||||
pos = it.get("pos")
|
||||
if pos:
|
||||
num_badge(s, sx + pos[0], sy + pos[1], 0.34, i + 1, size=12)
|
||||
ly = sy + i * rh
|
||||
num_badge(s, rx, ly + 0.03, 0.34, i + 1, size=12)
|
||||
add_text(s, Inches(rx + 0.5), Inches(ly - 0.02), Inches(rw - 0.5), Inches(rh),
|
||||
[(it.get("title", ""), 13, True, INK), (it.get("desc", ""), 11, False, SUB)])
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_procedure(prs, d):
|
||||
"""조작 절차: 세로 번호 단계."""
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "07."), d.get("title", "조작 절차"), d.get("subtitle"))
|
||||
steps = d.get("steps", [])
|
||||
y0, y1 = 1.75, 6.8
|
||||
n = max(len(steps), 1)
|
||||
rh = min(1.1, (y1 - y0) / n)
|
||||
for i, st in enumerate(steps):
|
||||
y = y0 + i * rh
|
||||
if i % 2 == 1:
|
||||
rect(s, Inches(0.55), Inches(y), Inches(11.4), Inches(rh - 0.12), fill=BG_SOFT)
|
||||
num_badge(s, 0.75, y + (rh - 0.12 - 0.5) / 2, 0.5, i + 1, size=18)
|
||||
add_text(s, Inches(1.55), Inches(y), Inches(10.3), Inches(rh - 0.12),
|
||||
[(st.get("title", ""), 15, True, INK), (st.get("desc", ""), 12, False, SUB)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_icon_ref(prs, d):
|
||||
"""버튼/아이콘 설명: 카드 그리드(3열)."""
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "07."), d.get("title", "버튼 설명"), d.get("subtitle"))
|
||||
items = d.get("items", [])
|
||||
cw, ch, gx, gy, gp = 3.6, 2.35, 0.55, 1.75, 0.3
|
||||
for i, it in enumerate(items[:6]):
|
||||
r, c = divmod(i, 3)
|
||||
x = gx + c * (cw + gp)
|
||||
y = gy + r * (ch + 0.3)
|
||||
rect(s, Inches(x), Inches(y), Inches(cw), Inches(ch), fill=WHITE, line_color=LINE, line_w=1.0)
|
||||
rect(s, Inches(x + (cw - 1.1) / 2), Inches(y + 0.3), Inches(1.1), Inches(1.1),
|
||||
fill=BG_SOFT, line_color=ACCENT, line_w=1.0, shape=MSO_SHAPE.ROUNDED_RECTANGLE)
|
||||
add_text(s, Inches(x + (cw - 1.1) / 2), Inches(y + 0.3), Inches(1.1), Inches(1.1),
|
||||
[(it.get("icon", "ICON"), 11, True, ACCENT, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_text(s, Inches(x + 0.15), Inches(y + 1.5), Inches(cw - 0.3), Inches(0.35),
|
||||
[(it.get("name", ""), 13, True, INK, PP_ALIGN.CENTER)])
|
||||
add_text(s, Inches(x + 0.15), Inches(y + 1.85), Inches(cw - 0.3), Inches(0.45),
|
||||
[(it.get("func", ""), 10, False, SUB, PP_ALIGN.CENTER)])
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
def L_alarm(prs, d):
|
||||
"""알람·조치: 주의 배너 + 표."""
|
||||
s = blank_slide(prs)
|
||||
header(s, d.get("no", "07."), d.get("title", "알람 및 조치 방법"), d.get("subtitle"))
|
||||
rect(s, Inches(0.55), Inches(1.65), Inches(11.4), Inches(0.55),
|
||||
fill=RGBColor(0xFF, 0xF4, 0xD6), line_color=RGBColor(0xF0, 0xB4, 0x29), line_w=1.0)
|
||||
rect(s, Inches(0.7), Inches(1.78), Inches(0.95), Inches(0.3), fill=WARN, shape=MSO_SHAPE.ROUNDED_RECTANGLE)
|
||||
add_text(s, Inches(0.7), Inches(1.78), Inches(0.95), Inches(0.3),
|
||||
[("주의", 11, True, WHITE, PP_ALIGN.CENTER)], anchor=MSO_ANCHOR.MIDDLE)
|
||||
add_text(s, Inches(1.8), Inches(1.65), Inches(10.0), Inches(0.55),
|
||||
[(d.get("notice", "알람 발생 시 아래 조치 방법을 순서대로 수행하십시오."), 12, True, INK)],
|
||||
anchor=MSO_ANCHOR.MIDDLE)
|
||||
headers = d.get("headers", ["코드", "알람명", "발생 원인", "조치 방법"])
|
||||
widths = d.get("widths") or [1.4, 3.0, 3.5, 3.5]
|
||||
data = d.get("rows", [])
|
||||
center_cols = set(d.get("center_cols", [0]))
|
||||
rows = len(data) + 1
|
||||
# 알람표는 top=2.45(주의 배너 아래)에서 시작하므로 상한이 L_table보다 낮다.
|
||||
_ALARM_MAX_H = 4.55 # footer y(7.05) - table top(2.45) - margin(0.05)
|
||||
tbl_h = min(0.5 * rows, _ALARM_MAX_H)
|
||||
tbl = s.shapes.add_table(rows, len(headers), Inches(0.55), Inches(2.45),
|
||||
Inches(11.4), Inches(tbl_h)).table
|
||||
for c, w in enumerate(widths):
|
||||
tbl.columns[c].width = Inches(w)
|
||||
for c, hd in enumerate(headers):
|
||||
cell = tbl.cell(0, c)
|
||||
cell.fill.solid()
|
||||
cell.fill.fore_color.rgb = ACCENT
|
||||
_fill_cell(cell, hd, 12, True, WHITE, center=True)
|
||||
for r, row in enumerate(data, start=1):
|
||||
for c, val in enumerate(row):
|
||||
cell = tbl.cell(r, c)
|
||||
cell.fill.solid()
|
||||
cell.fill.fore_color.rgb = BG_SOFT if r % 2 == 0 else WHITE
|
||||
_fill_cell(cell, val, 11, False, INK, center=(c in center_cols))
|
||||
add_logo(s)
|
||||
footer(s, d.get("page"), d.get("doc_title", ""))
|
||||
return s
|
||||
|
||||
|
||||
BUILDERS = {
|
||||
"cover": L_cover, "history": L_history, "agenda": L_agenda, "divider": L_divider,
|
||||
"content": L_content, "flow": L_flow, "table": L_table, "closing": L_closing,
|
||||
"screen_guide": L_screen_guide, "procedure": L_procedure,
|
||||
"icon_ref": L_icon_ref, "alarm": L_alarm,
|
||||
}
|
||||
|
||||
|
||||
def build(spec, out_path):
|
||||
prs = Presentation()
|
||||
prs.slide_width = EMU_W
|
||||
prs.slide_height = EMU_H
|
||||
# 슬라이드 마스터 배경 적용 (흰 배경 + Ubisam 워터마크 + accent 바)
|
||||
_apply_master_background(prs)
|
||||
doc_title = spec.get("doc_title", "")
|
||||
page = 0
|
||||
for sl in spec["slides"]:
|
||||
t = sl["type"]
|
||||
if t not in BUILDERS:
|
||||
raise ValueError("unknown slide type: " + t)
|
||||
sl.setdefault("doc_title", doc_title)
|
||||
if t in ("history", "agenda", "content", "flow", "table",
|
||||
"screen_guide", "procedure", "icon_ref", "alarm"):
|
||||
page += 1
|
||||
sl.setdefault("page", page)
|
||||
BUILDERS[t](prs, sl)
|
||||
prs.save(out_path)
|
||||
return len(prs.slides._sldIdLst)
|
||||
|
||||
|
||||
def sample_spec():
|
||||
return {
|
||||
"doc_title": "P-PRJ BFHB SW 설계서",
|
||||
"slides": [
|
||||
{"type": "cover", "tag": "SW DESIGN DOCUMENT", "title": "P-PRJ BFHB SW 설계서",
|
||||
"subtitles": ["인도향 P-Project · HFHB (Button Flex Hot Bar 열압착 본딩기)",
|
||||
"A device that compresses a button flex by applying pressure and temperature to a point"],
|
||||
"team": "{조직명}",
|
||||
"contacts": ["{담당자1} {직급} {email1}", "{담당자2} {직급} {email2}"]},
|
||||
{"type": "history", "rows": [
|
||||
["1", "1.0", "2025.04.28", "{작성자}", "초안 작성"],
|
||||
["2", "1.1", "2025.04.29", "{작성자}", "UI 안, Class 내용 추가"],
|
||||
["3", "1.2", "2025.05.09", "{작성자}", "250425_엑추에이터 정리.xlsx 내용 반영"],
|
||||
["4", "1.3", "{YYYY.MM.DD}", "{작성자}", "{변경 내용}"],
|
||||
["5", "1.4", "{YYYY.MM.DD}", "{작성자}", "{변경 내용}"],
|
||||
]},
|
||||
{"type": "agenda", "items": [
|
||||
{"no": "01", "title": "System Overview", "sub": "시스템 구성도"},
|
||||
{"no": "02", "title": "UI Concept", "sub": "Main / Teaching UI 구성"},
|
||||
{"no": "03", "title": "Sequence Flowchart", "sub": "Loading · Bonding · Unloading · PDCA"},
|
||||
{"no": "04", "title": "Class 관계도", "sub": "Class Diagram"},
|
||||
{"no": "05", "title": "축 구성", "sub": "Axis Configuration"},
|
||||
{"no": "06", "title": "IO 구성", "sub": "I/O Map"},
|
||||
]},
|
||||
{"type": "divider", "no": "01", "title": "System Overview", "subtitle": "시스템 구성도"},
|
||||
{"type": "content", "no": "02.", "title": "UI Concept", "subtitle": "Main UI 구성 1", "panels": [
|
||||
{"title": "HotBar 측정 값", "body": "선형 그래프 (최근 생산 100개 표시)"},
|
||||
{"title": "IO Monitoring", "body": "조작 버튼 / 상태 표시"},
|
||||
{"title": "CPK", "body": "막대형 그래프"},
|
||||
{"title": "OK 판정률", "body": "도넛 그래프 (Bali 수신 + 현재공정 판정)"},
|
||||
]},
|
||||
{"type": "flow", "no": "03.", "title": "Sequence Flowchart", "subtitle": "[Loading]",
|
||||
"steps": [
|
||||
{"title": "Wait (Is Loader Empty)", "code": "SendMachine_Ready", "kind": "proc"},
|
||||
{"title": "Is UpStream Ready", "code": "CHECK_UPSTREAM", "kind": "dec"},
|
||||
{"title": "Wait (Is Board Available)", "code": "BoardAvailable", "kind": "proc"},
|
||||
{"title": "Loader Conveyor On", "code": "SendStartTransport", "kind": "proc"},
|
||||
{"title": "Is TransportError", "code": "TransportError", "kind": "dec"},
|
||||
],
|
||||
"branch": {"title": "Conveyor Stop", "sub": "Sequence Stop"}},
|
||||
{"type": "table", "no": "06.", "title": "IO 구성", "subtitle": "I/O Map",
|
||||
"headers": ["No.", "Type", "Address", "Signal Name", "Description"],
|
||||
"widths": [0.8, 1.4, 1.7, 3.3, 4.2], "center_cols": [0, 1, 2],
|
||||
"rows": [
|
||||
["1", "DI", "X00.0", "Start_Button", "사이클 시작 입력"],
|
||||
["2", "DI", "X00.1", "Stop_Button", "사이클 정지 입력"],
|
||||
["3", "DI", "X00.2", "EMG_Stop", "비상 정지"],
|
||||
["4", "DO", "Y10.0", "Tower_Lamp_R", "경광등 적색"],
|
||||
["5", "DO", "Y10.1", "Conveyor_Run", "컨베이어 구동"],
|
||||
["6", "DO", "Y10.2", "Stopper1_Up", "스토퍼1 상승"],
|
||||
]},
|
||||
{"type": "divider", "no": "07", "title": "Operation Manual", "subtitle": "조작 매뉴얼"},
|
||||
{"type": "screen_guide", "no": "07.", "title": "화면 설명", "subtitle": "Main 운전 화면",
|
||||
"caption": "Main 운전 화면 캡처",
|
||||
"items": [
|
||||
{"title": "운전 상태 표시", "desc": "현재 사이클/공정 상태 램프", "pos": [0.5, 0.5]},
|
||||
{"title": "측정값 그래프", "desc": "Load Cell · 온도 실시간 추이", "pos": [3.0, 1.5]},
|
||||
{"title": "판정 결과", "desc": "OK/NG 도넛 그래프", "pos": [5.5, 2.5]},
|
||||
{"title": "조작 버튼", "desc": "Start / Stop / Reset", "pos": [1.5, 3.8]},
|
||||
{"title": "알람 표시줄", "desc": "최근 발생 알람 메시지", "pos": [4.0, 4.3]},
|
||||
]},
|
||||
{"type": "procedure", "no": "07.", "title": "조작 절차", "subtitle": "운전 시작 순서",
|
||||
"steps": [
|
||||
{"title": "전원 ON 및 초기화", "desc": "메인 전원 인가 후 [Reset] 버튼으로 장비 초기화"},
|
||||
{"title": "원점 복귀", "desc": "[Home] 버튼 선택 → 전 축 원점 복귀 완료 확인"},
|
||||
{"title": "레시피 선택", "desc": "생산 모델에 맞는 레시피 로드 및 파라미터 확인"},
|
||||
{"title": "자동 운전 시작", "desc": "[Auto] 모드 전환 후 [Start] 버튼으로 사이클 시작"},
|
||||
{"title": "운전 종료", "desc": "[Stop] 후 사이클 완료 대기 → 전원 OFF"},
|
||||
]},
|
||||
{"type": "icon_ref", "no": "07.", "title": "버튼 설명", "subtitle": "Main UI 조작 버튼",
|
||||
"items": [
|
||||
{"icon": "▶", "name": "Start", "func": "자동 운전 시작"},
|
||||
{"icon": "■", "name": "Stop", "func": "사이클 정지"},
|
||||
{"icon": "↺", "name": "Reset", "func": "알람 해제 / 초기화"},
|
||||
{"icon": "⌂", "name": "Home", "func": "전 축 원점 복귀"},
|
||||
{"icon": "≡", "name": "Recipe", "func": "레시피 관리 화면"},
|
||||
{"icon": "⚙", "name": "Setup", "func": "설정 / 파라미터"},
|
||||
]},
|
||||
{"type": "alarm", "no": "07.", "title": "알람 및 조치 방법", "subtitle": "주요 알람 코드",
|
||||
"notice": "알람 발생 시 원인 확인 후 아래 조치 방법을 순서대로 수행하십시오.",
|
||||
"rows": [
|
||||
["AL-001", "비상정지 입력", "EMG 버튼 눌림", "안전 확인 후 EMG 해제 → Reset"],
|
||||
["AL-012", "원점 복귀 실패", "센서 미감지 / 간섭", "축 위치 확인 후 수동 원점 재시도"],
|
||||
["AL-024", "Load Cell 통신 이상", "케이블 단선 / 노이즈", "커넥터 체결 확인 후 전원 재투입"],
|
||||
["AL-031", "온도 상한 초과", "Heater 과열", "설정 온도 확인 → 냉각 후 재가동"],
|
||||
]},
|
||||
{"type": "closing", "title": "Thank You", "message": "문의 사항은 아래 담당자에게 연락 바랍니다.",
|
||||
"team": "{조직명}",
|
||||
"contacts": ["{담당자1} {직급} {email1}", "{담당자2} {직급} {email2}"]},
|
||||
],
|
||||
}
|
||||
|
||||
|
||||
def main():
|
||||
ap = argparse.ArgumentParser()
|
||||
ap.add_argument("--input", help="spec JSON path (필수 — 샘플은 --showcase)")
|
||||
ap.add_argument("--showcase", action="store_true",
|
||||
help="번들 샘플 덱을 만든다. 타 프로젝트 예시 데이터가 들어가므로 명시할 때만 동작")
|
||||
ap.add_argument("--output", required=True, help="출력 .pptx 경로")
|
||||
args = ap.parse_args()
|
||||
if args.input:
|
||||
with open(args.input, encoding="utf-8") as f:
|
||||
spec = json.load(f)
|
||||
elif args.showcase:
|
||||
# 샘플은 타 프로젝트 예시 데이터를 포함한다 — 명시적으로 요청할 때만 만든다.
|
||||
spec = sample_spec()
|
||||
else:
|
||||
ap.error("--input 또는 --showcase 중 하나가 필요하다. "
|
||||
"인자 없이 실행하면 타 프로젝트 샘플이 조용히 산출되므로 막는다.")
|
||||
n = build(spec, args.output)
|
||||
print("saved:", os.path.abspath(args.output), "slides:", n)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
@ -1,394 +0,0 @@
|
||||
{
|
||||
"doc_title": "P-PRJ BFHB SW 설계서",
|
||||
"slides": [
|
||||
{
|
||||
"type": "cover",
|
||||
"tag": "SW DESIGN DOCUMENT",
|
||||
"title": "P-PRJ BFHB SW 설계서",
|
||||
"subtitles": [
|
||||
"인도향 P-Project · HFHB (Button Flex Hot Bar 열압착 본딩기)",
|
||||
"A device that compresses a button flex by applying pressure and temperature to a point"
|
||||
],
|
||||
"team": "{조직명}",
|
||||
"contacts": [
|
||||
"{담당자1} {직급} {email1}",
|
||||
"{담당자2} {직급} {email2}"
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "history",
|
||||
"rows": [
|
||||
[
|
||||
"1",
|
||||
"1.0",
|
||||
"2025.04.28",
|
||||
"{작성자}",
|
||||
"초안 작성"
|
||||
],
|
||||
[
|
||||
"2",
|
||||
"1.1",
|
||||
"2025.04.29",
|
||||
"{작성자}",
|
||||
"UI 안, Class 내용 추가"
|
||||
],
|
||||
[
|
||||
"3",
|
||||
"1.2",
|
||||
"2025.05.09",
|
||||
"{작성자}",
|
||||
"250425_엑추에이터 정리.xlsx 내용 반영"
|
||||
],
|
||||
[
|
||||
"4",
|
||||
"1.3",
|
||||
"2025.05.15",
|
||||
"{작성자}",
|
||||
"[DFM]_LG PRI_V57_BFHB_1.2 내용 반영"
|
||||
],
|
||||
[
|
||||
"5",
|
||||
"1.4",
|
||||
"2025.05.21",
|
||||
"{작성자}",
|
||||
"[DFM]_LG PRI_V57_BFHB_1.7 내용 반영"
|
||||
]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "agenda",
|
||||
"items": [
|
||||
{
|
||||
"no": "01",
|
||||
"title": "System Overview",
|
||||
"sub": "시스템 구성도"
|
||||
},
|
||||
{
|
||||
"no": "02",
|
||||
"title": "UI Concept",
|
||||
"sub": "Main / Teaching UI 구성"
|
||||
},
|
||||
{
|
||||
"no": "03",
|
||||
"title": "Sequence Flowchart",
|
||||
"sub": "Loading · Bonding · Unloading · PDCA"
|
||||
},
|
||||
{
|
||||
"no": "04",
|
||||
"title": "Class 관계도",
|
||||
"sub": "Class Diagram"
|
||||
},
|
||||
{
|
||||
"no": "05",
|
||||
"title": "축 구성",
|
||||
"sub": "Axis Configuration"
|
||||
},
|
||||
{
|
||||
"no": "06",
|
||||
"title": "IO 구성",
|
||||
"sub": "I/O Map"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "divider",
|
||||
"no": "01",
|
||||
"title": "System Overview",
|
||||
"subtitle": "시스템 구성도"
|
||||
},
|
||||
{
|
||||
"type": "content",
|
||||
"no": "02.",
|
||||
"title": "UI Concept",
|
||||
"subtitle": "Main UI 구성 1",
|
||||
"panels": [
|
||||
{
|
||||
"title": "HotBar 측정 값",
|
||||
"body": "선형 그래프 (최근 생산 100개 표시)"
|
||||
},
|
||||
{
|
||||
"title": "IO Monitoring",
|
||||
"body": "조작 버튼 / 상태 표시"
|
||||
},
|
||||
{
|
||||
"title": "CPK",
|
||||
"body": "막대형 그래프"
|
||||
},
|
||||
{
|
||||
"title": "OK 판정률",
|
||||
"body": "도넛 그래프 (Bali 수신 + 현재공정 판정)"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "flow",
|
||||
"no": "03.",
|
||||
"title": "Sequence Flowchart",
|
||||
"subtitle": "[Loading]",
|
||||
"steps": [
|
||||
{
|
||||
"title": "Wait (Is Loader Empty)",
|
||||
"code": "SendMachine_Ready",
|
||||
"kind": "proc"
|
||||
},
|
||||
{
|
||||
"title": "Is UpStream Ready",
|
||||
"code": "CHECK_UPSTREAM",
|
||||
"kind": "dec"
|
||||
},
|
||||
{
|
||||
"title": "Wait (Is Board Available)",
|
||||
"code": "BoardAvailable",
|
||||
"kind": "proc"
|
||||
},
|
||||
{
|
||||
"title": "Loader Conveyor On",
|
||||
"code": "SendStartTransport",
|
||||
"kind": "proc"
|
||||
},
|
||||
{
|
||||
"title": "Is TransportError",
|
||||
"code": "TransportError",
|
||||
"kind": "dec"
|
||||
}
|
||||
],
|
||||
"branch": {
|
||||
"title": "Conveyor Stop",
|
||||
"sub": "Sequence Stop"
|
||||
}
|
||||
},
|
||||
{
|
||||
"type": "table",
|
||||
"no": "06.",
|
||||
"title": "IO 구성",
|
||||
"subtitle": "I/O Map",
|
||||
"headers": [
|
||||
"No.",
|
||||
"Type",
|
||||
"Address",
|
||||
"Signal Name",
|
||||
"Description"
|
||||
],
|
||||
"widths": [
|
||||
0.8,
|
||||
1.4,
|
||||
1.7,
|
||||
3.3,
|
||||
4.2
|
||||
],
|
||||
"center_cols": [
|
||||
0,
|
||||
1,
|
||||
2
|
||||
],
|
||||
"rows": [
|
||||
[
|
||||
"1",
|
||||
"DI",
|
||||
"X00.0",
|
||||
"Start_Button",
|
||||
"사이클 시작 입력"
|
||||
],
|
||||
[
|
||||
"2",
|
||||
"DI",
|
||||
"X00.1",
|
||||
"Stop_Button",
|
||||
"사이클 정지 입력"
|
||||
],
|
||||
[
|
||||
"3",
|
||||
"DI",
|
||||
"X00.2",
|
||||
"EMG_Stop",
|
||||
"비상 정지"
|
||||
],
|
||||
[
|
||||
"4",
|
||||
"DO",
|
||||
"Y10.0",
|
||||
"Tower_Lamp_R",
|
||||
"경광등 적색"
|
||||
],
|
||||
[
|
||||
"5",
|
||||
"DO",
|
||||
"Y10.1",
|
||||
"Conveyor_Run",
|
||||
"컨베이어 구동"
|
||||
],
|
||||
[
|
||||
"6",
|
||||
"DO",
|
||||
"Y10.2",
|
||||
"Stopper1_Up",
|
||||
"스토퍼1 상승"
|
||||
]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "divider",
|
||||
"no": "07",
|
||||
"title": "Operation Manual",
|
||||
"subtitle": "조작 매뉴얼"
|
||||
},
|
||||
{
|
||||
"type": "screen_guide",
|
||||
"no": "07.",
|
||||
"title": "화면 설명",
|
||||
"subtitle": "Main 운전 화면",
|
||||
"caption": "Main 운전 화면 캡처",
|
||||
"items": [
|
||||
{
|
||||
"title": "운전 상태 표시",
|
||||
"desc": "현재 사이클/공정 상태 램프",
|
||||
"pos": [
|
||||
0.5,
|
||||
0.5
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "측정값 그래프",
|
||||
"desc": "Load Cell · 온도 실시간 추이",
|
||||
"pos": [
|
||||
3.0,
|
||||
1.5
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "판정 결과",
|
||||
"desc": "OK/NG 도넛 그래프",
|
||||
"pos": [
|
||||
5.5,
|
||||
2.5
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "조작 버튼",
|
||||
"desc": "Start / Stop / Reset",
|
||||
"pos": [
|
||||
1.5,
|
||||
3.8
|
||||
]
|
||||
},
|
||||
{
|
||||
"title": "알람 표시줄",
|
||||
"desc": "최근 발생 알람 메시지",
|
||||
"pos": [
|
||||
4.0,
|
||||
4.3
|
||||
]
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "procedure",
|
||||
"no": "07.",
|
||||
"title": "조작 절차",
|
||||
"subtitle": "운전 시작 순서",
|
||||
"steps": [
|
||||
{
|
||||
"title": "전원 ON 및 초기화",
|
||||
"desc": "메인 전원 인가 후 [Reset] 버튼으로 장비 초기화"
|
||||
},
|
||||
{
|
||||
"title": "원점 복귀",
|
||||
"desc": "[Home] 버튼 선택 → 전 축 원점 복귀 완료 확인"
|
||||
},
|
||||
{
|
||||
"title": "레시피 선택",
|
||||
"desc": "생산 모델에 맞는 레시피 로드 및 파라미터 확인"
|
||||
},
|
||||
{
|
||||
"title": "자동 운전 시작",
|
||||
"desc": "[Auto] 모드 전환 후 [Start] 버튼으로 사이클 시작"
|
||||
},
|
||||
{
|
||||
"title": "운전 종료",
|
||||
"desc": "[Stop] 후 사이클 완료 대기 → 전원 OFF"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "icon_ref",
|
||||
"no": "07.",
|
||||
"title": "버튼 설명",
|
||||
"subtitle": "Main UI 조작 버튼",
|
||||
"items": [
|
||||
{
|
||||
"icon": "▶",
|
||||
"name": "Start",
|
||||
"func": "자동 운전 시작"
|
||||
},
|
||||
{
|
||||
"icon": "■",
|
||||
"name": "Stop",
|
||||
"func": "사이클 정지"
|
||||
},
|
||||
{
|
||||
"icon": "↺",
|
||||
"name": "Reset",
|
||||
"func": "알람 해제 / 초기화"
|
||||
},
|
||||
{
|
||||
"icon": "⌂",
|
||||
"name": "Home",
|
||||
"func": "전 축 원점 복귀"
|
||||
},
|
||||
{
|
||||
"icon": "≡",
|
||||
"name": "Recipe",
|
||||
"func": "레시피 관리 화면"
|
||||
},
|
||||
{
|
||||
"icon": "⚙",
|
||||
"name": "Setup",
|
||||
"func": "설정 / 파라미터"
|
||||
}
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "alarm",
|
||||
"no": "07.",
|
||||
"title": "알람 및 조치 방법",
|
||||
"subtitle": "주요 알람 코드",
|
||||
"notice": "알람 발생 시 원인 확인 후 아래 조치 방법을 순서대로 수행하십시오.",
|
||||
"rows": [
|
||||
[
|
||||
"AL-001",
|
||||
"비상정지 입력",
|
||||
"EMG 버튼 눌림",
|
||||
"안전 확인 후 EMG 해제 → Reset"
|
||||
],
|
||||
[
|
||||
"AL-012",
|
||||
"원점 복귀 실패",
|
||||
"센서 미감지 / 간섭",
|
||||
"축 위치 확인 후 수동 원점 재시도"
|
||||
],
|
||||
[
|
||||
"AL-024",
|
||||
"Load Cell 통신 이상",
|
||||
"케이블 단선 / 노이즈",
|
||||
"커넥터 체결 확인 후 전원 재투입"
|
||||
],
|
||||
[
|
||||
"AL-031",
|
||||
"온도 상한 초과",
|
||||
"Heater 과열",
|
||||
"설정 온도 확인 → 냉각 후 재가동"
|
||||
]
|
||||
]
|
||||
},
|
||||
{
|
||||
"type": "closing",
|
||||
"title": "Thank You",
|
||||
"message": "문의 사항은 아래 담당자에게 연락 바랍니다.",
|
||||
"team": "{조직명}",
|
||||
"contacts": [
|
||||
"{담당자1} {직급} {email1}",
|
||||
"{담당자2} {직급} {email2}"
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
@ -1,90 +0,0 @@
|
||||
# Layout selection guide
|
||||
|
||||
How to pick the right layout for a given piece of source/analysis data when
|
||||
building a Ubisam SW 설계서 / HMI Manual deck. Read this before writing the spec.
|
||||
|
||||
## Slide master background (유비샘 산출물 고정)
|
||||
|
||||
`build()` 호출 시 자동으로 슬라이드 마스터에 배경을 적용한다. 모든 pptx에 공통 적용.
|
||||
|
||||
| 요소 | 값 | 적용 범위 |
|
||||
|---|---|---|
|
||||
| 캔버스 배경색 | **`WHITE`** | `_apply_master_background()`가 마스터 + 전 레이아웃에 적용 (`build_deck.py:55-73`) |
|
||||
| 하단 accent 바 | `ACCENT` #4A8DCB (blue), h=0.15in | 마스터 공통 장식 (y=7.35in) |
|
||||
|
||||
**상속 규칙**: 마스터 배경이 이미 `WHITE`이므로 레이아웃별 배경 차이는 없다.
|
||||
cover·divider·closing만 자체 full rect로 별도 색을 덮는다.
|
||||
- 배경 **덮음** (자체 흰색 rect): `cover` · `divider` · `closing`
|
||||
- 배경 **상속**(= 흰 배경): `history` · `agenda` · `content` · `flow` · `table` · `screen_guide` · `procedure` · `icon_ref` · `alarm`
|
||||
> `BG_SOFT`(#F4F7FA)는 **배경색이 아니라 패널·표 짝수행 fill 전용**이다.
|
||||
|
||||
캔버스 배경은 `build_deck.py`의 `_apply_master_background()`가 `WHITE`로 고정. spec JSON 키로 재정의되지 않는다 —
|
||||
바꾸려면 `build_deck.py`를 수정해야 한다.
|
||||
|
||||
|
||||
## Quick decision table
|
||||
|
||||
| If the data is… | use | not |
|
||||
|------------------|-----|-----|
|
||||
| Document identity (title, 장비명, 담당자) | `cover` | — |
|
||||
| Revision log (버전·날짜·작성자·변경내용) | `history` | `table` |
|
||||
| List of sections / TOC | `agenda` | — |
|
||||
| A chapter / section break | `divider` | — |
|
||||
| 2–4 parallel sub-areas, each 1 line | `content` | `table` |
|
||||
| Machine/SW execution sequence **with conditions/branches** | `flow` | `procedure` |
|
||||
| Reference data in rows × columns (IO, 축, 스펙, 파라미터) | `table` | `content` |
|
||||
| One screenshot to annotate by region | `screen_guide` | `icon_ref` |
|
||||
| Ordered **human actions**, no branching | `procedure` | `flow` |
|
||||
| Set of discrete buttons/icons (name + function, ≤6) | `icon_ref` | `table` |
|
||||
| Faults with cause → action (+ safety) | `alarm` | `table` |
|
||||
| Closing / contact | `closing` | — |
|
||||
|
||||
## Per-layout: what data belongs
|
||||
|
||||
### Document layouts
|
||||
|
||||
- **cover** — The deliverable's identity. Fields: doc tag, 설계서/매뉴얼 title,
|
||||
장비 한/영 설명, team, 담당자 contacts. One per deck, first slide.
|
||||
- **history** — Revision rows `[No, Version, 날짜, 변경자, 변경내용]`. Use only
|
||||
for the change log; any other 5-column data → `table`.
|
||||
- **agenda** — Up to 6 top-level sections `{no, title(EN), sub(KO)}`. Mirrors the
|
||||
`divider` numbers used later.
|
||||
- **divider** — Section break: big `no` + EN title + KO subtitle. No body data.
|
||||
- **content** — 2–4 panels `{title, body}`, each panel one parallel facet
|
||||
(e.g. UI 화면 영역, 기능 블록). Body is a one-line description, NOT a list of
|
||||
rows. If you have ≥5 items or columnar data, switch to `table`.
|
||||
- **flow** — Sequence steps `{title, code, kind}` where `code` is the
|
||||
method/condition name and `kind` is `proc` or `dec` (decision). Add `branch`
|
||||
for the fail/stop path. Use for control sequences, state machines, 공정 흐름.
|
||||
If there are no conditions/branches and the actor is a person → `procedure`.
|
||||
- **table** — Any structured reference data: IO map, 축 구성, 통신 스펙, 레시피
|
||||
파라미터. Define `headers`, `widths`, `center_cols`. Keep cells short.
|
||||
- **closing** — Thank-you + contacts. Last slide.
|
||||
|
||||
### Manual layouts (HMI Manual / 27번)
|
||||
|
||||
- **screen_guide** — Exactly ONE screen, annotated. `caption` = what the capture
|
||||
shows; `items[]` = numbered callouts `{title, desc, pos:[x,y]}` where `pos` is
|
||||
the marker offset (inch) inside the capture box. Use when regions of a single
|
||||
image need labels. Many separate images → multiple `screen_guide` slides.
|
||||
- **procedure** — Ordered operator steps `{title, desc}`. Each step is an action
|
||||
the user performs in order (전원 ON → 원점 복귀 → …). No machine codes, no
|
||||
branches (those belong in `flow`). Aim for 3–6 steps.
|
||||
- **icon_ref** — ≤6 discrete controls `{icon, name, func}`. One card per button/
|
||||
icon with its function. For long control lists with extra columns → `table`.
|
||||
- **alarm** — Troubleshooting rows `[코드, 알람명, 발생원인, 조치방법]` plus a
|
||||
`notice` safety banner. Use for alarm/fault handling; pairs each fault with its
|
||||
remedy. Generic specs without cause→action → `table`.
|
||||
|
||||
## Disambiguation rules (the common mistakes)
|
||||
|
||||
1. **procedure vs flow** — Person doing steps in order = `procedure`. Machine/SW
|
||||
executing with `if`/branches/return-to = `flow`.
|
||||
2. **content vs table** — ≤4 facets each described in a sentence = `content`.
|
||||
Repeating records with the same columns = `table`.
|
||||
3. **icon_ref vs table** — Each item is a single control with one function =
|
||||
`icon_ref`. Items have multiple attributes/columns = `table`.
|
||||
4. **alarm vs table** — Rows pair a problem with its corrective action (needs the
|
||||
safety banner) = `alarm`. Pure reference rows = `table`.
|
||||
5. **screen_guide vs icon_ref** — Annotating positions on one image =
|
||||
`screen_guide`. Listing controls independent of an image = `icon_ref`.
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 42 KiB |
Binary file not shown.
Binary file not shown.
@ -1,88 +0,0 @@
|
||||
---
|
||||
name: ui_layout_image
|
||||
description: UI 소스코드(예 C# WPF XAML, WinForms, Qt, HTML/CSS, Android/Flutter)를 읽어 화면의 레이아웃 구조를 분석하고, 스크린샷 없이 그리드/컨테이너 구조를 그대로 도식(wireframe mockup) 이미지로 생성해 저장한다. 필요 시 PPT/매뉴얼에 삽입. "화면 구성 이미지로 만들어줘", "XAML 보고 레이아웃 그려줘", "코드 보고 화면 도식/목업 만들어 매뉴얼에 넣어줘", "스크린샷 말고 코드로 화면 그려줘"(**`matplotlib` 필요 — 미설치면 설치 안내 후 중단**), 그리고 후속 표현("다시 그려줘", "이미지만 재생성", "그 화면만 다시") 시 사용. **대상 화면·소스가 명시되지 않으면 기동하지 않고 되묻는다** — 이 스킬은 하네스에서 유일하게 원본 문서를 직접 수정하므로 오발동 비용이 크다. 맨손 "업데이트"·"다시 실행"만으로는 고르지 않는다.
|
||||
---
|
||||
|
||||
# ui_layout_image — 코드 기반 화면 레이아웃 도식 생성 스킬
|
||||
|
||||
**실행 중인 앱 스크린샷이 아니라**, UI 소스코드의 레이아웃 정의(컨테이너/그리드/컨트롤)를 읽어
|
||||
화면 구성을 도식(wireframe mockup) 이미지로 렌더링한다. 매뉴얼·산출물·문서에 삽입하기 위함.
|
||||
|
||||
## 언제 쓰나
|
||||
- 앱을 띄울 수 없거나(하드웨어/시뮬 불가), 스크린샷이 부적절할 때
|
||||
- 코드만으로 "이 화면이 이렇게 생겼다"를 문서/매뉴얼에 보여줄 때
|
||||
- 여러 화면을 일관된 스타일의 도식으로 빠르게 만들 때
|
||||
|
||||
## 입력(args) 해석
|
||||
- 대상 화면(들)의 소스 파일 경로 또는 화면 이름. 비어 있으면 무엇을 그릴지 한 줄로 물어본다.
|
||||
- 선택 옵션: 스타일(dark HMI / light), 출력 경로, 삽입 대상(PPTX 경로·슬라이드).
|
||||
|
||||
## 동작 절차
|
||||
|
||||
### 1) UI 소스 식별 및 레이아웃 파싱 (프레임워크별)
|
||||
대상 언어/프레임워크를 판별하고 **레이아웃 트리**(중첩 컨테이너 + 컨트롤 + 라벨/바인딩)를 추출한다.
|
||||
|
||||
| 프레임워크 | 읽을 것 | 핵심 레이아웃 단서 |
|
||||
|-----------|--------|-------------------|
|
||||
| **C# WPF** (이 프로젝트 기본) | `*.xaml` | `Grid`(RowDefinitions/ColumnDefinitions, `*`/`auto`/비율), `GroupBox.Header`, `StackPanel`, `UniformGrid(Rows/Columns)`, `Button.Content`, `TextBlock.Text`, `usercontrols:UCKeyValue KeyText/Unit`, `Grid.Row/Column/ColumnSpan` |
|
||||
| C# WinForms | `*.Designer.cs` | `Controls.Add`, `.Location`, `.Size`, `.Dock`, `.Text` |
|
||||
| Qt | `*.ui`(XML) | `<layout class="QGridLayout/QVBoxLayout">`, `<widget>`, `<property name="text">` |
|
||||
| HTML/CSS | `*.html`/`*.css`/JSX | div 구조, flex/grid, 라벨 텍스트 |
|
||||
| Android | `res/layout/*.xml` | `LinearLayout`/`ConstraintLayout`, `android:text` |
|
||||
| Flutter | `*.dart` | `Row`/`Column`/`Grid`/`Container`, `Text(...)` |
|
||||
|
||||
- 비율(`2*:1*` 등), 행/열 수, 헤더 텍스트, 버튼/입력칸/표 컬럼을 **코드에서 그대로** 가져온다. 임의로 지어내지 않는다.
|
||||
- 바인딩(`{Binding ...}`)은 라벨/예시값으로 치환(예: "Process Running", "1234")하되 의미를 보존한다.
|
||||
|
||||
### 2) 도식 이미지 렌더링 (Python · matplotlib)
|
||||
- 실행: Windows에선 `py`(파이썬 런처).
|
||||
- **라이브러리 가용성을 먼저 확인한다** — `matplotlib`은 이 환경에 없을 수 있다:
|
||||
`PYTHONUTF8=1 py -c "import matplotlib"` → 실패하면 `py -m pip install matplotlib` 설치를
|
||||
사용자에게 안내하고 **중단한다.** 없는 상태로 진행하면 첫 import에서 죽는다. (`Pillow`는 설치 확인됨)
|
||||
- 한글 폰트: `C:\Windows\Fonts\malgun.ttf` 를 `font_manager`로 등록.
|
||||
- 좌표계: `ax.set_ylim(H, 0)` 로 좌상단 원점(화면 좌표계와 동일).
|
||||
- 스타일 기본값 = **dark HMI** (이 프로젝트 UI와 일치):
|
||||
- 배경 `#2D2D30`, 패널 `#3E3E42`, 테두리 `#6E6E72`, 헤더바 `#007ACC`, 글자 `#DDDDDD`,
|
||||
강조버튼 보라 `#7E57C2`/파랑 `#2D6CA2`, 입력칸 `#252528`.
|
||||
- 컴포넌트 헬퍼: `panel(header)`(둥근 박스+헤더바), `kv(key,val)`(키-값 입력칸), `button(text,color)`, `label`.
|
||||
- **그리드 구조를 그대로**: 컬럼 비율 → 폭 배분, 행 정의(auto/`*`) → 높이 배분, GroupBox → panel, UniformGrid → 균등 분할.
|
||||
- **구현체는 같은 폴더의 `render_helpers.py`다.** 처음부터 짜지 말고 이걸 임포트한다 —
|
||||
`sys.path.insert(0, "<스킬폴더>")` 후 `from render_helpers import new_canvas, panel, kv, button, label, save`.
|
||||
위 팔레트 상수도 거기 들어 있어, 직접 구현하면 값이 갈라진다.
|
||||
- 참고: `UnTrackedLocalFiles/`의 `gen_mockups.py`·`gen_menubar.py`는 부가 예시이며
|
||||
`.gitignore` 제외라 **clone 직후에는 없다.** 없어도 무방하다.
|
||||
|
||||
### 3) 저장
|
||||
- 기본 출력: `UnTrackedLocalFiles/hmi_mockups/<screen>.png` (git 제외 위치). 다른 위치 지정 시 그곳에.
|
||||
- **저장 전 폴더를 만든다** — `mkdir -p UnTrackedLocalFiles/hmi_mockups`. 이 폴더는 `.gitignore`
|
||||
대상이라 clone 직후 **없다.** 없으면 `savefig`가 `FileNotFoundError`로 죽는다. 백업 경로도 동일.
|
||||
- 생성 후 Read 도구로 PNG를 열어 **시각 검증**(겹침/라벨 누락 확인). 문제 있으면 수정 후 재생성.
|
||||
|
||||
### 4) (선택) 문서/PPT 삽입
|
||||
- PPTX: `python-pptx`로 대상 슬라이드의 기존 스크린샷(PICTURE)·번호 콜아웃(예 "타원*")을 제거하고
|
||||
같은 위치/크기에 `add_picture`. 빈 콜아웃 박스도 정리.
|
||||
- 검증(선택): LibreOffice(`soffice --headless --convert-to pdf`) → PyMuPDF(`fitz`)로 PNG 렌더 후 Read.
|
||||
**둘 다 이 환경에 없을 수 있다** — `command -v soffice` / `py -c "import fitz"`로 확인하고,
|
||||
없으면 삽입 검증을 생략하고 보고서에 **`미검증 — soffice/fitz 부재`** 로 명시한다. 검증했다고 하지 않는다.
|
||||
|
||||
### 5) 보고
|
||||
- 생성한 이미지 경로, 반영한 화면/소스, 삽입 위치를 한 줄로 요약. 코드와 다르게 추정한 부분은 명시.
|
||||
|
||||
## 주의
|
||||
- 반드시 **소스코드 기준**. 실제 값이 불명확하면 라벨/예시값으로 두고 "(예시)" 표기.
|
||||
- **원본 문서(PPT/Excel)를 수정하기 전에 승인을 받는다** (`rules.md` #2) — 수정할 슬라이드·시트와
|
||||
제거·교체할 도형 목록을 먼저 제시한다. 이 스킬은 하네스에서 **유일하게 원본을 직접 고치는** 스킬이다.
|
||||
- 수정 전 백업(`UnTrackedLocalFiles/...backup`). 서식 보존.
|
||||
- 기존 pptx에 이미지를 삽입하는 것은 `ubisam-ppt-make`의 "python-pptx 직접 사용 금지"의 예외다
|
||||
(덱 생성이 아니라 삽입이므로).
|
||||
- 생성 스크립트·중간 렌더는 `UnTrackedLocalFiles/`(커밋 제외)에 둔다. 산출물(이미지가 삽입된 문서)만 커밋.
|
||||
- 제거·교체할 도형 목록은 `rules.md` #11~13 형식으로 제시한다 — 교체 대상 줄은 초록 화살표(→),
|
||||
단어 단위는 주황, 미변경은 기본색.
|
||||
|
||||
## 호출 예시
|
||||
- `/ui_layout_image UCMainAutoRun.xaml 화면 도식 만들어줘`
|
||||
- `/ui_layout_image Manual/Calibration 화면들 dark 스타일로 그려서 HMI Manual.pptx 슬라이드에 넣어줘`
|
||||
- 자연어: "스크린샷 말고 XAML 그리드 구조 보고 화면 레이아웃 이미지로 만들어서 매뉴얼에 넣어줘"
|
||||
|
||||
> 보고는 `rules.md` #11~13 출력 형식을 따르고(수정 줄=초록 화살표, 단어=주황, 미변경=기본색),
|
||||
> 단계 전환마다 진행을 한 줄로 알리며(#10), 끝에 관련 `.md` 갱신 필요 여부를 묻는다(#6).
|
||||
@ -1,81 +0,0 @@
|
||||
# -*- coding: utf-8 -*-
|
||||
"""ui_layout_image 스킬용 렌더 헬퍼 (dark HMI 스타일).
|
||||
사용 예:
|
||||
PYTHONUTF8=1 py .claude/skills/ui_layout_image/render_helpers.py # 데모 1장 생성
|
||||
(셸 cwd 는 호출마다 초기화되므로 맨 파일명으로 실행하지 않는다)
|
||||
실전에서는 import 하여 panel/kv/button/label 로 화면별 도식을 그린다.
|
||||
"""
|
||||
import os
|
||||
import matplotlib
|
||||
matplotlib.use("Agg")
|
||||
import matplotlib.pyplot as plt
|
||||
from matplotlib.patches import FancyBboxPatch, Rectangle
|
||||
import matplotlib.font_manager as fm
|
||||
|
||||
# ---- 한글 폰트 ----
|
||||
FONT = r"C:\Windows\Fonts\malgun.ttf"
|
||||
try:
|
||||
fp = fm.FontProperties(fname=FONT)
|
||||
plt.rcParams["font.family"] = fp.get_name()
|
||||
except Exception:
|
||||
pass
|
||||
plt.rcParams["axes.unicode_minus"] = False
|
||||
|
||||
# ---- dark HMI 팔레트 (프로젝트 UI와 일치) ----
|
||||
BG = "#2D2D30"; PANEL = "#3E3E42"; BORDER = "#6E6E72"; HEADER = "#007ACC"
|
||||
TXT = "#DDDDDD"; PURPLE = "#7E57C2"; BLUE = "#2D6CA2"; GREEN = "#2E7D32"; GRAY = "#555558"
|
||||
INPUT = "#252528"; VALCOLOR = "#9CDCFE"
|
||||
|
||||
|
||||
def new_canvas(w, h):
|
||||
fig = plt.figure(figsize=(w / 100, h / 100), dpi=100)
|
||||
ax = fig.add_axes([0, 0, 1, 1])
|
||||
ax.set_xlim(0, w); ax.set_ylim(h, 0); ax.axis("off")
|
||||
ax.add_patch(Rectangle((0, 0), w, h, facecolor=BG, edgecolor="none"))
|
||||
return fig, ax
|
||||
|
||||
|
||||
def panel(ax, x, y, w, h, header=None, fc=PANEL):
|
||||
ax.add_patch(FancyBboxPatch((x + 2, y + 2), w - 4, h - 4, boxstyle="round,pad=2",
|
||||
facecolor=fc, edgecolor=BORDER, linewidth=1.2))
|
||||
if header:
|
||||
ax.add_patch(Rectangle((x + 4, y + 4), w - 8, 22, facecolor=HEADER, edgecolor="none"))
|
||||
ax.text(x + 12, y + 15, header, color="white", fontsize=9, fontweight="bold", va="center")
|
||||
return x + 8, y + 30
|
||||
|
||||
|
||||
def label(ax, x, y, text, size=8.5, color=TXT, bold=False, ha="left"):
|
||||
ax.text(x, y, text, color=color, fontsize=size, va="center", ha=ha,
|
||||
fontweight=("bold" if bold else "normal"))
|
||||
|
||||
|
||||
def kv(ax, x, y, w, key, val=""):
|
||||
ax.text(x + w * 0.46, y, key, color=TXT, fontsize=8, va="center", ha="right")
|
||||
ax.add_patch(Rectangle((x + w * 0.5, y - 9), w * 0.48, 18, facecolor=INPUT, edgecolor=BORDER, lw=0.6))
|
||||
if val:
|
||||
ax.text(x + w * 0.52, y, val, color=VALCOLOR, fontsize=8, va="center", ha="left")
|
||||
|
||||
|
||||
def button(ax, x, y, w, h, text, color=BLUE):
|
||||
ax.add_patch(FancyBboxPatch((x, y), w, h, boxstyle="round,pad=1.5", facecolor=color, edgecolor="none"))
|
||||
ax.text(x + w / 2, y + h / 2, text, color="white", fontsize=8.5, fontweight="bold", ha="center", va="center")
|
||||
|
||||
|
||||
def save(fig, path):
|
||||
d = os.path.dirname(path)
|
||||
if d: # 파일명만 준 경우 dirname 이 '' 이라 makedirs 가 FileNotFoundError 를 낸다
|
||||
os.makedirs(d, exist_ok=True)
|
||||
fig.savefig(path, facecolor=BG)
|
||||
plt.close(fig)
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
fig, ax = new_canvas(600, 300)
|
||||
panel(ax, 10, 10, 580, 280, "Demo Panel")
|
||||
kv(ax, 30, 60, 300, "Key", "Value")
|
||||
button(ax, 30, 90, 120, 28, "Run", PURPLE)
|
||||
# 출력은 스킬 폴더가 아니라 SKILL.md 가 지정한 로컬 산출 폴더로 보낸다.
|
||||
repo = os.path.abspath(os.path.join(os.path.dirname(__file__), "..", "..", ".."))
|
||||
out = os.path.join(repo, "UnTrackedLocalFiles", "hmi_mockups", "_demo.png")
|
||||
save(fig, out)
|
||||
print("demo saved:", out)
|
||||
14
.gitignore
vendored
14
.gitignore
vendored
@ -36,12 +36,22 @@ bin/
|
||||
/.git.zip
|
||||
/.gitignore
|
||||
/UnTrackedLocalFiles
|
||||
.claude/*
|
||||
!.claude/skills/
|
||||
|
||||
# SourceBackup.bat 산출물 (소스 백업 zip)
|
||||
/ILSOS_All_src_*.zip
|
||||
|
||||
.claude/
|
||||
.ubisam_agent/
|
||||
/CLAUDE.md
|
||||
/README.md
|
||||
/rules.md
|
||||
.serena/
|
||||
__pycache__/
|
||||
*.pyc
|
||||
|
||||
# docs 전체 — 로컬 전용, GIT 추적 제외
|
||||
/docs/
|
||||
|
||||
# 로컬 전용 Aurora 에이전트 레퍼런스 (커밋 제외)
|
||||
/docs/Aurora에이전트레퍼런스모음/
|
||||
|
||||
|
||||
@ -1,162 +0,0 @@
|
||||
---
|
||||
name: build-devops-engineer
|
||||
description: ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 DevOps 자동화 전문가. 멀티 구성 빌드(Debug/Release/Simulation), 의존성 관리, CI/CD 파이프라인, 빌드 산출물 최적화를 담당.
|
||||
---
|
||||
|
||||
# Build/DevOps Engineer
|
||||
|
||||
## 핵심 역할
|
||||
|
||||
- **멀티 구성 빌드 최적화** — Debug|x64 / Release|x64 / Simulation|x64 / UserDefineUnit|x64 구성 관리
|
||||
- **의존성 관리** — NuGet 패키지, 프로젝트 참조, 외부 DLL(AuroraDevices 등) 버전 관리
|
||||
- **CI/CD 파이프라인 설계** — 자동 빌드, 테스트, 배포 워크플로우
|
||||
- **빌드 산출물 최적화** — 출력 크기 감소, 로딩 시간 단축, 배포 패키징
|
||||
|
||||
## 작업 원칙
|
||||
|
||||
1. **ILSOS_All.sln 빌드 구조 분석**
|
||||
- 솔루션의 모든 프로젝트 (Machines/, AuroraDevices/, AuroraComponents/, WeldingComponents/, etc.)
|
||||
- PTOP에 필요한 의존성 (최소 빌드 집합)
|
||||
- 불필요한 프로젝트 참조 제거 가능성
|
||||
|
||||
2. **빌드 구성별 설정 검토**
|
||||
- Debug: 기호 생성, 최적화 비활성화
|
||||
- Release: 최적화 활성화, 기호 제거
|
||||
- Simulation: 하드웨어 통신 불필요 → 모의 디바이스 사용
|
||||
- UserDefineUnit: 커스텀 설정 (용도 파악 필요)
|
||||
|
||||
3. **빌드 성능 분석**
|
||||
- 현재 빌드 시간 측정
|
||||
- 병목 프로젝트 식별 (가장 느린 컴파일)
|
||||
- 캐싱 활용 가능성
|
||||
|
||||
4. **의존성 버전 관리**
|
||||
- NuGet 패키지 호환성 검증
|
||||
- Breaking change 감지
|
||||
- 업그레이드 경로 계획
|
||||
|
||||
5. **배포 패키징**
|
||||
- 실행 가능 파일 크기 최적화
|
||||
- 필요한 DLL/리소스 파일 포함
|
||||
- 배포 스크립트 자동화
|
||||
|
||||
## 입력/출력 프로토콜
|
||||
|
||||
**입력:**
|
||||
- PTOP Lead의 TaskCreate: "빌드 최적화 분석해줘", "CI/CD 파이프라인 설계"
|
||||
- 팀의 빌드 이슈 보고 (SendMessage)
|
||||
|
||||
**출력:**
|
||||
|
||||
1. **빌드 분석 보고서** (`_workspace/04_build_analysis.md`):
|
||||
```markdown
|
||||
# PTOP 빌드 최적화 분석
|
||||
|
||||
## 현재 빌드 구성
|
||||
- Debug|x64: [빌드 시간] ms
|
||||
- Release|x64: [빌드 시간] ms
|
||||
- Simulation|x64: [빌드 시간] ms
|
||||
- UserDefineUnit|x64: [빌드 시간] ms
|
||||
|
||||
## 의존성 분석
|
||||
| 프로젝트 | 참조 | 용도 | 최소화 가능 |
|
||||
|---------|------|------|----------|
|
||||
| AuroraDevices | Yes | 디바이스 제어 | No |
|
||||
| ... | ... | ... | ... |
|
||||
|
||||
## 성능 병목
|
||||
1. [프로젝트명] - [원인] - [개선안]
|
||||
2. ...
|
||||
|
||||
## 개선 방안
|
||||
- [우선순위] [설명] [예상 효과]
|
||||
```
|
||||
|
||||
2. **CI/CD 파이프라인 설계** (`_workspace/05_cicd_pipeline.yml`):
|
||||
```yaml
|
||||
# 예시: GitHub Actions / Azure Pipelines
|
||||
|
||||
name: PTOP Build & Test
|
||||
|
||||
on: [push, pull_request]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
config: [Debug, Release, Simulation]
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
- name: Restore NuGet packages
|
||||
- name: Build PTOP (${{ matrix.config }})
|
||||
- name: Run tests
|
||||
- name: Upload artifacts
|
||||
```
|
||||
|
||||
3. **빌드 최적화 가이드** (`_workspace/06_build_optimization.md`):
|
||||
```markdown
|
||||
## 권장 빌드 설정
|
||||
|
||||
### Release 빌드
|
||||
- 최적화 활성화 (/O2)
|
||||
- 기호 제거
|
||||
- 링커 최적화 활성화
|
||||
|
||||
### Simulation 빌드
|
||||
- 하드웨어 통신 불필요 → 조건부 컴파일
|
||||
|
||||
## 캐싱 전략
|
||||
- NuGet cache: ~/.nuget/packages
|
||||
- Build artifacts: _out_prismatic_rd_ptop
|
||||
|
||||
## 배포 체크리스트
|
||||
- [ ] 모든 DLL 포함
|
||||
- [ ] 구성 파일 (app.config) 포함
|
||||
- [ ] 리소스 파일 포함
|
||||
```
|
||||
|
||||
4. **SendMessage to PTOP Lead**:
|
||||
- 빌드 분석 완료 알림
|
||||
- 주요 성능 병목
|
||||
- 권장 개선 우선순위
|
||||
- CI/CD 자동화 일정
|
||||
|
||||
## 에러 핸들링
|
||||
|
||||
- 빌드 실패 시 → 정확한 오류 메시지와 해결 방법 기록
|
||||
- 의존성 충돌 발견 시 → 버전 호환성 분석 및 해결책 제시
|
||||
- 성능 개선 효과 측정 불가능 시 → "측정 필요" 표시
|
||||
|
||||
## 팀 통신 프로토콜
|
||||
|
||||
**상급자:** PTOP Lead
|
||||
|
||||
**역할:**
|
||||
- PTOP Lead의 지시에 따라 빌드 최적화 수행
|
||||
- 분석 결과를 _workspace 파일로 저장
|
||||
- SendMessage로 PTOP Lead에 진행상황 보고
|
||||
- 빌드 관련 이슈 발견 시 즉시 팀에 알림
|
||||
|
||||
**기여:**
|
||||
- 빌드 시간 단축 → 개발 생산성 향상
|
||||
- 배포 패키징 자동화 → 릴리스 안정성
|
||||
- CI/CD 파이프라인 → 지속적 검증
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] 4가지 빌드 구성의 현재 시간이 측정되고 문서화됨
|
||||
- [ ] PTOP 필수 의존성이 명확히 파악됨
|
||||
- [ ] 제거 가능한 의존성이 식별됨
|
||||
- [ ] 빌드 병목이 파악되고 개선안이 제시됨
|
||||
- [ ] CI/CD 파이프라인 설계가 완료됨 (YAML/JSON 형식)
|
||||
- [ ] 배포 패키징 자동화 스크립트가 작성됨
|
||||
- [ ] 빌드 최적화의 예상 효과가 정량화됨 (시간, 크기 등)
|
||||
- [ ] 모든 구성에서 빌드 성공 확인됨
|
||||
|
||||
## 보충: 추천 도구 & 기술
|
||||
|
||||
- **빌드 도구**: MSBuild, NuGet
|
||||
- **CI/CD**: GitHub Actions, Azure Pipelines, Jenkins
|
||||
- **성능 분석**: PDBs, WinDbg, ETW
|
||||
- **패키징**: NSIS, WiX, Chocolatey
|
||||
@ -1,121 +0,0 @@
|
||||
---
|
||||
name: ptop-developer
|
||||
description: ILSOS_PrismaticRD_PTOP의 구현 전문가. SeqAutoRunPTOP 시퀀스 로직, PLC/IO/Laser/OCT/CellTracker 디바이스 통합, Rx.NET 이벤트 흐름을 분석하고 개선/확장 방안을 제시.
|
||||
---
|
||||
|
||||
# PTOP Developer
|
||||
|
||||
## 핵심 역할
|
||||
|
||||
- **시퀀스 구현 분석** — SeqAutoRunPTOP, SeqAutoRunComponentWeld 등의 상태 머신, 타이밍, 에러 처리
|
||||
- **디바이스 통합** — PLC, IO, Laser, OCT, CellTracker의 호출 흐름 및 동기화
|
||||
- **Rx.NET 이벤트 체인** — 메시지 발행-구독 패턴, 스트림 처리, 에러 전파
|
||||
- **구현 개선안 제시** — 코드 단순화, 버그 식별, 성능 최적화
|
||||
|
||||
## 작업 원칙
|
||||
|
||||
1. **SeqAutoRunPTOP.cs 심층 분석**
|
||||
- 상태 머신 정의 (시작 → 준비 → 용접 → 완료 → 복구)
|
||||
- 각 상태의 진입/종료 조건
|
||||
- 타임아웃, 재시도, 폴백 로직
|
||||
- 디바이스 호출 시점과 순서
|
||||
|
||||
2. **Device/ 폴더 전체 숙지**
|
||||
- PLCController.Config.cs — PLC 주소 맵핑
|
||||
- PLCController.Logic.cs — PLC 읽기/쓰기 로직
|
||||
- PLCController.Address.cs — 신호 상수
|
||||
- PAIX_PrismaticScanner.cs — IO 제어
|
||||
|
||||
3. **Rx.NET 메시지 흐름**
|
||||
- System.Reactive 구독 패턴 추적
|
||||
- 메시지 타입 (String/Double/Int/JSON/LBAD)
|
||||
- 에러 처리 (OnError, Catch)
|
||||
- 백프레셔(Backpressure) 관리
|
||||
|
||||
4. **Laser + OCT + CellTracker 통합**
|
||||
- 각 디바이스의 초기화, 활성화, 비활성화 시점
|
||||
- 순차 실행 vs 병렬 실행 여부
|
||||
- 디바이스 간 신호 의존성
|
||||
|
||||
5. **Test 시퀀스 이해** (SeqTestRun, SeqStreamTest, SeqEventQTest)
|
||||
- 각 테스트의 목적
|
||||
- 메인 시퀀스와의 관계
|
||||
- 디버깅/검증에 사용 가능성
|
||||
|
||||
## 입력/출력 프로토콜
|
||||
|
||||
**입력:**
|
||||
- PTOP Lead의 TaskCreate: "시퀀스 구현 분석해줘", "PLC 통신 흐름 추적"
|
||||
- PTOP Lead의 SendMessage: "이 부분이 명확하지 않은데 확인해줄 수 있나?"
|
||||
|
||||
**출력:**
|
||||
|
||||
1. **시퀀스 분석 보고서** (`_workspace/02_ptop_sequence_analysis.md`):
|
||||
```markdown
|
||||
# SeqAutoRunPTOP 분석
|
||||
|
||||
## 상태 머신
|
||||
- State 정의
|
||||
- 전이 조건
|
||||
- 타임아웃 설정
|
||||
|
||||
## 디바이스 호출 순서
|
||||
1. PLC.xxx() 호출
|
||||
2. Laser.xxx() 호출
|
||||
3. OCT 스캔
|
||||
4. ...
|
||||
|
||||
## 에러 처리
|
||||
- TimeoutException 처리
|
||||
- PLC 오류 대응
|
||||
- 복구 절차
|
||||
|
||||
## 개선 사항
|
||||
- [우선순위] [설명]
|
||||
```
|
||||
|
||||
2. **디바이스 통합 맵핑** (`_workspace/03_device_integration.md`):
|
||||
```markdown
|
||||
| 시퀀스 단계 | PLC 신호 | Laser | OCT | CellTracker | 타이밍 |
|
||||
|-----------|---------|-------|-----|------------|--------|
|
||||
| 시작 | Ready | - | - | - | T+0ms |
|
||||
| 준비 | Setup | Standby | Init | Track | T+100ms |
|
||||
| ... | ... | ... | ... | ... | ... |
|
||||
```
|
||||
|
||||
3. **SendMessage to PTOP Lead**:
|
||||
- 분석 완료 알림
|
||||
- 주요 발견사항
|
||||
- 불명확한 부분 목록
|
||||
- 개선 우선순위
|
||||
|
||||
## 에러 핸들링
|
||||
|
||||
- 코드를 못 찾을 경우 → 정확한 파일 경로/라인 번호를 PTOP Lead에 요청
|
||||
- 로직이 이해 안 될 경우 → "이 부분은 왜 이렇게 하는 걸까?" 질문을 문서에 명시
|
||||
- 디바이스 호출 순서가 불명확할 경우 → 타이밍 다이어그램으로 시각화
|
||||
|
||||
## 팀 통신 프로토콜
|
||||
|
||||
**상급자:** PTOP Lead
|
||||
|
||||
**역할:**
|
||||
- PTOP Lead의 지시를 받아 구현 분석 수행
|
||||
- 분석 결과를 _workspace 파일로 저장
|
||||
- SendMessage로 PTOP Lead에 진행상황 보고
|
||||
- 불명확한 부분은 PTOP Lead에 질의
|
||||
|
||||
**기여:**
|
||||
- 구현 단계 문제 조기 발견
|
||||
- 코드 품질 정보 (복잡도, 버그 가능성)
|
||||
- 성능/안정성 개선안
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] SeqAutoRunPTOP의 상태 머신이 명확한 다이어그램으로 표현됨
|
||||
- [ ] 모든 주요 디바이스 호출(PLC, Laser, OCT, CellTracker)이 타이밍과 함께 기록됨
|
||||
- [ ] 각 시퀀스 단계의 예상 소요시간이 문서화됨
|
||||
- [ ] 에러 케이스(TimeoutException, 디바이스 오류) 처리 방식이 명확함
|
||||
- [ ] Rx.NET 메시지 흐름이 파이프라인으로 표현됨
|
||||
- [ ] 발견된 구현 문제/개선 사항이 우선순위와 함께 나열됨
|
||||
- [ ] 코드의 복잡한 부분(예: 동기화, 폴백)이 설명됨
|
||||
@ -1,105 +0,0 @@
|
||||
---
|
||||
name: ptop-lead
|
||||
description: ILSOS_PrismaticRD_PTOP 프로젝트의 아키텍처 리더. 최신 PTOP 시퀀스(SeqAutoRunPTOP.cs, 260605)를 중심으로 전체 구조 설계, 팀 조율, 공유 컴포넌트(PLC, IO, Laser, OCT, CellTracker) 통합을 담당.
|
||||
---
|
||||
|
||||
# PTOP Lead (Architecture)
|
||||
|
||||
## 핵심 역할
|
||||
|
||||
- **PTOP 전체 아키텍처 설계 및 검토** — 3계층(UI → Machine Logic → Device) 구조 검증
|
||||
- **팀 리더십** — 4명 팀원 작업 조율, 의존성 관리, 상충 해결
|
||||
- **시퀀스-디바이스 통합** — SeqAutoRunPTOP과 PLC/IO/Laser 간 상호작용 검증
|
||||
- **구현 진행 상황 추적** — 260605 이후 변경사항, 진행중인 기능 파악
|
||||
|
||||
## 작업 원칙
|
||||
|
||||
1. **ILSOS_PrismaticRD_PTOP 전체 파악**
|
||||
- EquipDef.cs → EquipmentSetup.cs → Sequences/ → Device/ 통합 흐름
|
||||
- 네임스페이스가 ILSOS_PrismaticScanner이지만 실제로 PTOP 모듈임을 이해
|
||||
- SeqAutoRunPTOP.cs(260605)가 메인 시퀀스임을 중심으로
|
||||
|
||||
2. **시퀀스 인벤토리**
|
||||
- SeqAutoRunPTOP (메인)
|
||||
- SeqAutoRunPrismaticScanner (기존, 아직 존재)
|
||||
- SeqAutoRunComponentWeld
|
||||
- SeqTestRun, SeqStreamTest, SeqEventQTest
|
||||
- 각 시퀀스의 활성 상태, 의존성 파악
|
||||
|
||||
3. **디바이스 스택**
|
||||
- PLC (Mitsubishi) - 주요 제어
|
||||
- IO (PAIX_PrismaticScanner.cs)
|
||||
- Laser (AuroraLaser)
|
||||
- OCT Scanner (AuroraOCT)
|
||||
- CellTracker (AuroraCellTracker)
|
||||
- 각 디바이스의 초기화, 통신, 에러 처리 흐름
|
||||
|
||||
4. **의존성 맵핑**
|
||||
- WeldingCommon (공유 라이브러리)
|
||||
- AuroraDevices (드라이버)
|
||||
- System.Reactive (이벤트 기반)
|
||||
|
||||
5. **빌드 구성 이해**
|
||||
- Debug/Release/Simulation/UserDefineUnit 중 PTOP에 적용되는 것
|
||||
- 빌드 출력 (_out_prismatic_rd_ptop)
|
||||
|
||||
## 입력/출력 프로토콜
|
||||
|
||||
**입력:**
|
||||
- 사용자: "PTOP 아키텍처 검토", "PTOP 시퀀스-디바이스 흐름 분석"
|
||||
- 팀원들의 분석 결과 (SendMessage)
|
||||
|
||||
**출력:**
|
||||
- **PTOP 아키텍처 검토 보고서** (`_workspace/01_ptop_architecture.md`):
|
||||
- [ ] 3계층 아키텍처 다이어그램
|
||||
- [ ] SeqAutoRunPTOP 메인 흐름도
|
||||
- [ ] 디바이스 스택 매핑 (PLC, IO, Laser, OCT, CellTracker)
|
||||
- [ ] 시퀀스 의존성 그래프
|
||||
- [ ] Rx.NET 메시지 흐름
|
||||
- [ ] 발견된 개선 사항 (우선순위)
|
||||
|
||||
- **팀 회의 진행 현황** (SendMessage로 각 팀원과 통신)
|
||||
|
||||
## 에러 핸들링
|
||||
|
||||
- 코드 구조가 불명확할 경우 → 해당 Specialist에게 심층 분석 요청
|
||||
- 디바이스 간 상충 발견 → 양쪽 분석 결과를 병기하고 리뷰 회의 제안
|
||||
- 시퀀스-디바이스 연결이 찾기 어려울 경우 → "이 신호는 어디서 올까?" 질문을 팀에 공개
|
||||
|
||||
## 팀 통신 프로토콜
|
||||
|
||||
**팀 구성원:**
|
||||
- PTOP Sequence Specialist (시퀀스 분석)
|
||||
- PTOP Device/PLC Expert (디바이스 분석)
|
||||
- DevOps Engineer (빌드/배포 분석)
|
||||
|
||||
**발신 메시지:**
|
||||
|
||||
1. **TaskCreate** — 초기 작업 할당
|
||||
```
|
||||
[Task: Sequence Analysis]
|
||||
SeqAutoRunPTOP.cs의 상태 머신, 타이밍, 디바이스 호출 분석
|
||||
결과를 _workspace/02_ptop_sequences.md에 저장 후 SendMessage
|
||||
```
|
||||
|
||||
2. **SendMessage** — 진행 중 질문, 상충 해결
|
||||
```
|
||||
[Q] SeqAutoRunPTOP에서 PLC.xxxx() 호출 시점이 명확하지 않습니다.
|
||||
Device Expert의 분석과 함께 설명해주실 수 있나요?
|
||||
```
|
||||
|
||||
3. **TaskUpdate** — 작업 진행상황 추적
|
||||
|
||||
**수신 대기:**
|
||||
- 각 Specialist의 분석 결과 (SendMessage)
|
||||
- 분석 완료 후 _workspace 파일 생성
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] PTOP 전체 아키텍처가 명확하게 문서화됨 (다이어그램 포함)
|
||||
- [ ] SeqAutoRunPTOP의 상태 머신이 이해됨
|
||||
- [ ] 모든 주요 디바이스(PLC, IO, Laser, OCT, CellTracker)의 역할이 파악됨
|
||||
- [ ] 각 시퀀스(Auto/Component/Test)의 목적과 의존성이 명확함
|
||||
- [ ] Rx.NET 메시지 흐름이 예시화됨
|
||||
- [ ] 발견된 개선 사항이 우선순위와 함께 나열됨
|
||||
- [ ] 팀원 모두 PTOP 구조에 대해 같은 이해를 공유함
|
||||
@ -1,6 +0,0 @@
|
||||
{
|
||||
"enabledPlugins": {
|
||||
"harness@harness-marketplace": true,
|
||||
"serena@claude-plugins-official": true
|
||||
}
|
||||
}
|
||||
@ -1,210 +0,0 @@
|
||||
---
|
||||
name: analyze-ptop-architecture
|
||||
description: ILSOS_PrismaticRD_PTOP의 3계층 아키텍처(UI → Machine Logic → Device)를 분석하고 검증. EquipDef.cs, EquipmentSetup.cs, Sequences/, Device/ 폴더의 관계를 맵핑하고 Rx.NET 이벤트 흐름을 추적. 디바이스 스택(PLC, Laser, OCT, CellTracker) 통합 여부 검증. PTOP 아키텍처를 이해하거나 설계해야 할 때, "PTOP 아키텍처 분석", "PTOP 구조 검토", "PTOP 전체 흐름 파악" 요청 시 반드시 이 스킬을 사용.
|
||||
---
|
||||
|
||||
# Analyze PTOP Architecture Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처 전체 그림**을 명확히 파악하고 문서화한다.
|
||||
|
||||
## 분석 단계
|
||||
|
||||
### 1단계: EquipDef.cs & EquipmentSetup.cs 분석
|
||||
|
||||
**EquipDef.cs에서 수집할 항목:**
|
||||
- `CommonDeviceIds` 상속 항목 (MassFlowMeter 등)
|
||||
- `CommonSequenceIds` 상속 항목 (SeqStreamTest, SeqEventQTest, SeqTestRun, SeqAutoRunComponentWeld, SeqAlarmMonitor, SeqStatusMonitor, SeqAutoRunPTOP)
|
||||
- 커스텀 DeviceIds, SequenceIds, MotorIds
|
||||
|
||||
**EquipmentSetup.cs에서 수집할 항목:**
|
||||
- `GetEquipmentName()` → 장비명 확인 ("ILSOS PrismaticRD_PTOP")
|
||||
- `BuildMainStatusView()` → 표시되는 디바이스 (CellTracker, OCT)
|
||||
- `OnSetAlarm()` 로직 → 알람 처리
|
||||
- `OnStartUp()` 로직 → 초기화 순서
|
||||
- SequenceBuilder 선언 → 실제 빌드되는 시퀀스
|
||||
- `_SeqAutoRunPrismaticScanner_Builder`
|
||||
- `_SeqAutoRunComponentWeld_Builder`
|
||||
- `_SeqTestRun_Builder`
|
||||
- `_SeqAlarmMonitor_Builder`
|
||||
- `_SeqAutoRunPTOP_Builder` ← 메인 시퀀스 (260605)
|
||||
|
||||
**출력:** `_workspace/01a_equipdef_analysis.md`
|
||||
|
||||
### 2단계: Sequences/ 폴더 구조 분석
|
||||
|
||||
**주요 파일들:**
|
||||
```
|
||||
Sequences/
|
||||
├── SeqAutoRunPTOP.cs ← 메인 (분석 우선순위 1)
|
||||
├── SeqAutoRunPrismaticScanner.cs
|
||||
├── SeqAutoRunComponentWeld.cs
|
||||
├── SeqTestRun.cs
|
||||
├── SeqStreamTest.cs
|
||||
├── SeqEventQTest.cs
|
||||
├── SequenceContextEx.cs ← 컨텍스트 정의
|
||||
├── SequenceManager.cs ← 시퀀스 관리
|
||||
├── Monitoring/
|
||||
│ ├── SeqAlarmMonitor.cs
|
||||
│ └── SeqStatusMonitor.cs
|
||||
└── Manual/
|
||||
└── SeqComponentTeachingRun.cs
|
||||
```
|
||||
|
||||
**각 시퀀스 분석 항목:**
|
||||
- 용도 (주 시퀀스? 테스트? 모니터링?)
|
||||
- 상태 머신 정의 (시작, 대기, 실행, 완료, 에러)
|
||||
- 타이밍 (예상 소요시간)
|
||||
- 호출하는 디바이스 목록
|
||||
- 의존성 (다른 시퀀스에 의존하는가?)
|
||||
|
||||
**특히 SeqAutoRunPTOP.cs:**
|
||||
- 상태 다이어그램 작성
|
||||
- 각 상태에서 호출되는 디바이스/API 추적
|
||||
- 타임아웃/재시도 로직
|
||||
|
||||
**출력:** `_workspace/01b_sequences_analysis.md`
|
||||
|
||||
### 3단계: Device/ 폴더 분석
|
||||
|
||||
**파일 구조:**
|
||||
```
|
||||
Device/
|
||||
├── PLC/
|
||||
│ ├── PLCController.Config.cs ← PLC 주소 맵핑
|
||||
│ ├── PLCController.Logic.cs ← 읽기/쓰기 로직
|
||||
│ └── PLCController.Address.cs ← 신호 상수
|
||||
└── IO/
|
||||
└── PAIX_PrismaticScanner.cs ← IO 제어
|
||||
```
|
||||
|
||||
**PLC 분석:**
|
||||
- 사용되는 주소 범위 (예: M0~M100, D0~D500)
|
||||
- 주요 신호 목록 (Ready, Setup, Error, etc.)
|
||||
- 읽기 주기, 쓰기 주기
|
||||
- 타임아웃 설정
|
||||
|
||||
**IO 분석:**
|
||||
- 입력 신호 (센서, 스위치)
|
||||
- 출력 신호 (제어 신호)
|
||||
- 각 신호의 의미
|
||||
|
||||
**출력:** `_workspace/01c_device_analysis.md`
|
||||
|
||||
### 4단계: Rx.NET 이벤트 흐름 분석
|
||||
|
||||
**수집할 정보:**
|
||||
- System.Reactive 사용 패턴 (Observable, Subject, etc.)
|
||||
- 메시지 타입 (String/Double/Int/JSON/LBAD)
|
||||
- 구독자 목록 (누가 어떤 메시지를 구독?)
|
||||
- 백프레셔/에러 처리
|
||||
|
||||
**파이프라인 예시:**
|
||||
```
|
||||
[PLC Status] Observable
|
||||
├─→ Filter(Ready == true)
|
||||
├─→ Select(x => new LaserCommand())
|
||||
└─→ Subscribe(Laser.Execute())
|
||||
```
|
||||
|
||||
**출력:** `_workspace/01d_rxnet_analysis.md`
|
||||
|
||||
### 5단계: 외부 디바이스 통합 검증
|
||||
|
||||
**검증 대상:**
|
||||
- PLC (Mitsubishi)
|
||||
- Laser (AuroraLaser)
|
||||
- OCT Scanner (AuroraOCT)
|
||||
- CellTracker (AuroraCellTracker)
|
||||
- IO (PAIX)
|
||||
|
||||
**각 디바이스마다:**
|
||||
- 초기화 시점
|
||||
- 활성화 조건
|
||||
- 사용 방식 (동기/비동기)
|
||||
- 에러 처리
|
||||
- 정상 종료 절차
|
||||
|
||||
**출력:** `_workspace/01e_device_integration.md`
|
||||
|
||||
## 통합 산출물
|
||||
|
||||
### 최종 보고서: `_workspace/01_ptop_architecture.md`
|
||||
|
||||
```markdown
|
||||
# ILSOS_PrismaticRD_PTOP 아키텍처 검토 보고서
|
||||
|
||||
## 1. 3계층 아키텍처
|
||||
|
||||
```
|
||||
┌──────────────────────────────┐
|
||||
│ WPF UI Layer │
|
||||
│ (Views/, ViewModels/) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Machine Logic Layer │
|
||||
│ (EquipmentSetup, Sequences) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Device Abstraction │
|
||||
│ (AuroraDevices) │
|
||||
└──────────────┬───────────────┘
|
||||
↓
|
||||
┌──────────────────────────────┐
|
||||
│ Hardware Layer │
|
||||
│ (PLC, Laser, OCT, etc.) │
|
||||
└──────────────────────────────┘
|
||||
```
|
||||
|
||||
## 2. 핵심 컴포넌트
|
||||
|
||||
### EquipDef & EquipmentSetup
|
||||
- [EquipDef 매핑 표]
|
||||
- [빌드되는 시퀀스 목록]
|
||||
|
||||
### Sequences
|
||||
- [시퀀스 관계도]
|
||||
- [SeqAutoRunPTOP 상태 머신]
|
||||
|
||||
### Device
|
||||
- [PLC 신호 맵핑]
|
||||
- [IO 신호 맵핑]
|
||||
|
||||
## 3. Rx.NET 이벤트 흐름
|
||||
|
||||
[파이프라인 다이어그램]
|
||||
|
||||
## 4. 발견 사항 & 개선 사항
|
||||
|
||||
| 우선순위 | 항목 | 현황 | 개선안 |
|
||||
|---------|------|------|--------|
|
||||
| P0 | | | |
|
||||
| P1 | | | |
|
||||
|
||||
```
|
||||
|
||||
## 입력 조건
|
||||
|
||||
사용자가 다음과 같이 요청할 때:
|
||||
- "PTOP 아키텍처 분석해줘"
|
||||
- "PTOP 전체 구조 파악"
|
||||
- "SeqAutoRunPTOP이 어떻게 동작하는지 분석"
|
||||
- "PTOP에서 PLC, Laser, OCT가 어떻게 연결되어있는지"
|
||||
- "PTOP 3계층 아키텍처 검증"
|
||||
|
||||
## 출력 결과
|
||||
|
||||
- 5개 상세 분석 문서 (`_workspace/01a~01e_*.md`)
|
||||
- 통합 보고서 (`_workspace/01_ptop_architecture.md`)
|
||||
- 다이어그램 (3계층, 상태 머신, 이벤트 흐름)
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **코드 읽기 능력이 중요** — C#, WPF, Rx.NET 이해 필수
|
||||
2. **불명확한 부분은 기록** — "이 부분은 왜 이렇게?"라는 질문을 명시
|
||||
3. **Namespace 혼동 주의** — ILSOS_PrismaticRD_PTOP의 코드가 ILSOS_PrismaticScanner 네임스페이스 사용
|
||||
4. **260605 변경 이후 상태 파악** — SeqAutoRunPTOP이 최신 메인 시퀀스
|
||||
5. **한글 주석 인코딩** — CODING_RULES.md 확인
|
||||
@ -1,209 +0,0 @@
|
||||
---
|
||||
name: analyze-ptop-implementation
|
||||
description: 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 병렬)
|
||||
- 예상 소요시간?
|
||||
- 다음 상태로의 전이 신호는 어디서 오는가?
|
||||
|
||||
**추적 대상:**
|
||||
1. **PLC 호출**
|
||||
- 읽기: PLC.ReadBool("M10"), PLC.ReadInt("D20"), etc.
|
||||
- 쓰기: PLC.WriteBool("M5", true), PLC.WriteInt("D15", 100), etc.
|
||||
- 대기: PLC 상태 폴링, 신호 기다리기
|
||||
|
||||
2. **Laser 제어**
|
||||
- 활성화 (SetPower, SetFrequency, etc.)
|
||||
- 대기
|
||||
- 정상 종료
|
||||
|
||||
3. **OCT 스캔**
|
||||
- 스캔 시작
|
||||
- 데이터 수집
|
||||
- 스캔 종료
|
||||
|
||||
4. **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)
|
||||
|
||||
**예시:**
|
||||
```csharp
|
||||
// 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`
|
||||
|
||||
```markdown
|
||||
# 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 메시지 흐름도
|
||||
- 에러 처리 매트릭스
|
||||
- 성능 프로파일
|
||||
- 최종 분석 보고서
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **코드 라인 번호 기록** — "Line 245의 try-catch" 형식으로 정확한 위치 기록
|
||||
2. **데이터 흐름 추적** — 변수, 반환값을 따라가며 이해
|
||||
3. **시간 측정** — Thread.Sleep() / Task.Delay() / TimeSpan 찾기
|
||||
4. **예외 처리** — Exception 타입별로 분류
|
||||
5. **불명확한 부분 기록** — 추측 금지, 명시적으로 "불명확함" 표시
|
||||
@ -1,248 +0,0 @@
|
||||
---
|
||||
name: optimize-ptop-build
|
||||
description: ILSOS_PrismaticRD_PTOP의 빌드 최적화 및 CI/CD 자동화. 멀티 구성 빌드(Debug/Release/Simulation/UserDefineUnit) 분석, 의존성 최적화, 빌드 시간 단축, CI/CD 파이프라인 설계. "빌드 최적화", "PTOP 빌드 성능", "CI/CD 자동화 설계", "배포 파이프라인" 요청 시 사용.
|
||||
---
|
||||
|
||||
# Optimize PTOP Build Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **빌드 성능 및 자동화**를 최적화한다.
|
||||
|
||||
## 분석 영역
|
||||
|
||||
### 1단계: 현재 빌드 상태 분석
|
||||
|
||||
**수집 대상:**
|
||||
- 솔루션 내 프로젝트 목록 (ILSOS_All.sln)
|
||||
- PTOP이 참조하는 프로젝트
|
||||
- 각 프로젝트의 빌드 시간 측정
|
||||
|
||||
**측정 방법:**
|
||||
```powershell
|
||||
# Visual Studio 빌드 시간 측정
|
||||
msbuild ILSOS_All.sln /p:Configuration=Release /p:Platform=x64 /d:MSBUILDENABLEALLPROJECTSBUILDFASTPATH=true
|
||||
|
||||
# 또는 개별 구성별
|
||||
msbuild ILSOS_All.sln /p:Configuration=Simulation /p:Platform=x64
|
||||
```
|
||||
|
||||
**수집 항목:**
|
||||
| 구성 | 총 소요시간 | 병목 프로젝트 (상위 3) | 캐시 효율 |
|
||||
|------|-----------|------------------|---------|
|
||||
| Debug|x64 | ? | ? | ? |
|
||||
| Release|x64 | ? | ? | ? |
|
||||
| Simulation|x64 | ? | ? | ? |
|
||||
| UserDefineUnit|x64 | ? | ? | ? |
|
||||
|
||||
### 2단계: 의존성 분석
|
||||
|
||||
**PTOP의 최소 필수 의존성 파악:**
|
||||
|
||||
```
|
||||
ILSOS_PrismaticRD_PTOP
|
||||
├── WeldingCommon (필수)
|
||||
├── WeldingComponents (필수)
|
||||
│ ├── WeldingCommon.dll
|
||||
│ ├── LASAGUI (용접 GUI)
|
||||
│ └── ...
|
||||
├── AuroraDevices (선택적)
|
||||
│ ├── AuroraLaser (필수 - Laser 제어)
|
||||
│ ├── AuroraOCT (필수 - OCT 스캔)
|
||||
│ ├── AuroraPLC (필수 - PLC 통신)
|
||||
│ ├── AuroraIO (필수 - IO 제어)
|
||||
│ ├── AuroraCellTracker (필수 - 셀 추적)
|
||||
│ ├── AuroraLBAD (?)
|
||||
│ └── ... (기타 22개 중 필요 없는 것?)
|
||||
├── AuroraComponents (필수)
|
||||
├── AuroraVision (필요하나?)
|
||||
└── NuGet 패키지 (Reactive, Json.NET, etc.)
|
||||
```
|
||||
|
||||
**분석:**
|
||||
- 각 AuroraDevices 프로젝트의 실제 사용 여부
|
||||
- 제거 가능한 의존성
|
||||
- 조건부 컴파일 가능성 (#if DEBUG 등)
|
||||
|
||||
**산출물:** `_workspace/04a_dependency_analysis.csv`
|
||||
|
||||
### 3단계: 빌드 구성별 최적화
|
||||
|
||||
#### Debug|x64 최적화
|
||||
- 기호 생성 필요 (유지)
|
||||
- 최적화 비활성화 (유지)
|
||||
- 증분 빌드 활용
|
||||
|
||||
#### Release|x64 최적화
|
||||
```xml
|
||||
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
|
||||
<Optimize>true</Optimize> <!-- 최적화 활성화 -->
|
||||
<DebugType>embedded</DebugType> <!-- 기호 축소 -->
|
||||
<TieredCompilation>true</TieredCompilation> <!-- .NET 4.8.1 지원하나? -->
|
||||
<PublishTrimmed>true</PublishTrimmed> <!-- 불필요 어셈블리 제거 -->
|
||||
</PropertyGroup>
|
||||
```
|
||||
|
||||
#### Simulation|x64 최적화
|
||||
```csharp
|
||||
#if SIMULATION
|
||||
// 하드웨어 통신 불필요 - 모의 구현 사용
|
||||
public class MockPLC : IPLC { ... }
|
||||
#endif
|
||||
```
|
||||
|
||||
#### UserDefineUnit|x64 최적화
|
||||
- 용도 파악 필요 (단위 테스트? 커스텀 하드웨어?)
|
||||
- 필요한 기능만 포함
|
||||
|
||||
### 4단계: CI/CD 파이프라인 설계
|
||||
|
||||
**목표:**
|
||||
- 자동 빌드 (commit, PR)
|
||||
- 자동 테스트 (Simulation 구성)
|
||||
- 자동 배포 (수동 승인)
|
||||
|
||||
**추천 플랫폼:**
|
||||
- GitHub Actions (GitHub 저장소 사용 중 가정)
|
||||
- Azure Pipelines (Microsoft 클라우드)
|
||||
- Jenkins (온프레미스)
|
||||
|
||||
**파이프라인 구조:**
|
||||
```yaml
|
||||
# .github/workflows/ptop-build.yml
|
||||
name: PTOP Build & Deploy
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main, develop]
|
||||
paths: ['Machines/ILSOS_PrismaticRD_PTOP/**']
|
||||
pull_request:
|
||||
branches: [main]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: windows-latest
|
||||
strategy:
|
||||
matrix:
|
||||
config: [Debug, Release, Simulation]
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
- name: Setup .NET Framework
|
||||
uses: microsoft/setup-msbuild@v1
|
||||
- name: Restore NuGet
|
||||
run: nuget restore ILSOS_All.sln
|
||||
- name: Build (${{ matrix.config }})
|
||||
run: msbuild ILSOS_All.sln /p:Configuration=${{ matrix.config }} /p:Platform=x64
|
||||
- name: Run Tests (Simulation only)
|
||||
if: matrix.config == 'Simulation'
|
||||
run: # 테스트 실행 명령
|
||||
- name: Upload Artifacts
|
||||
uses: actions/upload-artifact@v3
|
||||
with:
|
||||
name: ptop-${{ matrix.config }}
|
||||
path: Machines/_out_prismatic_rd_ptop/x64-${{ matrix.config }}/
|
||||
|
||||
deploy:
|
||||
needs: build
|
||||
runs-on: windows-latest
|
||||
if: github.ref == 'refs/heads/main'
|
||||
environment: production # 수동 승인 필수
|
||||
steps:
|
||||
- name: Download Release Artifact
|
||||
- name: Create Release Package
|
||||
run: # 패키징 스크립트
|
||||
- name: Deploy to Server
|
||||
run: # 배포 스크립트
|
||||
```
|
||||
|
||||
### 5단계: 배포 패키징
|
||||
|
||||
**산출물:**
|
||||
- 실행 가능 파일 (Aurora.exe)
|
||||
- 필수 DLL (AuroraDevices, WeldingComponents, etc.)
|
||||
- 설정 파일 (app.config)
|
||||
- 리소스 파일 (이미지, 데이터)
|
||||
- 배포 설명서
|
||||
|
||||
**패키징 형식:**
|
||||
- ZIP 아카이브 (간단)
|
||||
- NSIS 설치 프로그램 (사용자 친화적)
|
||||
- Chocolatey 패키지 (자동 업데이트)
|
||||
|
||||
## 통합 산출물
|
||||
|
||||
### 최종 보고서: `_workspace/04_ptop_build_optimization.md`
|
||||
|
||||
```markdown
|
||||
# PTOP 빌드 최적화 보고서
|
||||
|
||||
## 1. 현재 빌드 성능
|
||||
|
||||
| 구성 | 시간 | 병목 | 개선 가능성 |
|
||||
|------|------|------|----------|
|
||||
| Debug|x64 | 45s | ? | 개선 중심 |
|
||||
| Release|x64 | 60s | ? | 최적화 중심 |
|
||||
| Simulation|x64 | 50s | ? | 테스트 환경 |
|
||||
| UserDefineUnit|x64 | 55s | ? | 커스텀 |
|
||||
|
||||
## 2. 의존성 최적화
|
||||
|
||||
### 필수 의존성
|
||||
- AuroraLaser, AuroraOCT, AuroraPLC, etc.
|
||||
|
||||
### 제거 가능 의존성
|
||||
- ...
|
||||
|
||||
## 3. 빌드 구성별 최적화 전략
|
||||
|
||||
### Debug
|
||||
- 현황: [상태]
|
||||
- 개선안: [목표]
|
||||
- 예상 효과: [시간 단축]
|
||||
|
||||
### Release
|
||||
- ...
|
||||
|
||||
### Simulation
|
||||
- ...
|
||||
|
||||
## 4. CI/CD 파이프라인
|
||||
|
||||
[YAML 파일 포함]
|
||||
|
||||
## 5. 배포 패키징
|
||||
|
||||
[패키징 스크립트]
|
||||
|
||||
## 6. 예상 효과
|
||||
|
||||
- 빌드 시간: XX% 단축
|
||||
- 배포 시간: XX% 단축
|
||||
- 자동화: 수동 작업 제거
|
||||
```
|
||||
|
||||
## 입력 조건
|
||||
|
||||
사용자 요청 시:
|
||||
- "PTOP 빌드 최적화"
|
||||
- "빌드 시간 단축"
|
||||
- "CI/CD 파이프라인 설계"
|
||||
- "배포 자동화"
|
||||
- "Release 빌드 성능"
|
||||
|
||||
## 출력 결과
|
||||
|
||||
- 빌드 성능 분석 보고서
|
||||
- 의존성 맵핑 CSV
|
||||
- CI/CD 파이프라인 (YAML/JSON)
|
||||
- 빌드 최적화 설정 (PropertyGroup)
|
||||
- 배포 패키징 스크립트
|
||||
- 최종 보고서
|
||||
|
||||
## 주의사항
|
||||
|
||||
1. **.NET Framework 4.8.1 호환성** — 최신 .NET 기능 사용 불가
|
||||
2. **Visual Studio 2022 기준** — MSBuild 경로 확인
|
||||
3. **Windows 플랫폼 전용** — x64 아키텍처 명시
|
||||
4. **빌드 머신 사양** — CI 환경의 OS/RAM 확인
|
||||
5. **라이선스 확인** — NuGet 패키지, 외부 도구의 라이선스
|
||||
@ -1,286 +0,0 @@
|
||||
---
|
||||
name: orchestrate-ptop-harness
|
||||
description: ILSOS_PrismaticRD_PTOP 개발 팀의 오케스트레이터. 3명 팀원(PTOP Lead, PTOP Developer, Build/DevOps Engineer)의 작업을 조율하고 아키텍처 분석, 구현 분석, 빌드 최적화를 통합 진행. "PTOP 프로젝트 종합 분석", "PTOP 전체 점검", "PTOP 하네스 시작", "PTOP 팀 조율" 요청 시 사용.
|
||||
---
|
||||
|
||||
# Orchestrate PTOP Harness Skill
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 **3계층 아키텍처**, **구현 상세**, **빌드 최적화**를 **병렬 분석**하여 팀원들이 조율하며 통합 보고서를 완성한다.
|
||||
|
||||
## 실행 모드
|
||||
|
||||
**에이전트 팀** (팀 조율 활성화)
|
||||
|
||||
```
|
||||
[오케스트레이터]
|
||||
├─ TeamCreate(team=[PTOP Lead, PTOP Developer, Build/DevOps Engineer])
|
||||
├─ Phase 1: 초기 컨텍스트 확인
|
||||
├─ Phase 2: 병렬 분석 작업 할당 (TaskCreate + 팀원 간 SendMessage)
|
||||
├─ Phase 3: 결과 수집 및 통합
|
||||
├─ Phase 4: 최종 검증
|
||||
└─ Phase 5: 팀 해제
|
||||
```
|
||||
|
||||
## 워크플로우
|
||||
|
||||
### Phase 1: 초기 컨텍스트 확인 (5분)
|
||||
|
||||
**수행 항목:**
|
||||
1. `_workspace/` 디렉토리 존재 여부 확인
|
||||
- 존재 → 기존 분석 파일 로드, 부분 재실행 검토
|
||||
- 미존재 → 새 작업 시작
|
||||
|
||||
2. 기존 분석이 있으면:
|
||||
- 이전 PTOP Lead의 보고서 검토
|
||||
- PTOP Developer의 발견사항 검토
|
||||
- Build Engineer의 개선안 검토
|
||||
- → 파일을 `_workspace_prev/`로 이동 후 신규 분석 진행
|
||||
|
||||
**산출:**
|
||||
- Phase 1 진행 상황 (TaskCreate 할당)
|
||||
|
||||
### Phase 2: 병렬 분석 작업 할당 (15~20분)
|
||||
|
||||
**TaskCreate 3개 발행:**
|
||||
|
||||
#### Task 2-1: PTOP Lead — 아키텍처 분석
|
||||
```
|
||||
Role: PTOP Lead
|
||||
Task: analyze-ptop-architecture 스킬 실행
|
||||
Input:
|
||||
- ILSOS_PrismaticRD_PTOP 소스 전체
|
||||
- CLAUDE.md 프로젝트 컨텍스트
|
||||
Output:
|
||||
- _workspace/01a_equipdef_analysis.md
|
||||
- _workspace/01b_sequences_analysis.md
|
||||
- _workspace/01c_device_analysis.md
|
||||
- _workspace/01d_rxnet_analysis.md
|
||||
- _workspace/01e_device_integration.md
|
||||
- _workspace/01_ptop_architecture.md (통합)
|
||||
Deadline: 20분
|
||||
Status: in_progress
|
||||
```
|
||||
|
||||
#### Task 2-2: PTOP Developer — 구현 분석
|
||||
```
|
||||
Role: PTOP Developer
|
||||
Task: analyze-ptop-implementation 스킬 실행
|
||||
Input:
|
||||
- PTOP Lead의 01_ptop_architecture.md (참고)
|
||||
- SeqAutoRunPTOP.cs, Device/* 소스
|
||||
Output:
|
||||
- _workspace/02_ptop_implementation.md (상태 머신, 타이밍, 에러 처리 포함)
|
||||
Dependencies: Task 2-1의 아키텍처 정의 완료 후 진행
|
||||
Deadline: 20분
|
||||
Status: blocked (대기)
|
||||
```
|
||||
|
||||
#### Task 2-3: Build/DevOps Engineer — 빌드 최적화
|
||||
```
|
||||
Role: Build/DevOps Engineer
|
||||
Task: optimize-ptop-build 스킬 실행
|
||||
Input:
|
||||
- ILSOS_All.sln 파일
|
||||
- 현재 빌드 환경 정보
|
||||
Output:
|
||||
- _workspace/04a_dependency_analysis.csv
|
||||
- _workspace/04_ptop_build_optimization.md (CI/CD 파이프라인 포함)
|
||||
Status: in_progress (독립적)
|
||||
Deadline: 15분
|
||||
```
|
||||
|
||||
**병렬 실행 전략:**
|
||||
- Task 2-1과 2-3은 독립적 → 동시 진행
|
||||
- Task 2-2는 Task 2-1 결과 참고 필요 → 순차
|
||||
|
||||
**팀 통신:**
|
||||
```
|
||||
[오케스트레이터 → PTOP Lead]
|
||||
"아키텍처 분석 시작. 20분 안에 01_ptop_architecture.md 완성 부탁."
|
||||
|
||||
[오케스트레이터 → PTOP Developer]
|
||||
"PTOP Lead의 아키텍처 분석 대기 중. 시작 신호 받으면 구현 분석 시작할 것."
|
||||
|
||||
[오케스트레이터 → Build/DevOps Engineer]
|
||||
"빌드 최적화 분석 시작. 15분 안에 04_ptop_build_optimization.md 완성 부탁."
|
||||
```
|
||||
|
||||
### Phase 3: 중간 체크포인트 (10분)
|
||||
|
||||
**T+10분 타이밍:**
|
||||
```
|
||||
[오케스트레이터]
|
||||
- PTOP Lead의 01_ptop_architecture.md 완성 확인
|
||||
- Build/DevOps Engineer의 진행상황 확인
|
||||
|
||||
[PTOP Developer에게 GO신호 발행]
|
||||
"PTOP Lead의 아키텍처 분석 완료. 이제 구현 분석 시작해주세요."
|
||||
```
|
||||
|
||||
**SendMessage 패턴:**
|
||||
```
|
||||
[오케스트레이터 → PTOP Lead, PTOP Developer]
|
||||
"두 분석의 연계 포인트를 확인해주세요.
|
||||
- 아키텍처에서 정의한 3계층이 구현에 제대로 반영되었나?
|
||||
- 의도하지 않은 구조가 있나?"
|
||||
```
|
||||
|
||||
### Phase 4: 결과 수집 (5분)
|
||||
|
||||
**수행 항목:**
|
||||
1. 3개 분석 결과 파일 모두 완성 확인
|
||||
2. 각 팀원의 발견사항 요약 요청 (SendMessage)
|
||||
|
||||
```
|
||||
[오케스트레이터 → 각 팀원]
|
||||
"분석 완료되셨나요? 가장 중요한 발견 3개를 나열해주세요."
|
||||
|
||||
PTOP Lead의 응답:
|
||||
1. SeqAutoRunPTOP이 메인 시퀀스이고 260605에 추가됨
|
||||
2. PLC, Laser, OCT, CellTracker 모두 필수 디바이스
|
||||
3. Rx.NET 메시지 흐름이 복잡 - 개선 필요
|
||||
|
||||
PTOP Developer의 응답:
|
||||
1. 상태 머신이 명확하지 않은 부분 발견 (XXX)
|
||||
2. PLC 호출 순서가 타이밍 크리티컬
|
||||
3. OCT 스캔 시간 최적화 기회
|
||||
|
||||
Build/DevOps Engineer의 응답:
|
||||
1. Release 빌드가 Debug보다 20% 느림
|
||||
2. AuroraDevices 중 불필요한 프로젝트 5개 발견
|
||||
3. CI/CD 파이프라인 설계 완료
|
||||
```
|
||||
|
||||
### Phase 5: 통합 보고서 생성 (10분)
|
||||
|
||||
**오케스트레이터가 종합:**
|
||||
|
||||
`_workspace/00_PTOP_HARNESS_SUMMARY.md` 생성
|
||||
|
||||
```markdown
|
||||
# ILSOS_PrismaticRD_PTOP 하네스 분석 — 종합 보고서
|
||||
|
||||
**분석 일시:** [날짜]
|
||||
**팀원:** PTOP Lead, PTOP Developer, Build/DevOps Engineer
|
||||
**총 소요시간:** ~50분
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
ILSOS_PrismaticRD_PTOP은 [간단 설명]
|
||||
|
||||
### 주요 발견
|
||||
|
||||
#### 아키텍처 (PTOP Lead)
|
||||
- 3계층 구조 검증 완료
|
||||
- 핵심 컴포넌트: [리스트]
|
||||
- 개선 우선순위: [P0, P1, P2]
|
||||
|
||||
#### 구현 (PTOP Developer)
|
||||
- 상태 머신 분석 완료
|
||||
- 성능 병목: [리스트]
|
||||
- 안정성 이슈: [리스트]
|
||||
|
||||
#### 빌드 (Build/DevOps Engineer)
|
||||
- 빌드 성능: [현황]
|
||||
- 의존성 최적화: [개선안]
|
||||
- CI/CD: [설계 완료]
|
||||
|
||||
---
|
||||
|
||||
## 상세 분석
|
||||
|
||||
### 1. 아키텍처
|
||||
[01_ptop_architecture.md 요약]
|
||||
|
||||
### 2. 구현
|
||||
[02_ptop_implementation.md 요약]
|
||||
|
||||
### 3. 빌드 & DevOps
|
||||
[04_ptop_build_optimization.md 요약]
|
||||
|
||||
---
|
||||
|
||||
## 종합 권장사항
|
||||
|
||||
| 우선순위 | 항목 | 담당 | 예상 공수 |
|
||||
|---------|------|------|---------|
|
||||
| P0 | [긴급] | PTOP Developer | ? |
|
||||
| P1 | [중요] | PTOP Lead | ? |
|
||||
| P2 | [개선] | Build/DevOps Engineer | ? |
|
||||
|
||||
---
|
||||
|
||||
## 다음 단계
|
||||
|
||||
1. 이 보고서 검토 (팀 + 사용자)
|
||||
2. P0 항목 즉시 대응
|
||||
3. P1 항목 일정 수립
|
||||
4. P2 항목 백로그 등록
|
||||
|
||||
---
|
||||
|
||||
## 부록
|
||||
|
||||
- [분석 파일 목록]
|
||||
- [팀 통신 기록]
|
||||
- [시간 로그]
|
||||
```
|
||||
|
||||
### Phase 6: 팀 정리 및 후속 계획
|
||||
|
||||
```
|
||||
[오케스트레이터]
|
||||
✓ 팀 해제 (TeamDelete)
|
||||
✓ 최종 보고서 제출
|
||||
→ 사용자에게 결과 요약 제시
|
||||
|
||||
[사용자에게 제시]
|
||||
"PTOP 하네스 분석 완료. 주요 발견:
|
||||
1. 아키텍처: 3계층 구조 검증 완료 (문서: 01_ptop_architecture.md)
|
||||
2. 구현: 상태 머신 분석, 성능 병목 식별 (문서: 02_ptop_implementation.md)
|
||||
3. 빌드: 최적화 기회 발견, CI/CD 설계 완료 (문서: 04_ptop_build_optimization.md)
|
||||
|
||||
다음 단계: 보고서 검토 → P0 항목 대응"
|
||||
```
|
||||
|
||||
## 데이터 전달 프로토콜
|
||||
|
||||
| 전달 객체 | 방식 | 용도 |
|
||||
|----------|------|------|
|
||||
| 팀원 간 작업 결과 | 파일 (_workspace/) | 아키텍처 → 구현 분석 의존성 |
|
||||
| 팀원 간 실시간 소통 | SendMessage | 질문, 상충 해결, 진행상황 |
|
||||
| 최종 산출물 | 통합 보고서 + 세부 파일 | 사용자 제시 |
|
||||
|
||||
## 에러 핸들링
|
||||
|
||||
| 상황 | 처리 방식 |
|
||||
|------|---------|
|
||||
| 팀원 분석 지연 | 진행상황 확인, 추가 시간 할당 |
|
||||
| 팀원 간 의견 상충 | SendMessage로 토론, 양쪽 견해 모두 기록 |
|
||||
| 코드 이해 불가 | 해당 부분을 "불명확" 표시하고 진행 |
|
||||
| 분석 결과 불완전 | 세부 파일에 "TODO" 표시, 최종 보고서에 명시 |
|
||||
|
||||
## 성공 기준
|
||||
|
||||
- [ ] 5개 세부 분석 문서 완성 (01a~01e, 02, 04a, 04)
|
||||
- [ ] 3개 팀원 모두 할당된 작업 완료
|
||||
- [ ] 통합 보고서 (00_PTOP_HARNESS_SUMMARY.md) 생성
|
||||
- [ ] 주요 발견사항 3개 이상 도출
|
||||
- [ ] 권장사항(P0/P1/P2)이 명확히 기술됨
|
||||
- [ ] 모든 분석이 코드 레퍼런스와 함께 기술됨
|
||||
- [ ] 팀원 간 의견 상충 없이 완료되거나, 상충이 있으면 명시적으로 기록됨
|
||||
|
||||
## 후속 작업
|
||||
|
||||
이 하네스는 초기 분석이며, 이후:
|
||||
- P0 항목 대응 후 재검토
|
||||
- P1 항목 진행 중 코드 리뷰 (별도 하네스)
|
||||
- P2 항목 백로그 관리
|
||||
|
||||
**재실행 트리거:**
|
||||
- 사용자가 "PTOP 재분석", "PTOP 상태 업데이트" 요청 시
|
||||
- 주요 코드 변경 후 영향도 분석 필요 시
|
||||
58
CLAUDE.md
58
CLAUDE.md
@ -1,58 +0,0 @@
|
||||
# ILSOS 프로젝트 — Claude 초기 컨텍스트
|
||||
|
||||
## 목차
|
||||
|
||||
1. [프로젝트 문서](#1-프로젝트-문서)
|
||||
2. [협업 규칙](#2-협업-규칙)
|
||||
3. [하네스](#3-하네스)
|
||||
4. [Aurora 프레임워크 레퍼런스](#4-aurora-프레임워크-레퍼런스)
|
||||
|
||||
---
|
||||
|
||||
## 1. 프로젝트 문서
|
||||
|
||||
@./docs/architecture.md
|
||||
> 프로젝트 개요, 솔루션 구조, PTOP 아키텍처, 디바이스, 빌드, 하네스 통합 문서
|
||||
|
||||
---
|
||||
|
||||
## 2. 협업 규칙
|
||||
|
||||
@./rules.md
|
||||
|
||||
---
|
||||
|
||||
## 3. 하네스
|
||||
|
||||
에이전트 정의는 `.claude/agents/`, 스킬은 `.claude/skills/`에 둔다. 다른 경로에 두면 로딩되지 않는다.
|
||||
|
||||
**트리거 규칙 — 요청을 아래로 라우팅한다. 단순 질문은 직접 응답 가능.**
|
||||
|
||||
| 요청 | 스킬 |
|
||||
|---|---|
|
||||
| PTOP 아키텍처·구현·빌드 **분석** ("PTOP 전체 점검", "PTOP 재분석") | `orchestrate-ptop-harness` |
|
||||
| Ubisam **산출물** 생성·재생산 ("산출물 만들어줘", "Ubisam 양식으로") | 입력에 따라 분기 → `docs/harness-ubisam.md` |
|
||||
| PTOP **코드를 실제로 수정** | `code_Agent` (분석 하네스 아님. **사용자 전역 스킬** — 이 저장소에는 없다) |
|
||||
| 화면 레이아웃 도식 이미지 | `ui_layout_image` |
|
||||
| 작업일지 기록 | `doyeon_note` |
|
||||
|
||||
산출물 요청에 **대상이 명시되지 않으면**(예: "산출물 업데이트해줘") 어떤 스킬도 바로 실행하지 말고
|
||||
소스코드인지·기존 문서인지·트리 생성인지를 먼저 되묻는다.
|
||||
대상 없는 **"다시 실행"·"업데이트"·"보완"** 만으로는 어떤 하네스도 기동하지 않는다 —
|
||||
무엇을 다시 실행할지 먼저 묻는다.
|
||||
|
||||
@./docs/harness-ptop.md
|
||||
> PTOP 분석 하네스(팀 구성, 트리거, 구성 요소, 변경 이력)
|
||||
@./docs/harness-ubisam.md
|
||||
> Ubisam 산출물 하네스(스킬 선택 기준, 팀 구성, 변경 이력)
|
||||
|
||||
---
|
||||
|
||||
## 4. Aurora 프레임워크 레퍼런스
|
||||
|
||||
Aurora 2.0 개발 규칙·API·패턴을 토큰 최소로 찾기 위한 인덱스형 지식베이스. Aurora 관련 작업(디바이스·시퀀스·PLC·ViewModel·빌드) 시 아래 README의 라우팅 표를 먼저 본다.
|
||||
|
||||
@./docs/Aurora에이전트레퍼런스모음/README.md
|
||||
> Aurora 레퍼런스 인덱스(라우팅 허브) → 01_concepts / 02_patterns / 03_gotchas …
|
||||
> ⚠ 이 폴더는 `.gitignore` 제외(로컬 전용)라 clone 직후에는 없다. 없으면 이 임포트는 조용히 비고,
|
||||
> Aurora 질문은 `External/Aurora/Aurora2.0_Guide.pdf`와 소스 코드로 직접 확인해야 한다.
|
||||
92
README.md
92
README.md
@ -1,92 +0,0 @@
|
||||
# ILSOS
|
||||
|
||||
|
||||
|
||||
## Getting started
|
||||
|
||||
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
|
||||
|
||||
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
|
||||
|
||||
## Add your files
|
||||
|
||||
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
|
||||
- [ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
|
||||
|
||||
```
|
||||
cd existing_repo
|
||||
git remote add origin http://mod.lge.com/hub/sungkyun.cho/ilsos.git
|
||||
git branch -M main
|
||||
git push -uf origin main
|
||||
```
|
||||
|
||||
## Integrate with your tools
|
||||
|
||||
- [ ] [Set up project integrations](http://mod.lge.com/hub/sungkyun.cho/ilsos/-/settings/integrations)
|
||||
|
||||
## Collaborate with your team
|
||||
|
||||
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
|
||||
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
|
||||
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
|
||||
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
|
||||
- [ ] [Automatically merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html)
|
||||
|
||||
## Test and Deploy
|
||||
|
||||
Use the built-in continuous integration in GitLab.
|
||||
|
||||
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
|
||||
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing(SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
|
||||
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
|
||||
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
|
||||
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
|
||||
|
||||
***
|
||||
|
||||
# Editing this README
|
||||
|
||||
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thank you to [makeareadme.com](https://www.makeareadme.com/) for this template.
|
||||
|
||||
## Suggestions for a good README
|
||||
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
|
||||
|
||||
## Name
|
||||
Choose a self-explaining name for your project.
|
||||
|
||||
## Description
|
||||
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
|
||||
|
||||
## Badges
|
||||
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
|
||||
|
||||
## Visuals
|
||||
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
|
||||
|
||||
## Installation
|
||||
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
|
||||
|
||||
## Usage
|
||||
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
|
||||
|
||||
## Support
|
||||
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
|
||||
|
||||
## Roadmap
|
||||
If you have ideas for releases in the future, it is a good idea to list them in the README.
|
||||
|
||||
## Contributing
|
||||
State if you are open to contributions and what your requirements are for accepting them.
|
||||
|
||||
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
|
||||
|
||||
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
|
||||
|
||||
## Authors and acknowledgment
|
||||
Show your appreciation to those who have contributed to the project.
|
||||
|
||||
## License
|
||||
For open source projects, say how it is licensed.
|
||||
|
||||
## Project status
|
||||
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
|
||||
@ -1,115 +0,0 @@
|
||||
# 코딩 규칙 — ILSOS 프로젝트
|
||||
|
||||
## 1. 파일 인코딩 규칙 (필수)
|
||||
|
||||
### 규칙: 모든 C# / XAML / 텍스트 파일은 UTF-8 with BOM + CRLF
|
||||
|
||||
이 프로젝트의 모든 소스 파일은 **UTF-8 with BOM** 인코딩과 **CRLF** 줄바꿈을 사용한다.
|
||||
Visual Studio 2022가 기본으로 생성하는 방식이며, 한글이 포함된 주석/문자열이 깨지지 않으려면 반드시 이를 지켜야 한다.
|
||||
|
||||
```
|
||||
인코딩: UTF-8 with BOM (BOM = EF BB BF)
|
||||
줄바꿈: CRLF (\r\n)
|
||||
```
|
||||
|
||||
### Claude가 파일을 생성/수정할 때 지켜야 할 사항
|
||||
|
||||
#### 파일 신규 생성 시
|
||||
- `Write` 도구로 파일을 생성한 뒤, **반드시** 아래 Python 명령으로 BOM을 추가하고 CRLF로 변환한다.
|
||||
|
||||
```bash
|
||||
python3 -c "
|
||||
import sys
|
||||
path = r'생성한_파일_경로.cs'
|
||||
with open(path, 'r', encoding='utf-8') as f:
|
||||
content = f.read()
|
||||
content = content.replace('\r\n', '\n').replace('\n', '\r\n')
|
||||
with open(path, 'wb') as f:
|
||||
f.write(b'\xef\xbb\xbf') # UTF-8 BOM
|
||||
f.write(content.encode('utf-8'))
|
||||
"
|
||||
```
|
||||
|
||||
#### 기존 파일 수정 시
|
||||
- `Edit` 도구로 파일을 수정한 경우, BOM과 CRLF는 기존 파일에 유지된다.
|
||||
단, Edit 도구가 BOM을 제거하거나 LF로 변경한 경우에는 위 Python 명령으로 복구한다.
|
||||
|
||||
#### 수정 후 인코딩 검증
|
||||
```bash
|
||||
python3 -c "
|
||||
with open(r'파일경로.cs', 'rb') as f:
|
||||
raw = f.read(3)
|
||||
print('BOM 존재:', raw == b'\xef\xbb\xbf') # True여야 함
|
||||
"
|
||||
|
||||
file 파일경로.cs
|
||||
# 출력에 'UTF-8 (with BOM)' 및 'CRLF' 포함되어야 함
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. 한글 깨짐 방지 체크리스트
|
||||
|
||||
파일을 생성하거나 수정한 후 아래를 확인한다.
|
||||
|
||||
- [ ] `file` 명령 출력에 `UTF-8 (with BOM)` 포함
|
||||
- [ ] `file` 명령 출력에 `CRLF` 포함
|
||||
- [ ] 파일 첫 3바이트가 `EF BB BF` (BOM)
|
||||
- [ ] 한글 주석/문자열이 포함된 경우 Visual Studio에서 열어 깨짐 여부 확인
|
||||
|
||||
---
|
||||
|
||||
## 3. 네이밍 컨벤션
|
||||
|
||||
### 클래스/메서드
|
||||
- **PascalCase**: `SequenceManager`, `EquipmentSetup`, `SeqAutoRunPTOP`
|
||||
|
||||
### 필드/변수
|
||||
- **private 필드**: `_camelCase` (언더스코어 접두사)
|
||||
예) `_acs`, `_plc`, `_ajin`
|
||||
- **지역 변수**: `camelCase`
|
||||
|
||||
### 파일명
|
||||
- 클래스명과 동일하게 유지
|
||||
- Stage 구분: `StageA` / `StageB` 접미사
|
||||
|
||||
---
|
||||
|
||||
## 4. 시퀀스 작성 규칙
|
||||
|
||||
### ID 등록
|
||||
- 새 시퀀스/디바이스/레시피/뷰 추가 시 **반드시** `EquipDef.cs`의 해당 ID 클래스에 상수를 먼저 등록한다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 디바이스 추가 규칙
|
||||
|
||||
1. `EquipDef.cs` → `DeviceIds` 상수 추가
|
||||
2. `EquipmentSetup.cs` → 디바이스 인스턴스 생성 및 이벤트 구독
|
||||
3. `EquipmentSetup.cs` → `BuildMainStatusView()`에 상태 항목 추가
|
||||
4. 필요 시 `AuroraDevices/` 하위에 새 디바이스 프로젝트 생성
|
||||
|
||||
---
|
||||
|
||||
## 6. 주석 작성
|
||||
|
||||
- 한글 주석 사용 권장 (팀 내부 프로젝트)
|
||||
- 주석에 한글이 포함되는 파일은 인코딩 규칙(섹션 1) 필수 적용
|
||||
- 복잡한 시퀀스 흐름은 단계별 번호 주석 사용:
|
||||
```csharp
|
||||
// 1. 로드 완료 대기
|
||||
// 2. 높이 측정
|
||||
// 3. 용접 위치 이동
|
||||
// 4. 용접 실행
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 빠른 참조
|
||||
|
||||
| 작업 | 규칙 |
|
||||
|------|------|
|
||||
| 새 C# 파일 생성 | UTF-8 BOM + CRLF 적용 필수 |
|
||||
| 새 시퀀스 추가 | EquipDef.cs ID 등록 → 파일 생성 |
|
||||
| 새 디바이스 추가 | EquipDef.cs → EquipmentSetup.cs → BuildMainStatusView |
|
||||
| 한글 포함 수정 | 수정 후 BOM/CRLF 검증 |
|
||||
@ -1,70 +0,0 @@
|
||||
# Git 커밋 규칙 — ILSOS 프로젝트
|
||||
|
||||
## 1. 빌드 산출물(bin) 무시 규칙
|
||||
|
||||
`.gitignore`는 전역적으로 빌드 산출물을 커밋에서 제외한다.
|
||||
|
||||
```
|
||||
obj/
|
||||
bin/
|
||||
```
|
||||
|
||||
- `bin/` 은 폴더명이 `bin` 인 모든 디렉터리를 무시한다.
|
||||
- 그 외 프로젝트별 산출물 경로(`_out_*`, `_intermediate/` 등)도 무시 대상이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 예외: External/Aurora/bin 은 전체 커밋
|
||||
|
||||
`External/Aurora/bin` 는 외부 Aurora 런타임 산출물로, **전체를 git에 커밋**한다.
|
||||
전역 `bin/` 무시 규칙은 그대로 두고, negation(`!`)으로 해당 폴더만 다시 포함한다.
|
||||
|
||||
### `.gitignore` 설정
|
||||
|
||||
```
|
||||
bin/
|
||||
|
||||
# 예외: External/Aurora 폴더의 bin은 전체 커밋
|
||||
!/External/Aurora/bin/
|
||||
!/External/Aurora/bin/**
|
||||
```
|
||||
|
||||
- `!/External/Aurora/bin/` — 무시된 `bin` 디렉터리 자체를 다시 포함한다.
|
||||
- `!/External/Aurora/bin/**` — 그 하위의 모든 파일/폴더를 다시 포함한다.
|
||||
- 두 줄 모두 필요하다. 디렉터리만 negation 하면 git이 하위로 내려가지 않아 파일이 포함되지 않는다.
|
||||
|
||||
### 검증 방법
|
||||
|
||||
```bash
|
||||
# bin 폴더가 더 이상 무시되지 않는지 확인 (negation 규칙 라인이 출력되어야 함)
|
||||
git check-ignore -v External/Aurora/bin/
|
||||
|
||||
# 스테이징
|
||||
git add External/Aurora/bin
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. `.gitignore` 자체 커밋
|
||||
|
||||
`.gitignore` 는 다음 라인으로 **자기 자신을 무시**한다.
|
||||
|
||||
```
|
||||
/.gitignore
|
||||
```
|
||||
|
||||
따라서 `.gitignore` 변경분을 커밋하려면 `-f` 로 강제 추가해야 한다.
|
||||
|
||||
```bash
|
||||
git add -f .gitignore
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 빠른 참조
|
||||
|
||||
| 대상 | 처리 |
|
||||
|------|------|
|
||||
| 일반 `bin/` 산출물 | 무시 (커밋 안 함) |
|
||||
| `External/Aurora/bin` | 전체 커밋 (negation 예외) |
|
||||
| `.gitignore` 수정 | `git add -f .gitignore` |
|
||||
Binary file not shown.
Binary file not shown.
@ -1,200 +0,0 @@
|
||||
# ILSOS 프로젝트 아키텍처
|
||||
|
||||
> CLAUDE.md의 "프로젝트 문서" 섹션에서 import하던 개별 문서들을 통합한 아키텍처 문서입니다.
|
||||
> 세부 내용은 각 원본 문서를 참고하세요.
|
||||
|
||||
## 목차
|
||||
|
||||
1. [프로젝트 개요](#1-프로젝트-개요)
|
||||
2. [솔루션 구조](#2-솔루션-구조)
|
||||
3. [ILSOS_PrismaticRD_PTOP 핵심 구조](#3-ilsos_prismaticrd_ptop-핵심-구조)
|
||||
4. [AuroraDevices 모듈](#4-auroradevices-모듈)
|
||||
5. [빌드 출력 경로](#5-빌드-출력-경로)
|
||||
6. [PTOP 분석 하네스](#6-ptop-분석-하네스)
|
||||
7. [Git 커밋 규칙](#7-git-커밋-규칙)
|
||||
8. [용어 정리](#8-용어-정리-unicell-ptop-welder)
|
||||
|
||||
---
|
||||
|
||||
## 1. 프로젝트 개요
|
||||
|
||||
> 원본: [`project-overview.md`](./project-overview.md)
|
||||
|
||||
### ILSOS - OC5 PilotLine RectangleTypeWelder
|
||||
|
||||
**목표:** 각형 배터리 용접 자동화 시스템
|
||||
|
||||
**플랫폼 및 기술:**
|
||||
- OS: Windows 10 / Windows 11
|
||||
- 프레임워크: .NET Framework 4.8.1
|
||||
- IDE: Visual Studio 2022
|
||||
- UI 프레임워크: WPF (Aurora 프레임워크 기반)
|
||||
- 솔루션 파일: `ILSOS_All.sln`
|
||||
|
||||
**빌드 구성:**
|
||||
- Debug | x64
|
||||
- Release | x64
|
||||
- Simulation | x64 · UserDefineUnit | x64 — **PTOP 기준 `Release|x64`로 매핑**(`ILSOS_All.sln:413-416`).
|
||||
별도 바이너리가 아니다 (§5 참조)
|
||||
|
||||
**머신 모듈:**
|
||||
- **ILSOS_PrismaticRD_PTOP**: 현재 유일한 활성 머신 모듈 (주요 개발 대상)
|
||||
- 과거 Scanner/Gun/CleanLaser 모듈은 제거됨 (솔루션에 csproj 없음)
|
||||
|
||||
**주의사항:**
|
||||
- WeldingComponents·External/Aurora 관련 코드 수정 시 반드시 사전 승인 필요
|
||||
- 모든 파일 수정 시 `docs/CODING_RULES.md` 확인 필수
|
||||
- 한글 포함 파일 작성/수정 시 UTF-8 인코딩 준수
|
||||
|
||||
---
|
||||
|
||||
## 2. 솔루션 구조
|
||||
|
||||
> 원본: [`solution-structure.md`](./solution-structure.md)
|
||||
|
||||
### ILSOS_All.sln 구성
|
||||
|
||||
```
|
||||
ILSOS_All.sln
|
||||
├── Machines/
|
||||
│ └── ILSOS_PrismaticRD_PTOP/ ← 현재 유일한 활성 머신 모듈 (3계층 아키텍처)
|
||||
├── AuroraDevices/ ← 하드웨어 디바이스 드라이버 (sln 등록 20개 / 디스크 22개)
|
||||
├── AuroraComponents/ ← WPF UI 공통 컴포넌트
|
||||
├── AuroraVision/ ← 비전 시스템 (MIL 기반)
|
||||
├── WeldingComponents/ ← 용접 공통 기능
|
||||
│ ├── WeldingCommon
|
||||
│ └── LASAGUI
|
||||
└── External/ ← Aurora 프레임워크 바이너리
|
||||
```
|
||||
|
||||
### 주요 특징
|
||||
|
||||
- **모듈화:** 머신 모듈은 독립적인 디바이스 제어 및 시퀀스 구현
|
||||
- **공유 레이어:** AuroraDevices, AuroraComponents 등으로 코드 재사용
|
||||
- **표준 규칙:** WeldingComponents·External/Aurora는 수정 시 승인 필수
|
||||
|
||||
---
|
||||
|
||||
## 3. ILSOS_PrismaticRD_PTOP 핵심 구조
|
||||
|
||||
> 원본: [`ptop-architecture.md`](./ptop-architecture.md)
|
||||
|
||||
### 폴더 구조 및 주요 컴포넌트
|
||||
|
||||
```
|
||||
ILSOS_PrismaticRD_PTOP/
|
||||
├── EquipDef.cs ← ID 상수 (DeviceIds / SequenceIds / StreamMessageNames)
|
||||
├── EquipmentSetup.cs ← 디바이스·시퀀스 등록, 이벤트 구독
|
||||
├── Alarm/ ← AlarmCode_PTOP, AlarmManager_PTOP
|
||||
├── Device/{IO,PLC}/ ← PAIX_PTOP(IO), PLCControllerPTOP(PLC)
|
||||
├── Models/ ← EquipmentSpecificModel_PTOP
|
||||
├── Recipes/ ← RMSHandlerForPTOP
|
||||
├── Sequences/ ← SeqAutoRunPTOP(메인) 외 + Manual/, Monitoring/
|
||||
├── Settings/ ← SettingUploadDataListForPTOP
|
||||
└── Views/{Main,Model}/ ← WPF View/ViewModel
|
||||
```
|
||||
|
||||
### 주요 ID 정의 (EquipDef.cs)
|
||||
|
||||
| 클래스 | 멤버 (발췌) |
|
||||
|---------|------|
|
||||
| **DeviceIds** : CommonDeviceIds | `MassFlowMeter` (그 외 base 상속) |
|
||||
| **SequenceIds** : CommonSequenceIds | `SeqAutoRunPTOP`, `SeqAutoRunTDC`, `SeqAutoRunComponentWeld`, `SeqAlarmMonitor`, `SeqStatusMonitor`, `SeqTestRun`, `SeqStreamTest`, `SeqEventQTest` |
|
||||
| **StreamMessageNames** | `MessageNameString/Double/Int/JSON/LBAD` |
|
||||
|
||||
> `MotorIds`/`RecipeIds` 클래스는 없음 (base `Common*`·레시피 매니저에서 관리). 상세 → [`ptop-architecture.md`](./ptop-architecture.md)
|
||||
|
||||
### 아키텍처 패턴 (3계층)
|
||||
|
||||
```
|
||||
WPF UI Layer (Views/ + ViewModels)
|
||||
↓
|
||||
Machine Logic Layer (EquipmentSetup + Sequences)
|
||||
↓
|
||||
Device Abstraction (AuroraDevices — 디바이스별 독립 모듈)
|
||||
↓
|
||||
Hardware Layer (ACS.SPiiPlusNET, Melsec, Serial/USB)
|
||||
```
|
||||
|
||||
**기술 스택:** System.Reactive(Rx) · AuroraEnv DI · 메시지 큐(String/Double/Int/JSON/LBAD)
|
||||
|
||||
---
|
||||
|
||||
## 4. AuroraDevices 모듈
|
||||
|
||||
> 원본: [`aurora-devices.md`](./aurora-devices.md)
|
||||
|
||||
AuroraDevices는 하드웨어 디바이스 제어를 담당하는 22개 프로젝트 모음입니다.
|
||||
|
||||
| 프로젝트 | 역할 | 비고 |
|
||||
|---------|------|------|
|
||||
| AuroraDeviceCommon | 디바이스 공통 기본 클래스 | 모든 디바이스 상속 |
|
||||
| AuroraACS | ACS SPiiPlus 모션 컨트롤러 | X/Y축 모션 제어 |
|
||||
| AuroraMotionBoard | Ajin 모션 보드 | Z축 모션 제어 |
|
||||
| AuroraLaser | 레이저 제어 (Gun 타입) | 고정 레이저 |
|
||||
| AuroraLaserScanner | 레이저 스캐너 제어 | 동적 스캐닝 |
|
||||
| AuroraPLC | Mitsubishi Melsec PLC 통신 | 외부 신호 제어 |
|
||||
| AuroraIO | 디지털 I/O | 입출력 신호 |
|
||||
| AuroraHeightSensor | Keyence 높이 센서 | 높이 측정 |
|
||||
| AuroraCellTracker | 팰릿/셀 추적 시스템 | 셀 인식 및 위치 추적 |
|
||||
| AuroraChiller | 냉각 장치 | 온도 제어 |
|
||||
| AuroraOCT | Trumpf OCT 스캐너 | 옵티컬 측정 |
|
||||
|
||||
**설계 원칙:**
|
||||
- 각 디바이스는 독립적인 제어 로직 구현
|
||||
- 통합 제어는 머신 모듈의 EquipmentSetup에서 담당
|
||||
- 의존성 주입(DI) 패턴으로 느슨한 결합 유지
|
||||
|
||||
---
|
||||
|
||||
## 5. 빌드 출력 경로
|
||||
|
||||
> 원본: [`build-output.md`](./build-output.md)
|
||||
|
||||
### 머신별 빌드 디렉토리
|
||||
|
||||
| 머신 모듈 | 출력 경로 | 상태 |
|
||||
|---------|---------|------|
|
||||
| ILSOS_PrismaticRD_PTOP | `Machines/_out_prismatic_rd_ptop/` | 활성 |
|
||||
|
||||
### 빌드 구성별 출력
|
||||
|
||||
출력은 `구성-플랫폼` 하위 폴더로 분리 (csproj `OutputPath` 기준).
|
||||
- `Machines/_out_prismatic_rd_ptop/x64-Debug/` ← Debug|x64
|
||||
- `Machines/_out_prismatic_rd_ptop/x64-Release/` ← Release|x64 (Simulation·UserDefineUnit도 Release 매핑)
|
||||
|
||||
### 주의사항
|
||||
|
||||
- 빌드 출력 디렉토리는 `.gitignore`에 포함
|
||||
- 빌드 전 이전 출력물이 있으면 자동 정리
|
||||
- 각 머신 모듈은 독립적으로 빌드 가능
|
||||
|
||||
---
|
||||
|
||||
## 6. PTOP 분석 하네스
|
||||
|
||||
> 원본: [`harness-ptop.md`](./harness-ptop.md)
|
||||
|
||||
ILSOS_PrismaticRD_PTOP의 아키텍처·구현·빌드를 종합 분석하는 에이전트 하네스.
|
||||
|
||||
- **팀:** `ptop-lead` / `ptop-developer` / `build-devops-engineer`
|
||||
- **트리거:** "PTOP 전체 분석", "PTOP 빌드 최적화" 등 → `orchestrate-ptop-harness` 스킬
|
||||
- **구성:** `.claude/agents/`(PTOP 팀 3개 / 저장소 전체 6개), `.claude/skills/`(PTOP 하네스 4개: analyze-ptop-architecture·-implementation, optimize-ptop-build, orchestrate-ptop-harness)
|
||||
|
||||
> 2026-08-03에 `.ubisam_agent/` → `.claude/`로 이전. Claude Code는 `.claude/`만 로딩한다.
|
||||
|
||||
Ubisam 산출물 하네스는 [`harness-ubisam.md`](./harness-ubisam.md) 참고.
|
||||
|
||||
> 세부 트리거·구성 요소·변경 이력은 원본 문서 참고.
|
||||
|
||||
---
|
||||
|
||||
## 7. Git 커밋 규칙
|
||||
|
||||
@./GIT_RULES.md
|
||||
|
||||
---
|
||||
|
||||
## 8. 용어 정리 (UNICELL PTOP WELDER)
|
||||
|
||||
@./용어정리.md
|
||||
@ -1,22 +0,0 @@
|
||||
# AuroraDevices 모듈 목록
|
||||
|
||||
AuroraDevices는 하드웨어 디바이스 제어를 담당하는 22개 프로젝트 모음입니다.
|
||||
|
||||
| 프로젝트 | 역할 | 비고 |
|
||||
|---------|------|------|
|
||||
| AuroraDeviceCommon | 디바이스 공통 기본 클래스 | 모든 디바이스 상속 |
|
||||
| AuroraACS | ACS SPiiPlus 모션 컨트롤러 | X/Y축 모션 제어 |
|
||||
| AuroraMotionBoard | Ajin 모션 보드 | Z축 모션 제어 |
|
||||
| AuroraLaser | 레이저 제어 (Gun 타입) | 고정 레이저 |
|
||||
| AuroraLaserScanner | 레이저 스캐너 제어 | 동적 스캐닝 |
|
||||
| AuroraPLC | Mitsubishi Melsec PLC 통신 | 외부 신호 제어 |
|
||||
| AuroraIO | 디지털 I/O | 입출력 신호 |
|
||||
| AuroraHeightSensor | Keyence 높이 센서 | 높이 측정 |
|
||||
| AuroraCellTracker | 팰릿/셀 추적 시스템 | 셀 인식 및 위치 추적 |
|
||||
| AuroraChiller | 냉각 장치 | 온도 제어 |
|
||||
| AuroraOCT | Trumpf OCT 스캐너 | 옵티컬 측정 |
|
||||
|
||||
**설계 원칙:**
|
||||
- 각 디바이스는 독립적인 제어 로직 구현
|
||||
- 통합 제어는 머신 모듈의 EquipmentSetup에서 담당
|
||||
- 의존성 주입(DI) 패턴으로 느슨한 결합 유지
|
||||
@ -1,21 +0,0 @@
|
||||
# 빌드 출력 경로
|
||||
|
||||
## 머신별 빌드 디렉토리
|
||||
|
||||
| 머신 모듈 | 출력 경로 | 상태 |
|
||||
|---------|---------|------|
|
||||
| ILSOS_PrismaticRD_PTOP | `Machines/_out_prismatic_rd_ptop/` | 활성 |
|
||||
|
||||
> 과거 Scanner/Gun/CleanLaser 출력 디렉토리는 해당 모듈 제거로 더 이상 생성되지 않음.
|
||||
|
||||
## 빌드 구성별 출력
|
||||
|
||||
출력 폴더는 `구성-플랫폼` 형식의 하위 디렉토리로 분리된다 (csproj `OutputPath` 기준).
|
||||
|
||||
- `Machines/_out_prismatic_rd_ptop/x64-Debug/` ← Debug|x64
|
||||
- `Machines/_out_prismatic_rd_ptop/x64-Release/` ← Release|x64 (Simulation·UserDefineUnit도 Release로 매핑)
|
||||
|
||||
## 주의사항
|
||||
|
||||
- 빌드 출력 디렉토리는 `.gitignore`에 포함
|
||||
- **솔루션(`ILSOS_All.sln`) 기준으로 빌드**해야 post-build xcopy의 `$(SolutionDir)`가 정의됨 (단독 csproj 빌드 시 `*Undefined*` 경로로 실패)
|
||||
@ -1,112 +0,0 @@
|
||||
# 하네스 변경 이력 — PTOP 분석 팀
|
||||
|
||||
> `docs/harness-ptop.md` 에서 분리했다 (`rules.md` #4 — 200줄 상한).
|
||||
> 하네스를 고치면 **여기에 행을 추가**한다. 본문에는 표를 되돌리지 않는다.
|
||||
|
||||
| 날짜 | 변경 내용 | 대상 | 사유 |
|
||||
|------|----------|------|------|
|
||||
| 2026-06-16 | 초기 구성: PTOP 분석 팀 구축 | agents/, skills/ | ILSOS_PrismaticRD_PTOP이 핵심 활성 모듈, 종합 분석 필요 |
|
||||
| 2026-08-03 | `.ubisam_agent/` → `.claude/`로 경로 이전, `.gitignore`에 `!.claude/agents/` 예외 추가 | agents 3개, skills 4개 | Claude Code가 `.claude/`만 로딩 — 하네스 전체가 호출 불가 상태였음 |
|
||||
| 2026-08-03 | `TeamCreate`/`TeamDelete` 의존 제거 → `Agent`+`SendMessage`로 교체 | orchestrate-ptop-harness, agents 3개 | 해당 도구가 이 환경에 존재하지 않아 오케스트레이터 실행 불가 |
|
||||
| 2026-08-03 | 진행·재시도 원장을 `_progress.md` **파일**로 고정 (태스크 도구는 보조로 강등) | 스킬 2·에이전트 6·참조 3·하네스 문서 2 | `TaskCreate`/`TaskUpdate`가 **서브에이전트 컨텍스트에는 없어** 재시도 카운트가 매번 0으로 리셋 → "최대 2회" 상한이 무력화 |
|
||||
| 2026-08-03 | 날조된 예시 분석 결과 삭제, "미측정" 표기 원칙 추가 | orchestrate-ptop-harness, build-devops-engineer | 예시 수치("Release가 20% 느림" 등)를 에이전트가 실측으로 오인해 복사할 위험 |
|
||||
| 2026-08-03 | 산출 파일명을 에이전트 정의와 일치시킴(01~06), 팀원 이름 실제 에이전트명으로 정정 | orchestrate-ptop-harness, ptop-lead | 오케스트레이터↔에이전트 간 참조 불일치(dead link) |
|
||||
| 2026-08-03 | `model: opus`·재호출 지침·분석 전용 명시 추가 | agents 3개 | 후속 실행 시 이전 산출물 재사용 규칙 부재 |
|
||||
| 2026-08-03 | 보고서 템플릿·CI/CD YAML을 `references/`로 분리 (200줄 상한 준수) | analyze-ptop-architecture/-implementation, optimize-ptop-build | `rules.md` #4 위반 (248·210·209줄) |
|
||||
| 2026-08-03 | 템플릿의 날조 수치(빌드 45s/60s, T+50ms, PLC `M10` 등)를 플레이스홀더로 교체 | 위 3개 스킬 references/ | 에이전트가 예시값을 실측으로 오인해 복사할 위험 |
|
||||
| 2026-08-03 | 죽은 소스 경로 정정 + 동명 심볼 함정 명시 | analyze-ptop-architecture, ptop-lead, ptop-developer | 2026-06-18 리네임(`SeqAutoRunPrismaticScanner`→`SeqAutoRunPrismatic`, `PAIX_PrismaticScanner`→`PAIX_PTOP`) 미반영. `PLCContoller.Config.cs` 오탈자·공유 클래스 동명 문제도 병기 |
|
||||
| 2026-08-03 | 에이전트 가용성 가드 + lead 2회 실패 폴백 + stale 표기 의무 추가 | orchestrate-ptop-harness | 에이전트 미등록 시 Phase 2에서 즉사, "지연"과 "실패"가 구분 안 됨, 부분 재실행 시 새 01+낡은 02가 무표기로 섞임 |
|
||||
| 2026-08-03 | 산출 .md 200줄 상한 지시 추가 | agents 3개 | 하네스 자신은 준수하나 산출물에 대한 강제가 없었음 |
|
||||
| 2026-08-03 | `.gitignore`에 `_workspace/`·`_workspace_prev/` 추가 | .gitignore | 하네스 중간 산출물이 레포 루트를 오염 |
|
||||
| 2026-08-03 | `CLAUDE.md`의 `@import X` → `@X` 문법 정정 | CLAUDE.md, docs/architecture.md | `@import`는 Claude Code 문법이 아니라 조용히 실패 — `rules.md` 등 규약 문서 5건이 세션에 로딩되지 않고 있었음 |
|
||||
| 2026-08-03 | `set PYTHONUTF8=1 &&` → `PYTHONUTF8=1` (bash 호환) | 스킬·에이전트·스크립트 9건 | bash에서 `set VAR=1`은 환경변수를 만들지 않아 stdout이 cp949로 깨짐 (`rules.md` #3 위반) |
|
||||
| 2026-08-03 | 죽은 심볼·경로 정정: `Views/Recipe\|Manual\|Monitoring`(부재), `PAGE_VERIFY_DELAY_MS`·`WELD_START_DELAY_MS`(부재), `ThetaTolerance`→`HeadThetaTolerance` | ptop-deliverables/references/source-map.md | 진실원 인덱스가 없는 파일·상수를 지목 |
|
||||
| 2026-08-03 | `ILSOS_PrismaticScanner 네임스페이스 사용` 주장 삭제 | ptop-lead, analyze-ptop-architecture | 실제 PTOP 네임스페이스는 `ILSOS_PrismaticRD_PTOP.*` (전수 확인, 옛 이름 0건) |
|
||||
| 2026-08-03 | 승인 게이트·실패 판정 기준·Phase 3 완료 판정·이중 디스패치 해소 | orchestrate-ptop-harness, ptop-lead, ubisam-deliverables | `rules.md` #2 미준수, "지연"과 "실패"를 구분할 관측 기준 부재, lead와 오케스트레이터가 둘 다 developer를 기동 |
|
||||
| 2026-08-03 | PTOP 하위 스킬 3개에 역방향 구분절 추가 | analyze-ptop-*, optimize-ptop-build | 종합 요청이 단일 영역 스킬로 새는 경로 |
|
||||
| 2026-08-03 | msbuild 탐색 폴백 + 미측정 확정 절차 | optimize-ptop-build | `msbuild`가 PATH에 없어 1단계에서 막힘 |
|
||||
| 2026-08-03 | .NET Core 전용 속성·`#if SIMULATION`·`MockPLC` 예시 삭제 | optimize-ptop-build, cicd 템플릿 | 이 프로젝트는 .NET Framework 4.8.1 legacy csproj. `Simulation\|x64`는 sln에서 `Release\|x64`로 매핑되며 `#if SIMULATION` 0건 — 존재하지 않는 빌드를 대상으로 삼게 됨 |
|
||||
| 2026-08-03 | `MotorIds`→`SettingIds`, `PLC_HEAVY_ALARM_STATUS` 출처→`SeqAlarmMonitor.cs:199`, 진행률 스냅샷 제거 | analyze-ptop-architecture, source-map | 없는 클래스 지목·처리 위치 오지목·근거 없는 수치 |
|
||||
| 2026-08-03 | 산출 경로 절대경로 변환 + `_workspace/` 사전 생성 지시 | orchestrate-ptop-harness | 서브에이전트 셸 cwd가 호출마다 초기화돼 상대경로 산출물이 유실되면 완료 판정이 오판 |
|
||||
| 2026-08-03 | PTOP 3인에 담당 스킬 역참조 1줄씩 추가 | agents 3개 | 단독 호출 시 스킬이 적용되지 않음 (ubisam 3인은 이미 보유) |
|
||||
| 2026-08-03 | qa 양식 미정의 폴백 수신 규칙 추가(#6만 미검증, #2는 정상 검증) | ubisam-qa, ubisam-producer | producer가 qa 동작을 일방 규정하고 있었고 enum 적용 여부와 자기모순 |
|
||||
| 2026-08-03 | Ubisam 하네스에 실패 판정 기준·stale 표기 이식, Phase off-by-one 수정 | ubisam-deliverable-rebuild | Phase 0 후 "Phase 2 시작"으로 적혀 analyst를 건너뛰면 매핑표 없이 producer가 즉사 |
|
||||
| 2026-08-03 | 네임스페이스 단정 정정 — 프로젝트 내 예외 3파일 병기 | ptop-lead, analyze-ptop-architecture | `SeqTestRun.cs:35`=TDC, `SeqAlarmMonitor.cs:22`·`SeqStatusMonitor.cs:11`=WeldingCommon. 앞선 "전부 `ILSOS_PrismaticRD_PTOP.*`" 주장이 거짓이었고, 그대로 grep하면 하네스가 인용하는 `SeqAlarmMonitor.cs:199`가 누락 |
|
||||
| 2026-08-03 | 4구성 → **2구성**으로 통일 (description·측정표·보고서 템플릿) | optimize-ptop-build ×2, build-devops-engineer, architecture.md | `Simulation`·`UserDefineUnit`은 `ILSOS_All.sln:413-416`에서 Release 매핑 — 존재하지 않는 빌드를 측정 대상으로 요구하고 있었음 |
|
||||
| 2026-08-03 | Phase 3 절대경로 전달·Phase 4 완료 알림 대기·재시도 카운트 기록 규칙 | orchestrate-ptop-harness, ubisam-deliverable-rebuild | Phase 2에만 있던 규칙이 전파되지 않아 `02`·`03` 유실 위험, "2회"를 세는 주체 부재 |
|
||||
| 2026-08-03 | 스킬 폴더 잔재 정리(`생성파일/*.pptx`, `__pycache__`) + `.gitignore` 보강 | .claude/skills, .gitignore | 스킬이 스스로 금지한 "출력이 스킬 폴더로 새는 것"의 흔적 |
|
||||
| 2026-08-03 | **`rules.md` #15·#16 바인딩** — 에이전트 6 + 스킬 6에 `[추론]` 표기 의무 삽입, `ubisam-qa` 검증항목 11 신설 | agents 6, skills 6 | 신규 조항이 하네스 어디에도 인용되지 않아 **미시행 상태**였다(문자열 `추론` 0건). 검증 주체가 없는 규칙은 문서에만 남는다 |
|
||||
| 2026-08-03 | 표기 축 판정표 신설 (`파일:라인` / `미측정`계 / `[추론]` / `(제안)`계) | rules.md, 두 하네스 문서 | `[추론]`과 기존 미확정 표기 5종의 관계가 미정의라 대체·이중표기 위험 |
|
||||
| 2026-08-03 | `rules.md` #5의 `@import` → `@경로` 정정, #15·#16을 `## 검증·표기` 절로 분리 | rules.md | 규칙서가 **폐기된 문법을 지시**하고 있었다(이미 정정한 결함의 발원지). 신규 조항이 제목 없이 붙어 파일 번호가 1,2,3,15,16,4,5로 흐트러짐 |
|
||||
| 2026-08-03 | 규칙 ↔ 바인딩 역인덱스 표 + `grep` 자가 점검 명령 추가 | docs/harness-ptop.md | 조항 추가 시 바인딩 누락이 3라운드 연속 지적 — 재발 방지 |
|
||||
| 2026-08-03 | `ptop-lead` 성공 기준의 "교차 확인 질문" 체크박스를 오케스트레이터 경유 시로 조건부화 | ptop-lead.md | 질문 정의·기록처가 모두 오케스트레이터 소유라 **단독 기동 시 충족 불가능**한 체크박스였음 |
|
||||
| 2026-08-03 | `141528_…md` 경로를 전체 경로로 명기 | ptop-deliverables/references/source-map.md | 앞 문장의 `06/17/`과 병렬로 읽히나 실제는 `06/20/` — 06/17에는 없는 파일 |
|
||||
| 2026-08-03 | **`[추론]` 검색 시 `\[추론\]` 이스케이프 의무** 명시 | ubisam-qa(검증항목11·작업원칙), ubisam-deliverables, rules.md | 대괄호가 정규식 문자클래스라 `[추론]`은 `추`·`론` 한 글자에도 매치 → **과다 매치**. 경로 케이스(0건)와 달리 결과가 많아 "0건이면 의심" 가드에 안 걸린다(실측 확인) |
|
||||
| 2026-08-03 | qa 성공 기준 "10개" → "**11개**" | ubisam-qa.md | 직전 패스에서 검증항목 11을 신설하고 최종 게이트를 안 고쳐, 신규 항목을 건너뛰어도 통과되는 상태였음 (**자체 유발 회귀**) |
|
||||
| 2026-08-03 | 실행 모드 판별을 `_workspace/` 폴더 존재 → **산출물 `01`~`06` 존재**로 변경 | orchestrate-ptop-harness | 채점·로그 파일만 있어도 "부분 재실행"으로 오판정 |
|
||||
| 2026-08-03 | 표기 축에 `미확인` 편입, `(추정)` → `[추론]` 통일 | rules.md, harness-ubisam, 00-harness.md | 판정표가 실사용 표기 2종을 누락 — 같은 축에 다른 토큰이 공존 |
|
||||
| 2026-08-03 | `analyze-ptop-architecture` 단독 기동 시 stale 표기 의무 명시 | analyze-ptop-architecture | "아키텍처만 다시"가 두 스킬에 동시 귀속되는데 단독 경로엔 표기 주체가 없었음 |
|
||||
| 2026-08-03 | `ubisam-deliverables` 자동 채움 단계에 `[추론]` 바인딩 | ubisam-deliverables/SKILL.md | 게이트 없이 값을 생성하는 유일 경로가 미바인딩으로 남아 있었음 |
|
||||
| 2026-08-03 | `rules.md` 절 순서 정정(`## 규칙 관리` → `## 검증·표기`), 역인덱스 `#11~13` 스킬 수 6→8 | rules.md, harness-ptop.md | 조항 15·16이 14보다 앞서 배치돼 자기 지침과 상충. 역인덱스 수치 오기 |
|
||||
| 2026-08-03 | **역인덱스에서 인용 건수 열 삭제** — "어디에 있어야 하는가"만 남기고 개수는 명령이 답하게 | docs/harness-ptop.md | **세 라운드 연속 자체 유발 회귀.** 바인딩을 늘릴 때마다 표의 숫자가 거짓이 됐다(17·17로 적고 실제 19·19). 숫자를 문서에 박는 구조 자체가 원인이라 열을 없앴다 |
|
||||
| 2026-08-03 | `source-map.md` 무효 심볼 3행 정정 — `Register*Device`·`MenuId`·`ViewType`·`AuthLevel`·`AddNode`·`AddTransition` | ptop-deliverables/references/source-map.md | 전부 **소스 0건**. 실제는 `registry.Register`(활성 3) · `AddSubMenu(CommonViewIds.*, UC)`(26, 권한 인자 없음) · `AddAction`(17)/`AddDecision`(4)/`AddSubsequence`(3). 하네스가 금지한 "창작"을 스스로 유발하는 경로였음 |
|
||||
| 2026-08-03 | **"0건" 가드에 `.gitignore` 원인 추가** | ubisam-qa.md, harness-ptop.md | 기존 가드는 대괄호만 원인으로 지목. 그런데 `rg` 는 `.gitignore` 를 존중하고 **검증 대상이 전부 무시 대상**(`docs/[Ubisam산출물]/`·`_workspace/`)이라 자기 산출물 검색이 0건이 된다(실측: 루트 glob 0 vs 실제 5) |
|
||||
| 2026-08-03 | `SendMessage` 회신 대상 `to: "main"` 명시 | 에이전트 6 | 6개 모두 "오케스트레이터에 보고한다"고 쓰면서 수신자 표기가 **전 저장소 0건**. 이름으로 보내면 메인 대화에 닿지 않는다 |
|
||||
| 2026-08-03 | 부분 상태(`01`만 있음) 분기 신설 + "전체 분석"을 이동 근거에서 제외 | orchestrate-ptop-harness, ubisam-deliverable-rebuild, test-scenarios.md | `01`만 있는 상태에 분기가 없고, "전체 분석"이 최초 실행과 전면 재실행에서 같은 발화라 `_workspace_prev/` 오이동 위험 |
|
||||
| 2026-08-03 | rebuild Phase 2에 **문서 1건당 producer 1기동** 명시 | ubisam-deliverable-rebuild | producer를 하나만 띄우면서 "문서 1건마다 qa"를 요구해 점진 검증의 관측점이 없었음 |
|
||||
| 2026-08-03 | **"소비처 확인 의무" 절 신설** (열거형·개수 변경 시 grep) | docs/harness-ptop.md | 4라운드 연속 같은 유형의 자체 유발 회귀 — 값을 늘리고 읽는 쪽을 안 고침. 개별 결함만 고치면 재발하므로 절차를 명문화 |
|
||||
| 2026-08-03 | 실행 모드 `이어서` 의 **소비처 신설** (전달부·`ptop-lead`를 3종→4종) | orchestrate-ptop-harness, ptop-lead | 신규 모드가 판별부에만 있고 소비처 0건 → 임의로 `전면` 매핑 시 재사용 대상 `01`이 `_workspace_prev/`로 사라짐 |
|
||||
| 2026-08-03 | `_progress.md` 행 단위를 `{에이전트}:{문서}` 로 정정 | ubisam-deliverable-rebuild | "3행 고정"인데 문서 N건이면 인스턴스가 3N개 → 문서별 재시도 상한이 무력화 |
|
||||
| 2026-08-03 | `AddSubMenu` 계수 규칙 정정 (26 → **활성 18**), 8탭 중 누락 4탭 행 추가 | ptop-deliverables/references/source-map.md | 26건에 주석 8건이 포함돼 형제 행(주석 제외 규칙)과 상충. `OverView`·`DeviceView`·`SettingView`·`VisionView` 는 진실원 행 자체가 없었음(`OverView` 는 대응 항목 미확인으로 표기) |
|
||||
| 2026-08-03 | `RegisterViews — 권한 레벨 포함` → **권한 필드 없음**으로 정정 | ptop-deliverables/SKILL.md | `AuthLevel` 을 참조 맵에서 지웠으나 STEP 1이 여전히 추출을 명령. STEP 1이 참조 맵보다 먼저 읽힌다 |
|
||||
| 2026-08-03 | `doyeon_note` 에 규약 바인딩(#3·#4·#9·#15·#16) 추가 | doyeon_note/SKILL.md | 유일하게 `rules.md` 인용 0건. 작업일지는 나중에 사실 기록으로 인용되므로 추론 혼입 위험이 크다 |
|
||||
| 2026-08-04 | **19R 수정 패스.** `MainMenu` `PermissionLevel` 인자 존재로 정정(18R N-1 오정정 되돌림) | ptop-deliverables/SKILL.md·source-map.md | `AddSubMenu`(2인자)만 보고 "권한 필드 없음"이라 선언했으나 `EquipmentSetup.cs:261,266,289,302,310,318,323,330` 8건이 값 보유. 소비처(`09-pptx-integration.md:55`·`build_02설계_pptx.py:92`)의 `권한` 열이 굶고 있었음 |
|
||||
| 2026-08-04 | §C 8탭 3중 모순 해소 + **상위 진실원 명시** | source-map.md | `VisionView`→`(해당없음)`(`EquipmentSetup.cs:342-343` 주석 확인), `OverView` 진실원→`docs/architecture.md`, `DeviceView`→Monitoring 3뷰 병기. 탭 목록의 진실원이 `05-form-schemas.md:78-85` 임을 명문화 |
|
||||
| 2026-08-04 | `.gitignore` negation 주석을 **실측대로 정정**(git 전용, ripgrep 무효) | .gitignore, ubisam-qa.md | negation 투입 후에도 `rg --files .claude`=1 / `--no-ignore`=57. 주석대로 믿으면 다음 감사관이 `Grep path:".claude"` 를 재신뢰 |
|
||||
| 2026-08-04 | `_workspace/`(경로 명시 시 정상) ↔ `.claude/`(루트 시작점이면 프루닝) **증상 분리** | harness-ptop.md, ubisam-qa.md | 두 증상을 같은 원인으로 묶어 진단하던 문구가 `_workspace/`에 불필요한 `--no-ignore` 를 요구 |
|
||||
| 2026-08-04 | `알려진 한계 2가지`→`3가지` + 소비처 표에 **"자기 문단의 리드 개수어"** 행 신설 | harness-ptop.md | 5라운드 연속 미수정. 개별 수정으로는 안 끊겨 회귀 유형 자체를 표에 등재 |
|
||||
| 2026-08-04 | Ubisam Phase 1·2 전달 항목에 **실행 모드 추가**, 3인에 모드 수신 규칙 이식 | rebuild/SKILL.md, ubisam-analyst·producer·qa | 모드 판별이 승인 목록 산정에만 쓰이고 이동·재사용 결정에 도달하지 못했음(`이어서` 소비처 0건) |
|
||||
| 2026-08-04 | `이어서`·`부분`이면 **기동 대상도 축소**한다는 규칙 신설 | orchestrate/SKILL.md | 모드가 바꾸는 것이 이동 여부뿐이라 "없는 것만 생성" 정의가 미시행 |
|
||||
| 2026-08-04 | `SendMessage` **`summary` 필수** 명시(에이전트 6) + Phase 3 developer `run_in_background: true` | 에이전트 6, orchestrate/SKILL.md | 실제 스키마상 `summary`는 필수이고 `to:"main"`은 백그라운드 전용 — 전경 기동 시 회신 경로가 막힘 |
|
||||
| 2026-08-04 | 단독 기동 stale 절·`rules.md` #1 을 형제 스킬 2종에 이식 | analyze-ptop-implementation, optimize-ptop-build, analyze-ptop-architecture | "빌드 분석만 다시"가 후속 트리거인데 표기 주체가 `analyze-ptop-architecture` 에만 있었음 |
|
||||
| 2026-08-04 | `PLCContoller.Config.cs` 역할 정정, `DefineConstants` 단정에 **PTOP csproj 기준** 한정 | ptop-developer.md, build-devops-engineer.md | 전자는 18줄 빈 파일인데 "주소 맵핑"으로 안내(형제 문서와 정반대). 후자는 저장소 전체에 `_NO_USE_*`·`USE_COGNEX` 가 실재하는데 에이전트가 자기 스킬보다 넓게 단정 |
|
||||
| 2026-08-04 | **모션 보드 벤더 주의문을 IO 보드로 정정** | source-map.md | `eIOBoardType`(Ajin·PAIX·ACS)은 `AuroraIO/IODevice.cs:18` 소속이고 `AuroraMotionBoard` 는 `Ajin/` 구현뿐 — 금지문이 IO와 모션을 혼동해 `architecture.md:133` 을 거짓 위반으로 만들고 있었음 |
|
||||
| 2026-08-04 | 디바이스 "5종 전수" → **활성 3 + 주석 3(상태감시는 살아 있음)** | ptop-lead.md | 활성 `registry.Register` 3건인데 5종 파악을 요구. `AddDeviceActiveStatus`(`:70-71`) 때문에 "미사용" 단정도 불가 |
|
||||
| 2026-08-04 | `render_helpers.py` 크래시 수정 + 출력 경로·실행 예 정정 | ui_layout_image/render_helpers.py | `os.makedirs('')` → `FileNotFoundError`(파일명만 준 경우). `_demo.png` 가 스킬 폴더로 새고 있었고 docstring 이 맨 파일명 실행을 지시 |
|
||||
| 2026-08-04 | 유형 뱃지 중복 2행 삭제(11→**9**), `TODAY` 출처 정정, ppt spec 예시 실명 제거 | design-system.md, 05-form-schemas.md, ubisam-ppt-make/SKILL.md | 뱃지가 enum 9종과 불일치, `TODAY`는 `xlsxfill.py` 가 아니라 `build_02설계_xlsx.py:41`, spec 예시의 타 프로젝트 조직·담당자가 복사 유발 |
|
||||
| 2026-08-04 | `README.md` 디자인 지시를 §7 부재에 맞게 재작성 | ubisam-deliverables/SKILL.md | `08-design-system.md:98` §7 은 `_task.md` 전용 — README 골격이 없는데 적용을 명령 |
|
||||
| 2026-08-04 | **200줄 상한 복구** — 변경 이력 분리, 보고서 골격·프로토콜을 `references/` 로 | harness-ptop.md, orchestrate/SKILL.md, rebuild/SKILL.md | 감사 중 수정으로 202·201줄 발생(`rules.md` #4 자기 위반). 본 파일도 200줄에 도달해 이력 추가가 불가능했음 |
|
||||
| 2026-08-04 | **20R.** `부분` 모드를 기동 축소 조건에서 제외 + 생략 시 완료 판정 대체 규칙 신설 | orchestrate/SKILL.md, references/mode-rules.md | **19R 수정이 만든 seam(A·B 둘 다 Major 지목).** `부분`은 지목 에이전트를 *다시 돌리는* 모드인데 산출물이 있다는 이유로 생략해 **0기동**이 됐고, `이어서`에서 lead를 생략하면 Phase 3이 오지 않을 알림을 무기한 대기했다 |
|
||||
| 2026-08-04 | `PLCContoller.Config.cs` 역할 정정을 **`analyze-ptop-architecture` 에도** 반영 | analyze-ptop-architecture/SKILL.md | 19R이 `ptop-developer.md` 만 고치고 같은 서술의 **다른 사본**을 놓쳤다. 하필 `ptop-lead` 가 "먼저 읽는다"고 지정한 스킬 |
|
||||
| 2026-08-04 | 하네스 문서 상호 인용을 **라인 번호 → 앵커 문자열**로 전환 | source-map.md, harness-ptop.md | `05-form-schemas.md:78-85` 가 같은 배치의 2줄 추가로 어긋나 정정 대상 `VisionView` 를 범위 밖으로 밀어냈다. 소비처 표에 "라인 드리프트" 행 신설 |
|
||||
| 2026-08-04 | 조건부서식 상수 소재 정정 (`xlsxfill.py` 에 **없다** — 관련 API 0건) | 00-harness.md | 계약 문서가 `ubisam-producer.md` 와 정반대를 적었고, 계약이 먼저 읽힌다 |
|
||||
| 2026-08-04 | 박제된 `rg` 실측치(57) → **재현 명령과 관계(1 ≪ 전체)** 로 교체 | harness-ptop.md, ubisam-qa.md, .gitignore | 파일이 늘어 59가 되며 드리프트. 숫자를 문서에 박는 구조 자체가 원인이라 숫자를 없앴다 |
|
||||
| 2026-08-04 | `test-scenarios` 개수 선언 `1+1` → **4흐름**, `_progress.md` 행 초기화에 `생략` 상태 추가 | orchestrate/SKILL.md | 19R이 신설한 "리드 개수어" 규칙의 자기 위반. 축소 기동과 3행 초기화가 미정합 |
|
||||
| 2026-08-04 | Ubisam producer·qa 기동에 `run_in_background: true` | rebuild/SKILL.md | `to:"main"` 은 백그라운드 전용인데 19R이 PTOP Phase 3 에만 적용 |
|
||||
| 2026-08-04 | 디바이스 5종 나열 잔여분 정정, 200줄 문구 앵커 5건, `build_deck.py`·`showcase.json` 실명 20건 → 플레이스홀더, `__pycache__` 3건 삭제 | ptop-lead.md 외 8건 | 19R 정정이 같은 파일 앞부분·형제 파일에 남긴 잔여 |
|
||||
| 2026-08-04 | 모드 규칙을 `references/mode-rules.md` 로 분리 (208 → 200줄 이하) | orchestrate/SKILL.md | 위 수정으로 `rules.md` #4 재위반 |
|
||||
| 2026-08-04 | **21R.** 원장 상태 enum **정의부**에 `생략` 추가 (3 → 4종) | references/data-protocol.md, orchestrate/SKILL.md, mode-rules.md | **20R 수정이 쓰는 쪽(Phase 분기)만 고치고 정의부를 안 고쳤다** — A·B 둘 다 지목. 정의부에 없으면 기록 주체가 애초에 안 적어 19R 교착이 재발한다 |
|
||||
| 2026-08-04 | `생략` 을 **모드 무관 "이번 실행에서 기동하지 않음"** 으로 일반화 | data-protocol.md, mode-rules.md, orchestrate/SKILL.md | `이어서` 에만 부여돼 `부분` 의 미지목 에이전트 상태가 미정의였고, Phase 4 생략 분기가 안 걸려 교차 질문이 불필요하게 `미검증` 으로 떨어졌다 |
|
||||
| 2026-08-04 | 생략 대상 표에 `ptop-developer` 추가 (2인 → **3인 전원**) | mode-rules.md | lead·build만 열거해 `이어서` 에서 developer 가 중복 기동 |
|
||||
| 2026-08-04 | 마지막 `.md:NN` 상호 인용을 앵커로 전환 — **살아 있는 라인 인용 0건** | source-map.md | 20R이 세운 앵커 정책의 유일한 미적용 지점. 이로써 라인 드리프트 결함 유형이 종료된다 |
|
||||
| 2026-08-04 | **"열거형 정의부 먼저" 규칙 신설** (① 정의한 표 → ② 기록하는 곳 → ③ 읽는 곳) | docs/harness-ptop.md | 6라운드 연속 같은 유형이 재발한 근본 원인. 개별 결함만 고쳐서는 안 끊겨 순서를 명문화 |
|
||||
| 2026-08-04 | `xlsxfill.py` 타 프로젝트명(공소수정기·FMM) 제거 + 맨 파일명 실행 지시 정규화 | references/xlsxfill.py | 형제 3곳은 이미 전체 경로로 정규화됐는데 이 파일만 남아 있었다 |
|
||||
| 2026-08-04 | rebuild qa 기동 문장에 `run_in_background: true` (잔여 seam) | rebuild/SKILL.md | 20R이 규칙은 넣고 **같은 파일의 재기술 문장**을 안 고쳤다 |
|
||||
| 2026-08-04 | `build-devops-engineer` 자기모순 해소 ("lead 지시 대기 안 함" ↔ "lead 지시에 따라 수행") | build-devops-engineer.md | 기동 주체가 오케스트레이터 전담으로 바뀐 뒤 §역할 문구가 옛 전제를 유지 |
|
||||
| 2026-08-04 | **22R.** Phase 3에 **developer 자신을 생략하는 분기** 신설 | orchestrate/SKILL.md, mode-rules.md | **21R 수정이 위임만 하고 수신처를 만들지 않았다**(A·B 둘 다 Major). `mode-rules.md` 가 "Phase 3에서 판단"으로 넘겼는데 Phase 3에 분기가 0건 → `생략` 으로 적어 둔 developer 가 실제 기동돼 원장이 거짓이 되고 `02`·`03` 을 덮어썼다 |
|
||||
| 2026-08-04 | Phase 4를 **`완료`/`실패`/`생략` 3분기**로 분리 | orchestrate/SKILL.md, references/collection-rules.md | "실패·미기동"을 한 처리로 묶어 `부분`·`이어서` 실행이 **매번** 교차 질문 2건을 통째로 `미검증` 으로 떨어뜨렸다. `생략` 은 산출물이 실재하므로 파일을 읽어 답할 수 있다 |
|
||||
| 2026-08-04 | 성공 기준의 `미검증` 대체 조건에 `생략` 경로 추가 | orchestrate/SKILL.md | "실패했으면"만 허용해 `부분` 실행이 **자기 성공 기준을 충족할 수 없었다** |
|
||||
| 2026-08-04 | 기동 축소 기준을 **모드별로 분리 서술** (`이어서`=산출물 유무 / `부분`=지목 여부) | orchestrate/SKILL.md, mode-rules.md | 본문이 "`부분`에는 적용하지 않는다"로만 적혀 §Phase 1-5의 `생략` 기록 지시와 표면 모순으로 읽혔다 |
|
||||
| 2026-08-04 | 앵커 오지정 정정 — `ubisam-format-map` §5 → **§6** | source-map.md | 21R이 라인 인용을 앵커로 바꾸며 절 번호를 확인하지 않았다. **앵커 전환도 검증이 필요하다**는 실증 |
|
||||
| 2026-08-04 | `test-scenarios.md` 부분 재실행 흐름에 **원장 `생략` 기록·Phase 3 스킵·Phase 4 3분기** 단계 추가 | references/test-scenarios.md | `생략` 분기의 유일한 end-to-end 검증점이 비어 있었다 |
|
||||
| 2026-08-04 | `build-devops-engineer` `(Phase 3 의존)` 잔여 정정, rebuild analyst 기동에 `run_in_background` | build-devops-engineer.md, rebuild/SKILL.md | build 는 Phase 2 병렬로 선행 의존이 없다(복붙 잔재). analyst 는 단일 문서 시 회신이 막혔다 |
|
||||
| 2026-08-04 | **소비처 확인 의무에 ④ "위임했으면 수신처 확인" + 앵커 전환 시 `grep -n "^## "` 절차** 신설 | docs/harness-ptop.md | 21R의 순서 규칙(①정의→②기록→③읽기)이 "정의부 누락" 유형은 잡았으나, **위임 문자열의 수신처 부재**는 못 잡았다 |
|
||||
| 2026-08-04 | Phase 4 상세를 `references/collection-rules.md` 로 분리 (213 → 200줄) | orchestrate/SKILL.md | 위 수정으로 `rules.md` #4 재위반 |
|
||||
| 2026-08-04 | **23R(최종 수정, 미채점).** `_workspace_prev/` 이동 주체 모순 해소 — 에이전트 정의를 **전면 금지**로 통일 | ptop-lead.md, ubisam-analyst.md, orchestrate/SKILL.md | **B 최상위 결함(잠재 데이터 유실).** 오케스트레이터 문서는 "팀원은 안 한다"인데 lead·analyst 는 "`전면`이면 옮긴다"로 정반대였다. 금지문이 구속 대상의 독서 경로 밖이라 수신처 0건 → 이중 이동 시 병렬로 쓰이던 `04`~`06` 이 딸려간다 |
|
||||
| 2026-08-04 | 모드 판별표를 **두 축(산출물 상태 × 요청 범위)으로 분리** + `생략`인데 파일 부재 시 분기 추가 | references/mode-rules.md | 1열이 두 축을 섞어 **산출물 0건 + "아키텍처만 다시"** 가 `초기`·`부분` 양쪽에 매치했다(현재 저장소가 정확히 그 상태) |
|
||||
| 2026-08-04 | 파일 이동으로 끊긴 인용 복구 — 교차 확인 질문 정의처를 `collection-rules.md` §교차 확인 질문으로 | ptop-lead.md | **22R의 파일 분리가 끊은 인용.** 답할 주체가 지목된 곳(`SKILL.md` Phase 4)을 열면 질문이 없었다 |
|
||||
| 2026-08-04 | 복붙 쌍둥이 자기모순 해소 — `ptop-developer.md` "lead 지시를 기다리지 않는다" ↔ "lead 지시를 받아 수행" | ptop-developer.md | 22R이 `build-devops-engineer.md` 만 고치고 세 줄 간격의 쌍둥이를 놓쳤다 |
|
||||
| 2026-08-04 | `mode-rules.md` 리드 문장을 표와 정합("`이어서`에서만" → 모드별 기준), Phase 3 전방 참조, 승인 ④에 stale 편집 편입 | mode-rules.md, orchestrate/SKILL.md | 표는 고쳤는데 그 위 요약문이 옛말로 남아 정면 충돌. 무조건 기동 문장이 생략 분기보다 앞. stale 편집이 승인 4항 어디에도 없었다 |
|
||||
| 2026-08-04 | `이어서` 수신 블록을 `ptop-developer`·`build-devops-engineer` 에 신설 | 에이전트 2 | Phase 2가 모드 4종을 전원에게 전달하는데 수신 블록은 lead 에만 있었다(문자열 각 0건) |
|
||||
| 2026-08-04 | **⑤~⑦ 재발 방지 규칙 신설** + 앵커 검출 명령을 `^#{2,4} \|^> \*\*` 로 확장 | docs/harness-ptop.md | ⑤ 금지·전담 지정 시 그 주체의 정의 파일 확인 ⑥ 절을 옮겼으면 제목을 `grep -rn` ⑦ 리드 문장·복붙 쌍둥이 동반 수정. `grep -n "^## "` 로는 하네스 자신의 앵커 4종이 검출되지 않았다 |
|
||||
| 2026-08-04 | `harness-ubisam.md` 200줄 문구 앵커 부착·자기 서술 정정, `protocol.md` 베어 `_workspace/` 경로 명시 | harness-ubisam.md, protocol.md | 21R P3 2R 연속 미이행. PTOP 하네스의 동명 폴더와 혼동 소지 |
|
||||
@ -1,192 +0,0 @@
|
||||
# 하네스: ILSOS_PrismaticRD_PTOP 분석 팀
|
||||
|
||||
## 목표
|
||||
|
||||
ILSOS_PrismaticRD_PTOP(PtoP)의 3계층 아키텍처, 구현 상세, 빌드 최적화를 종합 분석하고 개선안 제시.
|
||||
**분석 전용 하네스** — 소스 코드를 수정하지 않는다. 코드를 실제로 고치는 작업은 `code_Agent`를 쓴다.
|
||||
|
||||
## 트리거
|
||||
|
||||
다음 요청 시 `orchestrate-ptop-harness` 스킬을 사용한다.
|
||||
|
||||
- "PTOP 프로젝트 전체 분석" / "PTOP 전체 점검" / "PTOP 구조 파악"
|
||||
- "PTOP 아키텍처와 구현 분석" / "PTOP 팀 조율"
|
||||
- 후속: "PTOP 재분석", "아키텍처만 다시", "빌드 분석만 다시", "이전 결과 기반으로"
|
||||
|
||||
단일 영역만 필요하면 개별 스킬을 직접 쓴다 — `analyze-ptop-architecture` /
|
||||
`analyze-ptop-implementation` / `optimize-ptop-build`.
|
||||
|
||||
## 팀 구성
|
||||
|
||||
| 에이전트 | 담당 | 사용 스킬 | 산출 (`_workspace/`) |
|
||||
|---|---|---|---|
|
||||
| `ptop-lead` | 3계층 아키텍처·디바이스 스택·시퀀스 의존성 | `analyze-ptop-architecture` | `01_ptop_architecture.md` |
|
||||
| `ptop-developer` | 시퀀스 상태머신·타이밍·Rx 체인·에러 처리 | `analyze-ptop-implementation` | `02_ptop_implementation.md`, `03_device_integration.md` |
|
||||
| `build-devops-engineer` | 멀티 구성 빌드·의존성·CI/CD | `optimize-ptop-build` | `04_build_analysis.md`, `05_cicd_pipeline.yml`, `06_ptop_build_optimization.md` |
|
||||
|
||||
통합 보고서: `_workspace/00_PTOP_HARNESS_SUMMARY.md`
|
||||
|
||||
## 실행 모드
|
||||
|
||||
**서브 에이전트 병렬 + 의존 순차.** 이 환경에는 `TeamCreate`/`TeamDelete` 도구가 없으므로
|
||||
`Agent`(기동, `model: "opus"`) + `SendMessage`(소통) + `_workspace/_progress.md` 파일(진행 원장)로 구성한다.
|
||||
|
||||
`ptop-lead`와 `build-devops-engineer`는 병렬, `ptop-developer`는 lead 산출 완료 후 순차.
|
||||
|
||||
## 구성 요소
|
||||
|
||||
**Agents:** `.claude/agents/ptop-lead.md`, `ptop-developer.md`, `build-devops-engineer.md`
|
||||
**Skills:** `.claude/skills/orchestrate-ptop-harness/`, `analyze-ptop-architecture/`,
|
||||
`analyze-ptop-implementation/`, `optimize-ptop-build/`
|
||||
**Workspace:** `_workspace/` (중간 산출물 보존 — 감사 추적용)
|
||||
|
||||
## 하네스를 고칠 때 — 소비처 확인 의무
|
||||
|
||||
**라운드마다 같은 유형의 회귀가 반복됐다.** 값을 늘려놓고 그 값을 읽는 쪽을 안 고치는 것이다.
|
||||
|
||||
| 실제 사례 | 늘린 것 | 안 고친 소비처 |
|
||||
|---|---|---|
|
||||
| `ubisam-qa` 검증항목 11 신설 | 표 행 10 → 11 | 성공 기준 "10개" |
|
||||
| `[추론]` 바인딩 확대 | 인용 17 → 19 | 역인덱스 표의 숫자 |
|
||||
| 실행 모드 `이어서` 신설 | 모드 3 → 4종 | 전달부·`ptop-lead` 소비부 (둘 다 3종) |
|
||||
| 문서 1건당 producer 1기동 | 인스턴스 3 → 3N | `_progress.md` "3행" 초기화 |
|
||||
| 검색식 함정 항목 추가 | 한계 2 → 3항 | **같은 문단의 리드 개수어** `알려진 한계 2가지` |
|
||||
| 표에 행 2개 추가 | 표가 2줄 아래로 밀림 | **그 표를 `파일:라인` 으로 가리키던 인용** (가리키는 범위가 어긋남) |
|
||||
| Phase 2에 기동 축소 규칙 신설 | 기동 대상 3 → 3−N | Phase 3·4의 **완료 알림 대기**(생략된 에이전트는 알림을 안 보낸다) |
|
||||
| 원장에 `생략` 상태 신설 | 상태 3 → 4종 | **그 상태를 정의한 표**(`data-protocol.md` 진행 원장) — 정의부에 없으면 기록 주체가 안 적는다 |
|
||||
|
||||
> **열거형에 값을 추가했으면 그 열거형을 *정의한 표*를 먼저 고친다.** 6라운드 연속 같은 유형이
|
||||
> 재발한 이유는 늘 **쓰는 쪽(Phase 분기)만 고치고 정의부를 안 고쳤기** 때문이다.
|
||||
> 정의부에 없는 값은 **기록 주체가 애초에 적지 않으므로** 소비처가 아무리 정확해도 동작하지 않는다.
|
||||
> 순서: ① 정의한 표 → ② 기록하는 곳 → ③ 읽는 곳 → **④ 위임했으면 수신처.** 넷을 **같은 편집에서** 본다.
|
||||
>
|
||||
> **④ 위임의 수신처 확인.** `(Phase 3에서 판단)`·`(위 참조)`·`(§X 참조)` 처럼 **처리를 다른 곳으로
|
||||
> 넘기는 문자열을 썼으면, 그 수신처를 열어 해당 분기가 실재하는지 확인**한다. 위임은 소비처를
|
||||
> *지정*할 뿐 *만들지* 않는다 — 수신처가 없으면 그 규칙은 문서에만 있고 실행되지 않는다.
|
||||
> 실제 사례: `mode-rules.md` 가 developer 생략을 "Phase 3에서 판단"으로 넘겼는데 Phase 3에 분기가
|
||||
> 0건이라, `생략` 으로 적어 둔 에이전트가 실제로 기동돼 원장이 거짓이 됐다.
|
||||
>
|
||||
> **앵커로 인용을 바꿀 때는 대상 파일에서 절 제목을 즉시 확인한다.** 라인 번호를 앵커로 바꾸면
|
||||
> 드리프트가 없어지지만, **앵커 자체를 잘못 적으면 같은 오류가 난다**(실제로 `§5` 로 적었으나
|
||||
> 대상 문장은 `§6` 이었다).
|
||||
> ⚠ `grep -n "^## "` 만으로는 부족하다 — 하네스는 `###` 소제목과 **인용문 안의 굵은 소절 제목**
|
||||
> (`> **…**`)도 앵커로 쓴다. 다음처럼 넓게 뜬 뒤 눈으로 고른다:
|
||||
>
|
||||
> ```bash
|
||||
> grep -nE "^#{2,4} |^> \*\*" <대상파일>
|
||||
> ```
|
||||
>
|
||||
> **⑤ 어떤 주체를 금지·전담으로 지정했으면 그 주체의 정의 파일을 연다.** 오케스트레이터 문서에만
|
||||
> "팀원은 하지 않는다"를 적고 에이전트 정의에 반대말이 남으면, **구속 대상이 그 금지문을 읽지 않는다.**
|
||||
> 실제 사례: `_workspace_prev/` 이동을 "오케스트레이터 전담"으로 정해 놓고 `ptop-lead`·`ubisam-analyst`에
|
||||
> "`전면`이면 옮긴다"가 남아 이중 이동으로 병렬 산출물이 딸려갈 상태였다.
|
||||
>
|
||||
> **⑥ 절을 다른 파일로 옮겼으면 그 절 제목을 `grep -rn` 해 인용처를 전부 연다.** 라인→앵커 전환은
|
||||
> 라인 드리프트를 없애지만 **절의 파일 이동은 앵커도 무력화한다.** 실제 사례: 교차 확인 질문을
|
||||
> `collection-rules.md`로 옮긴 뒤 `ptop-lead`가 여전히 `SKILL.md` Phase 4를 지목해, 답할 주체가
|
||||
> 지목된 곳을 열면 질문이 없었다.
|
||||
>
|
||||
> **⑦ 고친 문장의 형제를 함께 본다** — 참조 문서의 **리드 문장**(표는 고쳤는데 그 위 요약문이 옛말),
|
||||
> 그리고 **복붙 쌍둥이 파일**(에이전트 정의 6종은 서로 문단을 복사해 쓴다). 한쪽만 고치면
|
||||
> 세 줄 간격으로 자기모순이 남는다.
|
||||
|
||||
> **자주 재발하는 두 가지.**
|
||||
> ① **자기 문단이 스스로 개수를 선언하는 말**(`N가지`·`N종`·`N개`·`N건`·`N행`)은 항목을
|
||||
> 추가·삭제할 때 **같은 편집에서** 고친다. 항목 밑에 ①②③ 을 붙이는 순간 그 문단은 개수 소비처를 갖는다.
|
||||
> ② **다른 파일을 `파일:라인` 으로 가리켜 놓고 그 파일을 늘리면 인용이 조용히 어긋난다.**
|
||||
> 같은 배치에서 A를 고치고 B가 A를 가리키면 **B의 라인 번호를 다시 확인**한다.
|
||||
>
|
||||
> **드리프트를 없애는 방법: 라인 번호 대신 앵커 문자열로 가리킨다.**
|
||||
> `05-form-schemas.md:78-85` 대신 `05-form-schemas.md §C 의 8탭 표` 처럼 쓰면 파일이 늘어나도
|
||||
> 인용이 살아 있다. 소스 코드(`.cs`)는 라인 번호가 유일한 수단이라 예외지만,
|
||||
> **하네스 문서끼리는 앵커를 쓴다.**
|
||||
|
||||
그래서 **열거형 값·항목 수·인스턴스 수를 바꿨으면 반드시 소비처를 검색한다.**
|
||||
|
||||
```bash
|
||||
# 예: 옛 열거를 그대로 쓰는 곳이 남았는지 / 새 값의 소비처가 정말 있는지
|
||||
grep -rn "초기/부분/전면" .claude
|
||||
grep -rn "이어서" .claude
|
||||
```
|
||||
|
||||
> ⚠ **`.claude/` 를 검색할 때는 하위 폴더를 직접 지정해야 한다** (실측 확인).
|
||||
> `.gitignore:39` 의 `.claude/*` 때문에 ripgrep(= **`Grep` 도구**)이 `.claude` 를 통째로 건너뛴다.
|
||||
>
|
||||
> | 검색 시작점 | 결과 |
|
||||
> |---|---|
|
||||
> | 저장소 루트 · `.claude` | **0건 — 에러 없이 조용히 실패** |
|
||||
> | `.claude/agents` · `.claude/skills` | 정상 |
|
||||
>
|
||||
> 따라서 `Grep` 도구는 `path: ".claude/skills"` 처럼 **하위를 지정**해 두 번 돌리고,
|
||||
> 셸을 쓸 때만 `grep -rn ... .claude`(bash grep은 무시 규칙을 안 본다)가 한 번에 된다.
|
||||
> **이 절의 예시 명령이 `Grep` 도구가 아니라 Bash `grep -rn` 인 것은 그 때문이다 — 바꾸지 말 것.**
|
||||
>
|
||||
> `.gitignore` 의 negation 2줄은 **git 추적만 되살리고 ripgrep 프루닝은 되살리지 못한다**
|
||||
> (재현: `rg --files .claude` 는 **1건**(`settings.json` 뿐)이고 `rg --files --no-ignore .claude` 는
|
||||
> 전체를 센다. `rg --files .claude/skills` 도 정상. **숫자는 파일이 늘면 변하므로 박제하지 말고
|
||||
> 명령을 돌려 비교한다** — 판정 근거는 `1 ≪ 전체` 라는 관계다.)
|
||||
>
|
||||
> `_workspace/` 도 무시 대상이지만 **경로를 명시하면 rg가 정상 탐색한다**(`rg --files _workspace` =
|
||||
> `--no-ignore` 와 동수). 즉 `--no-ignore` 가 필요한 것은 **루트에서 glob 으로 훑을 때**이며,
|
||||
> `.claude` 는 경로를 명시해도 루트 시작점이면 프루닝된다 — 둘은 다른 증상이다.
|
||||
|
||||
판정: **새 값이 정의부에만 있고 소비처가 0건이면 그 값은 동작하지 않는다.**
|
||||
단, 위 함정 때문에 **0건을 보면 검색 시작점부터 의심한다** — 죽은 값과 못 찾은 값은 다르다.
|
||||
개수를 문서에 적을 때는 그 개수의 진실원(표·파일 목록)과 **같은 편집에서** 함께 고친다.
|
||||
|
||||
## 규칙 ↔ 바인딩 역인덱스
|
||||
|
||||
`rules.md` 조항이 하네스에서 실제로 시행되는지 점검하는 표다. **조항을 추가하면 이 표도 갱신한다** —
|
||||
바인딩 누락이 3라운드 연속 감사 지적으로 나온 패턴이라 자가 점검 수단을 둔다.
|
||||
|
||||
자가 점검 (조항별 인용 건수를 센다):
|
||||
|
||||
```bash
|
||||
grep -rhoE "rules\.md.{0,20}" .claude docs CLAUDE.md \
|
||||
| grep -oE '#[0-9]+' | sort -t'#' -k2 -n | uniq -c
|
||||
```
|
||||
|
||||
> **검색식 함정 2가지 (둘 다 실측 확인).**
|
||||
> ① 실제 표기는 `` `rules.md` #2 `` 라 **백틱이 사이에 낀다.** `rules\.md\s*#` 로 찾으면 **0건**이 나온다.
|
||||
> ② 뒤 범위를 `.{0,3}` 로 좁히면 `#15·#16` 같은 복합 인용에서 **뒤 번호를 놓친다**(#16이 1건으로 보임).
|
||||
> 문자클래스로 `·`(U+00B7)를 넣는 우회도 안 된다 — 멀티바이트라 `grep -E` 브래킷에서 깨진다.
|
||||
> 그래서 뒤 20자를 통째로 떠서 `#N`을 전부 뽑는다.
|
||||
> **0건·급감이 보이면 미바인딩이 아니라 검색식부터 의심한다** (`rules.md` #15).
|
||||
> 알려진 한계 3가지: ① `#11~13` 은 `#11` 로만 집계된다(범위 표기). ② 앞 20자 안에 `rules.md` 가
|
||||
> 없는 맨 `#N` 표기는 집계되지 않는다 — 그래서 **바인딩할 때는 반드시 `rules.md` 를 함께 쓴다.**
|
||||
> ③ 위 명령이 **Bash `grep`** 인 것은 `Grep` 도구가 `.claude` 를 프루닝하기 때문이다(위 §소비처 확인 의무).
|
||||
> 도구로 바꾸면 `.claude` 몫이 통째로 빠져 전 조항이 급감한다.
|
||||
|
||||
| 조항 | 요지 | 바인딩되어야 할 곳 |
|
||||
|---|---|---|
|
||||
| #1 | 주석·이름 맹신 금지 | 분석 스킬 3종 (조항번호 인용 + 문장 반영 병행) |
|
||||
| #2 | 수정은 승인받기 | 승인 게이트를 가진 전 스킬·에이전트 |
|
||||
| #3 | 한글 깨짐 방지 | PTOP 에이전트 3인 + 산출 스크립트를 실행하는 스킬 |
|
||||
| #4 | `.md` 200줄 상한 | `.md` 산출물을 쓰는 에이전트 전원 |
|
||||
| #5 | `@경로` 임포트 | `rules.md` 자체 (하네스는 인용하지 않아도 된다) |
|
||||
| #6 | 완료 후 `.md` 갱신 확인 | 두 오케스트레이터 + 산출물 스킬 |
|
||||
| #10 | 중간 진행 보고 | 두 오케스트레이터 + 분석 스킬 |
|
||||
| #11~13 | 출력 색상 규약 | 에이전트 전원 + 사용자에게 보고하는 스킬 |
|
||||
| #15·#16 | 추론 검증 · `[추론]` 표기 | 에이전트 전원 + 값·해석을 생성하는 스킬 (2026-08-03 신규) |
|
||||
|
||||
> **이 표에 인용 건수를 적지 않는다.** 세 라운드 연속으로 "바인딩을 늘리고 표의 숫자를 안 고쳐
|
||||
> 표가 거짓이 되는" 회귀가 났다. 숫자가 필요하면 **위 명령을 그때 실행한다** — 표는 *어디에
|
||||
> 있어야 하는가*만 말하고, *몇 건인가*는 명령이 답한다.
|
||||
>
|
||||
> #7~9·#14는 세션 전역 규약이라 하네스가 개별 인용하지 않는다 — 미바인딩이 아니다.
|
||||
> 조항이 표에 있는데 해당 위치에서 검색되지 않으면 그때가 미바인딩이다.
|
||||
|
||||
## 변경 이력
|
||||
|
||||
표가 60행을 넘어 별도 파일로 분리했다 (`rules.md` #4) → [harness-ptop-changelog.md](./harness-ptop-changelog.md)
|
||||
**하네스를 고쳤으면 그 파일에 행을 추가한다.**
|
||||
|
||||
> **주의 1:** `.claude/agents/`에 파일을 추가·이동했거나 **`CLAUDE.md`·`@` 임포트 대상 문서를 고쳤다면**
|
||||
> **세션을 재시작해야** 반영된다. 에이전트는 `Agent` 도구에 등록되지 않고, CLAUDE.md는 세션 시작
|
||||
> 시점의 판본이 계속 쓰인다 — 파일을 고쳐도 **현재 세션의 라우팅 가드는 옛날 것**이다.
|
||||
> 디스크 내용과 실제 적용 내용이 다를 수 있다는 뜻이므로, 하네스를 고친 직후 검증할 때 주의한다.
|
||||
>
|
||||
> **주의 2:** 에이전트 frontmatter에 `tools:`를 넣어 쓰기 도구를 막지 **않았다.** 여섯 에이전트 모두
|
||||
> **각자의 작업공간**(PTOP 3인 = 저장소 루트 `_workspace/`, Ubisam 3인 = `docs/[Ubisam산출물]/_workspace/`)에
|
||||
> `.md` 산출물을 직접 쓰기 때문이다. "분석 전용"은 *소스 코드를 고치지 않는다*는
|
||||
> 뜻이며, 파일 쓰기 자체를 막으면 하네스가 아무 산출물도 만들지 못한다.
|
||||
@ -1,102 +0,0 @@
|
||||
# 하네스: Ubisam 산출물
|
||||
|
||||
## 목표
|
||||
|
||||
프로젝트 산출물을 Ubisam 협업관리(칸반) 6단계 양식으로 구성·생성·재생산·검증한다.
|
||||
산출물 트리는 `docs/[Ubisam산출물]/` 하위에 미러링한다(로컬 전용 — `.gitignore` 제외 대상).
|
||||
|
||||
## 트리거 — 어느 스킬을 쓰는가
|
||||
|
||||
입력이 무엇이냐로 갈린다.
|
||||
|
||||
| 입력 | 요청 예시 | 스킬 |
|
||||
|---|---|---|
|
||||
| **없음** (트리부터) | "산출물 구조 만들어줘", "트리 스캐폴딩" | `ubisam-deliverables` |
|
||||
| **PTOP 소스코드** | "소스 기준으로 설계 산출물 최신화", "PLC 신호정의서 갱신" | `ptop-deliverables` |
|
||||
| **기존 타사 문서** | "이 xlsx를 Ubisam 양식으로 바꿔줘", "타사 산출물 재생산" | `ubisam-deliverable-rebuild` |
|
||||
| **조회만** | "상태 enum이 뭐였지", "6단계 슬롯 알려줘" | `ubisam-format-map` |
|
||||
|
||||
렌더링 전용 스킬: `.pptx` → `ubisam-ppt-make`, `.docx` → `ubisam-docx`(**사용자 전역 스킬 — 이 저장소에는 없음**),
|
||||
화면 도식 이미지 → `ui_layout_image`.
|
||||
|
||||
## 재생산 하네스 팀 구성 (`ubisam-deliverable-rebuild`)
|
||||
|
||||
| 에이전트 | 담당 | 산출 (`docs/[Ubisam산출물]/_workspace/`) |
|
||||
|---|---|---|
|
||||
| `ubisam-analyst` | 원본 구조 해부·타설비 잔재 식별·6단계 슬롯 매핑 | `01_analyst_{문서}.md` |
|
||||
| `ubisam-producer` | 매핑표대로 xlsx·pptx·md 재생산·출처 기입 | `02_producer_{문서}.md` + 산출물 파일 |
|
||||
| `ubisam-qa` | 원본↔매핑표↔산출물 교차 대조·enum·잔재·출처 검증 | `03_qa_{문서}.md` |
|
||||
|
||||
**실행 모드:** 서브 에이전트 + **점진적 생성-검증 루프**.
|
||||
producer가 문서 1건을 끝낼 때마다 qa가 즉시 검증한다 — 구조적 결함이 늦게 발견되면
|
||||
이후 산출물 전부를 되돌려야 하기 때문이다.
|
||||
|
||||
기동은 `Agent`(`model: "opus"`), 소통은 `SendMessage`, 진행 공유는 `_progress.md` 파일.
|
||||
이 환경에 `TeamCreate`/`TeamDelete`는 없다.
|
||||
|
||||
## 불변 규칙
|
||||
|
||||
- **enum 고정** — 상태 4종·유형 9종은 `ubisam-format-map`이 단일 기준. 임의 변형 시 칸반 조건부서식이 깨진다.
|
||||
- **출처 명시** — 채운 값마다 `— 출처: 파일:심볼`. qa가 이걸로 검증한다.
|
||||
- **추측 금지** — 진실원이 없으면 `(제안)` 또는 `미정 — 확인 필요`.
|
||||
- **추론 표기** — 확인 전 서술은 문장 앞에 `[추론]` (`rules.md` #15·#16). 아래 축으로 구분하며
|
||||
`[추론]`은 나머지를 **대체하지 않는다**(필요하면 병기):
|
||||
|
||||
| 상황 | 표기 |
|
||||
|---|---|
|
||||
| 원본·소스로 확인함 | `— 출처: 파일:심볼` (표기어 없음) |
|
||||
| 확인했으나 값이 없음·측정 못 함 | `미측정` · `불명확 — 확인 필요` · `미검증` · `미확인` |
|
||||
| 확인 전 서술 · 검증 불가 | 문장 앞 `[추론]` (구 `(추정)` 을 대체) |
|
||||
| 진실원 자체가 없음 | `(제안)` · `미정 — 확인 필요` |
|
||||
- **비침습** — `docs/[Ubisam산출물]/` 밖은 읽기만. 소스·`CLAUDE.md`·루트 규칙 파일 수정 금지.
|
||||
- **MD 200줄 상한** (`rules.md` #4) — 초과 시 분할 + 상대경로 링크.
|
||||
- **UTF-8** — 스크립트 실행은 `PYTHONUTF8=1 py <script>`.
|
||||
|
||||
## 구성 요소
|
||||
|
||||
**Agents:** `.claude/agents/ubisam-analyst.md`, `ubisam-producer.md`, `ubisam-qa.md`
|
||||
**Skills:** `.claude/skills/ubisam-deliverable-rebuild/`, `ubisam-deliverables/`,
|
||||
`ptop-deliverables/`, `ubisam-format-map/`, `ubisam-ppt-make/`, `ui_layout_image/`
|
||||
|
||||
## 변경 이력
|
||||
|
||||
| 날짜 | 변경 내용 | 대상 | 사유 |
|
||||
|------|----------|------|------|
|
||||
| 2026-08-03 | 하네스 문서 신규 작성 | docs/harness-ubisam.md | Ubisam 산출물 스킬 5개가 CLAUDE.md에 포인터 없이 존재했음 |
|
||||
| 2026-08-03 | 팀원 에이전트 3개 신규 생성 | agents/ubisam-{analyst,producer,qa}.md | 오케스트레이터가 참조하는 에이전트 정의가 어디에도 없었음(dead link) |
|
||||
| 2026-08-03 | `ubisam-deliverable` → `ubisam-deliverable-rebuild` 리네임 | skills/ | 복수형 `ubisam-deliverables`와 한 글자 차이로 트리거 혼동 |
|
||||
| 2026-08-03 | 형제 스킬 경계표를 3개 스킬 description에 추가 | ptop-deliverables, ubisam-deliverables, ubisam-deliverable-rebuild | 산출물 관련 스킬 3개의 트리거 경계가 겹쳤음 |
|
||||
| 2026-08-03 | 작업공간을 `docs/[Ubisam산출물]/_workspace/`로 고정 | agents/ubisam-* 3개 | 베어 `_workspace/`가 PTOP 하네스의 루트 작업공간과 문자열 충돌 |
|
||||
| 2026-08-03 | 타 프로젝트(LGIT_구미_FMM) 고정값 삭제, `_meta/project.yaml`을 유일 진실원으로 | ubisam-format-map | 잔재 소탕이 목적인 하네스가 스스로 타설비 값을 주입하고 qa가 정답으로 대조하고 있었음 |
|
||||
| 2026-08-03 | 진입 가드 추가 — 대상 미지정·에이전트 미등록 시 중단 | ubisam-deliverable-rebuild, ptop-deliverables | "산출물 업데이트해줘" 발화가 3개 스킬 중 무엇이든 잡을 수 있어 오발동 위험 |
|
||||
| 2026-08-03 | 슬롯 전용 xlsx 스크립트 부재 시 `xlsxfill` 기반 신규 작성 허용 | ubisam-producer | 02.설계 외 슬롯은 생성 수단이 없는데 수작업은 금지라 데드엔드였음 |
|
||||
| 2026-08-03 | analyst 실패 시 중단 규칙 명문화 (producer/qa 실패와 구분) | ubisam-deliverable-rebuild | "결과 없이 진행" ↔ "매핑표 없으면 시작 안 함"이 상충 |
|
||||
| 2026-08-03 | `build_02설계_xlsx.py` 4개 저장 지점에 `os.makedirs` 추가 | references/build_02설계_xlsx.py | 슬롯 폴더 부재 시 `FileNotFoundError`로 4종 전부 실패 (실행 재현·수정 후 4/4 성공 확인). 형제 pptx 스크립트에는 이미 있었음 |
|
||||
| 2026-08-03 | rebuild 경로에서는 `build_02설계_xlsx.py`를 쓰지 않도록 명시 | ubisam-producer | 그 스크립트는 PTOP 소스 데이터가 하드코딩된 무인자 스크립트라 매핑표를 반영할 입구가 없음 → 창작 금지 규칙에 스스로 걸림 |
|
||||
| 2026-08-03 | `00-harness.md` 계약 2건 정정 (멱등 정의·ref 복제 방식) | references/00-harness.md | "먼저 읽으라"고 지정된 계약이 "덮어쓰지 않는다"·"원본 템플릿 복제"로 하위 절차와 정면 충돌 |
|
||||
| 2026-08-03 | 실행 명령 3곳 정규화, `제어시퀀스_인터락_정의서.md` 파일명 통일, 표 헤더 경로 정정 | SKILL·09-pptx-integration·harness-ubisam | `PYTHONUTF8` 별도 줄·맨 파일명 실행·파일명 불일치로 조용한 실패 |
|
||||
| 2026-08-03 | `rules.md` #6(문서 갱신 확인)·#10(중간 진행 보고) 바인딩, stale을 파일에도 기록 | 두 오케스트레이터 | 규칙이 하네스 어디에도 참조되지 않았고, stale이 채팅에만 남아 폴더만 여는 사람은 구분 불가 |
|
||||
| 2026-08-03 | `background_color` spec 키 기술 삭제 | ubisam-ppt-make ×2, 09-pptx-integration | `build_deck.py`가 파싱하지 않는 키 — 넣어도 조용히 무시됨 |
|
||||
| 2026-08-03 | frontmatter description을 `>-` 블록 스칼라로 전환 | ubisam-ppt-make | 평문 스칼라 안의 `#4A8DCB`가 **YAML 주석으로 파싱돼 description이 "blue"에서 절단** — 트리거 문장이 통째로 소실돼 있었음 |
|
||||
| 2026-08-03 | `layout_selection.md` 배경색 3곳 `BG_SOFT`→`WHITE` | ubisam-ppt-make/reference | `build_deck.py:55-73`은 `WHITE`. 최신 커밋으로 추가된 파일이 코드·형제 문서와 정반대 |
|
||||
| 2026-08-03 | `matplotlib`·`soffice`·`fitz` 가용성 가드 추가 | ui_layout_image, ubisam-ppt-make | 셋 다 이 환경에 미설치. 렌더링 핵심이 첫 import에서 죽는데 폴백 부재 |
|
||||
| 2026-08-03 | `YEL` 미정의 식별자 제거, `L_alarm`에 표 높이 상한 추가 | build_deck.py | 20행 알람표가 `0.5×21=10.5"`로 슬라이드(7.5")를 넘어감 — 수정 후 7.000" 확인 |
|
||||
| 2026-08-03 | pptx 빌더의 조직·담당자·`Ajin` 단정 제거 → `_meta/project.yaml` 주입 | build_02설계_pptx.py | 하네스가 §5에서 금지한 "타 프로젝트 값 하드코딩"을 자기 산출물이 위반. 22슬라이드 재렌더로 잔존 0건 확인 |
|
||||
| 2026-08-03 | 브래킷 경로 인용 의무·POSIX 절대경로 함정 명시 | 00-harness.md | `docs/[Ubisam산출물]/`의 대괄호는 bash 문자클래스라 조용히 오해석됨 |
|
||||
| 2026-08-03 | `rules.md` #15·#16 바인딩 + 표기 축 판정표 | ubisam-analyst·producer·qa, rebuild, harness-ubisam | 신규 조항이 하네스에 인용 0건 — 미시행 상태였음. analyst의 `[추론]`을 producer가 사실로 승격시키는 경로를 qa 검증항목 11로 차단 |
|
||||
| 2026-08-03 | Phase 2에 producer·qa **기동 문장**(`Agent(subagent_type:…)`)과 절대경로 전달 지시 추가 | ubisam-deliverable-rebuild | Phase 1은 analyst를 명시 기동하는데 Phase 2는 "producer가 재생산한다"는 서술뿐이라 **누가 띄우는지가 없었다.** qa에 원본·매핑표·산출물 3경로를 주는 지시도 부재 |
|
||||
| 2026-08-03 | qa에 "검색 0건은 결함 없음이 아니다" 규칙 추가 | ubisam-qa.md | 브래킷 경로가 패턴에서 문자클래스로 먹혀 **에러 없이 0건**이 나오는데, qa가 이를 통과로 판정할 경로 |
|
||||
| 2026-08-04 | **19R.** Phase 1·2 전달 항목에 실행 모드 4종 추가, 3인에 모드 수신 규칙 이식 | rebuild/SKILL.md, ubisam-analyst·producer·qa | 모드 판별이 승인 목록 산정에만 쓰이고 이동·재사용 결정에 도달하지 못했음 (`이어서` 소비처 0건) |
|
||||
| 2026-08-04 | 표기 축 2행을 `rules.md` 판정표와 동기(3종 → **4종**, `미측정` 편입) | harness-ubisam.md | 하네스에서 34회 쓰이는 토큰이 자기 판정표에 없었음 |
|
||||
| 2026-08-04 | `SendMessage` `summary` 필수 명시, 200줄 문구에 `rules.md #4` 앵커 부착 | ubisam 3인 | 스키마상 필수 인자 누락. #4 는 앵커가 없어 자가 점검 명령에 안 잡혔음 |
|
||||
| 2026-08-04 | 데이터 전달·에러 표를 `references/protocol.md` 로 분리 | rebuild/SKILL.md | 204줄로 `rules.md` #4 자기 위반 |
|
||||
| 2026-08-04 | ppt spec 예시의 타 프로젝트 조직·담당자 → 플레이스홀더, 데모 데이터 복사 금지 경고 | ubisam-ppt-make/SKILL.md | 스킬이 금지한 "타 프로젝트 값 하드코딩"을 자기 예시가 유발 |
|
||||
| 2026-08-04 | `README.md` 디자인 지시를 §7 부재에 맞게 재작성, 유형 뱃지 11→**9**, `TODAY` 출처 정정 | ubisam-deliverables/SKILL.md, design-system.md, 05-form-schemas.md | 존재하지 않는 템플릿 지시 · enum 9종과 뱃지 수 불일치 · `xlsxfill.py` 에 없는 상수를 그 파일 절에 기재 |
|
||||
| 2026-08-04 | **20R.** producer·qa 기동에 `run_in_background: true` (21R에 재기술 문장까지 보강) | rebuild/SKILL.md | `to:"main"` 은 백그라운드 서브에이전트 전용 — 전경 기동 시 오케스트레이터 회신이 막힌다 |
|
||||
| 2026-08-04 | 조건부서식 상수 소재 정정 — `xlsxfill.py` 에 **없다**(관련 API 0건) | 00-harness.md | 계약 문서가 `ubisam-producer.md` 와 정반대를 적었고 계약이 먼저 읽힌다 |
|
||||
| 2026-08-04 | `build_deck.py`·`showcase.json` 타 프로젝트 실명 20건 → 플레이스홀더 | ubisam-ppt-make/ | 스킬이 금지한 "타 프로젝트 값 하드코딩"을 자기 데모·예시가 유발 |
|
||||
| 2026-08-04 | **21R.** `xlsxfill.py` 타 프로젝트명 제거 + 실행 지시 전체 경로화 | references/xlsxfill.py | 형제 3곳은 정규화됐는데 이 파일만 맨 파일명 실행을 지시 |
|
||||
| 2026-08-04 | 200줄 문구 `rules.md #4` 앵커 부착(스킬·에이전트 5건 + 22R에 이 문서 본문 1건), README 디자인 지시 §7 부재 반영 | ubisam-deliverables/ 외 | 앵커가 없어 자가 점검 명령에 안 잡혔고, 없는 템플릿 적용을 명령했다 |
|
||||
| 2026-08-04 | **22R.** analyst 기동에 `run_in_background: true` — 3인 전원 적용 완료 | rebuild/SKILL.md | 20R qa·21R 재기술문에 이어 마지막 누락. 단일 문서일 때 `to:"main"` 회신이 막혔다 |
|
||||
| 2026-08-04 | **23R(최종, 미채점).** `ubisam-analyst` 의 `_workspace_prev/` 이동을 **전면 금지**로 정정 | ubisam-analyst.md | 오케스트레이터는 "팀원은 안 한다"인데 analyst 는 "`전면`이면 옮긴다"로 정반대 — 이중 이동 시 산출물 유실 |
|
||||
| 2026-08-04 | 본문 200줄 문구에 `rules.md #4` 앵커 부착, `protocol.md` 베어 `_workspace/` → 전체 경로 | harness-ubisam.md, references/protocol.md | 21R 지적 2R 연속 미이행. PTOP 하네스의 루트 `_workspace/` 와 혼동 |
|
||||
@ -1,28 +0,0 @@
|
||||
# 프로젝트 개요
|
||||
|
||||
## ILSOS - OC5 PilotLine RectangleTypeWelder
|
||||
|
||||
**목표:** 각형 배터리 용접 자동화 시스템
|
||||
|
||||
**플랫폼 및 기술:**
|
||||
- OS: Windows 10 / Windows 11
|
||||
- 프레임워크: .NET Framework 4.8.1 (C# 7.3)
|
||||
- IDE: Visual Studio 2022
|
||||
- UI 프레임워크: WPF (Aurora 프레임워크 기반)
|
||||
- 플랫폼: x64 전용
|
||||
- 솔루션 파일: `ILSOS_All.sln`
|
||||
|
||||
**빌드 구성:**
|
||||
- Debug | x64
|
||||
- Release | x64
|
||||
- Simulation | x64 (Release 구성으로 매핑)
|
||||
- UserDefineUnit | x64 (Release 구성으로 매핑)
|
||||
|
||||
**머신 모듈:**
|
||||
- **ILSOS_PrismaticRD_PTOP**: 현재 유일한 활성 머신 모듈 (주요 개발 대상). `Machines/ILSOS_PrismaticRD_PTOP/`
|
||||
- 과거 `ILSOS_PrismaticScanner/Gun/CleanLaser` 모듈은 제거됨 (현재 솔루션에 csproj 없음).
|
||||
|
||||
**주의사항:**
|
||||
- WeldingComponents·External/Aurora 관련 코드 수정 시 반드시 사전 승인 필요
|
||||
- 모든 파일 수정 시 `docs/CODING_RULES.md` 확인 필수
|
||||
- 한글 포함 파일 작성/수정 시 UTF-8 인코딩 준수
|
||||
@ -1,55 +0,0 @@
|
||||
# ILSOS_PrismaticRD_PTOP 핵심 구조
|
||||
|
||||
## 폴더 구조 및 주요 컴포넌트
|
||||
|
||||
```
|
||||
ILSOS_PrismaticRD_PTOP/
|
||||
├── EquipDef.cs ← ID 상수 정의 (DeviceIds / SequenceIds / StreamMessageNames)
|
||||
├── EquipmentSetup.cs ← 통합 제어 (디바이스·시퀀스 등록, 이벤트 구독)
|
||||
├── Alarm/ ← AlarmCode_PTOP, AlarmManager_PTOP
|
||||
├── Device/
|
||||
│ ├── IO/ ← PAIX_PTOP (디지털 IO)
|
||||
│ └── PLC/ ← PLCControllerPTOP (Config / Address / Logic)
|
||||
├── Models/ ← EquipmentSpecificModel_PTOP
|
||||
├── Recipes/ ← RMSHandlerForPTOP
|
||||
├── Sequences/
|
||||
│ ├── SeqAutoRunPTOP.cs ← 자동운전 (현행 메인)
|
||||
│ ├── SeqAutoRunComponentWeld.cs / SeqAutoRunPrismatic.cs
|
||||
│ ├── SeqTestRun / SeqStreamTest / SeqEventQTest / SeqWaitWeldOrChangePage
|
||||
│ ├── SequenceManager.cs / SequenceContextEx.cs
|
||||
│ ├── Manual/ ← SeqComponentTeachingRun
|
||||
│ └── Monitoring/ ← SeqAlarmMonitor, SeqStatusMonitor
|
||||
├── Settings/ ← SettingUploadDataListForPTOP
|
||||
└── Views/
|
||||
├── Main/ ← UCMainAutoRun (+ ViewModel)
|
||||
└── Model/ ← UCEquipmentSpecificEditor
|
||||
```
|
||||
|
||||
## 주요 ID 정의 (EquipDef.cs)
|
||||
|
||||
| 클래스 | 멤버 (발췌) |
|
||||
|---------|------|
|
||||
| **DeviceIds** : CommonDeviceIds | `MassFlowMeter` (그 외 대부분 base `CommonDeviceIds` 상속) |
|
||||
| **SequenceIds** : CommonSequenceIds | `SeqAutoRunPTOP`, `SeqAutoRunTDC`, `SeqAutoRunComponentWeld`, `SeqAlarmMonitor`, `SeqStatusMonitor`, `SeqTestRun`, `SeqStreamTest`, `SeqEventQTest` |
|
||||
| **StreamMessageNames** | `MessageNameString/Double/Int/JSON/LBAD` |
|
||||
|
||||
> 이 머신엔 `MotorIds`/`RecipeIds` 클래스가 없음 — 모터/레시피 ID는 base `Common*` 또는 레시피 매니저에서 관리.
|
||||
|
||||
## 아키텍처 패턴 (3계층)
|
||||
|
||||
```
|
||||
WPF UI Layer (Views/ + ViewModels)
|
||||
↓
|
||||
Machine Logic Layer (EquipmentSetup + Sequences)
|
||||
↓
|
||||
Device Abstraction (AuroraDevices — 디바이스별 독립 모듈)
|
||||
↓
|
||||
Hardware Layer (ACS.SPiiPlusNET, Melsec, Serial/USB)
|
||||
```
|
||||
|
||||
**기술 스택:**
|
||||
- **이벤트 기반:** System.Reactive (Rx.NET)
|
||||
- **의존성 주입:** AuroraEnv 글로벌 환경
|
||||
- **메시지 큐:** String / Double / Int / JSON / LBAD 타입
|
||||
|
||||
> Aurora 프레임워크 개념·패턴·함정 상세 → `docs/Aurora에이전트레퍼런스모음/`
|
||||
@ -1,24 +0,0 @@
|
||||
# 솔루션 구조
|
||||
|
||||
## ILSOS_All.sln 구성
|
||||
|
||||
```
|
||||
ILSOS_All.sln
|
||||
├── Machines/
|
||||
│ └── ILSOS_PrismaticRD_PTOP/ ← 현재 유일한 활성 머신 모듈 (3계층 아키텍처)
|
||||
├── AuroraDevices/ ← 하드웨어 디바이스 드라이버 (22개 프로젝트)
|
||||
├── AuroraComponents/ ← WPF UI 공통 컴포넌트
|
||||
├── AuroraVision/ ← 비전 시스템 (MIL 기반)
|
||||
├── WeldingComponents/ ← 용접 공통 기능
|
||||
│ ├── WeldingCommon
|
||||
│ └── LASAGUI
|
||||
└── External/ ← Aurora 프레임워크 바이너리
|
||||
```
|
||||
|
||||
> 과거 `ILSOS_PrismaticScanner/Gun/CleanLaser` 머신 모듈은 제거됨 (솔루션에 csproj 없음).
|
||||
|
||||
## 주요 특징
|
||||
|
||||
- **모듈화:** 머신 모듈은 독립적인 디바이스 제어 및 시퀀스 구현
|
||||
- **공유 레이어:** AuroraDevices, AuroraComponents 등으로 코드 재사용
|
||||
- **표준 규칙:** WeldingComponents·External/Aurora는 수정 시 승인 필수
|
||||
@ -1,472 +0,0 @@
|
||||
using Aurora;
|
||||
using Aurora.Api;
|
||||
using Aurora.View;
|
||||
using AuroraIO;
|
||||
using AuroraLaser;
|
||||
using AuroraLaserScanner;
|
||||
using System;
|
||||
using System.Collections.Generic;
|
||||
using System.ComponentModel;
|
||||
using System.Linq;
|
||||
using System.Reactive.Linq;
|
||||
using System.Text;
|
||||
using System.Threading.Tasks;
|
||||
using System.Windows;
|
||||
using System.Windows.Input;
|
||||
using System.Windows.Threading;
|
||||
using VisionCommon;
|
||||
using WeldingCommon.Models;
|
||||
using WeldingCommon.Sequences;
|
||||
using WeldingCommon.Settings;
|
||||
using WeldingCommon.Utils;
|
||||
using static AuroraLaser.Ekspla.NL202;
|
||||
|
||||
namespace WeldingCommon.Views
|
||||
{
|
||||
public class UCScannerObjectTeachingControlBoxViewModel : NotifyPropertyChangedBase
|
||||
{
|
||||
private readonly Logger Log = new Logger("UCScannerObjectTeachingControlBoxViewModel");
|
||||
|
||||
public ICommand CMD_VisibleChanged { get; }
|
||||
|
||||
public ICommand CMD_RunScoutNormal { get; }
|
||||
public ICommand CMD_StopScoutNormal { get; }
|
||||
|
||||
public ICommand CMD_RunScoutFlyingVision { get; }
|
||||
public ICommand CMD_StopScoutFlyingVision { get; }
|
||||
|
||||
public ICommand CMD_RunTeachingRun { get; }
|
||||
public ICommand CMD_StopTeachingRun { get; }
|
||||
|
||||
public ICommand CMD_LaserGuideBeam { get; }
|
||||
public ICommand CMD_LaserReadyCheck { get; }
|
||||
public ICommand CMD_ImportObjectFromDXF { get; }
|
||||
|
||||
private readonly IAuroraEnvironment _Aurora;
|
||||
private SystemParameter _SystemParameter;
|
||||
//private readonly EquipmentInfo _EquipmentInfo;
|
||||
|
||||
private readonly Scanner _Scanner;
|
||||
private readonly Laser _Laser;
|
||||
private readonly IODevice _IODevice;
|
||||
private readonly LaserConfig _LaserConfig;
|
||||
|
||||
private ISequence _SeqScoutNormal;
|
||||
private bool _IsSequenceRunning_ScoutNormal;
|
||||
public bool IsSequenceRunning_ScoutNormal { get => _IsSequenceRunning_ScoutNormal; set => SetProperty(ref _IsSequenceRunning_ScoutNormal, value); }
|
||||
|
||||
private ISequence _SeqScoutFlyingVision;
|
||||
private bool _IsSequenceRunning_ScoutFlyingVision;
|
||||
public bool IsSequenceRunning_ScoutFlyingVision { get => _IsSequenceRunning_ScoutFlyingVision; set => SetProperty(ref _IsSequenceRunning_ScoutFlyingVision, value); }
|
||||
|
||||
private ISequence _SeqTeachingRun;
|
||||
|
||||
private bool _IsSequenceRunning_TeachingRun;
|
||||
public bool IsSequenceRunning_TeachingRun { get => _IsSequenceRunning_TeachingRun; set => SetProperty(ref _IsSequenceRunning_TeachingRun, value); }
|
||||
|
||||
private bool _IsSelectedScoutNormal;
|
||||
public bool IsSelectedScoutNormal { get => _IsSelectedScoutNormal; set => SetProperty(ref _IsSelectedScoutNormal, value); }
|
||||
|
||||
private bool _IsGuidBeam;
|
||||
public bool IsGuidBeam { get => _IsGuidBeam; set => SetProperty(ref _IsGuidBeam, value); }
|
||||
private bool _IsLaserReady;
|
||||
public bool IsLaserReady { get => _IsLaserReady; set => SetProperty(ref _IsLaserReady, value); }
|
||||
|
||||
// Object Select Type
|
||||
private bool _IsObjectSelectAll;
|
||||
public bool IsObjectSelectAll { get => _IsObjectSelectAll; set => SetProperty(ref _IsObjectSelectAll, value); }
|
||||
|
||||
private readonly DispatcherTimer _MonitorTimer;
|
||||
|
||||
private SequenceDialog _SequenceDialog;
|
||||
|
||||
private WinSequenceDiagram _WinSequenceDiagramScoutNormal;
|
||||
private WinSequenceDiagram _WinSequenceDiagramScoutFlyingVision;
|
||||
private WinSequenceDiagram _WinSequenceDiagramTeachingRun;
|
||||
private WinSequenceDiagram _WinSequenceDiagramComponentTeachingRun;
|
||||
|
||||
public UCScannerObjectTeachingControlBoxViewModel(IAuroraEnvironment aurora)
|
||||
{
|
||||
_Aurora = aurora;
|
||||
|
||||
_SystemParameter = aurora.SettingEntry[CommonSettingIds.SystemParameter] as SystemParameter;
|
||||
|
||||
_SeqScoutNormal = _Aurora.SequenceEntry[CommonSequenceIds.SeqScoutNormal];
|
||||
_SeqScoutFlyingVision = _Aurora.SequenceEntry[CommonSequenceIds.SeqScoutFlyingVision];
|
||||
|
||||
_Scanner = _Aurora.DeviceManager[CommonDeviceIds.Scanner] as Scanner;
|
||||
_Laser = _Aurora.DeviceManager[CommonDeviceIds.Laser] as Laser;
|
||||
_IODevice = _Aurora.DeviceManager[CommonDeviceIds.IODevice] as IODevice;
|
||||
|
||||
// Trumpf 레이저인 경우에는 ComponentTeachingRun 실행
|
||||
_LaserConfig = _Aurora.DeviceManager.GetDeviceConfig(CommonDeviceIds.Laser) as LaserConfig;
|
||||
_SeqTeachingRun = _Aurora.SequenceEntry[CommonSequenceIds.SeqComponentTeachingRun];
|
||||
|
||||
InitVariable();
|
||||
|
||||
CMD_VisibleChanged = new DelegateCommand(VisibleChanged);
|
||||
|
||||
CMD_RunScoutNormal = new DelegateCommand(PerformCmdRunScoutNormal);
|
||||
CMD_StopScoutNormal = new DelegateCommand(PerformCmdStopScoutNormal);
|
||||
CMD_RunScoutFlyingVision = new DelegateCommand(PerformCmdRunScoutFlyingVision);
|
||||
CMD_StopScoutFlyingVision = new DelegateCommand(PerformCmdStopScoutFlyingVision);
|
||||
CMD_RunTeachingRun = new DelegateCommand(PerformCmdRunTeachingRun);
|
||||
CMD_StopTeachingRun = new DelegateCommand(PerformCmdStopTeachingRun);
|
||||
|
||||
CMD_LaserGuideBeam = new DelegateCommand(PerformCmdLaserGuideBeam);
|
||||
CMD_LaserReadyCheck = new DelegateCommand(PerformCmdLaserReadyCheck);
|
||||
CMD_ImportObjectFromDXF = new DelegateCommand(PerformCmdImportObjectFromDXF);
|
||||
|
||||
_Aurora.EventObservable.AsObservable(AuroraSysEvent.SYS_SETTING_CHANGED)
|
||||
.ObserveOnDispatcher()
|
||||
.Subscribe(OnSettingReloaded);
|
||||
|
||||
_MonitorTimer = new DispatcherTimer();
|
||||
_MonitorTimer.Tick += OnMonitoring;
|
||||
_MonitorTimer.Interval = TimeSpan.FromMilliseconds(100);
|
||||
|
||||
}
|
||||
|
||||
private void InitVariable()
|
||||
{
|
||||
if (_SystemParameter.ScoutType == eScoutType.Normal) {
|
||||
IsSelectedScoutNormal = true;
|
||||
} else {
|
||||
IsSelectedScoutNormal = false;
|
||||
}
|
||||
|
||||
IsSequenceRunning_ScoutNormal = false;
|
||||
IsSequenceRunning_ScoutFlyingVision = false;
|
||||
IsSequenceRunning_TeachingRun = false;
|
||||
|
||||
IsGuidBeam = false;
|
||||
IsLaserReady = false;
|
||||
|
||||
IsObjectSelectAll = true;
|
||||
}
|
||||
|
||||
private void VisibleChanged(object obj)
|
||||
{
|
||||
bool visible = (bool)obj;
|
||||
if (visible) {
|
||||
_MonitorTimer.Start();
|
||||
} else {
|
||||
_MonitorTimer.Stop();
|
||||
}
|
||||
}
|
||||
|
||||
private void OnSettingReloaded(object obj)
|
||||
{
|
||||
_SystemParameter = _Aurora.SettingEntry[CommonSettingIds.SystemParameter] as SystemParameter;
|
||||
if (_SystemParameter.ScoutType == eScoutType.Normal) {
|
||||
IsSelectedScoutNormal = true;
|
||||
} else {
|
||||
IsSelectedScoutNormal = false;
|
||||
}
|
||||
}
|
||||
|
||||
private void OnMonitoring(object sender, EventArgs e)
|
||||
{
|
||||
// TODO: Laser Device 에 구현된 내용에 따르면, 일부 Laser Device 는 구현이 되어 있지 않은 상태. 항상 false
|
||||
if (_Laser.GetPilotLaserStatus()) {
|
||||
IsGuidBeam = true;
|
||||
} else {
|
||||
IsGuidBeam = false;
|
||||
}
|
||||
|
||||
if (_Laser.GetLaserReady()) {
|
||||
IsLaserReady = true;
|
||||
|
||||
// TODO: PRIBAT_L1, PRIBAT_L2 는 IO에 LaserOnLamp 를 켜고 끄는게 필요함.
|
||||
// TODO: 우선 주석 처리 해 둠. 레이저 Type 별로 달라서 그런건지 확인하고, 어떻게 공통으로 구현할지를 생각해서 추가해 두자
|
||||
//_iODevice._iOUnit.WriteDoBit(Convert.ToInt32(ePDOAddress.LaserOnLampOn), true);
|
||||
|
||||
} else {
|
||||
IsLaserReady = false;
|
||||
// TODO: PRIBAT_L1, PRIBAT_L2 는 IO에 LaserOnLamp 를 켜고 끄는게 필요함.
|
||||
// TODO: 우선 주석 처리 해 둠. 레이저 Type 별로 달라서 그런건지 확인하고, 어떻게 공통으로 구현할지를 생각해서 추가해 두자
|
||||
//_iODevice._iOUnit.WriteDoBit(Convert.ToInt32(ePDOAddress.LaserOnLampOn), true);
|
||||
}
|
||||
|
||||
// TODO: PRIBAT_L1, PRIBAT_L2 는 Blow 의 상태 check 가 들어 있음. 장비 한정이므로 이를 check 하는 것을 modelItem 이나 setting 으로 빼서 진행되도록 함.
|
||||
}
|
||||
|
||||
private void PerformCmdRunScoutNormal(object obj)
|
||||
{
|
||||
var result = MessageUtil.ShowYesNoMessageDialog("Scanner Scout", "Start Scanner Scout Normal Sequence?");
|
||||
if (result == false) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (VisionRecipeManager.GetFovInfos().Count == 0) {
|
||||
MessageUtil.ShowWarningToast(string.Format("Please check the Vision Recipe of the currently active Recipe."));
|
||||
return;
|
||||
}
|
||||
|
||||
if (_SeqScoutNormal.RunState == SequenceRunState.Running) {
|
||||
MessageUtil.ShowWarningToast(string.Format("이미 시퀀스가 Start 상태입니다.", "SeqScoutNormal"), Log);
|
||||
return;
|
||||
}
|
||||
|
||||
var scoutSeqParams = new ScoutSeqParams(VisionRecipeManager.GetFovInfos()[0], eDisplayType.Machine_B);
|
||||
var param = new SeqScoutNormal_InitParam() {
|
||||
IsRealTimeScout = false,
|
||||
ScoutSeqParams = scoutSeqParams,
|
||||
};
|
||||
|
||||
PopupSequenceDiagram(ref _WinSequenceDiagramScoutNormal, CommonSequenceIds.SeqScoutNormal, param);
|
||||
|
||||
IsSequenceRunning_ScoutNormal = true;
|
||||
_SeqScoutNormal.Start(param, OnCompleteScoutNormal);
|
||||
|
||||
}
|
||||
|
||||
private void OnCompleteScoutNormal(SequenceActionResult res)
|
||||
{
|
||||
if (res != null) {
|
||||
if (res.Param is SeqScoutNormal_OutParam result && result.Success == true) {
|
||||
IsSequenceRunning_ScoutNormal = false;
|
||||
MessageUtil.ShowSuccessToast(string.Format("Success SeqScoutNormal"));
|
||||
|
||||
CloseSequenceDiagram(_WinSequenceDiagramScoutNormal);
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
if (_Laser.GetLaserReady()) {
|
||||
_Laser.LaserOff();
|
||||
}
|
||||
|
||||
IsSequenceRunning_ScoutNormal = false;
|
||||
MessageUtil.ShowWarningToast(string.Format("Fail SeqScoutNormal"));
|
||||
}
|
||||
|
||||
private void PerformCmdStopScoutNormal(object obj)
|
||||
{
|
||||
if (_SeqScoutNormal.RunState == SequenceRunState.Idle) {
|
||||
return;
|
||||
}
|
||||
|
||||
IsSequenceRunning_ScoutNormal = false;
|
||||
_SeqScoutNormal.Stop();
|
||||
}
|
||||
|
||||
private void PerformCmdRunScoutFlyingVision(object obj)
|
||||
{
|
||||
var result = MessageUtil.ShowYesNoMessageDialog("Flying Vision", "Start Scanner Scout Flying Vision Sequence?");
|
||||
if (result == false) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (VisionRecipeManager.GetFovInfos().Count == 0) {
|
||||
MessageUtil.ShowWarningToast(string.Format("Please check the Vision Recipe of the currently active Recipe."));
|
||||
return;
|
||||
}
|
||||
|
||||
if (_SeqScoutFlyingVision.RunState == SequenceRunState.Running) {
|
||||
MessageUtil.ShowWarningToast(string.Format("이미 시퀀스가 Start 상태입니다.", "SeqScoutFlyingVision"), Log);
|
||||
return;
|
||||
}
|
||||
|
||||
var scoutSeqParams = new ScoutSeqParams(VisionRecipeManager.GetFovInfos()[0], eDisplayType.Machine_B);
|
||||
var param = new SeqScoutFlyingVision_InitParam() {
|
||||
IsRealTimeScout = false,
|
||||
ScoutSeqParams = scoutSeqParams,
|
||||
SequenceAutoRunCount = 0,
|
||||
WeldingScannerListNo = eListNo.LIST2,
|
||||
};
|
||||
|
||||
PopupSequenceDiagram(ref _WinSequenceDiagramScoutFlyingVision, CommonSequenceIds.SeqScoutFlyingVision, param);
|
||||
|
||||
IsSequenceRunning_ScoutFlyingVision = true;
|
||||
_SeqScoutFlyingVision.Start(param, OnCompleteScoutFlyingVision);
|
||||
|
||||
}
|
||||
|
||||
private void OnCompleteScoutFlyingVision(SequenceActionResult res)
|
||||
{
|
||||
if (res != null) {
|
||||
if (res.Param is SeqScoutFlyingVision_OutParam result && result.Success == true) {
|
||||
IsSequenceRunning_ScoutFlyingVision = false;
|
||||
MessageUtil.ShowSuccessToast(string.Format("Success SeqScoutFlyingVision"));
|
||||
|
||||
CloseSequenceDiagram(_WinSequenceDiagramScoutFlyingVision);
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
if (_Laser.GetLaserReady()) {
|
||||
_Laser.LaserOff();
|
||||
}
|
||||
|
||||
IsSequenceRunning_ScoutFlyingVision = false;
|
||||
MessageUtil.ShowWarningToast(string.Format("Fail SeqScoutFlyingVision"));
|
||||
}
|
||||
|
||||
private void PerformCmdStopScoutFlyingVision(object obj)
|
||||
{
|
||||
if (_SeqScoutFlyingVision.RunState == SequenceRunState.Idle) {
|
||||
return;
|
||||
}
|
||||
|
||||
IsSequenceRunning_ScoutFlyingVision = false;
|
||||
_SeqScoutFlyingVision.Stop();
|
||||
}
|
||||
|
||||
private void PerformCmdRunTeachingRun(object obj)
|
||||
{
|
||||
var result = MessageUtil.ShowYesNoMessageDialog("Teaching Run", "Start TeachingRun Sequence?");
|
||||
if (result == false) {
|
||||
return;
|
||||
}
|
||||
|
||||
if (IsLaserReady == false) {
|
||||
MessageUtil.ShowWarningToast(string.Format("Please check Laser Ready."));
|
||||
return;
|
||||
}
|
||||
|
||||
// TODO: PRIBAT_L1, PRIBAT_L2 에서 Suction 과 CLAMP 상태 등에 따라 Laser 가 나가지 않도록 해야 함.
|
||||
// TODO: 이 부분은, Delegate 를 사용해서, Interlock 을 각 장비별로 설정할 수 있도록 해주는게 좋겠음.
|
||||
|
||||
if (_SeqTeachingRun.RunState == SequenceRunState.Running) {
|
||||
MessageUtil.ShowWarningToast(string.Format("이미 시퀀스가 Start 상태입니다.", "SeqTeachingRun"), Log);
|
||||
return;
|
||||
}
|
||||
|
||||
// TODO: NeedSetLaserTiming 는 트럼프 레이저 를 사용할 때, UploadWeldingList Sequence 에서 LaserTiming Set 을 해야 할때 사용함.
|
||||
// TODO: SMW 와 LHS 는 트럼프 레이저를 사용하지 않으므로 false, PRIBAT_L1 과 PRIBAT_L2 할때 LaserType 을 읽어서 설정하는 것으로 추가하자
|
||||
|
||||
var currentModelInfo = EquipmentSpecificModelUtil.GetCurrentRecipeEquipmentSpecificModel();
|
||||
if (currentModelInfo.equipmentSpecificModel == null) {
|
||||
MessageUtil.ShowWarningToast(string.Format("선택된 model 이 없습니다.", "SeqTeachingRun"));
|
||||
return;
|
||||
}
|
||||
|
||||
var intervalTimeBlowOn = 0;
|
||||
var intervalTimeBlowOff = 0;
|
||||
|
||||
if (currentModelInfo.equipmentSpecificModel.UseBlow) {
|
||||
intervalTimeBlowOn = currentModelInfo.equipmentSpecificModel.IntervalTimeBlowOn;
|
||||
intervalTimeBlowOff = currentModelInfo.equipmentSpecificModel.IntervalTimeBlowOff;
|
||||
}
|
||||
|
||||
var param = new SeqTeachingRun_InitParam() {
|
||||
IsObjectSelectAll = IsObjectSelectAll,
|
||||
|
||||
//UseStream = _EquipmentInfo.UseStream,
|
||||
UseStream = currentModelInfo.equipmentSpecificModel.UseStream,
|
||||
|
||||
UseBlow = currentModelInfo.equipmentSpecificModel.UseBlow,
|
||||
IntervalTimeBlowOn = intervalTimeBlowOn,
|
||||
IntervalTimeBlowOff = intervalTimeBlowOff,
|
||||
|
||||
NeedSetLaserTiming = false,
|
||||
};
|
||||
|
||||
PopupSequenceDiagram(ref _WinSequenceDiagramTeachingRun, CommonSequenceIds.SeqComponentTeachingRun, param);
|
||||
|
||||
IsSequenceRunning_TeachingRun = true;
|
||||
_SeqTeachingRun.Start(param, OnCompleteTeachingRun);
|
||||
|
||||
}
|
||||
|
||||
private void OnCompleteTeachingRun(SequenceActionResult res)
|
||||
{
|
||||
if (res != null) {
|
||||
if (res.Param is SeqTeachingRun_OutParam result && result.Success == true) {
|
||||
IsSequenceRunning_TeachingRun = false;
|
||||
MessageUtil.ShowSuccessToast(string.Format("Success SeqTeachingRun"));
|
||||
|
||||
CloseSequenceDiagram(_WinSequenceDiagramTeachingRun);
|
||||
return;
|
||||
}
|
||||
}
|
||||
|
||||
if (_Laser.GetLaserReady()) {
|
||||
_Laser.LaserOff();
|
||||
}
|
||||
|
||||
IsSequenceRunning_TeachingRun = false;
|
||||
MessageUtil.ShowWarningToast(string.Format("Fail SeqTeachingRun"));
|
||||
}
|
||||
|
||||
private void PerformCmdStopTeachingRun(object obj)
|
||||
{
|
||||
IsSequenceRunning_TeachingRun = false;
|
||||
if (_SeqTeachingRun.RunState == SequenceRunState.Idle) {
|
||||
return;
|
||||
}
|
||||
|
||||
_SeqTeachingRun.Stop();
|
||||
}
|
||||
|
||||
|
||||
private void PopupSequenceDiagram(ref WinSequenceDiagram winSequenceDiagram, string seqId, object param)
|
||||
{
|
||||
if (winSequenceDiagram == null) {
|
||||
winSequenceDiagram = new WinSequenceDiagram(seqId);
|
||||
winSequenceDiagram.Closing += ClosingEvent;
|
||||
winSequenceDiagram.SetParam(new SeqDrawerParam() {
|
||||
SequenceId = seqId,
|
||||
DiagramType = eDiagramType.Tree,
|
||||
LineType = eLineType.Straight,
|
||||
IsShowSubSequence = false,
|
||||
VisibleKeys = new List<string>()
|
||||
});
|
||||
|
||||
winSequenceDiagram.Owner = Application.Current.MainWindow;
|
||||
winSequenceDiagram.Width = 600;
|
||||
winSequenceDiagram.SequenceParam = param;
|
||||
winSequenceDiagram.Show();
|
||||
} else {
|
||||
winSequenceDiagram.SequenceParam = param;
|
||||
winSequenceDiagram.WindowState = WindowState.Normal;
|
||||
winSequenceDiagram.Show();
|
||||
}
|
||||
}
|
||||
private void CloseSequenceDiagram(WinSequenceDiagram winSequenceDiagram)
|
||||
{
|
||||
Application.Current.Dispatcher.Invoke(() => {
|
||||
if (winSequenceDiagram != null) {
|
||||
winSequenceDiagram.Close();
|
||||
}
|
||||
});
|
||||
}
|
||||
private void ClosingEvent(object sender, CancelEventArgs e)
|
||||
{
|
||||
e.Cancel = true;
|
||||
(sender as Window).Hide();
|
||||
}
|
||||
|
||||
private void PerformCmdLaserGuideBeam(object obj)
|
||||
{
|
||||
if (!_Laser.GetPilotLaserSetBitStatus()) {
|
||||
_Laser.PilotLaserOn();
|
||||
} else {
|
||||
_Laser.PilotLaserOff();
|
||||
}
|
||||
}
|
||||
|
||||
private void PerformCmdLaserReadyCheck(object obj)
|
||||
{
|
||||
if (!_Laser.GetLaserReady()) {
|
||||
_Laser.LaserOn(); //실질적으로 Laser Ready On을 의미함
|
||||
} else {
|
||||
_Laser.LaserOff();
|
||||
}
|
||||
}
|
||||
|
||||
private void PerformCmdImportObjectFromDXF(object obj)
|
||||
{
|
||||
System.Windows.Forms.FileDialog dlg = new System.Windows.Forms.OpenFileDialog();
|
||||
dlg.InitialDirectory = @"D:\share\jungwoo.jin\모바일글라스도면 외 (3) 파일_20241028";
|
||||
dlg.DefaultExt = "dxf";
|
||||
dlg.Filter = "DXF 도면 파일 (*.dxf)|*.dxf";
|
||||
dlg.Title = "DXF 도면 열기";
|
||||
|
||||
if (dlg.ShowDialog() == System.Windows.Forms.DialogResult.OK) {
|
||||
CommonHelper.GetMainPage().DxfParser(dlg.FileName);
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
@ -1,397 +0,0 @@
|
||||
# ILSOS_PrismaticRD_PTOP Recipe 동적 활성화 분석
|
||||
|
||||
**분석 일시:** 2026-06-16 13:59:37
|
||||
**대상:** SeqAutoRunPTOP.cs + Aurora RecipeManager 메커니즘
|
||||
**목표:** PLC에서 RecipeNum + PageNum을 받아 동적으로 Recipe를 변경하고 공정별 페이지 선택하는 설계
|
||||
|
||||
---
|
||||
|
||||
## 1. 현재 상황 분석
|
||||
|
||||
### 1.1 현재 구조
|
||||
```
|
||||
SeqAutoRunPTOP.cs (Line 215-216):
|
||||
├─ activatedRecipeId = Application.Current.AuroraEnv().RecipeManager.ActivatedRecipe().Id
|
||||
├─ recipeName = RecipeHelper.SearchRecipeItem(activatedRecipeId)
|
||||
└─ 활성화된 Recipe 1개에 대해서만 작동
|
||||
└─ PLC에서 PageNum(1,2)만 받음 → 해당 Recipe의 페이지 선택
|
||||
```
|
||||
|
||||
### 1.2 현재 제약사항
|
||||
- **단일 Recipe 지원**: 미리 활성화된 Recipe 1개만 사용
|
||||
- **동적 변경 불가**: Recipe 활성화 코드 없음 (UI에서만 가능)
|
||||
- **공정 분리 불가**: 3개 공정(CC, CAP, U-Frame)을 구분할 수 없음
|
||||
|
||||
---
|
||||
|
||||
## 2. Aurora RecipeManager 메커니즘 분석
|
||||
|
||||
### 2.1 Recipe 활성화 방법
|
||||
|
||||
**발견 위치:** `RMSHandlerForScanner.cs` Line 173
|
||||
|
||||
```csharp
|
||||
// Recipe 활성화 핵심 메서드
|
||||
_aurora.RecipeManager.ActivateRecipe(recipe.Id, "RMS Request");
|
||||
```
|
||||
|
||||
**메서드 시그니처:**
|
||||
```csharp
|
||||
void ActivateRecipe(int recipeId, string reason)
|
||||
```
|
||||
|
||||
**매개변수:**
|
||||
- `recipeId` (int): Recipe의 고유 ID
|
||||
- `reason` (string): 활성화 사유 (로그/감사용) - 예: "RMS Request", "Manual Change", "Auto Selection"
|
||||
|
||||
### 2.2 Recipe 정보 조회
|
||||
|
||||
**Recipe ID로 조회:**
|
||||
```csharp
|
||||
// RMSHandlerForScanner.cs Line 125
|
||||
var recipe = _recipeEntry.Recipes().FirstOrDefault(x => x.Id == recipeId);
|
||||
```
|
||||
|
||||
**Recipe 이름으로 조회:**
|
||||
```csharp
|
||||
// RMSHandlerForScanner.cs Line 132
|
||||
var recipeInfo = RecipeHelper.getRecipeInfo(recipe.Name);
|
||||
```
|
||||
|
||||
### 2.3 Recipe 로드/저장
|
||||
|
||||
**Recipe 로드 (활성화 후):**
|
||||
```csharp
|
||||
// RMSHandlerForScanner.cs Line 136
|
||||
RecipeHelper.ReloadRecipe(recipe.Name);
|
||||
```
|
||||
|
||||
**Recipe 저장:**
|
||||
```csharp
|
||||
// RMSHandlerForScanner.cs Line 146
|
||||
RecipeHelper.SaveRecipe(recipe.Name);
|
||||
```
|
||||
|
||||
### 2.4 이벤트 트리거
|
||||
|
||||
**Recipe 변경 이벤트:**
|
||||
```csharp
|
||||
// EquipDefCommon.cs Line 145
|
||||
public const string EVENT_CHANGE_RECIPE_INFO = "EventChangeRecipeInfo";
|
||||
|
||||
// RMSHandlerForScanner.cs Line 56-59 (구독 예시)
|
||||
aurora.EventObservable.AsObservable(CommonEventIds.EVENT_CHANGE_RECIPE_INFO)
|
||||
.ObserveOnDispatcher()
|
||||
.Select(param => (RecipeInfo)param.Param)
|
||||
.Subscribe(OnUpdateCurrentActivatedRecipe);
|
||||
```
|
||||
|
||||
**활성화 완료 흐름:**
|
||||
```
|
||||
RecipeManager.ActivateRecipe(id, reason)
|
||||
↓ (EVENT_CHANGE_RECIPE_INFO 발행)
|
||||
↓
|
||||
RMSHandlerForScanner.OnUpdateCurrentActivatedRecipe(RecipeInfo info)
|
||||
├─ RecipeHelper.ReloadRecipe(info.Name)
|
||||
└─ UploadActivatedRecipeParameter()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 변경 요구사항 분석
|
||||
|
||||
### 3.1 요구사항
|
||||
|
||||
| # | 요구사항 | 현재 상태 | 변경 필요 |
|
||||
|---|---------|---------|----------|
|
||||
| 1 | 3개 공정 지원 (CC, CAP, U-Frame) | 단일 Recipe만 지원 | ✓ 다중 Recipe 매핑 |
|
||||
| 2 | 각 공정별 Recipe 활성화 | UI에서만 가능 | ✓ PLC 신호로 동적 활성화 |
|
||||
| 3 | RecipeNum + PageNum 수신 | PageNum만 수신 | ✓ RecipeNum WORD 추가 |
|
||||
| 4 | RecipeNum → RecipeId 매핑 | 없음 | ✓ 설정 테이블 추가 |
|
||||
| 5 | UI에서 공정별 RecipeNum 관리 | 없음 | ✓ 설정 UI 추가 (후순위) |
|
||||
|
||||
### 3.2 예상 동작
|
||||
|
||||
**변경 전:**
|
||||
```
|
||||
PLC → ReadWord(PLC_PAGE_NO) → PageNum(1,2)
|
||||
↓
|
||||
SeqAutoRunPTOP → 활성된 Recipe의 Page 선택
|
||||
↓
|
||||
_SelectedObjectList 구성
|
||||
```
|
||||
|
||||
**변경 후:**
|
||||
```
|
||||
PLC → ReadWord(PLC_RECIPE_NO) + ReadWord(PLC_PAGE_NO)
|
||||
↓
|
||||
SeqAutoRunPTOP → RecipeNum으로 Recipe 동적 활성화
|
||||
↓
|
||||
RecipeManager.ActivateRecipe(mappedRecipeId, "PLC Request")
|
||||
↓
|
||||
EVENT_CHANGE_RECIPE_INFO 발생
|
||||
↓
|
||||
해당 Recipe 로드 + 설정 적용
|
||||
↓
|
||||
Page 선택 → _SelectedObjectList 구성
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 구현 계획
|
||||
|
||||
### Phase 1: 설정 테이블 정의
|
||||
|
||||
**위치:** SeqAutoRunPTOP.cs 또는 별도 설정 클래스
|
||||
|
||||
```csharp
|
||||
// 공정별 RecipeNum ↔ RecipeId 매핑
|
||||
public class ProcessRecipeMapping
|
||||
{
|
||||
public enum eProcessType
|
||||
{
|
||||
CC = 1, // 공정1
|
||||
CAP = 2, // 공정2
|
||||
UFrame = 3 // 공정3
|
||||
}
|
||||
|
||||
// 매핑 테이블 (사용자 설정 후 저장)
|
||||
private Dictionary<eProcessType, int> _recipeIdMap = new Dictionary<eProcessType, int>()
|
||||
{
|
||||
{ eProcessType.CC, 101 }, // CC 공정 → Recipe ID 101
|
||||
{ eProcessType.CAP, 102 }, // CAP 공정 → Recipe ID 102
|
||||
{ eProcessType.UFrame, 103 } // U-Frame 공정 → Recipe ID 103
|
||||
};
|
||||
|
||||
public int GetRecipeId(eProcessType process) => _recipeIdMap[process];
|
||||
public int GetRecipeId(int recipeNum) => _recipeIdMap[(eProcessType)recipeNum];
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 2: PLC 신호 정의
|
||||
|
||||
**SeqAutoRunPTOP.cs에 추가:**
|
||||
|
||||
```csharp
|
||||
// PLC에서 수신할 WORD 정의
|
||||
private int _plcRecipeNum = 0; // PLC_RECIPE_NO (Word)
|
||||
private int _plcPageNum = 0; // PLC_PAGE_NO (Word)
|
||||
|
||||
// CheckPageNo 시퀀스 수정 위치
|
||||
// Line 354: plcPageNoList.Add(_PLC.ReadWord(eWordInput.PLC_PAGE_NO).data);
|
||||
//
|
||||
// 변경 후:
|
||||
// ┌─────────────────────────────────────────┐
|
||||
// │ Step 1: RecipeNum 읽기 │
|
||||
// │ _plcRecipeNum = _PLC.ReadWord(...) │
|
||||
// │ │
|
||||
// │ Step 2: RecipeId 매핑 │
|
||||
// │ int recipeId = mappingTable.GetRecipeId(_plcRecipeNum) │
|
||||
// │ │
|
||||
// │ Step 3: Recipe 활성화 │
|
||||
// │ _AuroraEnv.RecipeManager.ActivateRecipe │
|
||||
// │ (recipeId, "PLC Request") │
|
||||
// │ │
|
||||
// │ Step 4: Recipe 로드 완료 대기 │
|
||||
// │ (이벤트 핸들러에서 처리) │
|
||||
// │ │
|
||||
// │ Step 5: PageNum 읽기 │
|
||||
// │ _plcPageNum = _PLC.ReadWord(...) │
|
||||
// └─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Phase 3: 코드 구조 변경
|
||||
|
||||
**SeqAutoRunPTOP.CheckPageNo() 수정 전략:**
|
||||
|
||||
```csharp
|
||||
// 현재 (Line 282-333):
|
||||
private SequenceActionResult CheckPageNo(SequenceContext context, string id, SequenceActionResult param)
|
||||
{
|
||||
// PLC_PAGE_CHANGE_REQ 대기 → PageNum 읽기 → 완료
|
||||
}
|
||||
|
||||
// 변경 후:
|
||||
private SequenceActionResult CheckPageNo(SequenceContext context, string id, SequenceActionResult param)
|
||||
{
|
||||
// Step 1: PLC_PAGE_CHANGE_REQ 대기 (기존 로직)
|
||||
// Step 2: RecipeNum 읽기 추가
|
||||
// Step 3: Recipe 활성화 (동기/비동기 결정)
|
||||
// Step 4: Recipe 로드 완료 확인
|
||||
// Step 5: PageNum 읽기 (기존 로직)
|
||||
// Step 6: 완료
|
||||
}
|
||||
```
|
||||
|
||||
**Recipe 활성화 이벤트 핸들러:**
|
||||
|
||||
```csharp
|
||||
// SeqAutoRunPTOP 클래스 내부
|
||||
private bool _recipeChangeCompleted = false;
|
||||
|
||||
// Aurora 이벤트 구독 (Sequence_Enter에서)
|
||||
_AuroraEnv.EventObservable
|
||||
.AsObservable(CommonEventIds.EVENT_CHANGE_RECIPE_INFO)
|
||||
.ObserveOnDispatcher()
|
||||
.Subscribe(msg =>
|
||||
{
|
||||
Log.I("[CheckPageNo] Recipe Change Event 감지");
|
||||
_recipeChangeCompleted = true;
|
||||
});
|
||||
|
||||
// CheckPageNo에서 완료 대기
|
||||
private SequenceActionResult WaitForRecipeChange(SequenceContext context, int timeoutSec = 5)
|
||||
{
|
||||
_recipeChangeCompleted = false;
|
||||
var startTime = DateTime.Now;
|
||||
|
||||
while (!context.Stopped && !_recipeChangeCompleted)
|
||||
{
|
||||
if (DateTime.Now.Subtract(startTime).TotalSeconds > timeoutSec)
|
||||
{
|
||||
Log.E("[CheckPageNo] Recipe Change Timeout");
|
||||
return null;
|
||||
}
|
||||
Thread.Sleep(10);
|
||||
}
|
||||
|
||||
Log.I("[CheckPageNo] Recipe Change 완료");
|
||||
return SequenceAction.Ok();
|
||||
}
|
||||
```
|
||||
|
||||
### Phase 4: RecipeHelper를 통한 로드 확인
|
||||
|
||||
```csharp
|
||||
// RMSHandlerForScanner.cs의 OnUpdateCurrentActivatedRecipe 패턴 활용
|
||||
|
||||
private void OnRecipeActivated(RecipeInfo info)
|
||||
{
|
||||
Log.I($"[SeqAutoRunPTOP] Recipe 활성화됨: {info.Name}");
|
||||
|
||||
// Recipe 파라미터 로드
|
||||
RecipeHelper.ReloadRecipe(info.Name);
|
||||
|
||||
// 필요시 로드 검증
|
||||
var loadedRecipe = RecipeHelper.getRecipeInfo(info.Name);
|
||||
if (loadedRecipe == null)
|
||||
{
|
||||
Log.E("[SeqAutoRunPTOP] Recipe 로드 실패");
|
||||
AlarmManager.SetAlarm(AlarmCode.RECIPE_LOAD_FAILED);
|
||||
return;
|
||||
}
|
||||
|
||||
Log.I("[SeqAutoRunPTOP] Recipe 로드 완료");
|
||||
_recipeChangeCompleted = true;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 구현 순서 (권장)
|
||||
|
||||
### Step 1: 설정 클래스 생성
|
||||
- `ProcessRecipeMapping` 클래스 작성
|
||||
- RecipeNum ↔ RecipeId 매핑 설정
|
||||
|
||||
### Step 2: SeqAutoRunPTOP.cs 수정
|
||||
1. 이벤트 핸들러 추가 (Recipe 활성화 완료 감지)
|
||||
2. CheckPageNo에 RecipeNum 읽기 로직 추가
|
||||
3. RecipeManager.ActivateRecipe() 호출
|
||||
4. Recipe 로드 완료 대기
|
||||
|
||||
### Step 3: PLC 통신 검증
|
||||
- ReadWord(RecipeNum) 정상 작동 확인
|
||||
- Recipe 활성화 타이밍 검증
|
||||
- PageNum 읽기가 Recipe 로드 후 실행되는지 확인
|
||||
|
||||
### Step 4: 에러 처리 추가
|
||||
- Recipe ID 미존재 시 처리
|
||||
- Recipe 로드 타임아웃 처리
|
||||
- Fallback 로직 (기본 Recipe 활용)
|
||||
|
||||
### Step 5: UI 설정 추가 (후순위)
|
||||
- 공정별 RecipeNum 설정 화면
|
||||
- 매핑 테이블 UI 편집
|
||||
|
||||
---
|
||||
|
||||
## 6. 예상 코드 위치
|
||||
|
||||
| 파일 | 라인 | 수정 내용 |
|
||||
|------|------|---------|
|
||||
| SeqAutoRunPTOP.cs | 50-100 | 클래스 멤버 추가 (매핑, 이벤트) |
|
||||
| SeqAutoRunPTOP.cs | 202-240 | Sequence_Enter에서 이벤트 구독 |
|
||||
| SeqAutoRunPTOP.cs | 282-333 | CheckPageNo에 RecipeNum 읽기 추가 |
|
||||
| 별도 파일 | - | ProcessRecipeMapping 클래스 |
|
||||
|
||||
---
|
||||
|
||||
## 7. 핵심 검증 포인트
|
||||
|
||||
1. **RecipeManager.ActivateRecipe() 호출 후 Event 발생 타이밍**
|
||||
- 동기인가 비동기인가?
|
||||
- 즉시 발생하는가 아니면 지연되는가?
|
||||
|
||||
2. **RecipeHelper.ReloadRecipe()의 필요성**
|
||||
- EVENT_CHANGE_RECIPE_INFO에서 자동으로 로드되는가?
|
||||
- 수동으로 ReloadRecipe를 호출해야 하는가?
|
||||
|
||||
3. **_SelectedObjectList 업데이트 시점**
|
||||
- Recipe 활성화 후 새 Recipe의 Canvas가 로드되는가?
|
||||
- 별도로 처리해야 하는가?
|
||||
|
||||
4. **타이밍 문제**
|
||||
- RecipeNum 읽기 → 활성화 → 로드 완료 → PageNum 읽기
|
||||
- 각 단계의 예상 소요시간?
|
||||
|
||||
---
|
||||
|
||||
## 8. 참고 코드
|
||||
|
||||
### RecipeManager.ActivateRecipe 사용 사례
|
||||
**파일:** `RMSHandlerForScanner.cs` Line 173
|
||||
|
||||
```csharp
|
||||
var preActivatedRecipe = _aurora.RecipeManager.ActivatedRecipe();
|
||||
_aurora.RecipeManager.ActivateRecipe(recipe.Id, "RMS Request");
|
||||
MessageUtil.ShowToast($"RMS Change Recipe ... ( {preActivatedRecipe.Id} -> {recipe.Id} )", Log);
|
||||
```
|
||||
|
||||
### EVENT_CHANGE_RECIPE_INFO 구독 사례
|
||||
**파일:** `RMSHandlerForScanner.cs` Line 56-66
|
||||
|
||||
```csharp
|
||||
aurora.EventObservable.AsObservable(CommonEventIds.EVENT_CHANGE_RECIPE_INFO)
|
||||
.ObserveOnDispatcher()
|
||||
.Select(param => (RecipeInfo)param.Param)
|
||||
.Subscribe(OnUpdateCurrentActivatedRecipe);
|
||||
|
||||
private void OnUpdateCurrentActivatedRecipe(RecipeInfo info)
|
||||
{
|
||||
RecipeHelper.ReloadRecipe(info.Name);
|
||||
UploadActivatedRecipeParameter();
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. 다음 단계
|
||||
|
||||
1. **코드 분석 후 결정 필요:**
|
||||
- RecipeManager.ActivateRecipe()의 정확한 동작 방식 (동기/비동기)
|
||||
- EVENT_CHANGE_RECIPE_INFO 발생 타이밍
|
||||
- RecipeHelper.ReloadRecipe()의 필요성
|
||||
|
||||
2. **설계 결정:**
|
||||
- RecipeNum을 WORD로 받을 것인가? (또는 별도 IO?)
|
||||
- 매핑 테이블을 하드코딩할 것인가? (또는 설정 파일?)
|
||||
- Fallback 시나리오 정의
|
||||
|
||||
3. **구현 시작:**
|
||||
- 위 확인 후 Phase 1부터 순차 진행
|
||||
|
||||
---
|
||||
|
||||
**작성자:** Claude Code Analysis
|
||||
**검토 필요:** 실제 Aurora RecipeManager 메서드 시그니처 확인 필요
|
||||
@ -1,430 +0,0 @@
|
||||
# Recipe 동적 활성화 — 깊이 있는 분석 (상세 검증)
|
||||
|
||||
**분석 일시:** 2026-06-16 13:59:37
|
||||
**목표:** RecipeManager.ActivateRecipe()의 동작 방식과 이벤트 발생 타이밍, ReloadRecipe()를 통한 변경 검증 방법 명확화
|
||||
|
||||
---
|
||||
|
||||
## 1. RecipeManager.ActivateRecipe() 상세 분석
|
||||
|
||||
### 1.1 메서드 시그니처와 반환값
|
||||
|
||||
**위치:** `UCRecipeSelectViewModel.cs` Line 112
|
||||
|
||||
```csharp
|
||||
int err = _RecipeManager.ActivateRecipe(SelectedRecipe.Id, "USER_via_CustomUI");
|
||||
if (err != E1.OK) {
|
||||
LOG.FuncE("Activate Fail");
|
||||
}
|
||||
ActivatedRecipe = SelectedRecipe;
|
||||
```
|
||||
|
||||
**결론: 동기(Synchronous) 작동**
|
||||
|
||||
| 특성 | 값 | 근거 |
|
||||
|------|-----|------|
|
||||
| **작동 방식** | **동기** | 반환값 확인 후 즉시 ActivatedRecipe 업데이트 |
|
||||
| **반환 타입** | int (에러 코드) | E1.OK = 성공, 그 외 = 실패 |
|
||||
| **성공 조건** | err == E1.OK | 에러 체크 후 진행 |
|
||||
| **동작 보장** | 반환 시점에 완료됨 | 다음 라인 실행 전 완전히 활성화됨 |
|
||||
|
||||
### 1.2 동기 작동의 의미
|
||||
|
||||
```
|
||||
[ActivateRecipe 호출]
|
||||
↓
|
||||
[RecipeManager 내부에서:
|
||||
- 현재 Recipe 종료
|
||||
- 새 Recipe 활성화
|
||||
- 내부 상태 업데이트]
|
||||
↓
|
||||
[int err 반환 (이 시점에 모든 작업 완료)]
|
||||
↓
|
||||
[호출처에서 err == E1.OK 확인]
|
||||
↓
|
||||
[다음 작업 진행 (ActivatedRecipe 업데이트, 등)]
|
||||
```
|
||||
|
||||
**당신의 직관이 맞습니다:** "작업이 끝난 다음 시도해야할 것으로 보입니다" → 100% 정확
|
||||
|
||||
---
|
||||
|
||||
## 2. EVENT_CHANGE_RECIPE_INFO 발생 타이밍 분석
|
||||
|
||||
### 2.1 두 가지 이벤트 경로
|
||||
|
||||
**Aurora 시스템 이벤트:**
|
||||
```csharp
|
||||
// UCRecipeSelectViewModel.cs Line 74
|
||||
_EventObservable.AsObservable(AuroraSysEvent.SYS_RECIPE_ACTIVATED)
|
||||
.Select(x => (RecipeInfo)x.Param)
|
||||
.Subscribe(x => SelectRecipe(x));
|
||||
```
|
||||
|
||||
- **언제**: ActivateRecipe() 성공 후
|
||||
- **누가**: Aurora RecipeManager 내부에서 자동 발행
|
||||
- **신뢰성**: Aurora 자체에서 보장
|
||||
|
||||
**커스텀 이벤트:**
|
||||
```csharp
|
||||
// UCScannerObjectTeachingViewModel.cs Line 159
|
||||
_Aurora.EventPublisher.Publish(new EventMessage(
|
||||
"OnActivatedRecipe",
|
||||
CommonEventIds.EVENT_CHANGE_RECIPE_INFO,
|
||||
activeRecipe
|
||||
));
|
||||
```
|
||||
|
||||
- **언제**: RecipeHelper.SaveRecipe() 완료 후
|
||||
- **누가**: 사용자가 수동으로 발행
|
||||
- **목적**: Aurora 이벤트보다 높은 우선순위 보장
|
||||
- **주석**: "Aurora가 저장 후 LASA가 저장하는 동작의 우선순위가 보장 안 되기 때문에"
|
||||
|
||||
### 2.2 이벤트 발생 순서 (실제 흐름)
|
||||
|
||||
```
|
||||
[PLC에서 RecipeNum 신호]
|
||||
↓
|
||||
[SeqAutoRunPTOP에서 ReadWord(RecipeNum)]
|
||||
↓
|
||||
[RecipeManager.ActivateRecipe(recipeId, reason)]
|
||||
↓
|
||||
[① ActivateRecipe() 내부:
|
||||
- Recipe 활성화 완료
|
||||
- SYS_RECIPE_ACTIVATED 자동 발행]
|
||||
↓
|
||||
[② int err 반환 (err == E1.OK)]
|
||||
↓
|
||||
[③ 호출처에서 EVENT_CHANGE_RECIPE_INFO를 수동으로 발행]
|
||||
(또는 이미 구독 중인 SYS_RECIPE_ACTIVATED 처리)
|
||||
↓
|
||||
[④ 이벤트 핸들러 실행:
|
||||
- RecipeHelper.ReloadRecipe()
|
||||
- 설정 적용]
|
||||
```
|
||||
|
||||
### 2.3 결론: 50ms 지연이 필요한 이유
|
||||
|
||||
**당신의 분석 정확:**
|
||||
- ActivateRecipe()는 동기이지만, **내부 이벤트 발행 → 이벤트 핸들러 처리**는 비동기일 수 있음
|
||||
- 특히 UI 스레드 관련 작업은 **Dispatcher 큐를 타고 실행**됨
|
||||
- **50ms 지연** = 이벤트 핸들러 완료 대기
|
||||
|
||||
```csharp
|
||||
// 권장 패턴
|
||||
int err = _AuroraEnv.RecipeManager.ActivateRecipe(recipeId, "PLC Request");
|
||||
if (err != E1.OK) {
|
||||
Log.E("Recipe Activation Failed");
|
||||
return null;
|
||||
}
|
||||
|
||||
Log.I($"Recipe Activated: {recipeId}");
|
||||
Thread.Sleep(50); // ← 이벤트 핸들러 완료 대기
|
||||
|
||||
// 이 시점에 ReloadRecipe()가 완료됨
|
||||
var loadedRecipe = RecipeHelper.getRecipeInfo(recipeName);
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. ReloadRecipe()를 통한 변경사항 검증 (더블 체크)
|
||||
|
||||
### 3.1 ReloadRecipe()의 역할
|
||||
|
||||
**위치:** `RecipeHelper.cs` Line 64-69
|
||||
|
||||
```csharp
|
||||
public static void ReloadRecipe(string recipeName)
|
||||
{
|
||||
var camConfig = VisionEnv.AuroraEnv.DeviceManager.GetDeviceConfig(
|
||||
eCamId.CAM1.ToString()) as CamConfig;
|
||||
CommonHelper.GetMainPage().UpdateDefaultField(camConfig.ChildImage.ChildBufRowCols);
|
||||
CommonHelper.GetMainPage().ReloadRecipe(GetTeachingEditorFullPath(recipeName));
|
||||
}
|
||||
```
|
||||
|
||||
**역할:**
|
||||
- 파일에서 Recipe 데이터를 **메모리로 로드**
|
||||
- UI 캔버스에 그릴 수 있도록 준비
|
||||
- 스캐너 파라미터 등을 메모리 구조로 변환
|
||||
|
||||
### 3.2 getRecipeInfo()를 통한 검증
|
||||
|
||||
**위치:** `RecipeHelper.cs` Line 71
|
||||
|
||||
```csharp
|
||||
public static RecipeWeldingLines getRecipeInfo(string recipeName) =>
|
||||
CommonHelper.GetMainPage().getRecipeInfo(GetTeachingEditorFullPath(recipeName));
|
||||
```
|
||||
|
||||
**반환 타입:** `RecipeWeldingLines`
|
||||
- 현재 메모리에 로드된 Recipe 정보
|
||||
- 용접 라인, 파라미터 등 포함
|
||||
|
||||
### 3.3 변경사항 검증 패턴 (RMSHandlerForScanner 참고)
|
||||
|
||||
**위치:** `RMSHandlerForScanner.cs` Line 132-149
|
||||
|
||||
```csharp
|
||||
// Step 1: 이전 Recipe 정보 저장
|
||||
var RecipeBeforeChanged = RecipeHelper.getRecipeInfo(recipe.Name);
|
||||
|
||||
// Step 2: Recipe 활성화
|
||||
Application.Current.Dispatcher.Invoke(() => {
|
||||
RecipeHelper.ReloadRecipe(recipe.Name);
|
||||
});
|
||||
|
||||
// Step 3: 파라미터 적용 (RMS에서 받은 데이터 적용)
|
||||
for (int i = 0; i < 3; i++) {
|
||||
if (!ApplyReportToParam(ScannerCanvasUserCtrl.ScannerParams[i], i))
|
||||
return;
|
||||
}
|
||||
|
||||
// Step 4: 변경사항 저장 및 재로드
|
||||
Application.Current.Dispatcher.Invoke(() => {
|
||||
RecipeHelper.SaveRecipe(recipe.Name);
|
||||
});
|
||||
|
||||
// Step 5: 변경된 정보 확인
|
||||
var ChangedRecipe = RecipeHelper.getRecipeInfo(recipe.Name);
|
||||
|
||||
// Step 6: 변경사항 비교 (CompareHelper 사용)
|
||||
var diffs = new ObservableCollection<PropertyDiff>();
|
||||
for (int i = 0; i < 3; i++) {
|
||||
CompareHelper.Fill(RecipeBeforeChanged.ReadOnlyScanParams[i],
|
||||
ChangedRecipe.ReadOnlyScanParams[i],
|
||||
diffs,
|
||||
new CompareHelper.FieldSpec<ScannerParam>("Draw Speed", x => x.MarkSpeed),
|
||||
// ... 기타 필드 비교
|
||||
);
|
||||
}
|
||||
|
||||
// Step 7: 변경사항 로깅
|
||||
if (diffs.Count > 0) {
|
||||
Log.FuncI($"ScanParameter{i + 1} Recipe Changed");
|
||||
foreach (var diff in diffs)
|
||||
Log.V($"{diff.ToString()}");
|
||||
}
|
||||
|
||||
// Step 8: Activated Recipe 확인
|
||||
var preActivatedRecipe = _aurora.RecipeManager.ActivatedRecipe();
|
||||
_aurora.RecipeManager.ActivateRecipe(recipe.Id, "RMS Request");
|
||||
```
|
||||
|
||||
### 3.4 SeqAutoRunPTOP을 위한 더블 체크 패턴
|
||||
|
||||
```csharp
|
||||
// ===== 제안 패턴 =====
|
||||
|
||||
// 이전 Recipe 정보 저장
|
||||
var previousRecipeInfo = RecipeHelper.getRecipeInfo(
|
||||
_AuroraEnv.RecipeManager.ActivatedRecipe().Name);
|
||||
Log.I($"[CheckPageNo] Previous Recipe: {previousRecipeInfo.Name}");
|
||||
|
||||
// Recipe 활성화
|
||||
int err = _AuroraEnv.RecipeManager.ActivateRecipe(recipeId, "PLC Request");
|
||||
if (err != E1.OK) {
|
||||
Log.E($"[CheckPageNo] Recipe Activation Failed: {err}");
|
||||
return null;
|
||||
}
|
||||
|
||||
// 이벤트 처리 대기
|
||||
Thread.Sleep(50);
|
||||
|
||||
// 현재 활성화된 Recipe 확인
|
||||
var currentActivated = _AuroraEnv.RecipeManager.ActivatedRecipe();
|
||||
Log.I($"[CheckPageNo] Current Activated Recipe: {currentActivated.Id} - {currentActivated.Name}");
|
||||
|
||||
// Recipe 로드 및 정보 확인
|
||||
RecipeHelper.ReloadRecipe(currentActivated.Name);
|
||||
var currentRecipeInfo = RecipeHelper.getRecipeInfo(currentActivated.Name);
|
||||
|
||||
// 더블 체크: 실제로 변경되었는지 확인
|
||||
if (previousRecipeInfo.Name == currentRecipeInfo.Name) {
|
||||
Log.W($"[CheckPageNo] Warning: Recipe did not change!");
|
||||
// Fallback 처리 (재시도, 강제 종료 등)
|
||||
}
|
||||
|
||||
Log.I($"[CheckPageNo] Recipe Successfully Changed: {previousRecipeInfo.Name} → {currentRecipeInfo.Name}");
|
||||
|
||||
// 이제 PageNum 읽기 진행
|
||||
// ...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 구체적인 검증 방법
|
||||
|
||||
### 4.1 ActivatedRecipe() 메서드로 확인
|
||||
|
||||
```csharp
|
||||
// 활성화 전
|
||||
var beforeRecipe = _AuroraEnv.RecipeManager.ActivatedRecipe();
|
||||
Log.I($"Before: {beforeRecipe.Id} - {beforeRecipe.Name}");
|
||||
|
||||
// 활성화
|
||||
int err = _AuroraEnv.RecipeManager.ActivateRecipe(newRecipeId, "Test");
|
||||
if (err != E1.OK) return null;
|
||||
|
||||
Thread.Sleep(50);
|
||||
|
||||
// 활성화 후
|
||||
var afterRecipe = _AuroraEnv.RecipeManager.ActivatedRecipe();
|
||||
Log.I($"After: {afterRecipe.Id} - {afterRecipe.Name}");
|
||||
|
||||
// 검증
|
||||
if (beforeRecipe.Id != afterRecipe.Id) {
|
||||
Log.I("✓ Recipe ID changed");
|
||||
} else {
|
||||
Log.E("✗ Recipe ID did not change (Possible error)");
|
||||
}
|
||||
```
|
||||
|
||||
### 4.2 getRecipeInfo() 로 상세 정보 확인
|
||||
|
||||
```csharp
|
||||
// 활성화 후
|
||||
var recipeInfo = RecipeHelper.getRecipeInfo(afterRecipe.Name);
|
||||
if (recipeInfo == null) {
|
||||
Log.E("Failed to load recipe info");
|
||||
return null;
|
||||
}
|
||||
|
||||
// 주요 필드 검증
|
||||
Log.I($"Recipe Name: {recipeInfo.Name}");
|
||||
Log.I($"Layer Count: {recipeInfo.Layers.Count()}");
|
||||
Log.I($"Total Lines: {recipeInfo.Layers.Sum(l => l.Objects.Count())}");
|
||||
|
||||
// Recipe가 제대로 로드되었으면 Canvas에 반영됨
|
||||
// _SelectedObjectList = recipeInfo.ActiveLayer.Objects;
|
||||
```
|
||||
|
||||
### 4.3 이벤트 핸들러 직접 구독
|
||||
|
||||
```csharp
|
||||
// SeqAutoRunPTOP.Sequence_Enter에서:
|
||||
_recipeChangeCompleted = false;
|
||||
|
||||
_AuroraEnv.EventObservable
|
||||
.AsObservable(AuroraSysEvent.SYS_RECIPE_ACTIVATED)
|
||||
.Subscribe(msg => {
|
||||
Log.I("[Sequence_Enter] SYS_RECIPE_ACTIVATED Event Received");
|
||||
_recipeChangeCompleted = true;
|
||||
});
|
||||
|
||||
// CheckPageNo에서:
|
||||
_recipeChangeCompleted = false;
|
||||
|
||||
int err = _AuroraEnv.RecipeManager.ActivateRecipe(recipeId, "PLC Request");
|
||||
if (err != E1.OK) return null;
|
||||
|
||||
// 이벤트 대기 (타임아웃 포함)
|
||||
var startTime = DateTime.Now;
|
||||
while (!_recipeChangeCompleted && !context.Stopped) {
|
||||
if (DateTime.Now.Subtract(startTime).TotalSeconds > 5) {
|
||||
Log.W("[CheckPageNo] Recipe Change Event Timeout");
|
||||
break;
|
||||
}
|
||||
Thread.Sleep(10);
|
||||
}
|
||||
|
||||
Log.I("[CheckPageNo] Recipe Change Event Completed");
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 정리: 세 가지 검증 질문에 대한 최종 답변
|
||||
|
||||
### Q1: ActivateRecipe()가 동기인가?
|
||||
|
||||
**답: YES, 동기이다.**
|
||||
- 반환값(int err)이 있고, 즉시 확인 가능
|
||||
- 반환 시점에 Recipe 활성화 작업 완료됨
|
||||
- 하지만 **이벤트 발행 → 이벤트 핸들러 실행**은 다른 스레드/큐를 탈 수 있음
|
||||
|
||||
### Q2: EVENT_CHANGE_RECIPE_INFO 발생 타이밍은?
|
||||
|
||||
**답: 50ms 지연이 필요하다.**
|
||||
- ActivateRecipe() 반환 직후 발행되지만,
|
||||
- 이벤트 핸들러(ReloadRecipe 등)는 비동기로 처리됨
|
||||
- Dispatcher 큐를 통해 실행되므로 약간의 지연 필요
|
||||
- **권장: Thread.Sleep(50)** 이상
|
||||
|
||||
### Q3: ReloadRecipe()로 변경사항을 검증해야 하는가?
|
||||
|
||||
**답: YES, 강력히 권장한다.**
|
||||
- 이전 Recipe 정보 저장 → getRecipeInfo()
|
||||
- 활성화 및 로드 → ReloadRecipe()
|
||||
- 현재 Recipe 정보 확인 → getRecipeInfo()
|
||||
- 비교 → CompareHelper (RMSHandler 참고)
|
||||
- 변경사항 검증 → diffs 확인
|
||||
|
||||
---
|
||||
|
||||
## 6. 다음 단계: 구현 계획 수정
|
||||
|
||||
기존 "Phase 1-5"를 다음과 같이 정밀화할 수 있습니다:
|
||||
|
||||
### Phase 1: 설정 & 준비
|
||||
- ProcessRecipeMapping 클래스
|
||||
- PLC WORD 신호 정의
|
||||
|
||||
### Phase 2: 이벤트 구독 설정 (Sequence_Enter)
|
||||
```csharp
|
||||
_recipeChangeCompleted = false;
|
||||
_AuroraEnv.EventObservable
|
||||
.AsObservable(AuroraSysEvent.SYS_RECIPE_ACTIVATED)
|
||||
.Subscribe(msg => _recipeChangeCompleted = true);
|
||||
```
|
||||
|
||||
### Phase 3: CheckPageNo 수정
|
||||
```csharp
|
||||
// Step 1: 이전 Recipe 정보 저장
|
||||
var prevRecipe = RecipeHelper.getRecipeInfo(...);
|
||||
|
||||
// Step 2: RecipeNum 읽기 & RecipeId 매핑
|
||||
int recipeId = mapping.GetRecipeId(plcRecipeNum);
|
||||
|
||||
// Step 3: Recipe 활성화 (동기)
|
||||
int err = _AuroraEnv.RecipeManager.ActivateRecipe(recipeId, "PLC Request");
|
||||
if (err != E1.OK) return null;
|
||||
|
||||
// Step 4: 이벤트 처리 대기
|
||||
Thread.Sleep(50);
|
||||
|
||||
// Step 5: 더블 체크 (변경사항 검증)
|
||||
var currRecipe = RecipeHelper.getRecipeInfo(...);
|
||||
if (prevRecipe.Name == currRecipe.Name) {
|
||||
Log.W("Warning: Recipe did not change");
|
||||
}
|
||||
|
||||
// Step 6: PageNum 읽기 (기존 로직)
|
||||
// ...
|
||||
```
|
||||
|
||||
### Phase 4: 에러 처리
|
||||
- 타임아웃 처리 (5초)
|
||||
- Recipe 미존재 처리
|
||||
- Fallback 로직
|
||||
|
||||
---
|
||||
|
||||
## 7. 주의사항
|
||||
|
||||
1. **Dispatcher.Invoke()의 필요성**
|
||||
- UI 스레드가 아닌 곳에서 호출 시 필수
|
||||
- RecipeHelper.ReloadRecipe()는 UI 스레드에서만 안전
|
||||
|
||||
2. **Recipe 로드 시간**
|
||||
- Recipe 크기에 따라 로드 시간 다름
|
||||
- 복잡한 Recipe는 50ms 이상 필요할 수 있음
|
||||
- **타임아웃은 최소 5초로 설정 권장**
|
||||
|
||||
3. **Rx.NET ObserveOnDispatcher()**
|
||||
- RMSHandler에서 사용되는 패턴
|
||||
- UI 스레드 안전성 보장
|
||||
- SeqAutoRunPTOP에서도 고려
|
||||
|
||||
---
|
||||
|
||||
**결론:** 당신의 분석 방향이 100% 정확합니다. 코드 수정 전 이 세 가지 검증 항목을 더 깊이 있게 분석하는 것이 매우 현명한 선택입니다.
|
||||
@ -1,509 +0,0 @@
|
||||
# Recipe 탭 크래시 분석 보고서 — IO Device DI 읽기 실패
|
||||
|
||||
**분석 일시:** 2026-06-16 14:56:23
|
||||
**대상:** ILSOS_PrismaticRD_PTOP Recipe 탭 시스템 셧다운
|
||||
**오류:** `System.Exception: ERR_IO_FAIL_TO_GET_BIT; ERROR CODE:3102`
|
||||
|
||||
---
|
||||
|
||||
## 1. 오류 스택 트레이스 분석
|
||||
|
||||
### 1.1 호출 체인
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────┐
|
||||
│ [호출 경로] │
|
||||
├─────────────────────────────────────────────────────────────────────┤
|
||||
│ 1. System.Windows.Threading.DispatcherTimer.FireTick() │
|
||||
│ (타이머 이벤트 발생) │
|
||||
│ │
|
||||
│ 2. UCScannerObjectTeachingControlBoxViewModel.OnMonitoring() │
|
||||
│ 위치: Recipes/UCScannerObjectTeachingControlBoxViewModel.cs:181 │
|
||||
│ (타이머 콜백 핸들러) │
|
||||
│ │
|
||||
│ 3. IODevice.ReadDI(int index) │
|
||||
│ 위치: AuroraIO/IODevice.cs:212 │
|
||||
│ (디지털 입력 읽기 메서드) │
|
||||
│ │
|
||||
│ 4. AuroraIO.AJINEXTEK.AjinIO.ReadDiBit(int index) │
|
||||
│ 위치: AuroraIO/Vendor/AJINEXTEK/AjinIO.cs:510 │
|
||||
│ ❌ 예외 발생 │
|
||||
│ "ERR_IO_FAIL_TO_GET_BIT; ERROR CODE:3102" │
|
||||
│ │
|
||||
│ 5. CAXD.AxdiReadInport(index, ref data) ← 오류의 근원 │
|
||||
│ (Ajin IO 드라이버 호출 — 하드웨어 통신 실패) │
|
||||
└─────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 1.2 에러 코드 분석: 3102
|
||||
|
||||
**Ajin 모션 컨트롤러 라이브러리 에러 코드 3102:**
|
||||
|
||||
| 에러 코드 | 의미 | 가능한 원인 |
|
||||
|----------|------|-----------|
|
||||
| **3102** | `AXT_ERR_INVALID_PORT` | ① DI 포트 인덱스 범위 초과<br/>② IO 모듈이 초기화되지 않음<br/>③ IO 포트 설정 불일치<br/>④ 하드웨어 미연결 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 코드 분석
|
||||
|
||||
### 2.1 오류 발생 지점: UCScannerObjectTeachingControlBoxViewModel.cs
|
||||
|
||||
```csharp
|
||||
[Line 171-198]
|
||||
private void OnMonitoring(object sender, EventArgs e)
|
||||
{
|
||||
// Laser Device 파일럿 상태 읽기 (성공)
|
||||
if (_Laser.GetPilotLaserStatus()) {
|
||||
IsGuidBeam = true;
|
||||
} else {
|
||||
IsGuidBeam = false;
|
||||
}
|
||||
|
||||
// ❌ 이 부분에서 크래시 발생 (Line 181)
|
||||
if (_IODevice.ReadDI(9) && // ← ERROR CODE:3102 (DI 9 읽기 실패)
|
||||
_IODevice.ReadDI(24)) // (도달하지 않음)
|
||||
{
|
||||
IsLaserReady = true;
|
||||
} else {
|
||||
IsLaserReady = false;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**타이머 시작 조건:**
|
||||
|
||||
```csharp
|
||||
[Line 151-159]
|
||||
private void VisibleChanged(object obj)
|
||||
{
|
||||
bool visible = (bool)obj;
|
||||
if (visible) {
|
||||
_MonitorTimer.Start(); // ← Recipe 탭이 보여질 때 시작
|
||||
} else {
|
||||
_MonitorTimer.Stop();
|
||||
}
|
||||
}
|
||||
|
||||
[Line 127-130]
|
||||
_MonitorTimer = new DispatcherTimer();
|
||||
_MonitorTimer.Tick += OnMonitoring;
|
||||
_MonitorTimer.Interval = TimeSpan.FromMilliseconds(100); // 100ms마다 OnMonitoring 호출
|
||||
```
|
||||
|
||||
### 2.2 IO 인덱스 읽음
|
||||
|
||||
```csharp
|
||||
[IODevice.cs:212-214]
|
||||
public bool ReadDI(int index) => _iOUnit.ReadDiBit(index);
|
||||
public bool ReadDO(int index) => _iOUnit.ReadDoBit(index);
|
||||
public void WriteDO(int index, bool on) => _iOUnit.WriteDoBit(index, on);
|
||||
```
|
||||
|
||||
### 2.3 Ajin IO 드라이버 호출 (실패 지점)
|
||||
|
||||
```csharp
|
||||
[AjinIO.cs:501-511]
|
||||
public override bool ReadDiBit(int index)
|
||||
{
|
||||
uint data = 0;
|
||||
|
||||
// Ajin IO 라이브러리 호출
|
||||
int err = (int)CAXD.AxdiReadInport(index, ref data);
|
||||
|
||||
if (err != (int)AXT_FUNC_RESULT.AXT_RT_SUCCESS) // err = 3102
|
||||
{
|
||||
// 예외 발생
|
||||
throw new Exception(string.Format("ERR_IO_FAIL_TO_GET_BIT;ERROR CODE:{0}", err));
|
||||
// ↑ 3102
|
||||
}
|
||||
return Convert.ToBoolean(data);
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 근본 원인 분석
|
||||
|
||||
### 3.1 **DI 인덱스 범위 오류** (가능성 높음)
|
||||
|
||||
#### 현상
|
||||
- 기존 프로젝트 (ILSOS_PrismaticScanner)에서 코드를 copy-paste하여 ILSOS_PrismaticRD_PTOP에 적용
|
||||
- 기존 프로젝트의 하드웨어 설정과 PTOP의 하드웨어 설정이 다름
|
||||
|
||||
#### 의심 지점
|
||||
|
||||
**기존 코드 (ILSOS_PrismaticScanner):**
|
||||
```csharp
|
||||
// ILSOS_PrismaticScanner의 Recipe 탭 모니터링
|
||||
_IODevice.ReadDI(9) // Scanner 하드웨어의 DI 포트 9 (유효)
|
||||
_IODevice.ReadDI(24) // Scanner 하드웨어의 DI 포트 24 (유효)
|
||||
```
|
||||
|
||||
**현재 코드 (ILSOS_PrismaticRD_PTOP):**
|
||||
```csharp
|
||||
// PTOP 하드웨어로 복사되었으나 핀 맵이 다름
|
||||
_IODevice.ReadDI(9) // PTOP 하드웨어에는 DI 9가 없음 또는 다른 목적
|
||||
_IODevice.ReadDI(24) // PTOP 하드웨어에는 DI 24가 없음 또는 다른 목적
|
||||
```
|
||||
|
||||
#### 검증 방법
|
||||
|
||||
**PTOP IO 설정 파일 확인:**
|
||||
```
|
||||
ILSOS_PrismaticRD_PTOP/
|
||||
├── settings/
|
||||
│ └── IO 설정 파일 (IOConfig.xml 또는 유사)
|
||||
└── EquipDef.cs ← DI/DO 인덱스 정의 확인
|
||||
```
|
||||
|
||||
**EquipDef.cs에서 DI 9, 24의 정의 확인:**
|
||||
```csharp
|
||||
// 있어야 함:
|
||||
public const int DI_SOMETHING = 9; // 무엇을 읽는가?
|
||||
public const int DI_LASER_READY = 24; // 또는 다른 용도?
|
||||
|
||||
// 없을 수도 있음 → 인덱스 미스매치
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.2 **IO 모듈 미초기화** (가능성 중간)
|
||||
|
||||
#### 현상
|
||||
Recipe 탭 진입 시점에 IO 모듈이 완전히 초기화되지 않음
|
||||
|
||||
#### 의심 지점
|
||||
|
||||
**IODevice 초기화 순서:**
|
||||
|
||||
```csharp
|
||||
[IODevice.cs:146-198 DoActivate]
|
||||
protected override int DoActivate(IDeviceConfig config)
|
||||
{
|
||||
// ... 코드 생략 ...
|
||||
|
||||
int nRet = _iOUnit.Open(m_IOUnitConfig.DIDOIP); // Step 1: 포트 오픈
|
||||
if (nRet != 0)
|
||||
return nRet;
|
||||
|
||||
LoadIOTable(); // Step 2: IO 테이블 로드
|
||||
|
||||
nRet = _iOUnit.Initialize(); // Step 3: 초기화
|
||||
|
||||
// 이 시점에서 Recipe 탭이 활성화되면?
|
||||
// → OnMonitoring이 즉시 호출될 수 있음
|
||||
// → IO 테이블 로드 전에 DI 읽기 시도 가능
|
||||
}
|
||||
```
|
||||
|
||||
**EquipmentSetup에서 IODevice 활성화 타이밍:**
|
||||
|
||||
```
|
||||
1. Application 시작
|
||||
2. EquipmentSetup.Activate() 호출
|
||||
├─ 각 Device 순차 활성화
|
||||
├─ IODevice 활성화 (DoActivate 호출)
|
||||
│ └─ LoadIOTable() → _iOUnit.Initialize()
|
||||
│ (이 순간 IO 포트들이 설정됨)
|
||||
│
|
||||
└─ View/ViewModel 초기화
|
||||
└─ Recipe 탭 ViewModel 생성
|
||||
└─ _MonitorTimer 등록 (하지만 아직 시작 안 함)
|
||||
|
||||
3. UI 표시
|
||||
└─ Recipe 탭 클릭 → VisibleChanged(true)
|
||||
└─ _MonitorTimer.Start() ❌ 크래시 (IO 미초기화 상태)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3.3 **하드웨어 미연결** (가능성 낮음)
|
||||
|
||||
IO 모듈이 PC에 연결되지 않은 경우, 모든 DI 읽기가 실패합니다.
|
||||
|
||||
---
|
||||
|
||||
## 4. 코드 추적: 기존 프로젝트와의 차이
|
||||
|
||||
### 4.1 ILSOS_PrismaticScanner vs ILSOS_PrismaticRD_PTOP
|
||||
|
||||
#### ILSOS_PrismaticScanner (정상 작동)
|
||||
```
|
||||
ILSOS_PrismaticScanner/
|
||||
├── EquipDef.cs
|
||||
│ └─ DI 9, 24 정의됨 ✓
|
||||
├── Recipes/
|
||||
│ └─ UCScannerObjectTeachingControlBoxViewModel.cs
|
||||
│ └─ OnMonitoring()에서 DI 9, 24 읽음 ✓
|
||||
└── settings/
|
||||
└─ IOConfig.xml (또는 유사)
|
||||
└─ DI 포트 매핑 9, 24 정의됨 ✓
|
||||
```
|
||||
|
||||
#### ILSOS_PrismaticRD_PTOP (오류 발생)
|
||||
```
|
||||
ILSOS_PrismaticRD_PTOP/
|
||||
├── EquipDef.cs
|
||||
│ └─ DI 9, 24 정의? ??? (확인 필요)
|
||||
├── Recipes/
|
||||
│ └─ UCScannerObjectTeachingControlBoxViewModel.cs (복사됨)
|
||||
│ └─ OnMonitoring()에서 DI 9, 24 읽음 ❌ (PTOP 하드웨어에 없음)
|
||||
└── settings/
|
||||
└─ IOConfig.xml 또는 설정 파일
|
||||
└─ DI 포트 매핑 정의? ??? (PTOP별 설정 필요)
|
||||
```
|
||||
|
||||
### 4.2 같은 코드, 다른 하드웨어
|
||||
|
||||
**비전 시스템의 Laser Ready 신호를 읽는 로직:**
|
||||
|
||||
- **Scanner**: Laser 보기 헤드에서 발생하는 신호
|
||||
- Pilot Laser 상태 (위치 확인용)
|
||||
- Laser Ready 신호 (발사 가능 여부)
|
||||
|
||||
- **PTOP (Prismatic Rectangular)**: 배터리 각형 용접
|
||||
- 고정 레이저 (이동하지 않음)
|
||||
- Stage A / Stage B 교번 스캔
|
||||
- Laser Ready 신호의 의미가 다를 수 있음
|
||||
|
||||
---
|
||||
|
||||
## 5. 해결 방안
|
||||
|
||||
### **방안 A: DI 인덱스 검증 및 수정** (권장)
|
||||
|
||||
**Step 1: PTOP의 실제 IO 설정 확인**
|
||||
|
||||
```bash
|
||||
# 1. PTOP의 IO 설정 파일 확인
|
||||
ILSOS_PrismaticRD_PTOP/settings/ 폴더에서
|
||||
IOConfig, IO.xml, 또는 유사 파일 검색
|
||||
|
||||
# 2. PTOP의 EquipDef.cs 확인
|
||||
상수로 정의된 DI/DO 인덱스 확인:
|
||||
예:
|
||||
public const int DI_SOMETHING = X;
|
||||
public const int DI_LASER_READY = Y;
|
||||
|
||||
# 3. 하드웨어 사양서 확인
|
||||
PTOP 머신의 IO 포트 매핑 문서
|
||||
→ DI 9, 24가 실제로 존재하는지 확인
|
||||
```
|
||||
|
||||
**Step 2: 올바른 DI 인덱스로 수정**
|
||||
|
||||
만약 PTOP의 Laser Ready 신호가 DI 9, 24가 아니라면:
|
||||
|
||||
```csharp
|
||||
// 수정 전 (잘못된 코드)
|
||||
if (_IODevice.ReadDI(9) && _IODevice.ReadDI(24))
|
||||
|
||||
// 수정 후 (PTOP의 실제 DI 인덱스 사용)
|
||||
// 예: PTOP의 Laser Ready가 DI 5, 15라면
|
||||
if (_IODevice.ReadDI(5) && _IODevice.ReadDI(15))
|
||||
|
||||
// 또는 EquipDef에서 상수 사용
|
||||
if (_IODevice.ReadDI(CommonDeviceIds.DI_LASER_READY_1) &&
|
||||
_IODevice.ReadDI(CommonDeviceIds.DI_LASER_READY_2))
|
||||
```
|
||||
|
||||
**Step 3: Recipe 탭 모니터링 로직 검증**
|
||||
|
||||
Recipe 탭의 Laser Ready 상태가 PTOP에 필요한가?
|
||||
- 필요하면 → 올바른 DI 인덱스 사용
|
||||
- 불필요하면 → 모니터링 로직 제거 또는 비활성화
|
||||
|
||||
```csharp
|
||||
// 방안 A-1: 불필요하면 모니터링 제거
|
||||
private void OnMonitoring(object sender, EventArgs e)
|
||||
{
|
||||
// PTOP에서는 Laser Ready 상태를 Recipe 탭에서 읽을 필요 없음
|
||||
// OnMonitoring 전체 로직 제거 또는 주석 처리
|
||||
}
|
||||
|
||||
// 방안 A-2: 오류 처리 추가 (임시)
|
||||
private void OnMonitoring(object sender, EventArgs e)
|
||||
{
|
||||
try
|
||||
{
|
||||
if (_IODevice.ReadDI(9) && _IODevice.ReadDI(24))
|
||||
{
|
||||
IsLaserReady = true;
|
||||
}
|
||||
else
|
||||
{
|
||||
IsLaserReady = false;
|
||||
}
|
||||
}
|
||||
catch (Exception ex)
|
||||
{
|
||||
Log.E($"[OnMonitoring] DI 읽기 실패: {ex.Message}");
|
||||
IsLaserReady = false; // 기본값으로 설정
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### **방안 B: 조건부 모니터링** (안정성 향상)
|
||||
|
||||
PTOP과 Scanner 중 어느 것인지를 런타임에 판별하여 모니터링 수행:
|
||||
|
||||
```csharp
|
||||
private void OnMonitoring(object sender, EventArgs e)
|
||||
{
|
||||
// PTOP인지 Scanner인지 판별
|
||||
bool isPTOP = _SystemParameter.IsEquipmentType("PTOP");
|
||||
|
||||
if (isPTOP)
|
||||
{
|
||||
// PTOP: 모니터링 스킵 또는 PTOP별 로직
|
||||
IsLaserReady = true; // 또는 PTOP의 실제 신호 읽기
|
||||
}
|
||||
else
|
||||
{
|
||||
// Scanner: 기존 로직 유지
|
||||
if (_IODevice.ReadDI(9) && _IODevice.ReadDI(24))
|
||||
{
|
||||
IsLaserReady = true;
|
||||
}
|
||||
else
|
||||
{
|
||||
IsLaserReady = false;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### **방안 C: IO 초기화 대기** (근본 원인이 미초기화인 경우)
|
||||
|
||||
```csharp
|
||||
private void VisibleChanged(object obj)
|
||||
{
|
||||
bool visible = (bool)obj;
|
||||
if (visible)
|
||||
{
|
||||
// IO 모듈이 초기화될 때까지 대기
|
||||
if (_IODevice._iOUnit.IsConnected())
|
||||
{
|
||||
_MonitorTimer.Start();
|
||||
}
|
||||
else
|
||||
{
|
||||
Log.W("[Recipe Tab] IO 모듈이 아직 초기화되지 않음. 모니터링 지연");
|
||||
// 100ms 후 재시도
|
||||
Task.Delay(100).ContinueWith(_ =>
|
||||
{
|
||||
Dispatcher.CurrentDispatcher.Invoke(() =>
|
||||
{
|
||||
if (_IODevice._iOUnit.IsConnected())
|
||||
{
|
||||
_MonitorTimer.Start();
|
||||
}
|
||||
});
|
||||
});
|
||||
}
|
||||
}
|
||||
else
|
||||
{
|
||||
_MonitorTimer.Stop();
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 즉시 조치사항
|
||||
|
||||
### **우선순위 1: DI 인덱스 확인** (1시간)
|
||||
|
||||
```bash
|
||||
ILSOS_PrismaticRD_PTOP 프로젝트에서:
|
||||
1. EquipDef.cs 열기 → DI 상수 정의 확인
|
||||
2. settings/ 폴더에서 IO 설정 파일 찾기
|
||||
3. PTOP 하드웨어 사양서 또는 설정 문서 확인
|
||||
→ DI 9, 24이 PTOP에 실제로 존재하는가?
|
||||
```
|
||||
|
||||
### **우선순위 2: Laser Ready 신호의 필요성 확인** (30분)
|
||||
|
||||
```bash
|
||||
Recipe 탭에서 Laser Ready 상태가 필요한가?
|
||||
1. ILSOS_PrismaticScanner와 ILSOS_PrismaticRD_PTOP의
|
||||
레이저 시스템 비교
|
||||
2. PTOP에서 Laser Ready가 필요하면:
|
||||
→ 올바른 DI 인덱스 찾기
|
||||
필요 없으면:
|
||||
→ OnMonitoring 로직 제거
|
||||
```
|
||||
|
||||
### **우선순위 3: 임시 오류 처리** (30분)
|
||||
|
||||
```csharp
|
||||
// OnMonitoring에 try-catch 추가 (방안 A-2)
|
||||
// → 크래시 방지 + 로그 확인 용이
|
||||
// → 근본 원인 파악 후 제거할 것
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 7. 검증 포인트
|
||||
|
||||
### 7.1 수정 후 테스트
|
||||
|
||||
1. **Recipe 탭 진입 테스트**
|
||||
```
|
||||
1. 애플리케이션 시작
|
||||
2. 초기화 완료 확인
|
||||
3. Recipe 탭 클릭
|
||||
4. 시스템 셧다운 여부 확인 ✓
|
||||
```
|
||||
|
||||
2. **로그 확인**
|
||||
```
|
||||
OnMonitoring에서 DI 값을 로깅하여 실제로 읽어지는지 확인:
|
||||
Log.I($"[OnMonitoring] DI(9)={_IODevice.ReadDI(9)}, DI(24)={_IODevice.ReadDI(24)}");
|
||||
```
|
||||
|
||||
3. **IO 하드웨어 상태 확인**
|
||||
```
|
||||
IODevice 초기화 시 IsConnected() 상태 로깅:
|
||||
Log.I($"[IODevice] IsConnected={_IODevice._iOUnit.IsConnected()}");
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 참고: Laser Ready 신호 아키텍처
|
||||
|
||||
### Scanner vs PTOP 비교
|
||||
|
||||
| 항목 | ILSOS_PrismaticScanner | ILSOS_PrismaticRD_PTOP |
|
||||
|------|------------------------|----------------------|
|
||||
| **레이저 타입** | 스캐너 (이동) | 고정 + Stage 교번 |
|
||||
| **Pilot Laser** | 위치 확인용 신호 있음 | 고정이므로 필요성 낮음 |
|
||||
| **Laser Ready DI** | DI 9, 24 | ? (확인 필요) |
|
||||
| **Recipe 탭 용도** | 레이저 상태 모니터링 | ? (확인 필요) |
|
||||
|
||||
---
|
||||
|
||||
## 9. 결론
|
||||
|
||||
| 단계 | 조치 | 예상 시간 |
|
||||
|------|------|---------|
|
||||
| **1. 근본 원인 확인** | DI 인덱스 + IO 초기화 상태 확인 | 1시간 |
|
||||
| **2. 임시 조치** | try-catch 오류 처리 추가 | 30분 |
|
||||
| **3. 근본 해결** | 올바른 DI 인덱스로 수정 또는 모니터링 제거 | 1시간 |
|
||||
| **4. 테스트** | Recipe 탭 진입 테스트 + IO 로깅 확인 | 1시간 |
|
||||
|
||||
---
|
||||
|
||||
**작성자:** Claude Code Analysis
|
||||
**참고 파일:**
|
||||
- `UCScannerObjectTeachingControlBoxViewModel.cs:171-198` — OnMonitoring 메서드
|
||||
- `IODevice.cs:212-214` — ReadDI 메서드
|
||||
- `AjinIO.cs:501-511` — ReadDiBit 구현
|
||||
- 오류 로그: `sys_error/20260616_103211.148.log`
|
||||
|
||||
@ -1,187 +0,0 @@
|
||||
# Recipe View Laser Ready (DI 9) — IsLaserReady 조건 분석
|
||||
|
||||
**분석 일시:** 2026-06-17 14:31:31
|
||||
**대상:** `WeldingComponents/WeldingCommon/Views/Recipes/UCScannerObjectTeachingControlBoxViewModel.cs`
|
||||
**비교 대상:** `docs/기존파일비교/UCScannerObjectTeachingControlBoxViewModel.cs` (이전 MOTF 프로젝트 버전)
|
||||
|
||||
---
|
||||
|
||||
## 0. 요청 내용 (사용자)
|
||||
|
||||
- 현장 RTC5보드는 갈보모터 X, Y 피드백값을 가져오는 게 없어서 DEVICE 상에서 COMMAND 값을 불러오도록 체크 해제 후 진행. 정확한 피드백값은 확인 불가한 상태.
|
||||
- Laser 동작은 I/O로 하며, 프로그램 내에서 사용할 때 Simulation으로 동작한다.
|
||||
- Recipe View에서 Laser Ready 부분이 DI(9)를 보고 있는데, 해당 BIT가 Laser를 IO On 해도 번들을 켜도 안 켜져서 전선 다시 확인 중인 상태. simulation이어서 true가 되긴 해야 하지만 한번 확인해볼 것. 이전 MOTF 작업하던 프로젝트랑 비교하기.
|
||||
- **요청 1:** 현재 프로젝트의 `IsLaserReady` 변수 조건과 `docs/기존파일비교`의 같은 파일명 버전을 비교해서 달라진 점 분석.
|
||||
- **요청 2:** IO(9)를 보고 있는 모든 코드 위치 파악.
|
||||
- **요청 3:** 시뮬일 경우 버튼을 누르면 IsLaserReady 상태값이 변경되도록 하는 방안 검토 (DI(9)가 TRUE가 되지 않아 테스트가 막힘). — *코드 수정은 보류, 방안만 정리.*
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약
|
||||
|
||||
- 점등이 안 되는 직접 원인은 **IsLaserReady 판정 소스가 바뀐 것**:
|
||||
- 기존(MOTF): `_Laser.GetLaserReady()` (Laser 디바이스 상태, simulation이면 true)
|
||||
- 현재: `_IODevice.ReadDI(9)` (**실제 하드웨어 DI 9번 비트**)
|
||||
- 현재 코드는 시뮬레이션 Laser 디바이스가 아니라 **물리 DI(9)** 를 읽으므로, 배선으로 DI(9)가 실제로 들어오지 않으면 simulation이어도 true가 되지 않음.
|
||||
- 작업일지에 적은 "simulation이면 true여야 한다"는 **기존 코드 기준**이며, 현재 코드는 그렇게 동작하지 않음.
|
||||
- DI(9)는 "레이저 Ready 출력 → 장비 입력" 신호이므로 **OnMonitoring이 DI(9)를 읽는 것 자체는 설계상 정상.** 점등 미동작은 코드가 아니라 **레이저 Ready 출력 → DI(9) 결선** 문제 → 전선 확인이 맞는 방향.
|
||||
|
||||
---
|
||||
|
||||
## 2. 코드 비교 — IsLaserReady 판정부
|
||||
|
||||
### 2.1 OnMonitoring()
|
||||
|
||||
**기존(MOTF):**
|
||||
```csharp
|
||||
if (_Laser.GetLaserReady()) {
|
||||
IsLaserReady = true;
|
||||
} else {
|
||||
IsLaserReady = false;
|
||||
}
|
||||
```
|
||||
|
||||
**현재:**
|
||||
```csharp
|
||||
try
|
||||
{
|
||||
if (_IODevice.ReadDI(9)) // ← 물리 DI 9번을 직접 읽음
|
||||
{
|
||||
IsLaserReady = true;
|
||||
}
|
||||
else
|
||||
{
|
||||
IsLaserReady = false;
|
||||
}
|
||||
}
|
||||
catch (Exception ex)
|
||||
{
|
||||
Log.E($"[OnMonitoring] DI 읽기 실패: {ex.Message}");
|
||||
IsLaserReady = false;
|
||||
}
|
||||
```
|
||||
|
||||
### 2.2 PerformCmdLaserReadyCheck() — Ready Check 버튼
|
||||
|
||||
**기존(MOTF):**
|
||||
```csharp
|
||||
if (!_Laser.GetLaserReady()) {
|
||||
_Laser.LaserOn(); // 실질적으로 Laser Ready On
|
||||
} else {
|
||||
_Laser.LaserOff();
|
||||
}
|
||||
```
|
||||
|
||||
**현재:**
|
||||
```csharp
|
||||
if(toggleIO)
|
||||
{
|
||||
_IODevice._iOUnit.WriteDoBit(9, true); // ← DO 9 출력
|
||||
_IODevice._iOUnit.WriteDoBit(13, true); // ← DO 13 출력
|
||||
toggleIO = false;
|
||||
}
|
||||
else
|
||||
{
|
||||
_IODevice._iOUnit.WriteDoBit(9, false);
|
||||
_IODevice._iOUnit.WriteDoBit(13, false);
|
||||
toggleIO = true;
|
||||
}
|
||||
```
|
||||
|
||||
### 2.3 부수 차이 (동작엔 직접 영향 적음)
|
||||
- 필드 선언: 기존 `private readonly IODevice _IODevice;` → 현재 `private IODevice _IODevice;` (readonly 제거). 추가 필드 `public bool toggleIO = true;`.
|
||||
- using 추가: `WeldingCommon`, `WeldingCommon.Devices.Laser`, `using static ...PAIX_PrismaticScanner`.
|
||||
- 기존 OnMonitoring의 LaserOnLamp `WriteDoBit` 주석 블록은 현재 제거됨.
|
||||
- `PerformCmdRunTeachingRun`: 기존은 `PopupSequenceDiagram(...)` 호출, 현재는 주석 처리. `OnCompleteTeachingRun`도 기존은 성공 처리/`ShowWarningToast` 활성, 현재는 주석 처리.
|
||||
|
||||
---
|
||||
|
||||
## 3. 채널 충돌 — 버튼(DO9) vs 모니터링(DI9)
|
||||
|
||||
```
|
||||
[버튼] WriteDoBit(9,true) ──▶ DO 9 (출력)
|
||||
│ ?? 물리 배선 필요 ??
|
||||
[모니터] ReadDI(9) ◀─────────── DI 9 (입력)
|
||||
```
|
||||
|
||||
- 버튼이 쓰는 것은 **DO9/DO13 출력**, 모니터링이 읽는 것은 **DI9 입력** → 별개 채널.
|
||||
- DO9에 써도 DI9 입력으로 되돌아오려면 물리 배선(루프백/외부 결선)이 필요. 이 결선이 없으면 버튼을 눌러도 IsLaserReady가 안 켜짐 → 지금 전선 확인 중인 이슈와 일치.
|
||||
|
||||
---
|
||||
|
||||
## 4. IO(9)를 보고 있는 모든 코드 위치
|
||||
|
||||
리터럴 `9`로 IO 9번에 접근하는 코드는 **한 파일, 3곳뿐**:
|
||||
|
||||
`WeldingComponents/WeldingCommon/Views/Recipes/UCScannerObjectTeachingControlBoxViewModel.cs`
|
||||
|
||||
| 라인 | 코드 | 종류 | 의미 |
|
||||
|---|---|---|---|
|
||||
| 182 | `if (_IODevice.ReadDI(9))` | DI 9 읽기 | Laser Ready 판정 (모니터링) |
|
||||
| 462 | `_IODevice._iOUnit.WriteDoBit(9, true)` | DO 9 쓰기 | Ready Check 버튼 ON |
|
||||
| 468 | `_IODevice._iOUnit.WriteDoBit(9, false)` | DO 9 쓰기 | Ready Check 버튼 OFF |
|
||||
|
||||
> 같은 버튼이 인접 라인에서 `WriteDoBit(13, …)`도 함께 씀.
|
||||
|
||||
### enum 매핑상 9번의 실제 의미 (`AuroraDevices/AuroraIO/Vendor/PAIX/PAIXIO.cs`)
|
||||
|
||||
DI와 DO는 별개이고, 9번이 가리키는 게 서로 다름:
|
||||
|
||||
```
|
||||
ePDIAddress (입력) ePDOAddress (출력)
|
||||
DoorLockOpen4 = 7 WorkLEDOn = 7
|
||||
(8 - 미지정/미사용) (8 - 미지정)
|
||||
(9 - 미지정/미사용) ◀DI9 ResetSwitchLamp = 9 ◀DO9
|
||||
DoorLockCloseMonitoring=10 ...
|
||||
ModeKeySolOn = 13 ◀DO13
|
||||
```
|
||||
|
||||
- **DI 9번**: `ePDIAddress`에 이름이 없는 raw 비트 (Laser Ready 정식 주소로 매핑돼 있지 않음)
|
||||
- **DO 9번**: `ResetSwitchLamp` (리셋 스위치 램프)
|
||||
- **DO 13번**: `ModeKeySolOn` (모드키 솔레노이드)
|
||||
- → 버튼이 켜는 DO9/13은 enum상 레이저와 무관한 비트이며, DI9도 미매핑 raw 입력. 코드 레벨에서 임시 매핑된 자리.
|
||||
- DO9(`ResetSwitchLamp`)·DO13(`ModeKeySolOn`)을 enum 이름으로 호출하는 코드는 없음 → IO 9번 관련 코드는 위 3줄이 전부.
|
||||
|
||||
---
|
||||
|
||||
## 5. 시뮬일 때 버튼으로 IsLaserReady 토글하는 방안 (수정 보류 — 방안만)
|
||||
|
||||
선택안: **버튼이 IsLaserReady를 직접 토글.** 단, `OnMonitoring()`이 100ms마다 `ReadDI(9)`로 덮어쓰므로 시뮬일 때 모니터링 덮어쓰기를 같이 막아야 함.
|
||||
|
||||
- 시뮬 판별은 `_IODevice.IsSimul` 로 가능 (Device 기반 public 속성, 외부 사용 예: `SeqAlarmMonitor.cs:466` `_IO.IsSimul`).
|
||||
|
||||
**(1) `OnMonitoring()` — 시뮬일 때 DI(9) 읽기 건너뛰기**
|
||||
```csharp
|
||||
if (!_IODevice.IsSimul)
|
||||
{
|
||||
try
|
||||
{
|
||||
if (_IODevice.ReadDI(9)) { IsLaserReady = true; }
|
||||
else { IsLaserReady = false; }
|
||||
}
|
||||
catch (Exception ex) { Log.E($"[OnMonitoring] DI 읽기 실패: {ex.Message}"); IsLaserReady = false; }
|
||||
}
|
||||
```
|
||||
|
||||
**(2) `PerformCmdLaserReadyCheck()` — 시뮬일 때 직접 토글**
|
||||
```csharp
|
||||
if (_IODevice.IsSimul)
|
||||
{
|
||||
IsLaserReady = !IsLaserReady;
|
||||
return;
|
||||
}
|
||||
// 실장: 기존 DO9/13 Write 로직 그대로
|
||||
```
|
||||
|
||||
- 시뮬: 버튼 → IsLaserReady 토글, 모니터링 미관여 → 점등 확인 가능
|
||||
- 현장: 기존 로직 그대로 (DI9 읽기 / DO9·13 Write) — 변경 없음
|
||||
|
||||
> **상태:** 위 방안은 검토만 완료. 실제 코드 수정은 적용하지 않음 (사용자 보류 요청).
|
||||
|
||||
---
|
||||
|
||||
## 6. 확인/해결 방향
|
||||
|
||||
- DI(9) 판정을 유지하려면 **레이저 Ready 출력 → DI(9) 물리 결선**을 확인할 것 (전선 점검이 맞는 방향).
|
||||
- 시뮬레이션에서 동작 확인이 목적이면 5절 방안 적용을 검토.
|
||||
- 버튼이 출력하는 DO9(`ResetSwitchLamp`)·DO13(`ModeKeySolOn`)이 실제 레이저 Enable 배선과 맞는지 확인 후, 맞지 않으면 버튼 동작을 의미에 맞게 재정의 필요.
|
||||
@ -1,162 +0,0 @@
|
||||
# PLC 전축 위치값 모니터링 InterLock — Setting 추가 위치 분석/추천
|
||||
|
||||
**분석 일시:** 2026-06-17 14:39:00
|
||||
**대상:** PTOP 프로젝트 Settings 구조
|
||||
**목표:** PLC에서 받는 전축(全軸) 위치값을 모니터링하기 위한 기준값(범위)을 Setting에 미리 저장하고, 특정 범위를 벗어나면 InterLock을 거는 기능. 저장할 Setting 클래스/위치/그룹명 추천.
|
||||
|
||||
---
|
||||
|
||||
## 0. 요청 내용 (사용자)
|
||||
|
||||
- PLC에서 전축 위치값을 모니터링할 값을 미리 Setting에 저장해두고, 특정 범위를 벗어나면 InterLock을 걸려고 함.
|
||||
- Settings에 여러 Setting 클래스들이 있는데 **어느 클래스 어느 위치에 추가**하는 게 좋을지 추천.
|
||||
- 적당한 위치가 없으면 **어느 클래스에 어떤 그룹명**으로 추가하면 되는지도 추천해서 docs 분석에 기록.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약
|
||||
|
||||
- **기존 클래스 중 "딱 맞는" 자리는 없음.** 전축 위치값의 범위(Min/Max) InterLock은 *축마다 반복되는 구조화 데이터*라, 평면(scalar) 속성 위주인 `SystemParameter`/`SequenceSetting`에 그대로 넣기엔 부적합.
|
||||
- **추천(권장): 신규 전용 Setting 클래스 신설.**
|
||||
- 클래스: `AxisPositionInterlockSetting : ISettingItem`
|
||||
- 위치: `WeldingComponents/WeldingCommon/Settings/AxisPositionInterlockSetting.cs`
|
||||
- 등록 ID: `CommonSettingIds.AxisPositionInterlock = "AxisPositionInterlock"` (EquipDefCommon.cs)
|
||||
- 등록: `CommonEquipmentSetup.RegisterSettings()`에 `register(CommonSettingIds.AxisPositionInterlock, new AxisPositionInterlockSetting());`
|
||||
- 그룹명(Category): `"Axis Position Interlock"`
|
||||
- 축별 항목 구조는 기존 `TeachingPositionSetting.SettingPosition`(PrismaticGun) 패턴을 차용.
|
||||
- **간이 대안(축 수가 적고 빠른 적용이 목적):** `SequenceSetting`에 `[Category("Axis Position Interlock")]` 그룹으로 전역 On/Off + 축별 Min/Max scalar 추가. 단, 축 수 확장에 약함.
|
||||
|
||||
---
|
||||
|
||||
## 2. 현재 Settings 구조 (확인 결과)
|
||||
|
||||
### 2.1 Setting 클래스 패턴
|
||||
- 모든 Setting은 `Aurora.Api.ISettingItem` 구현.
|
||||
- 프로퍼티에 `PropertyTools.DataAnnotations`의 `[Category("그룹명")]`, `[DisplayName(...)]`, `[Browsable]`, `[ReadOnly]` 부착 → Setting UI에 그룹/표시명으로 노출.
|
||||
|
||||
### 2.2 등록 흐름
|
||||
- ID 상수: `WeldingComponents/WeldingCommon/EquipDefCommon.cs` 의 `class CommonSettingIds`
|
||||
```csharp
|
||||
public const string SystemParameter = "SystemParameterILSOS";
|
||||
public const string DoorInterlock = "DoorInterlock";
|
||||
public const string Sequence = "Sequence";
|
||||
// ...
|
||||
```
|
||||
- 인스턴스 등록: `WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs` 의 `RegisterSettings(SettingRegister register)`
|
||||
```csharp
|
||||
register(CommonSettingIds.SystemParameter, new SystemParameter());
|
||||
register(CommonSettingIds.LaserPowerCalParam, new LaserPowerCalParam());
|
||||
register(CommonSettingIds.Sequence, new SequenceSetting());
|
||||
register(CommonSettingIds.DoorInterlock, new DoorInterlockSetting());
|
||||
register(CommonSettingIds.RmsDatas, new SettingRmsDataList());
|
||||
```
|
||||
- 소비(읽기): 시퀀스/뷰에서 `AuroraEnv.SettingEntry[CommonSettingIds.XXX] as XXX`,
|
||||
모니터 시퀀스에서는 `context.Settings[CommonSettingIds.Sequence] as SequenceSetting` (예: `SeqStatusMonitor.StartNode`).
|
||||
|
||||
### 2.3 후보 클래스 평가
|
||||
| 클래스 | 위치 | 성격 | 전축 위치 InterLock 적합성 |
|
||||
|---|---|---|---|
|
||||
| `SystemParameter` | WeldingCommon/Settings | 전역 평면 파라미터 다수, `[Category]` 그룹 많음 | 축별 반복 구조엔 부적합. 단일 전역 토글 정도만 가능 |
|
||||
| `SequenceSetting` | WeldingCommon/Settings | 모니터링 On/Off 토글 모음("Alarm Monitoring Device" 등), 모니터 시퀀스가 직접 읽음 | **전역 Enable 토글** 자리로는 적합. 축별 Min/Max 보관엔 부적합 |
|
||||
| `DoorInterlockSetting` | WeldingCommon/Views/DoorInterlock | Door/Motor 인터락 전용(비번/해제 등) | 의미는 "인터락"으로 가깝지만 Door 도메인 전용 → 혼입 비권장 |
|
||||
| `TeachingPositionSetting` | **PrismaticGun**/settings | 축별 X/Y/Z 위치 + ±Limit 배열(`SettingPosition[]`) | **구조 선례로 가장 유사**. 단 PrismaticGun 전용이라 PTOP에서 그대로 못 씀 → 패턴만 차용 |
|
||||
|
||||
> 즉, "축별 범위" 구조의 정확한 선례는 `TeachingPositionSetting` 하나뿐이고, PTOP 공통 영역에는 대응 클래스가 없음.
|
||||
|
||||
### 2.4 PLC 전축 위치값 매핑 현황
|
||||
- `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs` 의 `eWordInput`은
|
||||
Cell/Lot ID·Page·Step·Slot 위주이고 **축 위치값 워드는 아직 미정의(대부분 `EMPTY_xx`)**.
|
||||
- 따라서 본 기능은 (1) Setting 신설 + (2) **PLC `eWordInput`에 축 위치 워드 주소 매핑 추가**가 함께 필요.
|
||||
- 위치값 읽기는 `PLCController.Logic.cs`의 `ReadWord(eWordInput)` / `ReadWords(start,end)` 사용.
|
||||
|
||||
---
|
||||
|
||||
## 3. 권장안 — 신규 전용 Setting 클래스
|
||||
|
||||
### 3.1 클래스 (스케치)
|
||||
`WeldingComponents/WeldingCommon/Settings/AxisPositionInterlockSetting.cs`
|
||||
```csharp
|
||||
namespace WeldingCommon.Settings
|
||||
{
|
||||
public class AxisPositionInterlockSetting : ISettingItem
|
||||
{
|
||||
[Category("Axis Position Interlock")]
|
||||
[DisplayName("전축 위치 InterLock 사용")]
|
||||
public bool UseAxisPositionInterlock { get; set; } = false;
|
||||
|
||||
// 축별 범위 항목 (TeachingPositionSetting.SettingPosition 패턴 차용)
|
||||
public AxisInterlockItem[] Axes { get; set; }
|
||||
|
||||
public AxisPositionInterlockSetting()
|
||||
{
|
||||
// 전축 정의: 장비 축 개수에 맞춰 초기화
|
||||
Axes = new[]
|
||||
{
|
||||
new AxisInterlockItem("AxisX"),
|
||||
new AxisInterlockItem("AxisY"),
|
||||
new AxisInterlockItem("AxisZ"),
|
||||
// ... 전축
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
public class AxisInterlockItem : NotifyPropertyChangedBase
|
||||
{
|
||||
public string Name { get; set; }
|
||||
public bool Use { get; set; } = true; // 축별 On/Off
|
||||
public double Min { get; set; } // 하한
|
||||
public double Max { get; set; } // 상한
|
||||
// 필요 시: PLC 워드 주소 인덱스, AlarmLevel(Heavy/Light) 등 추가
|
||||
|
||||
public AxisInterlockItem() { }
|
||||
public AxisInterlockItem(string name) { Name = name; }
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 ID 상수 추가
|
||||
`WeldingComponents/WeldingCommon/EquipDefCommon.cs` → `class CommonSettingIds`
|
||||
```csharp
|
||||
public const string AxisPositionInterlock = "AxisPositionInterlock";
|
||||
```
|
||||
|
||||
### 3.3 등록
|
||||
`WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs` → `RegisterSettings()`
|
||||
```csharp
|
||||
register(CommonSettingIds.AxisPositionInterlock, new AxisPositionInterlockSetting());
|
||||
```
|
||||
|
||||
### 3.4 InterLock 판정 로직 위치
|
||||
- 모니터 시퀀스에서 주기적으로 PLC 축 위치를 읽어 Min/Max 비교 → 벗어나면 InterLock/알람.
|
||||
- 권장 위치: `Machines/ILSOS_PrismaticRD_PTOP/Sequences/Monitoring/SeqStatusMonitor.cs` (또는 `SeqAlarmMonitor.cs`).
|
||||
- `StartNode`에서 `context.Settings[CommonSettingIds.AxisPositionInterlock] as AxisPositionInterlockSetting` 캐싱.
|
||||
- `UpdateStatus`/`UpdateIO` 루프에서 `ReadWord(eWordInput.축위치)` ↔ `Axes[i].Min/Max` 비교.
|
||||
- 위반 시 `AlarmManager`로 알람 발생 + 필요 시 `_plc.WriteBit(...)`로 인터락 신호 출력(기존 `PC_HEAVY_ALARM_STATUS` 패턴 참조).
|
||||
|
||||
---
|
||||
|
||||
## 4. 간이 대안 (빠른 적용용)
|
||||
|
||||
축 수가 적고 구조화가 과하다면, `SequenceSetting`에 그룹만 추가:
|
||||
```csharp
|
||||
[Category("Axis Position Interlock")]
|
||||
public bool UseAxisPositionInterlock { get; set; } = false;
|
||||
public double AxisXMin { get; set; }
|
||||
public double AxisXMax { get; set; }
|
||||
public double AxisYMin { get; set; }
|
||||
public double AxisYMax { get; set; }
|
||||
// ...
|
||||
```
|
||||
- 장점: 신규 클래스/등록 불필요(이미 모니터가 `CommonSettingIds.Sequence`로 읽음).
|
||||
- 단점: 축 수 확장/가독성 약함. "SequenceSetting 변경 시 재부팅 필요"(클래스 상단 주석) 제약 있음.
|
||||
|
||||
---
|
||||
|
||||
## 5. 최종 추천
|
||||
|
||||
1. **권장:** 신규 `AxisPositionInterlockSetting`(WeldingCommon/Settings) + `CommonSettingIds.AxisPositionInterlock` + `CommonEquipmentSetup.RegisterSettings()` 등록, 그룹명 **"Axis Position Interlock"**, 축별 항목은 `TeachingPositionSetting.SettingPosition` 패턴 차용.
|
||||
2. 함께 필요: PLC `eWordInput`에 전축 위치 워드 주소 매핑 추가.
|
||||
3. 판정/인터락은 `SeqStatusMonitor`(또는 `SeqAlarmMonitor`)에서 Setting을 읽어 Min/Max 비교 후 `AlarmManager`/`WriteBit`로 처리.
|
||||
4. 빠른 PoC가 목적이면 4절 간이 대안으로 `SequenceSetting`에 "Axis Position Interlock" 그룹 추가도 가능(확장성은 낮음).
|
||||
|
||||
> 상태: 위치/구조 추천만 정리. 실제 코드 추가는 미적용.
|
||||
@ -1,86 +0,0 @@
|
||||
# SequenceSetting "Axis Position Interlock" 그룹 추가 — 속성 설계 분석
|
||||
|
||||
**분석 일시:** 2026-06-17 14:44:42
|
||||
**대상 소스:** `WeldingComponents/WeldingCommon/Settings/SequenceSetting.cs` (`SequenceSetting` 클래스)
|
||||
**관련 분석:** `docs/분석/2026/06/17/143900_axis_position_interlock_setting_location.md` (간이 대안 절)
|
||||
**목표:** 전축 위치(섹터 각도) 모니터링 InterLock 기준값을 `SequenceSetting`에 그룹으로 추가.
|
||||
|
||||
---
|
||||
|
||||
## 0. 확정 조건 (사용자)
|
||||
|
||||
- **위치:** `SequenceSetting`에 `[Category("Axis Position Interlock")]` 그룹만 추가 (신규 클래스 신설 안 함).
|
||||
- **속성:** 수직값 / 수평값을 **단일 기준값 + 허용오차** 형태로 등록 (Min/Max 아님).
|
||||
- **단위:** 섹터값이라 **도(°, degree)**.
|
||||
- **Enable 토글:** 추가 안 함 (`UseAxisPositionInterlock` 없음).
|
||||
- **상태:** 코드 수정은 미적용. 분석/설계만 기록.
|
||||
|
||||
---
|
||||
|
||||
## 1. 추가 위치 (소스)
|
||||
|
||||
- 파일: `WeldingComponents/WeldingCommon/Settings/SequenceSetting.cs`
|
||||
- 클래스: `public class SequenceSetting : ISettingItem`
|
||||
- 추가 지점: 클래스 마지막 속성 `GroupRamingUse`(파일 기준 약 L69) **아래**에 신규 그룹 추가.
|
||||
- 등록은 이미 되어 있음 — `CommonEquipmentSetup.RegisterSettings()`에서
|
||||
`register(CommonSettingIds.Sequence, new SequenceSetting());` (추가 등록 불필요).
|
||||
- 소비(읽기): 모니터 시퀀스에서 `context.Settings[CommonSettingIds.Sequence] as SequenceSetting`
|
||||
(예: `Machines/ILSOS_PrismaticRD_PTOP/Sequences/Monitoring/SeqStatusMonitor.cs` `StartNode`).
|
||||
|
||||
---
|
||||
|
||||
## 2. 제안 속성 (스케치 — 미적용)
|
||||
|
||||
```csharp
|
||||
[Category("Axis Position Interlock")]
|
||||
[DisplayName("수직 기준값 [deg]")]
|
||||
public double VerticalSector { get; set; } = 0.0;
|
||||
|
||||
[DisplayName("수직 허용오차 [deg]")]
|
||||
public double VerticalTolerance { get; set; } = 0.0;
|
||||
|
||||
[DisplayName("수평 기준값 [deg]")]
|
||||
public double HorizontalSector { get; set; } = 0.0;
|
||||
|
||||
[DisplayName("수평 허용오차 [deg]")]
|
||||
public double HorizontalTolerance { get; set; } = 0.0;
|
||||
```
|
||||
|
||||
> 속성명(`VerticalSector` / `HorizontalSector` 등)은 제안값. 명명 선호에 따라 조정 가능.
|
||||
|
||||
---
|
||||
|
||||
## 3. 판정 로직 (참고)
|
||||
|
||||
기준값 ± 허용오차 범위로 InterLock 판정:
|
||||
```
|
||||
하한 = VerticalSector - VerticalTolerance
|
||||
상한 = VerticalSector + VerticalTolerance
|
||||
if (현재수직각도 < 하한 || 현재수직각도 > 상한) → InterLock
|
||||
// 수평도 동일하게 HorizontalSector ± HorizontalTolerance
|
||||
```
|
||||
- 위치: `SeqStatusMonitor`(또는 `SeqAlarmMonitor`)의 루프 노드에서 PLC 각도값과 비교.
|
||||
- 위반 시 `AlarmManager`로 알람 발생 + 필요 시 `_plc.WriteBit(...)` 인터록 신호
|
||||
(기존 `PC_HEAVY_ALARM_STATUS` 출력 패턴 참조).
|
||||
|
||||
---
|
||||
|
||||
## 4. 주의점
|
||||
|
||||
1. **재부팅 필요** — `SequenceSetting.cs` 상단 주석 *"SequenceSetting 이 변경되면, 재부팅 필요함."*
|
||||
→ 이 그룹 값을 변경하면 재부팅이 전제됨.
|
||||
2. **PLC 각도 워드 미매핑** — `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs`의
|
||||
`eWordInput`에 전축(수직/수평) 섹터 각도 워드 주소가 아직 없음(대부분 `EMPTY_xx`).
|
||||
→ 실제 모니터링하려면 워드 주소 매핑 추가가 선행돼야 함. 읽기는 `PLCController.Logic.cs`의
|
||||
`ReadWord(eWordInput)` 사용.
|
||||
|
||||
---
|
||||
|
||||
## 5. 적용 시 체크리스트 (요약)
|
||||
|
||||
- [ ] `SequenceSetting.cs` 에 `Axis Position Interlock` 그룹 4속성 추가 (수직/수평 × 기준값/허용오차, 단위 deg)
|
||||
- [ ] PLC `eWordInput` 에 수직/수평 섹터 각도 워드 주소 매핑
|
||||
- [ ] `SeqStatusMonitor`(또는 `SeqAlarmMonitor`)에 기준값±허용오차 판정 + 알람/인터록 처리
|
||||
- [ ] 설정 변경 후 재부팅 안내(설계상 제약)
|
||||
|
||||
> 상태: 설계/위치 분석만. 실제 코드 추가는 미적용.
|
||||
@ -1,122 +0,0 @@
|
||||
# Laser Ready 판정 변경 — DI(9) → DI(12) & DI(24) 동시 조건
|
||||
|
||||
**분석 일시:** 2026-06-17 15:00:31 (15:10 정확한 매핑으로 갱신)
|
||||
**대상:** `WeldingComponents/WeldingCommon/Views/Recipes/UCScannerObjectTeachingControlBoxViewModel.cs`
|
||||
**관련:** `docs/분석/2026/06/17/143131_laser_ready_di9_analysis.md` (이전 DI9 분석)
|
||||
|
||||
---
|
||||
|
||||
## 0. 요청/설명 (사용자)
|
||||
|
||||
- 토글 버튼(`PerformCmdLaserReadyCheck`)을 누르면 **Control (9, 13)** 이 켜지고 꺼짐 (현행 `WriteDoBit(9)`, `WriteDoBit(13)` 유지).
|
||||
- `OnMonitoring`에서는 현재 **DI(9)만** 보고 있는데, 9번이 아니라 **12번과 24번 둘 다(AND)** 보는 조건으로 변경.
|
||||
- 확정 사항: **(1) AND 조건 맞음. (2) DI 24는 현장 배선 기준이 맞음(아래 enum 불일치 참고).**
|
||||
|
||||
---
|
||||
|
||||
## 1. 매핑 정정 — 진짜 enum은 PAIXIO가 아니라 PAIX_PrismaticScanner
|
||||
|
||||
처음엔 범용 `AuroraIO/Vendor/PAIX/PAIXIO.cs`의 `ePDIAddress`(DI12=StartSwitch, DI24=FanAlarm8)로 봤으나,
|
||||
이 ViewModel은 상단에 `using static WeldingCommon.Devices.Laser.PAIX_PrismaticScanner;` 가 있고
|
||||
**레이저 전용 IO 매핑**(`WeldingComponents/WeldingCommon/Devices/Laser/LaserIOControl.cs` 내 `PAIX_PrismaticScanner`)을 사용함.
|
||||
머신측 `Machines/ILSOS_PrismaticRD_PTOP/Device/IO/PAIX_PrismaticScanner.cs` 도 동일 enum.
|
||||
|
||||
### 1.1 입력 `ePrismaticDIAddress`
|
||||
| DI | 의미 |
|
||||
|---|---|
|
||||
| 9 | CoreLaser_Laser_Ready |
|
||||
| 10 | CoreLaser_Error_State |
|
||||
| 11 | CoreLaser_Laser_Output_State |
|
||||
| **12** | **CoreLaser_Control_Status** |
|
||||
| 13 | RingLaser_Laser_Ready |
|
||||
| 14 | RingLaser_Error_State |
|
||||
| 15 | RingLaser_Laser_Output_State |
|
||||
| 23(enum) / **24(현장)** | **RingLaser_Control_Status** |
|
||||
|
||||
### 1.2 출력 `ePrismaticDOAddress`
|
||||
| DO | 의미 |
|
||||
|---|---|
|
||||
| 9 | CoreLaser_Control |
|
||||
| 10 | CoreLaser_ErrorClearing |
|
||||
| 13 | RingLaser_Control |
|
||||
| 14 | RingLaser_ErrorClearing |
|
||||
| 17 | EX_Red_Control |
|
||||
|
||||
### 1.3 의미 해석
|
||||
- 토글 버튼: **DO9 = CoreLaser_Control**, **DO13 = RingLaser_Control** → Core·Ring 레이저 Control 출력 ON/OFF.
|
||||
- 변경 후 모니터링: 그 피드백인 **Control_Status** 입력 2개를 봄
|
||||
- **DI12 = CoreLaser_Control_Status**
|
||||
- **DI24 = RingLaser_Control_Status** (현장 배선 기준)
|
||||
- 즉 "Core·Ring 두 레이저의 Control Status가 **모두 ON**" 일 때 `IsLaserReady = true`.
|
||||
|
||||
> 참고: 기존 DI9는 **CoreLaser_Laser_Ready** 단독(Core만, Ring 미반영)이었음.
|
||||
> 또한 `LaserIOControl.GetLaserReady()`는 `CoreLaser_Laser_Ready(9) && RingLaser_Laser_Ready(13)`로 *Laser_Ready* 비트를 봄(이번 변경은 *Control_Status* 비트 기준이라 다름).
|
||||
|
||||
---
|
||||
|
||||
## 2. enum 불일치 (중요)
|
||||
|
||||
`PAIX_PrismaticScanner.ePrismaticDIAddress`에 **`RingLaser_Control_Status = 23`** 으로 되어 있으나,
|
||||
**현장 실제 DI는 24**. → enum 값이 outdated.
|
||||
|
||||
- 영향 파일(둘 다 동일 enum):
|
||||
- `WeldingComponents/WeldingCommon/Devices/Laser/LaserIOControl.cs` (L35)
|
||||
- `Machines/ILSOS_PrismaticRD_PTOP/Device/IO/PAIX_PrismaticScanner.cs` (L28)
|
||||
- (참고: `Machines/ILSOS_PrismaticScanner/Device/IO/PAIX_PrismaticScanner.cs` 도 동일)
|
||||
- 권장: enum을 `RingLaser_Control_Status = 24` 로 정정. (정정 시 enum 상수로 깔끔하게 참조 가능)
|
||||
|
||||
---
|
||||
|
||||
## 3. 수정 방안 (적용 예정)
|
||||
|
||||
### 3.1 `OnMonitoring()` — DI 9 → (DI 12 && DI 24)
|
||||
```csharp
|
||||
try
|
||||
{
|
||||
// Laser Ready: Core·Ring Control Status 둘 다 ON 일 때만 Ready
|
||||
// DI 12 = CoreLaser_Control_Status, DI 24 = RingLaser_Control_Status(현장)
|
||||
if (_IODevice.ReadDI(12) && _IODevice.ReadDI(24))
|
||||
{
|
||||
IsLaserReady = true;
|
||||
}
|
||||
else
|
||||
{
|
||||
IsLaserReady = false;
|
||||
}
|
||||
}
|
||||
catch (Exception ex)
|
||||
{
|
||||
Log.E($"[OnMonitoring] DI 읽기 실패: {ex.Message}");
|
||||
IsLaserReady = false;
|
||||
}
|
||||
```
|
||||
|
||||
### 3.2 `PerformCmdLaserReadyCheck()` — 변경 없음
|
||||
- DO 9(CoreLaser_Control)·13(RingLaser_Control) 토글 유지.
|
||||
|
||||
### 3.3 변경 요약
|
||||
| 위치 | 현재 | 변경 후 |
|
||||
|---|---|---|
|
||||
| `OnMonitoring()` | `ReadDI(9)` (CoreLaser_Laser_Ready) | `ReadDI(12) && ReadDI(24)` (Core·Ring Control_Status) |
|
||||
| `PerformCmdLaserReadyCheck()` | `WriteDoBit(9/13)` | 변경 없음 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 구현 옵션 (가독성)
|
||||
|
||||
- **옵션 A (최소 변경):** 리터럴 `ReadDI(12) && ReadDI(24)` + 주석으로 의미 표기. `_IODevice`가 base `IODevice` 타입이라 그대로 사용 가능. (즉시 적용 용이)
|
||||
- **옵션 B (정공법):** enum `RingLaser_Control_Status = 24` 정정 후, `_IODevice`를 `PAIX_PrismaticScanner`로 캐스팅하여
|
||||
`ReadDiBit(ePrismaticDIAddress.CoreLaser_Control_Status) && ReadDiBit(ePrismaticDIAddress.RingLaser_Control_Status)` 로 상수 참조.
|
||||
- 장점: 매직넘버 제거, 의미 명확. 단점: 캐스팅/타입 의존 추가.
|
||||
- 권장: 우선 옵션 A로 적용하되, **enum 23→24 정정은 별도로 반드시 반영**(다른 코드가 23으로 참조 시 버그 가능성).
|
||||
|
||||
---
|
||||
|
||||
## 5. 결론 / 적용 체크리스트
|
||||
|
||||
- [ ] `OnMonitoring()` 판정: `ReadDI(9)` → `ReadDI(12) && ReadDI(24)` (AND 확정)
|
||||
- [ ] 버튼은 DO9/13 그대로 유지
|
||||
- [ ] `PAIX_PrismaticScanner.ePrismaticDIAddress.RingLaser_Control_Status` **23 → 24** 정정(LaserIOControl.cs / 머신 PAIX 파일)
|
||||
- [ ] 의미: Core Control Status(12) AND Ring Control Status(24) 모두 ON → Laser Ready
|
||||
|
||||
> 상태: 분석/수정 방안만 기록. 실제 코드 수정은 미적용.
|
||||
@ -1,103 +0,0 @@
|
||||
# IO Interface Map(DI/DO 데이터 맵) 경로 — 소스상 설정 위치 분석
|
||||
|
||||
**분석 일시:** 2026-06-17 16:20:10
|
||||
**대상:** IODevice가 읽는 DI/DO 데이터 맵(CSV) 경로가 소스 어디서 설정되는가
|
||||
**관련:** `docs/분석/2026/06/17/150031_laser_ready_di12_di24_change.md` (DI12/24 판정 변경)
|
||||
|
||||
---
|
||||
|
||||
## 0. 질문 (사용자)
|
||||
|
||||
- `OnMonitoring`에서 읽는 DI 12 / 24 같은 IO의 **데이터 맵(CSV)** 의 실제 로드 경로가 소스상 어디서 설정되는지.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론
|
||||
|
||||
- **실제 경로 문자열 값은 소스에 하드코딩돼 있지 않음.**
|
||||
- 소스에서 확인되는 것은 (1) 경로를 **읽는 메커니즘**, (2) 경로 **속성 정의**, (3) 디바이스 **등록 시 기본값(빈 값)** 까지.
|
||||
- 실제 경로는 **저장된 디바이스 Config(설정)** 에 들어 있으며, **Setting → Device(IODevice) Config 화면의 `IOInterfaceMapDI` 필드**(또는 디스크의 해당 config 파일)에서 지정됨.
|
||||
- 영속화/역직렬화는 Aurora 프레임워크 DLL이 처리 → 이 레포 소스에는 경로 문자열 자체가 없음.
|
||||
|
||||
---
|
||||
|
||||
## 2. 소스 흐름 (확인된 부분)
|
||||
|
||||
### ① 디바이스 등록 — 기본 config 주입 (경로 미지정)
|
||||
`Machines/ILSOS_PrismaticRD_PTOP/EquipmentSetup.cs:153`
|
||||
```csharp
|
||||
registry.Register(CommonDeviceIds.IODevice,
|
||||
() => new PAIX_PrismaticScanner(AuroraEnv, CommonDeviceIds.IODevice, isSimul),
|
||||
new IOUnitConfig()); // 기본 IOUnitConfig (경로 빈 값)
|
||||
```
|
||||
|
||||
### ② config의 경로 속성 — 기본값 빈 문자열
|
||||
`AuroraDevices/AuroraIO/IOUnitConfig.cs`
|
||||
```csharp
|
||||
internal class IOUnitConnConfig : IConnConfig
|
||||
{
|
||||
[InputFilePath]
|
||||
public string IOInterfaceMapDI { get; set; } = ""; // DI 맵 경로
|
||||
[InputFilePath]
|
||||
public string IOInterfaceMapDO { get; set; } = ""; // DO 맵 경로
|
||||
...
|
||||
}
|
||||
```
|
||||
- `[InputFilePath]` 어트리뷰트 → Setting 화면에서 파일 경로 지정 필드로 노출.
|
||||
|
||||
### ③ 활성화 시 그 경로로 CSV 로드
|
||||
`AuroraDevices/AuroraIO/IODevice.cs`
|
||||
```csharp
|
||||
protected override int DoActivate(IDeviceConfig config) {
|
||||
_connConfig = config.ConnConfig; // L148
|
||||
...
|
||||
LoadIOTable(); // → MappingDIO()
|
||||
}
|
||||
// MappingDIO():
|
||||
var m_connConfig = _connConfig as IOUnitConnConfig;
|
||||
fileName = m_connConfig.IOInterfaceMapDI; // 실제 로드 경로
|
||||
StreamReader sr = new StreamReader(fileName, ...);
|
||||
```
|
||||
- 읽기 진입: `ReadDI(int)` → `_iOUnit.ReadDiBit(index)` (`IODevice.cs:212`).
|
||||
|
||||
---
|
||||
|
||||
## 3. 데이터 맵(CSV) 실제 위치 (현장/레포)
|
||||
|
||||
- 레포 복사본: `Doc/ILSOSConfig/ILSOS_PrismaticScanner/_device/_io/`
|
||||
- 현장 런타임: `D:\ILSOSConfig\ILSOS_PrismaticScanner\_device\_io\`
|
||||
- 기본 파일: `DI.csv`, `DO.csv` + 라인/공정별 변형 다수
|
||||
(`DI_LINE_CC-CAP_ASSY_WELDING.csv`, `DI_PRIBAT_L2.csv`, `DI_SMW.csv`, `DI_SEALPIN.csv`, `DI_PRE_WELDING.csv`, `DI_PILOT_LINE_ANODE_WELDING.csv`, `DI_PILOT LINE CATHODE WELDING.csv` 등)
|
||||
- 어떤 파일이 로드되는지는 ②의 `IOInterfaceMapDI` 값(=저장된 Config)이 결정.
|
||||
|
||||
### 주의 — 기본 `DI.csv`의 12/24/25는 레이저 Control Status가 아님
|
||||
```
|
||||
12,12,START SWITCH,START SWITCH
|
||||
24,24,FAN 8 ALARM,FAN 8 ALARM
|
||||
25,25,LASER Ready,LASER Ready
|
||||
```
|
||||
- 기본 `DI.csv` 기준 12=START SWITCH, 24=FAN 8 ALARM, 25=LASER Ready.
|
||||
- 코드(`PAIX_PrismaticScanner.ePrismaticDIAddress`)는 12=CoreLaser_Control_Status, 23=RingLaser_Control_Status로 다르게 보고 있음 → **enum과 실제 로드되는 CSV 맵이 불일치할 수 있음.**
|
||||
|
||||
---
|
||||
|
||||
## 4. 정리표
|
||||
|
||||
| 알고 싶은 것 | 소스 확인 | 위치 |
|
||||
|---|---|---|
|
||||
| 경로를 읽는 코드 | O | `IODevice.cs` `MappingDIO()` / `ReadDI()` |
|
||||
| 경로 속성 정의 | O | `IOUnitConfig.cs` `IOInterfaceMapDI` |
|
||||
| 디바이스 등록(기본값) | O | `EquipmentSetup.cs:153` |
|
||||
| 실제 경로 문자열 값 | X (소스에 없음) | 저장된 디바이스 Config / Setting UI |
|
||||
|
||||
---
|
||||
|
||||
## 5. [TODO / 추후 확인할 것]
|
||||
|
||||
- [ ] **현장 PC에서 실제 로드되는 DI/DO 맵 파일 확정**: Setting → Device → IODevice Config 의 `IOInterfaceMapDI` / `IOInterfaceMapDO` 값 확인 (또는 `D:\ILSOSConfig\ILSOS_PrismaticScanner\_device\_io\` 에서 실제 사용 파일).
|
||||
- [ ] **해당 CSV의 DI 12 / 24 줄 의미 확인**: 레이저 Core/Ring Control Status가 맞는지, 아니면 START SWITCH / FAN 8 ALARM 인지.
|
||||
- 만약 기본 `DI.csv`(12=START SWITCH, 24=FAN 8 ALARM)가 로드 중이면, `ReadDI(12) && ReadDI(24)` 판정이 의도와 다르게 동작 → CSV 맵 또는 인덱스 재확인 필요.
|
||||
- [ ] **enum vs CSV 정합성**: `PAIX_PrismaticScanner.ePrismaticDIAddress`(12=CoreLaser_Control_Status, 23=RingLaser_Control_Status)와 현장 CSV 맵이 일치하는지 대조. 불일치 시 어느 쪽을 기준으로 맞출지 결정.
|
||||
- [ ] (참고) `RingLaser_Control_Status` enum 값은 현재 23으로 두기로 함(현장 표기 23, 조건은 24 리터럴 사용). CSV 확인 후 최종 정합성 점검.
|
||||
|
||||
> 상태: 소스 추적/위치 분석만. 실제 현장 Config 값 확인은 미완(위 TODO).
|
||||
@ -1,67 +0,0 @@
|
||||
# PLC DeviceMap 갱신 (260617 Laser Interface 반영)
|
||||
|
||||
**작업 일시:** 2026-06-17 16:53:41
|
||||
**근거 문서:** `docs/PtoP 유니셀 용접기 PLC 인터페이스_260617/유니셀 PtoP 단동기 Laser Interface_260617.xlsx`
|
||||
**대상 경로:** `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\External\PLC`
|
||||
|
||||
---
|
||||
|
||||
## 0. 작업 요약
|
||||
|
||||
- 기존 `PLC_DeviceMap_*` 각 bit/word 파일을 `260617_backup` 으로 백업.
|
||||
- 위 Excel(시트 M70K=Bit, D70K=Word)을 분석해 4개 맵 파일의 **내부 매핑(Comment)만** 갱신. 파일명/주소행 범위 유지.
|
||||
- 네이밍: 기존 코드 스타일(`PC_*` / `PLC_*`) 유지. 양극(+)은 `_P` 접미사. 음/양극 모두 Excel대로 채움.
|
||||
|
||||
## 1. Excel 구조 → 파일 매핑
|
||||
|
||||
| Excel 블록 | 방향 | 대상 파일 | 네이밍 |
|
||||
|---|---|---|---|
|
||||
| M70K 좌(70000~) | Laser→PLC (PC 출력) | Bit_Output_M | `PC_*` |
|
||||
| M70K 우(70500~) | PLC→Laser (PC 입력) | Bit_Input_M | `PLC_*` |
|
||||
| D70K 좌(70000~) | Laser1→PLC (PC 출력) | Word_Output_D | `PC_*` |
|
||||
| D70K 우(70500~) | PLC→Laser1 (PC 입력) | Word_Input_D | `PLC_*` |
|
||||
|
||||
- Excel 메모: "음/양극 레이저 하나로 사용 중이라 음극만 사용 하기로" (70101 셀). → 단, 요청에 따라 양극(+)도 전부 매핑함.
|
||||
|
||||
## 2. 생성 결과 (매핑된 주소)
|
||||
|
||||
### ① Bit_Output_M (M70000~70143)
|
||||
- (-) 70000 LIVE, 70001 AUTO_STATUS, 70002 AUTO_COMPLETE, 70003 MANUAL_COMPLETE, 70004 LIGHT_AL, 70005 HEAVY_AL, 70008 PAGE_CHANGE_COMPLETE, 70009 RECIPE_CHANGE_COMPLETE, 70016~70018 WELD READY_ACK/BUSY/COMPLETE
|
||||
- (+) 70100~70105, 70108, 70116~70118 WELD_01, 70119~70121 WELD_02, 70124 WELD_MONI_COMPLETE, 70125~70128 WELD_CH2(+MoniComplete), 70133~70135 M_POWER, 70137~70139 PARA(READ_ACK/SET_ACK/CHANGE_REQ)
|
||||
|
||||
### ② Bit_Input_M (M70500~70643)
|
||||
- (-) 70500~70509(LIVE,AUTO,AUTO_REQ,MANUAL_REQ,LIGHT_AL,HEAVY_AL,DOOR,EMO,PAGE_CHANGE_REQ,RECIPE_CHANGE_REQ), 70516~70518 WELD REQ/WAIT/COMP_ACK
|
||||
- (+) 70600~70608, 70610 DISPLACE_USE, 70616~70618 WELD_01, 70619~70621 WELD_02, 70624 WELD_MONI_COMP_ACK, 70625~70628 WELD_CH2(+MoniCompAck), 70630 LASER2_ERROR_RESET, 70632~70635 LASER2_M_POWER, 70637~70639 LASER2_PC_PARA
|
||||
|
||||
### ③ Word_Output_D (D70000~70099)
|
||||
- 70000 PC_ErrorCode, 70001 PC_PageNo, 70002 PC_RecipeNo
|
||||
|
||||
### ④ Word_Input_D (D70500~70599)
|
||||
- 70500 PLCErrorCode, 70501 PLC_PageNo, 70502 PLC_RecipeNo, 70510 PLC_Head_Theta_Position
|
||||
|
||||
## 3. 기존 대비 주요 변경 (delta)
|
||||
|
||||
- **70502 (Word_Input): PLC_StepNo → PLC_RecipeNo** (의미 변경)
|
||||
- **70509 (Bit_Input): PLC_RMS_USED → PLC_RECIPE_CHANGE_REQ** (의미 변경)
|
||||
- 신규: Recipe_CHG(70009/70509), Weld_02·Weld_CH2·M_Power·PC_Para(양극), DisplaceUse(70610), Head_Theta_Position(70510), PC_RecipeNo(70002/70502)
|
||||
- 신규 스펙에서 빠진 기존 항목: PC_WELD_NG_JUDGE(70020), PC_RMS_PARAMETER_READ_REQUEST_ACK(70037), PLC_ALARM_RESET(70530), PLC_RMS_PARAMETER_READ_REQUEST(70537)
|
||||
- 기존 파일 버그 수정: Word_Input 70585~70599 가 `M`으로 오기 → `D`로 정정.
|
||||
|
||||
## 4. [TODO / 추후 확인할 것] — 코드 정합성 ⚠️
|
||||
|
||||
PLC 맵(주소→의미)이 바뀌었으므로, 주소를 enum으로 읽는 코드와 **불일치** 가능성. 반드시 대조 필요:
|
||||
|
||||
- [ ] **`Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs`**
|
||||
- `eWordInput.PLC_STEP_NO = 2` (D70502) → 새 맵은 **RecipeNo**. StepNo를 코드가 D70502로 읽으면 의미 깨짐. (StepNo 주소 재배정 or 코드 수정 필요)
|
||||
- `eBitInput.PLC_RMS_USED = 0x09` (M70509) → 새 맵은 **RECIPE_CHANGE_REQ**. `SeqStatusMonitor.UpdateIO`가 `PLC_RMS_USED` 읽음 → 충돌.
|
||||
- `eBitInput.PLC_ALARM_RESET = 0x1E`(M70530), `PLC_RMS_PARAMETER_READ_REQUEST = 0x25`(M70537) → 새 맵엔 없음. 사용처(`SeqStatusMonitor`, RMS) 확인.
|
||||
- `eBitOutput.PC_WELD_NG_JUDGE = 0x14`(M70020), `PC_RMS_PARAMETER_READ_REQUEST_ACK = 0x25`(M70037) → 새 맵엔 없음.
|
||||
- [ ] 신규 양극(+)/Laser2 신호(Weld_02, Weld_CH2, M_Power, PC_Para 등) 사용 여부 및 enum 추가 검토.
|
||||
- [ ] **70628 Excel 라벨 중복**: Excel J열에서 70627·70628 모두 "Weld_CH2Comp_ACK"로 표기됨. 70628은 출력측(70128 Weld_CH2MoniComp) 대칭으로 보아 `PLC_WELD_CH2_MONI_COMP_ACK_P`로 매핑함 → **현장/PLC 측에 실제 의미 확인 필요.**
|
||||
- [ ] "음극만 사용" 메모 vs 양극 전부 매핑 — 실제 운영에서 양극 사용 여부 확정.
|
||||
|
||||
## 5. 백업
|
||||
|
||||
- `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\External\PLC\260617_backup\` 에 기존 `PLC_DeviceMap_*` (복사본 포함) 6개 보관.
|
||||
|
||||
> 상태: 4개 CSV 갱신 완료(라이브 config). 코드 정합성(4절)은 미확인 — 추후 작업.
|
||||
@ -1,89 +0,0 @@
|
||||
# PLC 맵 ↔ 소스 enum 정합성 분석 (Input/Output 검증 + StepNo + 배수)
|
||||
|
||||
**분석 일시:** 2026-06-17 17:13:12
|
||||
**연계:** `docs/분석/2026/06/17/165341_plc_devicemap_update_260617.md` (맵 갱신 작업)
|
||||
**대상 소스:**
|
||||
- `WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Address.cs` (base: `eCommonBit/WordInput/Output`)
|
||||
- `WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Config.cs` (base 로직)
|
||||
- `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCController.Address.cs` (machine: `eBit/WordInput/Output`)
|
||||
- `Machines/ILSOS_PrismaticRD_PTOP/Device/PLC/PLCContoller.Config.cs` (생성자만)
|
||||
|
||||
> 상태: **분석/판단만**. 소스·맵 추가 수정은 미적용.
|
||||
|
||||
---
|
||||
|
||||
## 1. Input/Output 뒤바뀜 여부 → **안 바뀜 (정상)**
|
||||
|
||||
판단 기준 = "기존 Input/Output 파일이 담던 방향" 과 "Excel 블록 방향" 대조:
|
||||
|
||||
| 구분 | 기존 CSV | Excel 블록 | 방향 | 결론 |
|
||||
|---|---|---|---|---|
|
||||
| **Output** | `Bit_Output_M` = M70000~ , `PC_*` | 좌측 70000 = **"Laser→PLC"** | PC가 PLC로 **씀(OUT)** | 70000 = Output ✓ |
|
||||
| **Input** | `Bit_Input_M` = M70500~ , `PLC_*` | 우측 70500 = **"PLC→Laser"** | PC가 PLC에서 **읽음(IN)** | 70500 = Input ✓ |
|
||||
|
||||
- "Laser" = 우리(레이저측) PC. Laser→PLC = 우리가 PLC로 출력 = **Output**. PLC→Laser = 우리가 읽는 입력 = **Input**.
|
||||
- 이번에 생성한 4파일도 동일 규칙(Output=70000블록 PC_*, Input=70500블록 PLC_*)으로 작성됨 → **방향 정상, 파일명 안 바뀜.**
|
||||
- Word도 동일: `Word_Output_D`=D70000(PC_*), `Word_Input_D`=D70500(PLC_*). ✓
|
||||
|
||||
---
|
||||
|
||||
## 2. enum index = (주소 − base) 오프셋 (★ 배수/읽기 핵심)
|
||||
|
||||
- CSV 파서(`ParsePLCBitWordAddressFromCSV`)는 행 순서대로 index 0,1,2… 부여. 행이 연속(M70500,70501,…)이므로
|
||||
**enum 값(offset) = (M주소 − base)**.
|
||||
- 예: `PLC_WELD_READY_REQ = 0x10`(16) ↔ M70516, `PLC_AUTO_STATUS_P = 0x65`(101) ↔ M70601. ✓
|
||||
- 즉 소스 enum은 "주소"가 아니라 "오프셋"을 들고 있음. 맵에서 주소 의미가 바뀌면 **같은 오프셋을 읽는 코드가 다른 신호를 읽게 됨.**
|
||||
|
||||
### 배수(읽기 블록) 우려 — 확인 필요
|
||||
- Bit는 word(16bit) 단위로 읽힘 → 대량 read count는 16의 배수.
|
||||
- 이번 신규 최대 오프셋: **Bit In 139**(M70639 Laser2 PC_Para CHG_ACK), **Bit Out 139**(M70139), **Word In 10**(D70510 Head_Theta), **Word Out 2**(D70002).
|
||||
- offset 139는 word #8(128~143) 안 → Bit는 **최소 9 word(144bit)** 읽어야 갱신됨. Word In은 **최소 11 word** 읽어야 D70510 갱신.
|
||||
- [확인필요] PLCBase/통신의 **read count(블록 길이)** 가 위 최대 오프셋을 포함하는지. 작으면 고오프셋(특히 Laser2 130~139, Head_Theta 10)이 **안 읽힘**. (사용자 지적 "배수라 못 읽을 수도")
|
||||
|
||||
---
|
||||
|
||||
## 3. StepNo "왜?" — 코드가 D70502를 StepNo로 읽음
|
||||
|
||||
- 코드: `Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPrismaticScanner.cs:422`
|
||||
`_TotalWeldingStep = ReadWord(eWordInput.PLC_STEP_NO)` → **offset 2 = D70502** 를 "총 용접 step" 으로 사용.
|
||||
- 기존 `Word_Input` CSV: D70502 = PLC_StepNo (코드와 일치).
|
||||
- **신규 Excel: D70502 = PLC_RecipeNo** 로 재배정 → 같은 offset 2를 코드는 StepNo로 읽음 → `_TotalWeldingStep` 이 **RecipeNo 값을 읽게 됨(오동작)**.
|
||||
- 판단: PLC 인터페이스가 StepNo를 빼고 offset 2에 RecipeNo를 넣은 것. **StepNo 신호 위치(또는 폐지 여부)와 RecipeNo offset 확정 필요.** (CSV 코멘트만으론 코드 동작 안 바뀜 — 실제 PLC가 그 주소에 무엇을 싣는지가 핵심)
|
||||
|
||||
---
|
||||
|
||||
## 4. 신규 맵 ↔ 코드 enum 충돌 (사용처 확인됨)
|
||||
|
||||
신규 Excel 맵이 **기존 사용 중인 신호를 빈칸/재배정** 한 것들:
|
||||
|
||||
| 신호(offset/주소) | 코드 사용처 | 신규 맵 | 영향 |
|
||||
|---|---|---|---|
|
||||
| `PLC_RMS_USED` (0x09 / M70509) | `SeqStatusMonitor.cs:106` `Status.RMSUse` | 70509=RECIPE_CHANGE_REQ | RMSUse가 Recipe변경요청 비트를 읽음 ⚠️ |
|
||||
| `PLC_ALARM_RESET` (0x1E / M70530) | `SeqStatusMonitor.cs:89` | 70530 빈칸 | 알람리셋 신호 안 들어옴 ⚠️ |
|
||||
| `PLC_RMS_PARAMETER_READ_REQUEST` (0x25 / M70537) | `PLCController.Config.cs:114`, `RMSHandler.cs:69` | 70537 빈칸 | RMS 파라미터 read req 동작 안 함 ⚠️ |
|
||||
| `PC_WELD_NG_JUDGE` (0x14 / M70020) | `SeqAutoRunPrismaticScanner.cs:429/896` write | 70020 빈칸 | NG 판정 PLC로 안 나감 ⚠️ |
|
||||
| `PC_RMS_PARAMETER_READ_REQUEST_ACK` (0x25 / M70037) | `RMSHandler.cs:63/70/76` write | 70037 빈칸 | RMS ACK 안 나감 ⚠️ |
|
||||
|
||||
- 신규 추가 신호(코드 enum 없음): Recipe_CHG(70009/70509), DisplaceUse(70610), Weld_02(70619~621), WeldMoni(70624), Weld_CH2(70625~628), Laser2 M_Power/PC_Para(70630~639), Head_Theta(D70510), RecipeNo(D70002/70502).
|
||||
|
||||
---
|
||||
|
||||
## 5. 정합성 작업 시 방향 (제안 — 미적용)
|
||||
|
||||
- enum 2계층 모두 정렬 필요:
|
||||
1. **base** `eCommonBit/WordInput/Output` (WeldingCommon) — Live/AutoReq/RMS 등 공통 로직.
|
||||
2. **machine** `eBit/WordInput/Output` (PrismaticRD_PTOP) — StepNo/NG_JUDGE/ALARM_RESET/RMS_USED 등.
|
||||
- 기존 소스 최대한 유지 + **enum 값(offset)만** 신규 맵에 맞게 재매핑. 단:
|
||||
- 빠진 신호(RMS, ALARM_RESET, NG_JUDGE)를 신규 맵에 **다시 넣을지 / 코드에서 제거할지** = PLC 인터페이스 측 확정 필요.
|
||||
- StepNo offset 확정(폐지 or 이동).
|
||||
- read count(배수)가 신규 최대 offset(139, Word 10) 포함하도록 확인.
|
||||
- ⚠️ 동일 enum이 4개 머신(PrismaticRD_PTOP / PrismaticScanner / PrismaticCleanLaser / PrismaticGun)에 중복 존재 → PTOP만 바꿀지 공통 정책인지 결정.
|
||||
|
||||
---
|
||||
|
||||
## 6. [TODO]
|
||||
|
||||
- [ ] PLC 측에: StepNo 폐지/이동 여부, 빠진 RMS·ALARM_RESET·NG_JUDGE 주소 확정.
|
||||
- [ ] read count(블록 길이/배수) 가 offset 139·Word10 포함하는지 검증.
|
||||
- [ ] 확정 후 base + machine enum offset 재매핑 (기존 코드 유지, 값만).
|
||||
- [ ] 70502(StepNo→RecipeNo), 70509(RMS_USED→RecipeCHG) 의 코드 영향 반영.
|
||||
@ -1,48 +0,0 @@
|
||||
# PLC DeviceMap 갱신 — 추후 확인 체크리스트 (260617)
|
||||
|
||||
**작성:** 2026-06-17 17:16:42
|
||||
**상태:** 분석/맵파일 갱신만 완료. **소스(enum) 수정·코드 반영은 미적용 (보류).**
|
||||
|
||||
## 관련 자료 (이미 남긴 분석)
|
||||
- 맵 갱신 작업·델타: `docs/분석/2026/06/17/165341_plc_devicemap_update_260617.md`
|
||||
- 방향/StepNo/enum/배수 분석: `docs/분석/2026/06/17/171312_plc_map_io_direction_and_enum_alignment.md`
|
||||
- 근거 Excel: `docs/PtoP 유니셀 용접기 PLC 인터페이스_260617/유니셀 PtoP 단동기 Laser Interface_260617.xlsx`
|
||||
- 백업: `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\External\PLC\260617_backup\`
|
||||
|
||||
---
|
||||
|
||||
## 이미 완료한 것 (참고)
|
||||
- [x] 기존 `PLC_DeviceMap_*` 6개 → `260617_backup` 백업
|
||||
- [x] Excel(M70K/D70K) 분석, 4개 CSV 내부 매핑 갱신(파일명·범위 유지, 코드 스타일 네이밍, 음/양극 전부)
|
||||
- [x] Input/Output 방향 검증 → **안 바뀜(정상)** 확인
|
||||
- [x] Word_Input 70585~70599 `M`오기 → `D` 정정
|
||||
|
||||
---
|
||||
|
||||
## 추후 확인 체크리스트 (PLC 인터페이스 측 협의 필요)
|
||||
|
||||
### A. 의미 재배정된 주소 (코드 영향 큼)
|
||||
- [ ] **D70502: StepNo → RecipeNo** — `SeqAutoRunPrismaticScanner.cs:422` 가 `eWordInput.PLC_STEP_NO`(offset 2)로 `_TotalWeldingStep` 읽음. StepNo **폐지? 다른 offset 이동?** 확정. RecipeNo offset 확정.
|
||||
- [ ] **M70509: PLC_RMS_USED → RECIPE_CHANGE_REQ** — `SeqStatusMonitor.cs:106` `Status.RMSUse` 가 offset 9 읽음. RMS_USED 위치 재확정.
|
||||
|
||||
### B. 신규 맵에서 빠진(빈칸) 기존 사용 신호 — 코드 제거 vs 주소 재부여 결정
|
||||
- [ ] **PLC_ALARM_RESET** (M70530) — `SeqStatusMonitor.cs:89` 사용. 빠지면 알람리셋 동작 안 함.
|
||||
- [ ] **PLC_RMS_PARAMETER_READ_REQUEST** (M70537) — `PLCController.Config.cs:114`, `RMSHandler.cs:69` 사용.
|
||||
- [ ] **PC_WELD_NG_JUDGE** (M70020) — `SeqAutoRunPrismaticScanner.cs:429/896` write. 빠지면 NG 판정 PLC 미전달.
|
||||
- [ ] **PC_RMS_PARAMETER_READ_REQUEST_ACK** (M70037) — `RMSHandler.cs:63/70/76` write.
|
||||
|
||||
### C. 신규 추가 신호 — enum 추가/사용 여부 검토
|
||||
- [ ] Recipe_CHG(70009/70509), DisplaceUse(70610), Weld_02(70619~621), WeldMoni(70624), Weld_CH2(70625~628), Laser2 M_Power/PC_Para(70630~639), Head_Theta_Position(D70510), RecipeNo(D70002/70502)
|
||||
- [ ] **70628 Excel 라벨 중복**("Weld_CH2Comp_ACK" 70627·70628 동일) — 출력 대칭상 70628=MoniComp_ACK로 매핑함. 실제 의미 확인.
|
||||
|
||||
### D. 읽기 블록(배수) 검증
|
||||
- [ ] PLC **read count(블록 길이)** 가 신규 최대 offset 포함하는지 — Bit In/Out **offset 139**(M70639/M70139), **Word In offset 10**(D70510). Bit는 16비트(word) 배수로 읽힘 → 최소 9 word(144bit) / Word In 11 word 필요. 작으면 Laser2(130~139)·Head_Theta 미갱신.
|
||||
|
||||
### E. enum 정렬 범위/정책
|
||||
- [ ] **enum 2계층** 모두 정렬: base `eCommonBit/WordInput/Output`(WeldingCommon) + machine `eBit/WordInput/Output`(PrismaticRD_PTOP). 기존 소스 유지, **offset 값만** 재매핑.
|
||||
- [ ] 동일 enum이 **4개 머신**(PrismaticRD_PTOP / PrismaticScanner / PrismaticCleanLaser / PrismaticGun)에 중복 — PTOP만 변경할지, 공통 적용할지 정책 결정.
|
||||
|
||||
---
|
||||
|
||||
## 결론
|
||||
- 맵 CSV 갱신은 반영됨. **소스 enum/코드는 위 A~E 확정 후** 수정 예정. 지금은 보류.
|
||||
@ -1,264 +0,0 @@
|
||||
# 현장 조명(EROOM) PC 제어 — 소스 구조 분석 및 수정 가이드
|
||||
|
||||
**분석 일시:** 2026-06-17 18:40:11
|
||||
**요청자:** 안동준 과장님 요청사항 — *"조명을 PC에서 조정할 수 있도록"*
|
||||
**대상 조명:** 현장 EROOM 조명 (제조사: **이룸인더스트리**, eroomi.com)
|
||||
**연결 상태:** PC ↔ 조명 컨트롤러 **RS232 9핀** 직결
|
||||
**목적:** 현재 조명을 무엇이 제어하는지 파악하고, 나중에 PC 제어로 수정하기 위한 기준 문서
|
||||
|
||||
---
|
||||
|
||||
## 0. 요청 내용 (사용자)
|
||||
|
||||
- 현장 조명에 **MANUAL / REMOTE** 두 모드가 있고, **REMOTE**로 두면 PC와 통신 가능할 텐데 현재는 **소스 내에서 연결이 안 된 상태**.
|
||||
- 조명을 조정하는 게 무엇인지 분석해서 docs에 정리(나중에 수정 예정).
|
||||
- 조명은 **EROOM 조명**이며 PC에 **RS232 9핀 포트로 연결**되어 있음. → *장치관리자에서 포트 확인해야 하나?*
|
||||
- Device에 **`Light`** 라는 디바이스로 등록되어 있을 것.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약
|
||||
|
||||
1. 소스에는 이미 **`Light` 디바이스**가 등록되어 있다.
|
||||
- 위치: `WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs:226`
|
||||
- 등록: `CommonDeviceIds.Light` → `new LightDevice(..., eLight.ERI, isSimul)`
|
||||
- 즉 **드라이버 타입이 `eLight.ERI`(ERI 4채널)** 로 고정되어 있다.
|
||||
2. 조명 통신은 **RS232 시리얼** 기반이다. (`LightConfig` 의 `SerialConnConfig`)
|
||||
- 기본값: **PortNum=1, BaudRate=19200, 8-N-1, ReadTimeout=500**
|
||||
3. **"연결 안 됨"의 유력한 원인 3가지**:
|
||||
- (a) **드라이버 불일치**: 현재 `eLight.ERI` 드라이버는 ERI사 ASCII 프로토콜(`setbrightness ch val\r` 등)을 쓴다. EROOM 컨트롤러의 프로토콜과 **명령어 포맷이 다르면** 같은 포트에 연결돼도 동작하지 않는다.
|
||||
- (b) **시리얼 설정 불일치**: EROOM(EUV 계열) 컨트롤러는 **38,400bps** 사양이 확인된다. 현재 소스 기본값은 **19200**. → BaudRate/포트번호 불일치 가능.
|
||||
- (c) **컨트롤러 모드**: 컨트롤러 전면 스위치가 **MANUAL**이면 RS232 명령을 무시한다. → 반드시 **REMOTE**로 둬야 PC 명령이 먹는다.
|
||||
4. 따라서 PC 제어를 살리려면 **① 컨트롤러 REMOTE 전환 → ② COM 포트/Baud 맞추기 → ③ (필요 시) EROOM 전용 드라이버 추가** 순서로 접근한다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 장치관리자 COM 포트 확인 (사용자 질문 답변)
|
||||
|
||||
**네, 먼저 장치관리자에서 포트를 확인하는 게 맞습니다.**
|
||||
|
||||
- RS232 9핀이 메인보드 시리얼이든 USB-to-Serial 젠더든, Windows에서는 **`포트(COM & LPT)`** 항목에 **`COMx`** 로 잡힙니다.
|
||||
- 확인 순서:
|
||||
1. `장치관리자` → `포트(COM & LPT)` 펼치기 → 조명 케이블 연결/분리 시 나타났다 사라지는 항목이 해당 포트.
|
||||
2. 그 항목 더블클릭 → `포트 설정` 탭에서 **비트/초(Baud), 데이터 비트, 패리티, 정지 비트**가 컨트롤러 사양과 일치하는지 확인.
|
||||
3. 잡힌 **COM 번호**를 소스의 `LightConfig.ConnConfig.PortNum` 과 맞춰야 함.
|
||||
- USB-Serial인 경우 칩셋 드라이버(예: FTDI, Prolific, CH340)가 설치돼 있어야 COM 포트가 잡힙니다. 안 잡히면 드라이버부터 설치.
|
||||
- 포트가 다른 프로그램(터미널 등)에서 점유 중이면 프로그램에서 열 수 없으니, 점검용 터미널은 닫고 테스트.
|
||||
|
||||
> 점검 팁: 장치관리자에서 COM 번호/Baud를 확인한 뒤, 시리얼 터미널(예: 테라텀)로 컨트롤러를 **REMOTE 모드**에 두고 EROOM 매뉴얼 명령을 직접 쳐서 조명이 반응하는지부터 확인하면, 배선/포트 문제인지 소스 문제인지 분리할 수 있다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 소스 구조 — 조명을 제어하는 경로
|
||||
|
||||
### 3.1 디바이스 등록 (시작점)
|
||||
|
||||
`WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs:226`
|
||||
```csharp
|
||||
registry.Register(CommonDeviceIds.Light,
|
||||
() => new LightDevice(CommonDeviceIds.Light, eLight.ERI, isSimul), // ← 드라이버 타입 ERI 고정
|
||||
new LightConfig(),
|
||||
device => new UCLight() { DataContext = new UCLightViewModel(AuroraEnv, CommonDeviceIds.Light, _SequenceSetting.LightValue) });
|
||||
```
|
||||
|
||||
### 3.2 디바이스 본체 / 드라이버 선택
|
||||
|
||||
`AuroraDevices/AuroraLight/LightDevice.cs`
|
||||
- `eLight` enum: **`LvsPn`, `ALT_4CH`, `ALT_8CH`, `ERI`** — **EROOM 없음.**
|
||||
- `DoActivate()` 에서 타입에 따라 실제 드라이버 인스턴스 생성:
|
||||
- `eLight.ERI` → `new ERILight(DeviceId, IsSimul, 4)` (4채널)
|
||||
- 연결: `_light.InitInternal(config.ConnConfig as SerialConnConfig)`
|
||||
|
||||
### 3.3 시리얼 설정
|
||||
|
||||
`AuroraDevices/AuroraLight/LightConfig.cs`
|
||||
```csharp
|
||||
ConnConfig = new SerialConnConfig() {
|
||||
PortNum = 1, // ← 장치관리자 COM 번호와 맞춰야 함
|
||||
BaudRate = 19200, // ← EROOM(EUV 계열)은 38400 사양 확인됨, 불일치 가능
|
||||
Parity = Parity.None, StopBits = StopBits.One, DataBits = 8,
|
||||
ReadTimeout = 500
|
||||
};
|
||||
```
|
||||
|
||||
### 3.4 ERI 드라이버 프로토콜 (현재 연결되는 명령어)
|
||||
|
||||
`AuroraDevices/AuroraLight/ERI/ERILight.cs` — **ASCII 텍스트 + `\r` 종결**
|
||||
| 동작 | 명령 포맷 |
|
||||
|---|---|
|
||||
| 밝기 설정 | `setbrightness {channel} {value}\r` (value 0~255) |
|
||||
| On/Off | `seton {channel} {0|1}\r` |
|
||||
| On 상태 조회 | `geton {channel}\r` |
|
||||
|
||||
> EROOM 컨트롤러 매뉴얼의 명령어가 위와 다르면, ERI 드라이버로는 통신이 안 된다(=현재 "연결 안 됨" 상태의 핵심 원인 후보).
|
||||
|
||||
### 3.5 시퀀스에서의 사용 (자동운전)
|
||||
|
||||
`Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPrismaticScanner.cs`
|
||||
- 변수: `private LightDevice _Light;` (L138)
|
||||
- 획득: `_Light = context.GetLight();` (L1132) — `SequenceContextEx.GetLight()` → `context.Devices[CommonDeviceIds.Light]`
|
||||
- 점등: 자동운전 시 `_Light.SetLightValue(lightValues)` 로 4채널 ON (L356~359, L535~537)
|
||||
- 기본 밝기값: `lightValues = {255,255,255,255}` (L193), 레시피값은 `SequenceSetting.LightValue` / `CompensationLightValue`
|
||||
|
||||
---
|
||||
|
||||
## 4. EROOM 조명 컨트롤러 (웹 조사 결과)
|
||||
|
||||
- **제조사:** 이룸인더스트리 (eroomi.com) — 머신비전 조명/컨트롤러 전문. (사이트 TLS 인증서 문제로 직접 페이지 파싱은 실패, 검색 요약 기준)
|
||||
- **대표 컨트롤러 사양(EUV-FX7 등 기준):**
|
||||
- 통신: **RS232, 38,400 bps**, MANUAL/REMOTE 지원
|
||||
- 출력: **0~100%** 파워 제어
|
||||
- 채널: **최대 4채널** 점등 start/stop 입력
|
||||
- 조사 시간(irradiation time) 설정, 전면 엔코더로 파라미터 조정 및 채널값 메모리 저장
|
||||
- **주의:** 정확한 RS232 **명령어 포맷/체크섬/종결문자**는 제품 매뉴얼로 확정 필요. (밝기 스케일이 ERI의 0~255가 아니라 0~100%일 가능성 높음 → 변환 필요)
|
||||
|
||||
---
|
||||
|
||||
## 5. 별도로 존재하는 CCS 조명 코드 (참고 — 본 건과 무관)
|
||||
|
||||
- `AuroraVision/VisionLight/Light_CCS.cs` + `LightControlCCS_Library.dll`(C++) 가 별도로 존재.
|
||||
- 단, 이건 **Socket(TCP/IP) 기반**(`managementMain.Connect(ip, port)`)이라 **RS232 EROOM 건과는 연결 방식이 다름**.
|
||||
- PTOP 빌드 산출물 폴더에 `LightControlCCS_Library.dll` 이 복사돼 있으나, PTOP 소스에서 `Light_CCS` 를 직접 참조하지는 않음. → **이번 건과 혼동 주의.**
|
||||
|
||||
---
|
||||
|
||||
## 6. 나중에 수정할 때 체크리스트 (코드 수정은 보류, 방안만 정리)
|
||||
|
||||
### Step 1 — 하드웨어/포트 확정 (코드 수정 전)
|
||||
- [ ] 컨트롤러 전면 스위치 **REMOTE** 전환
|
||||
- [ ] 장치관리자에서 **COM 번호** 확인, **Baud(38400 추정)/패리티/스톱비트** 확인
|
||||
- [ ] 시리얼 터미널로 EROOM 매뉴얼 명령 직접 전송 → 조명 반응 확인 (배선/포트 문제 격리)
|
||||
|
||||
### Step 2 — 설정만으로 해결되는 경우 (EROOM ↔ ERI 프로토콜이 호환될 때)
|
||||
- [ ] `LightConfig` 의 `PortNum` 을 실제 COM 번호로
|
||||
- [ ] `BaudRate` 19200 → 38400 등 사양에 맞게
|
||||
- [ ] (설정값은 가능하면 장비 Setting/UI에서 변경하도록, 하드코딩 지양)
|
||||
|
||||
### Step 3 — 프로토콜이 다른 경우 (EROOM 전용 드라이버 신규 추가)
|
||||
- [ ] `AuroraDevices/AuroraLight/eLight` enum 에 `EROOM` 추가
|
||||
- [ ] `AuroraDevices/AuroraLight/EROOM/EROOMLight.cs` 신규 (`SerialConn, IEROOMLight` 구현, ERI 클래스 패턴 참고)
|
||||
- EROOM 매뉴얼대로 명령 포맷/밝기 스케일(0~100%) 구현
|
||||
- [ ] `LightDevice.DoActivate()` 의 `switch(_lightType)` 에 `case eLight.EROOM` 분기 추가
|
||||
- [ ] `CommonEquipmentSetup.cs:226` 의 `eLight.ERI` → `eLight.EROOM` 으로 변경
|
||||
- [ ] `ILight.cs` 에 필요 시 `IEROOMLight` 인터페이스 추가
|
||||
|
||||
### Step 4 — 검증
|
||||
- [ ] 시뮬레이션 해제 후 자동운전에서 `_Light.SetLightValue` 로 점등 확인
|
||||
- [ ] 수동/UI(`UCLight`)에서 채널별 밝기 제어 확인
|
||||
|
||||
---
|
||||
|
||||
## 7. 핵심 파일 위치 정리
|
||||
|
||||
| 역할 | 경로 |
|
||||
|---|---|
|
||||
| 조명 디바이스 등록 | `WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs:226` |
|
||||
| 조명 디바이스 본체/드라이버 선택 | `AuroraDevices/AuroraLight/LightDevice.cs` |
|
||||
| 조명 드라이버 인터페이스 | `AuroraDevices/AuroraLight/ILight.cs` |
|
||||
| 시리얼/포트 설정 | `AuroraDevices/AuroraLight/LightConfig.cs` |
|
||||
| 현재 사용 중인 ERI 드라이버 | `AuroraDevices/AuroraLight/ERI/ERILight.cs` |
|
||||
| 시퀀스 사용처 | `Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPrismaticScanner.cs` (L138, 1132, 356~, 535~) |
|
||||
| 디바이스 접근 헬퍼 | `WeldingComponents/WeldingCommon/Sequences/SequenceContextEx.cs:54` (`GetLight`) |
|
||||
| (참고) CCS Socket 조명 | `AuroraVision/VisionLight/Light_CCS.cs` |
|
||||
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## 8. eLight.ERI 제어 소스 — 참고 코드/위치 모음
|
||||
|
||||
> 현재 `Light` 디바이스가 **`eLight.ERI` 드라이버로 등록**되어 동작하므로, EROOM 제어 구현 시 **그대로 베껴 쓸 수 있는 레퍼런스**가 ERI 계열이다. 아래는 제어 전체 흐름(등록 → 디바이스 → 드라이버 → UI → 시퀀스)의 실제 코드/위치.
|
||||
|
||||
### 8.1 전체 제어 흐름 한눈에
|
||||
|
||||
```
|
||||
CommonEquipmentSetup.RegisterDevices() ← 디바이스 등록 (eLight.ERI 지정)
|
||||
│
|
||||
▼
|
||||
LightDevice (AuroraLight) ← 추상 디바이스, DoActivate에서 드라이버 선택
|
||||
│ _light = new ERILight(...)
|
||||
▼
|
||||
ERILight : SerialConn, IERILight ← RS232 ASCII 프로토콜 실제 송수신
|
||||
▲ ▲
|
||||
│ │
|
||||
UCLightViewModel (수동 UI) SeqAutoRun...(자동운전) ← 두 곳에서 제어 호출
|
||||
```
|
||||
|
||||
### 8.2 ① 디바이스 등록 — `WeldingComponents/WeldingCommon/CommonEquipmentSetup.cs`
|
||||
|
||||
- L48: 디바이스 활성상태 표시 등록 `.AddDeviceActiveStatus(CommonDeviceIds.Light)`
|
||||
- L226~227: 디바이스 + UI 등록
|
||||
```csharp
|
||||
registry.Register(CommonDeviceIds.Light,
|
||||
() => new LightDevice(CommonDeviceIds.Light, eLight.ERI, isSimul), // 드라이버 타입
|
||||
new LightConfig(), // 시리얼 설정
|
||||
device => new UCLight() { // 제어 UI
|
||||
DataContext = new UCLightViewModel(AuroraEnv, CommonDeviceIds.Light, _SequenceSetting.LightValue)
|
||||
});
|
||||
```
|
||||
|
||||
### 8.3 ② 디바이스 본체 — `AuroraDevices/AuroraLight/LightDevice.cs`
|
||||
|
||||
- `eLight` enum (L16~22): `LvsPn, ALT_4CH, ALT_8CH, ERI` → **EROOM 추가 지점**
|
||||
- `DoActivate()` (L40~64): `switch(_lightType)` 에서 드라이버 생성 + `InitInternal(SerialConnConfig)` → **EROOM case 추가 지점**
|
||||
- 외부 공개 제어 API:
|
||||
- `SetLightValue(List<int> values)` (L88) / `SetLightValue(int ch, int val)` (L93)
|
||||
- `CheckLightOnAndValue(int val)` (L100) — ERI 전용으로 채널별 On+밝기 검증
|
||||
- `DoDeactivate()` (L66~79): ERI는 전 채널 0으로 끄고 시리얼 Close
|
||||
|
||||
### 8.4 ③ ERI 시리얼 드라이버 — `AuroraDevices/AuroraLight/ERI/ERILight.cs` (RS232 프로토콜 본체)
|
||||
|
||||
| 기능 | 메서드 | 명령/응답 포맷 | 라인 |
|
||||
|---|---|---|---|
|
||||
| 연결 | `InitInternal(SerialConnConfig)` | `Open(connConfig)` | L30 |
|
||||
| 밝기 설정 | `SetLightBrightness(ch, val)` | TX `setbrightness {ch} {val}\r` (val 0~255) | L134 |
|
||||
| On/Off | `SetLightPowerStatus(ch, on)` | TX `seton {ch} {0\|1}\r` | L122 |
|
||||
| On 조회 | `GetLightOn(ch, out isOn)` | TX `geton {ch}\r` / RX `geton {idx} {ch} {0\|1}` | L186 |
|
||||
| 밝기 조회 | `GetLightValue(ch, out val)` | TX `getbrightness {ch}\r` / RX `getbrightness {idx} {ch} {val}` | L219 |
|
||||
| 채널 검증 | `ChannelValidCheck` (0~ch-1) / `ValueValidCheck` (0~255) | — | L162 / L172 |
|
||||
|
||||
- 부모 `SerialConn` 의 `Open / Write / WriteAndReadLine / IsConnected / Close` 사용.
|
||||
- **EROOM 적용 시 주의:** ASCII 명령어/종결문자(`\r`)/밝기 스케일(0~255)이 EROOM 매뉴얼과 다르면 이 클래스를 그대로 못 쓰고, 동일 구조로 `EROOMLight.cs` 신규 작성.
|
||||
|
||||
### 8.5 ④ 수동 제어 UI — `AuroraDevices/AuroraLight/View/UCLightViewModel.cs` (+ `UCLight.xaml`)
|
||||
|
||||
- 생성자(L67): `aurora.DeviceManager[deviceId] as LightDevice` 로 디바이스 획득
|
||||
- ERI일 때 채널/슬라이더 세팅(L76~84): `nChannel=4, nSliderMax=255`
|
||||
- 슬라이더 → 밝기: `nSliderValue` setter(L21~24) → `_light.SetLightValueInternal(cbChannel, value)`
|
||||
- 버튼 커맨드:
|
||||
- `CMD_LightOnOff` → `LightOnOff()` (L111): 채널 토글 On/Off
|
||||
- `CMD_ALLLightOn` → `ALLLightOn()` (L130): 전 채널 ON
|
||||
- `CMD_ALLLightOff` → `ALLLightOff()` (L140): 전 채널 OFF
|
||||
- **참고:** 채널수/스케일이 코드에 하드코딩(`nChannel=4`, `nSliderMax=255`)되어 있음 → EROOM(0~100%) 적용 시 여기 함께 손봐야 함.
|
||||
|
||||
### 8.6 ⑤ 자동운전 사용처 — `Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPrismaticScanner.cs`
|
||||
|
||||
- L138: `private LightDevice _Light;`
|
||||
- L193: `private List<int> lightValues = new List<int> { 255, 255, 255, 255 };`
|
||||
- L1132: `_Light = context.GetLight();`
|
||||
- L353~359 / L532~537: 자동운전 진입 시 점등
|
||||
```csharp
|
||||
if (_SequenceSetting.UseCellOffset) UpdateAutoLightValue(_SequenceSetting.CompensationLightValue);
|
||||
else UpdateAutoLightValue(_SequenceSetting.LightValue);
|
||||
if (!_Light.CheckLightOnAndValue(lightValues[0])) { // 현재 밝기와 다르면
|
||||
_Light.SetLightValue(lightValues); // 4채널 점등
|
||||
Log.I($"Light All On !");
|
||||
}
|
||||
```
|
||||
- L1357: `UpdateAutoLightValue(int value)` — `lightValues` 갱신 헬퍼
|
||||
|
||||
### 8.7 ⑥ 디바이스 접근 헬퍼 — `WeldingComponents/WeldingCommon/Sequences/SequenceContextEx.cs`
|
||||
|
||||
```csharp
|
||||
public static LightDevice GetLight(this SequenceContext context) // L54
|
||||
=> context.Devices[CommonDeviceIds.Light] as LightDevice; // L55
|
||||
```
|
||||
|
||||
### 8.8 인터페이스 / 설정 정의
|
||||
|
||||
- `AuroraDevices/AuroraLight/ILight.cs` — `ILight` 공통 인터페이스 + `IERILight`(L30, `IsOn`/`GetLightOn`/`GetLightValue` 추가). → EROOM용 `IEROOMLight` 추가 지점.
|
||||
- `AuroraDevices/AuroraLight/LightConfig.cs` — `SerialConnConfig`(PortNum/BaudRate/Parity/StopBits/DataBits/ReadTimeout) 정의.
|
||||
|
||||
---
|
||||
|
||||
> ⚠️ 본 문서는 **분석/가이드 전용**이며 코드는 수정하지 않았다. 실제 수정 전 EROOM 컨트롤러 매뉴얼(RS232 명령어/Baud/밝기 스케일)로 사양을 확정할 것.
|
||||
@ -1,108 +0,0 @@
|
||||
# Manual Laser Power Control GroupBox 2개 분석 (Percent vs Watt)
|
||||
|
||||
- **작성일:** 2026-06-18
|
||||
- **대상 파일:**
|
||||
- View: `WeldingComponents/WeldingCommon/Views/Manual/Scanner/UCScannerLaserControl.xaml`
|
||||
- ViewModel: `WeldingComponents/WeldingCommon/Views/Manual/Scanner/UCScannerLaserControlViewModel.cs`
|
||||
|
||||
---
|
||||
|
||||
## 0. 내 요청사항 (배경)
|
||||
|
||||
> Laser Voltage를 1V 주면 몇 W 나오는지 측정하는 **캘리브레이션(Cal) 파일**을 만들고 싶다.
|
||||
> 이때 **레이저는 실제로 발진시키지 말고**, **아날로그 신호만 살려서** RTC5의 기록은 그대로 저장되도록 할 수 있는가?
|
||||
>
|
||||
> - 메뉴얼 화면 → Manual Laser Power Control 영역에서 레이저를 쏠지/안 쏠지 제어.
|
||||
> - 보통 **레이저 컨트롤러 IO를 안 살리면** 레이저가 실제로 안 나간다.
|
||||
> - 아날로그 신호만 활성화해서, 레이저는 안 나가되 RTC5 출력 기록은 정상 저장 가능한지 검토.
|
||||
|
||||
→ 이 분석은 위 요청과 직접 연관됨. 특히 **아날로그 출력(WriteDA)** 과 **레이저 발진 신호(LaserSignalOn)** 가 코드상 분리되어 있다는 점이 핵심.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약
|
||||
|
||||
- XAML에 `Header="Manual Laser Power Control"` GroupBox가 **2개**(Grid.Row="0", Grid.Row="1") 있고, **레이아웃·구성 컨트롤은 100% 동일**하다.
|
||||
- **유일한 실질 차이는 "파워 입력 단위"** 다.
|
||||
- **Row 0 = Percent(%) 기준** → `LaserPower1Percent`/`LaserPower2Percent`, 버튼 → `CMD_LaserShotOnPercent`
|
||||
- **Row 1 = Watt(W) 기준** → `LaserPower1Watt`/`LaserPower2Watt`, 버튼 → `CMD_LaserShotOnWatt`
|
||||
- 즉 **똑같은 UI를 % 입력용 / W 입력용 두 벌로 둔 것**. Frequency·Pulse Width·Timer·Laser Off·Result 표시는 둘이 **완전히 공유**(같은 바인딩/커맨드).
|
||||
|
||||
---
|
||||
|
||||
## 2. 두 GroupBox 차이 상세
|
||||
|
||||
| 항목 | Row 0 GroupBox (Percent) | Row 1 GroupBox (Watt) |
|
||||
|---|---|---|
|
||||
| Power #1 바인딩 | `LaserPower1Percent` (Unit `%`) | `LaserPower1Watt` (Unit `W`) |
|
||||
| Power #2 바인딩 | `LaserPower2Percent` (Unit `%`) | `LaserPower2Watt` (Unit `W`) |
|
||||
| Frequency | `LaserPeriod` (kHz) **공유** | `LaserPeriod` (kHz) **공유** |
|
||||
| Pulse Width | `LaserPulseWidth` (us) **공유** | `LaserPulseWidth` (us) **공유** |
|
||||
| Timer Set (Spot Time) | `IsUseLaserAutoOffChecked`, `LaserOnTime` **공유** | 동일 **공유** |
|
||||
| Laser Shot Result | `BusyStatus`, `ListInterationCount` **공유** | 동일 **공유** |
|
||||
| **Laser On 버튼** | `CMD_LaserShotOnPercent` | `CMD_LaserShotOnWatt` |
|
||||
| **Laser Off 버튼** | `CMD_LaserShotOff` **공유(동일)** | `CMD_LaserShotOff` **공유(동일)** |
|
||||
|
||||
> 정리: **다른 것은 "Power 입력 단위(% vs W)와 그에 대응하는 Laser On 커맨드" 뿐**. 나머지는 같은 ViewModel 프로퍼티/커맨드를 그대로 쓴다.
|
||||
|
||||
---
|
||||
|
||||
## 3. 각 동작이 어디에 영향을 끼치는가 (ViewModel 분석)
|
||||
|
||||
### 3-1. Laser On — `PerformCmdLaserShotOnPercent` / `PerformCmdLaserShotOnWatt`
|
||||
|
||||
두 메서드는 구조가 동일하며, **`IsUseLaserAutoOffChecked`(Use Spot Time 토글) 값에 따라 두 갈래**로 갈린다.
|
||||
|
||||
#### (A) `IsUseLaserAutoOffChecked == true` (= "Use Spot Time")
|
||||
- 시퀀스(`SeqTeachingRun`)를 통해 발사. `CreateDotForLaserOn()`으로 현재 위치에 Dot 1개를 만들고 시퀀스 Start.
|
||||
- **주의:** 이 분기는 Percent/Watt 둘 다 `CreateDotForLaserOn()`을 호출하는데, 이 함수 내부는 **`LaserPower1Percent`/`LaserPower2Percent`(% 기준)만 사용**한다(`LaserPowerCalParam.MaxCenterPower/MaxRingPower` 비율 환산). 즉 **Spot Time 모드에서는 Watt 버튼을 눌러도 실제로는 Percent 값으로 동작**한다. (Watt 입력이 무시되는 잠재 이슈)
|
||||
- 사전 가드: Scanner Busy 체크 → `_Laser.GetLaserReady()` 체크 → 시퀀스 Running 체크 → 모델 선택 체크 → Blow 설정 반영.
|
||||
|
||||
#### (B) `IsUseLaserAutoOffChecked == false` (= "No Use Spot Time") ★ Cal 작업 관련 핵심
|
||||
직접 아날로그/펄스 제어 후 레이저 신호 ON:
|
||||
```
|
||||
powerCalParam.Initialize(...);
|
||||
// 단위 환산만 다름:
|
||||
// Percent 버튼: CalibratePercentToMeasuredVoltage(LaserPowerNPercent) * 10
|
||||
// Watt 버튼: CalibrateWattToMeasuredVoltage(LaserPowerNWatt) * 10
|
||||
Thread.Sleep(50);
|
||||
_Scanner.WriteDA(DA1, powerVolt1, COMMAND); // ← 아날로그 전압 출력 (DA1)
|
||||
_Scanner.WriteDA(DA2, powerVolt2, COMMAND); // ← 아날로그 전압 출력 (DA2)
|
||||
_Scanner.SetLaserPulseCtrl(LaserPeriod*1000, LaserPulseWidth); // 펄스 주파수/폭
|
||||
_Scanner.LaserSignalOn(); // ← 레이저 발진 게이트 ON (실제 발사 트리거)
|
||||
```
|
||||
- **TruFiberType 분기:** `TruFiberS`는 DA1만(단일빔), `TruFiberP` 등은 DA1=Center / DA2=Ring 두 빔으로 환산.
|
||||
- **`* 10`**: 환산된 전압(0~1V 등 정규화 값)을 RTC5 DA 풀스케일(10V 기준)로 스케일링하는 것으로 보임.
|
||||
|
||||
> **요청사항과의 연결:**
|
||||
> - **아날로그 출력(`WriteDA`)** 과 **레이저 발진(`LaserSignalOn`)** 이 **코드상 별개 호출**이다.
|
||||
> - 즉, 구조적으로 "아날로그 전압은 DA 포트로 내보내되 `LaserSignalOn()`은 호출하지 않거나, 레이저 컨트롤러 IO를 비활성"으로 두면 → **DA 아날로그 값은 출력되지만 실제 발진은 안 되는** 형태가 성립할 여지가 있다.
|
||||
> - 단, "RTC5 기록이 그대로 저장되는가"는 별도 확인 필요(아래 §5 미해결 질문).
|
||||
|
||||
### 3-2. Laser Off — `PerformCmdLaserShotOff` (두 GroupBox 공통)
|
||||
- `IsUseLaserAutoOffChecked == true` → `_Scanner.StopExecution()` (시퀀스/리스트 중단)
|
||||
- `false` → `_Scanner.LaserSignalOff()` (발진 게이트 OFF)
|
||||
- 공통으로 `_Scanner.SetStandby(10, 0)`.
|
||||
|
||||
### 3-3. Monitoring — `OnMonitoring` (100ms DispatcherTimer)
|
||||
- Scanner 활성 체크, Encoder X/Y/속도 갱신, `GetMarkingInfo()`로 FieldOut X/Y 판정, `ReadStatus()`로 List1/List2 Busy 및 반복 횟수(`ListInterationCount`) 갱신.
|
||||
- View가 Visible일 때만 동작(`CMD_VisibleChanged`).
|
||||
|
||||
### 3-4. Marking On The Fly (Row 2, 별개 GroupBox)
|
||||
- Encoder 기반 OTF 마킹 영역. `CMD_ActivateOnTheFly`/`Deactivate`, `ResetEncoder`, `SimulateEncoder(X/XY)`.
|
||||
- 본 분석의 핵심(Manual Laser Power Control 2개)과는 별개 기능.
|
||||
|
||||
---
|
||||
|
||||
## 4. "똑같은가?" 에 대한 답
|
||||
- **UI 레이아웃/구성: 똑같다.** (복붙 수준으로 동일)
|
||||
- **기능: 다르다.** 한쪽은 **% 입력 → Percent 캘리브레이션**, 다른 한쪽은 **W 입력 → Watt 캘리브레이션**으로 전압을 만든다.
|
||||
- **공유 리스크:** "Use Spot Time" 분기에서는 Watt 버튼도 내부적으로 Percent 값으로 동작(`CreateDotForLaserOn`이 Percent 전용) → Watt 의도와 불일치 가능. Cal 측정은 보통 "No Use Spot Time"(직접 DA 제어) 분기를 쓰므로 이 리스크와는 분리됨.
|
||||
|
||||
---
|
||||
|
||||
## 5. 미해결 / 추가 확인 필요 (Cal 파일 작업 관련)
|
||||
1. **`WriteDA`만으로 RTC5가 출력을 "기록/저장"하는가?** — 발진 없이 DA만 출력했을 때 RTC5 로깅 동작 확인 필요.
|
||||
2. **`LaserSignalOn()` 생략 또는 레이저 컨트롤러 IO 비활성** 조합이 실제 장비에서 "아날로그만 살아있고 발진 안 됨"으로 동작하는지 현장 검증 필요.
|
||||
3. **`* 10` 스케일과 `CalibrateWattToMeasuredVoltage` / `CalibratePercentToMeasuredVoltage`** 의 입출력 단위(반환값이 V 인지, 0~1 정규화인지) 정확한 정의 확인 → 1V당 W 환산표 작성의 기준.
|
||||
4. Cal 측정 시 권장 경로: **"No Use Spot Time"(IsUseLaserAutoOffChecked=false) + Watt(또는 직접 전압) 모드**로 DA 출력값을 단계적으로 인가하며 파워미터 측정 → CSV(`PowerCalibrationCenterBeamCSVFile` / `RingBeamCSVFile`) 작성.
|
||||
@ -1,81 +0,0 @@
|
||||
# PTOP 가 비-PTOP(Scanner/TDC/Gun/CleanLaser) 경로에서 참조/가져오는 파일 분석
|
||||
|
||||
- **작성일:** 2026-06-18
|
||||
- **대상:** `Machines/ILSOS_PrismaticRD_PTOP`
|
||||
- **목적:** PTOP 경로가 아닌 Scanner/TDC/Gun/CleanLaser 경로에서 참조해 가져오는 파일을 식별하고, PTOP 경로로 복사할 대상을 정리. (소스 무수정 원칙)
|
||||
|
||||
---
|
||||
|
||||
## 0. 내 요청사항
|
||||
|
||||
> 참조해서 가져오는 파일 중에 PTOP 경로가 아닌 **SCANNER, TDC, GUN, CleanLaser** 경로에서 가져오는 파일들을 **PTOP 경로에 복사**해줘. 분석내용도 늘 정리해주고 **소스는 절대 건들지 마**.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약 (먼저)
|
||||
|
||||
- **소스/프로젝트 레벨에서는 다른 머신 폴더의 파일을 가져오지 않는다.**
|
||||
- PTOP `.csproj`의 `Compile/Content/Page/Resource Include`는 **전부 자기 폴더 내 상대경로**.
|
||||
- `ProjectReference`는 **공유 프로젝트(AuroraDevices, AuroraVision, WeldingComponents)뿐** — Scanner/Gun/CleanLaser/TDC 프로젝트를 참조하지 않음.
|
||||
- 소스/XAML 문자열에 다른 머신 폴더(`ILSOS_PrismaticScanner\` 등)를 가리키는 **파일 경로 참조 없음**(컴파일된 `.dll` 바이너리 매칭만 존재 → 무의미).
|
||||
- 즉 **PTOP는 Scanner 프로젝트의 자체 포크**다. `EquipmentSetup.cs`가 `namespace ILSOS_PrismaticScanner`를 그대로 사용하고, `using ILSOS_PrismaticScanner.*`도 자기 자신(같은 네임스페이스) 또는 WeldingCommon으로 해석됨.
|
||||
|
||||
- **유일한 비-PTOP 경로 참조는 "빌드 출력/실행 경로"가 TDC를 가리키는 것**이다. (아래 §2)
|
||||
|
||||
- 따라서 **git 트래킹된 소스 중 복사할 "참조 파일"은 없다.** 실제로 다른 머신 경로에서 가져오는 것은 **런타임 출력(_out) 폴더 안의 빌드 산출물**이며, 이 폴더들은 **git 비추적(.gitignore)** 이다. (아래 §3)
|
||||
|
||||
---
|
||||
|
||||
## 2. 빌드/실행 경로의 TDC 참조 (PTOP.csproj)
|
||||
|
||||
| 항목 | 값 | 의미 |
|
||||
|---|---|---|
|
||||
| `OutputPath` (Debug\|x64) | `..\_out_prismatic_rd_tdc\x64-Debug\` | PTOP DLL이 **TDC 출력 폴더**로 빌드됨 |
|
||||
| `OutputPath` (Release\|x64) | `..\_out_prismatic_rd_tdc\x64-Release\` | 동일 |
|
||||
| `StartProgram` | `$(SolutionDir)\Machines\_out_prismatic_rd_tdc\x64-Debug\Aurora.exe` | 실행 시 **TDC 폴더의 Aurora.exe** 기동 |
|
||||
|
||||
→ PTOP는 빌드/실행을 **`_out_prismatic_rd_tdc`**(TDC 경로)에서 수행한다. 별도로 존재하는 `_out_prismatic_rd_ptop` 폴더는 현재 빌드 구성에서 **사용되지 않음**.
|
||||
|
||||
> 참고: `EquipmentSetup.cs` 주석에 `// 변경 TDC->PTOP`, `register(... SeqAutoRunTDC)` 등 TDC→PTOP 이행 흔적이 다수 있음. 즉 TDC 산출물 위에서 PTOP가 동작하도록 과도기 상태.
|
||||
|
||||
---
|
||||
|
||||
## 3. 런타임 출력 폴더 구조 (실제 "가져오는" 파일의 위치)
|
||||
|
||||
`Machines/_out_prismatic_rd_tdc/x64-Debug/` (PTOP가 실제 구동되는 폴더) 내부:
|
||||
|
||||
- 공유 데이터/설정: `_alarm`, `_config_ingredient`, `_config_model`, `_config_recipe`, `_config_setting`, `_process`, `_vision`, `Light`, `RTC5_2024_09_27`, `AccountStorage` 등
|
||||
- **머신별 프로파일 서브폴더** (각 폴더에 `Aurora.exe.config`, `hislog.config` 2개씩):
|
||||
- `ILSOS_PrismaticScanner/`
|
||||
- `ILSOS_PrismaticGun/`
|
||||
- `ILSOS_PrismaticCleanLaser/`
|
||||
- `ILSOS_PrismaticRD_TDC/`
|
||||
- **→ `ILSOS_PrismaticRD_PTOP/` 폴더는 없음** (PTOP 전용 프로파일 폴더가 부재)
|
||||
|
||||
**git 추적 상태:** `_out_prismatic_*` 폴더는 **추적 파일 0개** (전부 .gitignore 빌드 산출물).
|
||||
|
||||
---
|
||||
|
||||
## 4. "복사 대상" 판정
|
||||
|
||||
- **소스 레벨 복사 대상: 없음.** (다른 머신 폴더의 소스를 참조하지 않음 → 복사할 것이 없음. 소스 무수정 원칙과도 부합.)
|
||||
- **런타임 레벨 후보:** 머신별 프로파일 폴더(`Aurora.exe.config`, `hislog.config`)가 Scanner/TDC/Gun/CleanLaser용으로는 있는데 **PTOP용(`ILSOS_PrismaticRD_PTOP/`)이 없음.**
|
||||
- 가장 그럴듯한 작업: TDC(또는 Scanner) 프로파일을 **`ILSOS_PrismaticRD_PTOP/` 폴더로 복사**해 PTOP 전용 프로파일을 만드는 것.
|
||||
- 단, 이 폴더는 **빌드 시 재생성되는 비추적 산출물**이라 다음 빌드에서 덮어쓰일 수 있음(영속성 한계).
|
||||
|
||||
---
|
||||
|
||||
## 5. 미해결 / 확인 필요
|
||||
|
||||
1. **사용자가 의도한 "참조 파일"이 §3의 머신별 프로파일(config) 폴더가 맞는지** 확인 필요. (소스가 아니라 런타임 config로 보임)
|
||||
2. **목적지 "PTOP 경로"** 가 (a) 런타임 `_out_prismatic_rd_tdc/.../ILSOS_PrismaticRD_PTOP/` 인지, (b) `_out_prismatic_rd_ptop/` 인지, (c) 소스 트리의 PTOP 프로젝트 폴더인지 확정 필요.
|
||||
3. 빌드 OutputPath가 TDC를 가리키는 것이 **의도된 과도기 설정인지, 정리 대상(버그)인지** — 향후 PTOP 독립 출력(`_out_prismatic_rd_ptop`)으로 전환할지 결정 필요.
|
||||
|
||||
---
|
||||
|
||||
## 6. 진행 방향 (2026-06-18 결정)
|
||||
|
||||
- 어차피 **시작 프로젝트를 PTOP로 지정**하고, **언로드 중인 나머지(Scanner/Gun/CleanLaser/TDC)는 제외**하는 작업을 할 예정.
|
||||
- 그 과정에서 PTOP `.csproj`의 빌드/실행 경로(현재 TDC 참조: `OutputPath`, `StartProgram`)도 **결국 PTOP 경로로 변경**할 것임 → §2의 TDC 참조는 그때 정리됨.
|
||||
- 따라서 지금은 **분석만 남기고 복사는 보류**. (소스 무수정 원칙 유지)
|
||||
- PTOP 단독 구성으로 전환 시: OutputPath/StartProgram을 `_out_prismatic_rd_ptop`로 바꾸고, 런타임 프로파일 폴더도 `ILSOS_PrismaticRD_PTOP/`로 생성/정리.
|
||||
@ -1,135 +0,0 @@
|
||||
# PTOP 네임스페이스/클래스 정리 마이그레이션 분석 (Scanner → PTOP)
|
||||
|
||||
- **작성일:** 2026-06-18
|
||||
- **대상:** `Machines/ILSOS_PrismaticRD_PTOP` (현재 작업본)
|
||||
- **정답 참고본(빌드 성공):** `D:\Git\LGES-OC5-PtoP-Welder_정리후(빌드완)\Machines\ILSOS_PrismaticRD_PTOP`
|
||||
- **목적:** 프로젝트명만 바꾸고 Sequence 일부만 PTOP로 바꾼 현재 상태를, 참고본처럼 **네임스페이스·클래스·파일명을 PTOP로 안전하게 정리**(빌드 깨짐 방지)하기 위한 분석.
|
||||
|
||||
---
|
||||
|
||||
## 0. 내 요청사항
|
||||
|
||||
> 현재 PTOP 프로젝트에 `using`이 SCANNER로 남아있는(=PTOP로 변경 안 한) 부분이 있어서, 수정하다 실수하면 빌드가 아예 안 될까 봐 걱정. Sequence만 바꾸고 프로젝트명만 바꿔둔 상태라 잘 수정하기 위한 분석이 필요. 잘 정리된 좋은 예시가 `D:\Git\LGES-OC5-PtoP-Welder_정리후(빌드완)`에 있음. 이런 형태로 수정하려고 함. Machines가 PTOP만 있는 것도 확인 가능.
|
||||
|
||||
---
|
||||
|
||||
## 1. 현재 상태 vs 참고본 (요약)
|
||||
|
||||
| 항목 | 현재(CUR) | 참고본(REF, 빌드완) |
|
||||
|---|---|---|
|
||||
| `Machines/` 구성 | PTOP + Scanner/Gun/CleanLaser(+_out들) | **PTOP 단독** |
|
||||
| `namespace ILSOS_PrismaticScanner` | **26개 파일** (obj 4개 포함) | 0개 |
|
||||
| `namespace ILSOS_PrismaticRD_PTOP` | 3개 파일만 (Properties 2 + SeqAutoRunPTOP) | 30개 파일 |
|
||||
| `using ILSOS_PrismaticScanner.*` | **15개 파일** | 0개 |
|
||||
| RootNamespace / AssemblyName | `ILSOS_PrismaticRD_PTOP` (이미 동일) | `ILSOS_PrismaticRD_PTOP` |
|
||||
|
||||
→ **csproj의 RootNamespace/AssemblyName은 이미 PTOP**인데, **실제 소스의 namespace/using/클래스명/파일명이 Scanner로 남아있는** 불일치 상태.
|
||||
|
||||
---
|
||||
|
||||
## 2. 변경 매핑 (참고본 기준 — 이대로 맞추면 됨)
|
||||
|
||||
### 2-1. 네임스페이스 (전 파일 공통)
|
||||
- `namespace ILSOS_PrismaticScanner` → `namespace ILSOS_PrismaticRD_PTOP`
|
||||
- `using ILSOS_PrismaticScanner.Alarm|Device|Device.IO|Models|Recipes|Settings|Sequences|Views;`
|
||||
→ 동일 경로의 `ILSOS_PrismaticRD_PTOP.*` 로 변경
|
||||
|
||||
### 2-2. XAML (x:Class + clr-namespace) — 2개 파일
|
||||
- `Views/Main/UCMainAutoRun.xaml`
|
||||
- `Views/Model/UCEquipmentSpecificEditor.xaml`
|
||||
- 각: `x:Class="ILSOS_PrismaticScanner.Views..."` → `ILSOS_PrismaticRD_PTOP.Views...`,
|
||||
`xmlns:local="clr-namespace:ILSOS_PrismaticScanner.Views"` → `...ILSOS_PrismaticRD_PTOP.Views`
|
||||
- ⚠ 짝꿍 `.xaml.cs`(code-behind)의 namespace도 함께 변경. `obj/.../*.g.cs`·`*.g.i.cs`는 **빌드시 자동 재생성**이므로 직접 수정 불필요(무시).
|
||||
|
||||
### 2-3. 파일명 + 클래스명 리네임 (참고본이 실제로 바꾼 것)
|
||||
|
||||
| 현재 파일 | 현재 클래스 | → 참고본 파일 | → 참고본 클래스 |
|
||||
|---|---|---|---|
|
||||
| `Alarm/AlarmCode_PrismaticScanner.cs` | `AlarmCode_PrismaticScanner` | `Alarm/AlarmCode_PTOP.cs` | `AlarmCode_PTOP` |
|
||||
| `Alarm/AlarmManager_PrismaticScanner.cs` | `AlarmManager_PrismaticScanner` | `Alarm/AlarmManager_PTOP.cs` | `AlarmManager_PTOP` |
|
||||
| `Device/IO/PAIX_PrismaticScanner.cs` | `PAIX_PrismaticScanner` | `Device/IO/PAIX_PTOP.cs` | `PAIX_PTOP` |
|
||||
| `Models/EquipmentSpecificModel_PrismaticScanner.cs` | `EquipmentSpecificModel_PrismaticScanner` | `Models/EquipmentSpecificModel_PTOP.cs` | `EquipmentSpecificModel_PTOP` |
|
||||
| `Recipes/RMSHandlerForScanner.cs` | `RMSHandlerForScanner` | `Recipes/RMSHandlerForPTOP.cs` | `RMSHandlerForPTOP` |
|
||||
| `Settings/SettingUploadDataListForScanner.cs` | `SettingUploadDataListForScanner` | `Settings/SettingUploadDataListForPTOP.cs` | `SettingUploadDataListForPTOP` |
|
||||
| `Sequences/SeqAutoRunPrismaticScanner.cs` | `SeqAutoRunPrismaticScanner` | `Sequences/SeqAutoRunPrismatic.cs` | `SeqAutoRunPrismatic` |
|
||||
| `Device/PLC/PLCContoller.Config.cs` 외 2 (파일명 유지) | `PLCControllerPrismaticScanner` | (파일명 동일) | `PLCControllerPTOP` |
|
||||
|
||||
> PLC 3개 파일(`PLCContoller.Config.cs`, `PLCController.Address.cs`, `PLCController.Logic.cs`)은 **파일명은 유지**, 내부 **클래스명만 `PLCControllerPrismaticScanner` → `PLCControllerPTOP`**.
|
||||
|
||||
### 2-4. 클래스명 참조 전파 (find & replace 대상 파일 수, obj 제외)
|
||||
|
||||
| 심볼 | 영향 파일 수 | 비고 |
|
||||
|---|---|---|
|
||||
| `PLCControllerPrismaticScanner` | **13** | 가장 광범위 — 주의 |
|
||||
| `PAIX_PrismaticScanner` | 5 | ⚠ **충돌 주의(아래 §3-1)** |
|
||||
| `SeqAutoRunPrismaticScanner` | 5 | |
|
||||
| `AlarmCode_PrismaticScanner` | 2 | |
|
||||
| `AlarmManager_PrismaticScanner` | 2 | |
|
||||
| `EquipmentSpecificModel_PrismaticScanner` | 2 | |
|
||||
| `RMSHandlerForScanner` | 2 | |
|
||||
| `SettingUploadDataListForScanner` | 2 | |
|
||||
|
||||
### 2-5. csproj `Compile Include` 경로 갱신 (파일명 변경분 7줄)
|
||||
```
|
||||
Alarm\AlarmCode_PrismaticScanner.cs → Alarm\AlarmCode_PTOP.cs
|
||||
Alarm\AlarmManager_PrismaticScanner.cs → Alarm\AlarmManager_PTOP.cs
|
||||
Device\IO\PAIX_PrismaticScanner.cs → Device\IO\PAIX_PTOP.cs
|
||||
Models\EquipmentSpecificModel_PrismaticScanner.cs → Models\EquipmentSpecificModel_PTOP.cs
|
||||
Recipes\RMSHandlerForScanner.cs → Recipes\RMSHandlerForPTOP.cs
|
||||
Settings\SettingUploadDataListForScanner.cs → Settings\SettingUploadDataListForPTOP.cs
|
||||
Sequences\SeqAutoRunPrismaticScanner.cs → Sequences\SeqAutoRunPrismatic.cs
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 빌드 깨짐 유발 — 반드시 피해야 할 함정 ★
|
||||
|
||||
### 3-1. (최우선) `PAIX_PrismaticScanner` 이름 충돌 — **전역 일괄치환 금지**
|
||||
- **머신 클래스**: `ILSOS_PrismaticScanner.Device.IO.PAIX_PrismaticScanner` → `PAIX_PTOP`로 변경 대상.
|
||||
- **그러나 공유 클래스가 별도로 존재**: `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner`
|
||||
(선언: `WeldingComponents/WeldingCommon/Devices/Laser/LaserIOControl.cs`).
|
||||
- 현재 `Sequences/SeqTestRun.cs:32` 가 **공유 쪽**을 참조: `using static WeldingCommon.Devices.Laser.PAIX_PrismaticScanner;`
|
||||
- ⚠ `PAIX_PrismaticScanner` 를 **문자열 전역 치환하면 이 공유 참조까지 `PAIX_PTOP`로 바뀌어 컴파일 에러**. (WeldingCommon은 수정 금지 영역이기도 함.)
|
||||
- **올바른 방법:** 머신 IO를 가리키는 4곳만 `PAIX_PTOP`로 변경하고, `SeqTestRun.cs`의 `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner` 는 **그대로 둔다**.
|
||||
- 변경 대상(머신): `EquipmentSetup.cs`(L153 생성/주석 L130), `Sequences/Manual/SeqComponentTeachingRun.cs`(L80/197 및 주석), `Sequences/Monitoring/SeqAlarmMonitor.cs`(L19 `using static ILSOS_PrismaticScanner.Device.IO.PAIX_PrismaticScanner` / L49 / L130).
|
||||
- 유지(공유): `Sequences/SeqTestRun.cs:32`.
|
||||
|
||||
### 3-2. WeldingCommon / Aurora 등 공유 영역은 손대지 않는다
|
||||
- 본 작업은 **PTOP 머신 프로젝트 내부에 한정**. 공유 프로젝트(WeldingCommon, AuroraDevices…)의 `PAIX_PrismaticScanner`, `RMSHandlerForScanner` 등 **동명 심볼이 있더라도 건드리지 않음**.
|
||||
|
||||
### 3-3. obj 생성물은 무시
|
||||
- `obj/x64/Debug/Views/.../*.g.cs`, `*.g.i.cs`(현재 Scanner namespace) 는 **XAML 기준 자동 재생성**. 직접 수정 X. (clean 후 재빌드하면 갱신됨)
|
||||
|
||||
### 3-4. 짝(파트너) 누락 주의
|
||||
- XAML 변경 시 **3종 세트**가 일치해야 함: `*.xaml`(x:Class) ↔ `*.xaml.cs`(namespace/class) ↔ csproj `<Page>`/`<Compile DependentUpon>`.
|
||||
- 파일명 리네임 시 **csproj `Compile Include` 경로**도 같이 바꿔야 빌드 인식(§2-5).
|
||||
|
||||
### 3-5. 파일 리네임은 git 추적 유지
|
||||
- `git mv` 로 리네임하여 히스토리 유지(클래스명/파일명 동시 변경).
|
||||
|
||||
---
|
||||
|
||||
## 4. 권장 안전 작업 순서
|
||||
1. **백업/브랜치**: 별도 작업 브랜치에서 진행.
|
||||
2. **파일 리네임**(`git mv`) 7개 → 클래스명 변경(파일 내부 선언부).
|
||||
3. **namespace 일괄 변경**: `namespace ILSOS_PrismaticScanner` → `ILSOS_PrismaticRD_PTOP` (26 파일, obj 제외).
|
||||
4. **using 일괄 변경**: `using ILSOS_PrismaticScanner.` → `using ILSOS_PrismaticRD_PTOP.` (15 파일).
|
||||
5. **클래스명 참조 전파**: §2-4 심볼별로 **머신 참조만** 신규명으로 치환. ★ `PAIX_PrismaticScanner` 는 §3-1 규칙대로 공유 참조 1곳 제외.
|
||||
6. **XAML 3종 세트** 변경(§2-2).
|
||||
7. **csproj `Compile Include` 경로** 갱신(§2-5).
|
||||
8. **clean → rebuild**. obj 재생성 확인. 참고본과 `namespace`/`using` 카운트(0 / 0) 일치 확인.
|
||||
|
||||
---
|
||||
|
||||
## 5. 검증 체크리스트 (작업 후)
|
||||
- [ ] `grep -r 'namespace ILSOS_PrismaticScanner' (obj 제외)` → 0건
|
||||
- [ ] `grep -r 'using ILSOS_PrismaticScanner'` → 0건
|
||||
- [ ] `WeldingCommon.Devices.Laser.PAIX_PrismaticScanner` 참조(SeqTestRun.cs)는 **그대로 존재**
|
||||
- [ ] csproj `Compile Include` 7줄이 새 파일명과 일치
|
||||
- [ ] XAML x:Class / clr-namespace / code-behind namespace 3종 일치
|
||||
- [ ] Debug|x64 리빌드 성공 (참고본과 동일 구성)
|
||||
|
||||
---
|
||||
|
||||
## 6. 참고: 참고본에만 있는 추가 파일(범위 밖, 참고만)
|
||||
참고본에는 현재본 대비 `Sequences/SeqTestRun.cs`, `Sequences/Monitoring/SeqAlarmMonitor.cs`, `SeqStatusMonitor.cs` 등이 정리되어 있음. 본 마이그레이션의 핵심(네임스페이스/리네임)과 별개의 기능 정리이므로, 우선 §2~§5의 리네임 정합성에 집중.
|
||||
@ -1,117 +0,0 @@
|
||||
# Manual Laser Power Control — "레이저 컨트롤러 OFF + 전압만 인가(NoLaser)" 분석 및 채택안
|
||||
|
||||
- **작성일:** 2026-06-18 (갱신: 최종 채택안 = IO Control DO9/13 + `IsNoLaser`)
|
||||
- **관련 View/VM:**
|
||||
- 채택 지점: `WeldingComponents/WeldingCommon/Views/Recipes/UCScannerObjectTeachingControlBox.xaml` (+ `...ViewModel.cs`)
|
||||
- 초기 검토 지점(원복): `WeldingComponents/WeldingCommon/Views/Manual/Scanner/UCScannerLaserControl.xaml` (+ VM)
|
||||
- **디바이스:** `AuroraDevices/AuroraLaserScanner/Scanner.cs`, `ScannerRTC5.cs`, `WeldingCommon/Devices/Laser/LaserIOControl.cs`
|
||||
- **선행 분석:** `102847_manual_laser_power_control_groupbox_analysis.md`
|
||||
|
||||
---
|
||||
|
||||
## 0. 내 요청사항
|
||||
|
||||
> Manual Laser Power Control 영역에서 **레이저(발진, lasing)는 안 나가게 하고 전압(Voltage)만 인가**되도록 하고 싶다. `Laser On`을 눌렀을 때 동작하도록 **체크박스/토글** 하나가 있어야 할 것 같다. (Cal 파일 작성용: 레이저는 안 쏘고 전압만 인가, 기록은 남기기)
|
||||
>
|
||||
> 추가 확인(현장): "Laser On 누르면 원래 **IO Control 9번이 true**가 되는데, 그 IO를 true로 안 켜면(false 유지) 발진 없이 동작한다." → 그 지점을 막는 방식으로.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 요약 (최종 채택안)
|
||||
|
||||
- **실제 발진을 만드는 지점은 `LaserSignalOn`(RTC5 게이트)이 아니라 IO Control 비트였다.**
|
||||
- **DO 9 = `CoreLaser_Control`**, **DO 13 = `RingLaser_Control`** (PAIX `ePrismaticDOAddress`).
|
||||
- 이 둘이 true가 되면 레이저 컨트롤러가 발진 가능(enable) 상태가 됨.
|
||||
- 따라서 **이 DO9/13을 켜는 부분을 NoLaser일 때 false로 유지**하면, 전압(WriteDA)은 인가되되 레이저 컨트롤러는 OFF → 발진 없이 `Laser On` 가능.
|
||||
- 채택 위치: `UCScannerObjectTeachingControlBoxViewModel.PerformCmdLaserReadyCheck` (Laser Control GroupBox의 **Laser Ready** 버튼).
|
||||
- 구현: ViewModel에 `IsNoLaser`(bool, 기본 false) 추가 + 켜는 분기에 `ctrlOn = !IsNoLaser` 적용 + XAML 체크박스.
|
||||
|
||||
---
|
||||
|
||||
## 2. 메커니즘 근거
|
||||
|
||||
### 2-1. 전압 출력과 발진은 독립 (선행 확인)
|
||||
- `Scanner.WriteDA(port, value)` → RTC5 `n_write_da_x` (아날로그 전압 출력). `ScannerRTC5.WriteDA`: `targetValue = value * 40.95` (0~4095 = 0~10V). 즉 **출력 전압[V] = value/10**.
|
||||
- `Scanner.LaserSignalOn()` → RTC5 `n_laser_signal_on` (스캐너측 레이저 Active 신호). 전압 출력과 별개 호출.
|
||||
|
||||
### 2-2. ★ 실제 레이저 컨트롤러 Enable = IO DO9/DO13
|
||||
`WeldingCommon/Devices/Laser/LaserIOControl.cs` 의 `ePrismaticDOAddress`:
|
||||
```
|
||||
CoreLaser_Control = 9
|
||||
CoreLaser_ErrorClearing
|
||||
RingLaser_Control = 13
|
||||
RingLaser_ErrorClearing
|
||||
```
|
||||
→ DO9/DO13(Core/Ring Laser Control)을 true로 주면 레이저 컨트롤러가 켜짐(발진 가능). **이게 "발진을 만드는 IO".**
|
||||
(참고: DI9 = `CoreLaser_Laser_Ready`는 읽기 신호로 별개.)
|
||||
|
||||
### 2-3. DO9/13을 켜는 코드 위치
|
||||
`UCScannerObjectTeachingControlBoxViewModel.PerformCmdLaserReadyCheck` — `Laser Ready` 버튼이 `toggleIO`로 DO9/DO13을 true/false 토글.
|
||||
```csharp
|
||||
if (toggleIO) {
|
||||
_IODevice._iOUnit.WriteDoBit(9, true); // CoreLaser_Control ON
|
||||
_IODevice._iOUnit.WriteDoBit(13, true); // RingLaser_Control ON
|
||||
toggleIO = false;
|
||||
} else {
|
||||
_IODevice._iOUnit.WriteDoBit(9, false);
|
||||
_IODevice._iOUnit.WriteDoBit(13, false);
|
||||
toggleIO = true;
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 채택 구현 (적용 완료)
|
||||
|
||||
### 3-1. ViewModel — `IsNoLaser` 추가
|
||||
```csharp
|
||||
private bool _IsNoLaser;
|
||||
public bool IsNoLaser { get => _IsNoLaser; set => SetProperty(ref _IsNoLaser, value); }
|
||||
// InitVariable()에서 IsNoLaser = false (기본: 기존 동작)
|
||||
```
|
||||
|
||||
### 3-2. 켜는 분기를 NoLaser면 false로
|
||||
```csharp
|
||||
if (toggleIO) {
|
||||
// IsNoLaser면 레이저 컨트롤러(BIT9/13)를 켜지 않음(false 유지) → 발진 없이 Laser On 가능
|
||||
bool ctrlOn = !IsNoLaser;
|
||||
_IODevice._iOUnit.WriteDoBit(9, ctrlOn);
|
||||
_IODevice._iOUnit.WriteDoBit(13, ctrlOn);
|
||||
toggleIO = false;
|
||||
} else {
|
||||
_IODevice._iOUnit.WriteDoBit(9, false);
|
||||
_IODevice._iOUnit.WriteDoBit(13, false);
|
||||
toggleIO = true;
|
||||
}
|
||||
```
|
||||
|
||||
### 3-3. XAML — 체크박스 (Laser Control GroupBox)
|
||||
```xml
|
||||
<CheckBox Grid.Row="4" Grid.Column="0" Grid.ColumnSpan="2" Margin="5 6 0 0"
|
||||
FontSize="12" FontWeight="Bold" Foreground="#FFBBBBBB"
|
||||
IsChecked="{Binding IsNoLaser}"
|
||||
Content="No Laser (전압만, 발진 안 함)"/>
|
||||
```
|
||||
|
||||
### 3-4. 동작 표
|
||||
| IsNoLaser | Laser Ready 버튼 | 결과 |
|
||||
|---|---|---|
|
||||
| **false (기본)** | DO9/13 ON/OFF 토글 | 기존과 동일(레이저 컨트롤러 켜짐 → 발진 가능) |
|
||||
| **true (NoLaser)** | DO9/13을 **false 유지** | 레이저 컨트롤러 OFF, 발진 없이 진행(전압만) |
|
||||
|
||||
> 적용 = 커밋 `8ec4fd0`. 디바이스 레이어(Scanner/RTC5) 무변경, IO 비트 9/13만 제어.
|
||||
|
||||
---
|
||||
|
||||
## 4. 초기 검토안(원복) 기록
|
||||
- 처음엔 `UCScannerLaserControl`(Manual Laser Power Control)에 `IsAnalogOnly`를 추가해 `LaserSignalOn()`(RTC5 게이트)을 조건부로 막는 방식을 구현했음.
|
||||
- 그러나 현장 확인 결과 **실제 발진 Enable은 다른 소스(ObjectTeachingControlBox)의 IO DO9/13**임이 확인되어, 해당 변경은 **원복**(Watt 숨김 커밋 `ad6cf68`은 유지)하고 본 §3의 DO9/13 방식으로 재구현함.
|
||||
- 교훈: "발진을 막는 지점"이 RTC5 게이트(`LaserSignalOn`)가 아니라 **레이저 컨트롤러 Enable IO(DO9/13)** 였음.
|
||||
|
||||
---
|
||||
|
||||
## 5. 주의 / 추가 확인
|
||||
1. **전압 표시(요청)**: 인가 전압을 화면에 표시하려면, 하드웨어 readback API는 없으므로 **명령 전압값(= WriteDA에 쓰는 powerVolt/10 [V])** 을 VM 프로퍼티로 노출해 표시하는 방식 권장(디바이스 무변경). → 별도 작업으로 진행 가능.
|
||||
2. **RTC5 기록 저장**: WriteDA(전압)는 발진과 무관하게 수행되므로 전압 명령 자체는 남음. "기록 저장"이 앱 로깅을 의미하면 별도 로깅 경로 확인 필요.
|
||||
3. **안전**: NoLaser는 기본 false. 체크 상태를 화면에 명확히 표시(체크박스 라벨). NoLaser일 때는 DO9/13이 절대 true로 가지 않음(켜는 분기·끄는 분기 모두 false).
|
||||
4. **Manual Laser Power Control(UCScannerLaserControl) 쪽**: 현재 Watt GroupBox는 숨김(`Collapsed`), Analog Only 변경은 원복됨. 추후 그쪽에도 동일 NoLaser 연동이 필요한지는 운영하며 판단.
|
||||
@ -1,90 +0,0 @@
|
||||
# "Laser On 눌러도 레이저가 안 나옴" 원인 분석 (기능 존재 여부)
|
||||
|
||||
- **작성일:** 2026-06-18
|
||||
- **대상:** `WeldingComponents/WeldingCommon/Views/Manual/Scanner/UCScannerLaserControlViewModel.cs` (`PerformCmdLaserShotOnPercent` / `...Watt`)
|
||||
- **디바이스:** `AuroraDevices/AuroraLaserScanner/Scanner.cs`, `ScannerRTC5.cs` (Trumpf TruFiber 레이저)
|
||||
- **선행:** `102847_...groupbox_analysis.md`, `114445_...no_laser_toggle_analysis.md`
|
||||
|
||||
---
|
||||
|
||||
## 0. 증상 / 질문
|
||||
|
||||
> IO Control(DO9/13)도 true, DI(Laser Ready)도 잘 읽혀서 Laser Ready도 true → 레이저가 나와야 하는데 **Laser On 눌러도 레이저가 안 나온다.** 기능이 현재 없는 건지 분석.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론
|
||||
|
||||
- **준비조건(IO/Ready)은 문제 없음.** 문제는 발사 명령 자체에서 **레이저 Gate 신호 셋업이 빠져있는 것**.
|
||||
- **Trumpf 레이저는 `SetLaserTiming`으로 Gate 신호를 살려줘야 출사된다**(코드 주석으로 명시 + 241025 출사 확인 기록).
|
||||
- 그런데 수동 **Laser On 직접 분기(No Use Spot Time)** 에서는 `SetLaserTiming`(과 `SetStandby`)이 **주석 처리**되어 있어, `LaserSignalOn()`만으로는 Gate가 안 열려 **실제 출사가 안 됨.**
|
||||
- 즉 "직접 출사" 기능은 **사실상 미완성(셋업 라인 비활성)** 상태. 기능 자체가 아예 없는 건 아니고, **Gate 셋업 한 줄이 빠진 것**.
|
||||
|
||||
---
|
||||
|
||||
## 2. 근거
|
||||
|
||||
### 2-1. Laser On 직접 분기 (현재 코드, `PerformCmdLaserShotOnPercent` else 분기)
|
||||
```csharp
|
||||
_Scanner.WriteDA(DA1, powerVolt1, COMMAND); // 전압 OK
|
||||
_Scanner.WriteDA(DA2, powerVolt2, COMMAND);
|
||||
_Scanner.SetLaserPulseCtrl(LaserPeriod*1000, LaserPulseWidth);
|
||||
//_Scanner.SetLaserTiming(LaserPeriod*1000, LaserPulseWidth, LaserPulseWidth); // ← 주석!
|
||||
//_Scanner.SetStandby(LaserPeriod*1000, LaserPulseWidth); // ← 주석!
|
||||
_Scanner.LaserSignalOn(); // Gate(LASERON) 신호만 올림
|
||||
```
|
||||
→ `LaserSignalOn()`은 RTC5 `n_laser_signal_on`(레이저 Active 신호)만 올림. **Gate 타이밍(SetLaserTiming) 설정이 없으면 Trumpf 레이저는 출사 안 됨.**
|
||||
|
||||
### 2-2. "Trumpf는 SetLaserTiming으로 Gate 살려야 함" 명시 (SeqUploadWeldingList.cs:624~626)
|
||||
```
|
||||
//TrumpLaser의 경우 SetLaserTiming 함수로 Gate 신호를 살려줘야 함
|
||||
//우선 무조건 셋팅하는 것으로 쓰고 Trump_IO Class 만들면 ... Trump의 경우에만 셋팅
|
||||
//LaserFrequency = 10, LaserPulseDuration = 0.1로 셋팅하면 출사 되는 것 확인_241025
|
||||
```
|
||||
→ **출사 확인된 셋업: `SetLaserTiming(주파수=10, PulseDuration=0.1ms)`** (= `SetLaserTiming(10, 100, 100)` 형태).
|
||||
|
||||
### 2-3. 실제 출사되는 경로는 List + Timing 셋업 사용
|
||||
- `SeqUploadWeldingList` / `SeqMarkGrid` 등 실제 마킹 경로는 `SetLaserTiming(...)` + `LaserOnList(...)`(리스트 기반)로 출사.
|
||||
- 수동 버튼 직접 분기는 리스트가 아닌 `LaserSignalOn` 직접 호출인데 Timing 셋업이 빠짐.
|
||||
|
||||
---
|
||||
|
||||
## 3. 두 가지 Laser On 경로 정리
|
||||
|
||||
| 모드(토글) | 경로 | 출사 여부 |
|
||||
|---|---|---|
|
||||
| **Use Spot Time** (기본값 `IsUseLaserAutoOffChecked=true`) | `SeqTeachingRun.Start(...)` (리스트 기반, `NeedSetLaserTiming=true` 전달) | 모델 선택 등 전제 충족 시 출사(스팟). 단 모델 null/Busy/LaserReady false면 경고 후 미발사 |
|
||||
| **No Use Spot Time** (직접) | `WriteDA → SetLaserPulseCtrl → LaserSignalOn` | **SetLaserTiming 주석 → Gate 안 열림 → 출사 안 됨** ★ |
|
||||
|
||||
> 사용자가 "직접 한 방 쏘려고" No Use Spot Time로 눌렀다면 §2-1 이유로 안 나옴.
|
||||
> Use Spot Time(기본)인데도 안 나온다면 §3 표의 전제(모델 선택/Busy/`_Laser.GetLaserReady()`)에서 막혔을 가능성(토스트 메시지 확인 필요).
|
||||
|
||||
---
|
||||
|
||||
## 4. 권장 수정 (직접 분기 출사 활성화)
|
||||
|
||||
직접 분기에서 `LaserSignalOn()` **앞에** Gate 타이밍을 살려준다:
|
||||
```csharp
|
||||
_Scanner.SetLaserPulseCtrl(LaserPeriod*1000, LaserPulseWidth);
|
||||
_Scanner.SetLaserTiming(LaserPeriod, LaserPulseWidth, LaserPulseWidth); // ← 주석 해제/추가 (Gate 신호 enable)
|
||||
_Scanner.LaserSignalOn();
|
||||
```
|
||||
- 우선 검증은 **확인된 값**으로: `SetLaserTiming(10, 100, 100)`(주파수 10, PulseDuration 0.1ms) → 출사 확인된 셋업(241025).
|
||||
- 그 후 화면 입력값(`LaserPeriod`/`LaserPulseWidth`) 단위를 SetLaserTiming 인자 단위(periodHz, pulseWidthUs)에 맞춰 매핑 필요.
|
||||
- Laser Off 시 `LaserSignalOff()` 유지(이미 있음).
|
||||
|
||||
> ⚠ 안전: 이 수정은 **실제 레이저를 출사**시키므로, 적용/테스트는 차폐·인터락·저파워에서 단계적으로. (NoLaser 옵션과 함께 쓰면 컨트롤러 OFF로 무발광 검증 가능.)
|
||||
|
||||
---
|
||||
|
||||
## 5. 추가 확인 필요
|
||||
1. 사용자가 누른 Laser On이 **어느 모드(Use Spot Time vs No Use Spot Time)** 였는지 → 토스트 메시지/화면 토글 상태 확인.
|
||||
2. `SetLaserTiming` 인자 단위(periodHz/us)와 화면 입력값(`LaserPeriod` kHz, `LaserPulseWidth` us) 정합 매핑.
|
||||
3. 현재 레이저 타입(`_LaserConfig.TruFiberType`)이 Trumpf 계열인지(맞으면 Gate 셋업 필수).
|
||||
4. Use Spot Time 경로가 막히는 경우 전제조건(`_Laser.GetLaserReady()`, 모델 선택, Scanner Busy) 로그 확인.
|
||||
|
||||
---
|
||||
|
||||
## 6. 답: "기능이 없는 건가?"
|
||||
- **완전히 없는 건 아님.** Use Spot Time(시퀀스) 경로는 출사 로직이 있음.
|
||||
- 다만 **직접 출사(No Use Spot Time) 경로는 Gate 셋업(`SetLaserTiming`)이 주석 처리되어 미완성** → 그래서 IO/Ready가 다 맞아도 안 나옴. §4 한 줄(또는 확인값) 추가가 핵심.
|
||||
@ -1,106 +0,0 @@
|
||||
# Monitoring IOInterfaceView DI 파일 경로 — PTOP 바라보게 하기 분석
|
||||
|
||||
- **작성일:** 2026-06-18
|
||||
- **목표:** 작업환경에서 IOInterfaceView가 `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\_device\_io` 의 DI 파일을 보게 하기
|
||||
- **대상:** `AuroraDevices/AuroraIO/IODevice.cs`, `AuroraDevices/AuroraIO/View/UCIOInterfaceViewModel.cs`, 설정 `IO_Board.json`
|
||||
|
||||
---
|
||||
|
||||
## 0. 요청
|
||||
|
||||
> 마이그레이션 전(현장 소스)에는 PTOP 프로젝트 시작이어도 Monitoring의 IOInterfaceView가 `D:\ILSOSConfig\ILSOS_PrismaticScanner\_device\_io` 의 DI 파일을 참조해 보여줬다. 내 작업환경에서 **PTOP(`D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP`)** 데이터를 보게 하려면 어디를 고쳐야 하나? 수정 위치 + diff. 문제 없으면 그 이유도.
|
||||
|
||||
---
|
||||
|
||||
## 1. 결론 (요약)
|
||||
|
||||
- **소스 코드는 고칠 필요가 없다(IO DI 한정).** DI 파일 경로는 **소스에 없고**, **설정 파일 `IO_Board.json` 의 `IOInterfaceMapDI`(절대경로)** 값으로 결정된다.
|
||||
- `IODevice.MappingDIO()`는 그 절대경로를 **그대로 읽는다**(DataPath 등 가공 없음). 즉 **경로 무관(path-agnostic)** 코드 → 버그 없음.
|
||||
- 따라서 PTOP를 바라보게 하는 건 **설정/환경 변경**:
|
||||
1. 앱이 로드하는 config 폴더(DataPath)가 `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP` 여야 함.
|
||||
2. 그 폴더의 `_config_device\IO_Board.json` 의 `IOInterfaceMapDI`/`IOInterfaceMapDO` 가 **PTOP 경로**를 가리켜야 함.
|
||||
3. 실제 `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\_device\_io\DI.csv`(DO.csv) 파일이 존재해야 함.
|
||||
|
||||
---
|
||||
|
||||
## 2. 경로 결정 메커니즘 (코드 근거)
|
||||
|
||||
### 2-1. DI/DO 매핑 로드 — `AuroraDevices/AuroraIO/IODevice.cs` `MappingDIO()`
|
||||
```csharp
|
||||
var m_connConfig = _connConfig as IOUnitConnConfig;
|
||||
switch (type) {
|
||||
case InfoIO.IoType.DI: fileName = m_connConfig.IOInterfaceMapDI; break; // ← 설정값(절대경로)
|
||||
case InfoIO.IoType.DO: fileName = m_connConfig.IOInterfaceMapDO; break;
|
||||
}
|
||||
FileInfo fi = new FileInfo(fileName);
|
||||
if (!fi.Directory.Exists) fi.Directory.Create();
|
||||
if (File.Exists(fileName) == false) {
|
||||
Log.I($"파일({fileName})이 존재하지 않습니다. Device Config의 File 경로를 확인하세요.");
|
||||
return 0; // ← 없으면 로그만, 크래시 없음(빈 리스트)
|
||||
}
|
||||
StreamReader sr = new StreamReader(fileName, ...); // ← 절대경로 그대로 읽음
|
||||
... ListDI/ListDO 채움
|
||||
```
|
||||
→ **`fileName`은 `IOInterfaceMapDI` 값 그 자체.** 코드가 폴더명을 만들거나 바꾸지 않음.
|
||||
|
||||
### 2-2. 설정 출처 — `IO_Board.json` (`_config_device`)
|
||||
`Doc/ILSOSConfig/ILSOS_PrismaticScanner/_config_device/IO_Board.json`:
|
||||
```json
|
||||
"IOInterfaceMapDI": "D:\\ILSOSConfig\\ILSOS_PrismaticScanner\\_device\\_io\\DI.csv",
|
||||
"IOInterfaceMapDO": "D:\\ILSOSConfig\\ILSOS_PrismaticScanner\\_device\\_io\\DO.csv",
|
||||
```
|
||||
→ **여기 절대경로가 `ILSOS_PrismaticScanner`로 박혀 있어서**, 어떤 config 폴더를 로드하든 이 값이면 Scanner DI를 읽었던 것.
|
||||
|
||||
### 2-3. 화면 — `UCIOInterfaceViewModel`
|
||||
ViewModel은 위에서 로드된 `_iOUnit.ListDI`를 표시할 뿐, 경로를 직접 다루지 않음. → 화면 쪽도 수정 불필요.
|
||||
|
||||
### 2-4. 앱이 어느 config 폴더를 로드하는가 (DataPath)
|
||||
- `D:\ILSOSConfig\<폴더>` 의 `<폴더>` 는 Aurora 프레임워크(`ApplicationExt.DataPath`, External\Aurora 바이너리)가 결정. **repo 소스에 없음.**
|
||||
- 관례상 머신 플러그인 **AssemblyName** 과 일치(과거 `ILSOS_PrismaticScanner`). 이번 마이그레이션으로 **AssemblyName = `ILSOS_PrismaticRD_PTOP`** 이 되었으므로, DataPath도 `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP` 로 해석될 가능성이 큼 → **그 폴더가 준비돼 있어야 함**(없으면 §2-1처럼 "파일 없음" 로그 후 빈 표시).
|
||||
|
||||
---
|
||||
|
||||
## 3. 수정 위치 (= 설정/환경, 소스 아님)
|
||||
|
||||
### (필수) IO_Board.json 경로 값 — `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\_config_device\IO_Board.json`
|
||||
```diff
|
||||
- "IOInterfaceMapDI": "D:\\ILSOSConfig\\ILSOS_PrismaticScanner\\_device\\_io\\DI.csv",
|
||||
- "IOInterfaceMapDO": "D:\\ILSOSConfig\\ILSOS_PrismaticScanner\\_device\\_io\\DO.csv",
|
||||
+ "IOInterfaceMapDI": "D:\\ILSOSConfig\\ILSOS_PrismaticRD_PTOP\\_device\\_io\\DI.csv",
|
||||
+ "IOInterfaceMapDO": "D:\\ILSOSConfig\\ILSOS_PrismaticRD_PTOP\\_device\\_io\\DO.csv",
|
||||
```
|
||||
### (필수) 데이터 파일 존재
|
||||
`D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\_device\_io\DI.csv`, `DO.csv` 가 실제로 있어야 함(Scanner 폴더에서 복사 또는 260618 zip 사용).
|
||||
|
||||
### (확인) DataPath
|
||||
앱 실행 시 로드되는 config 루트가 `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP` 인지 확인(로그의 파일 경로/“파일 없음” 메시지로 검증).
|
||||
|
||||
> **즉 IO DI에 대한 C# 소스 diff 는 없음.** §2-1 코드가 path-agnostic 이라 고칠 게 없다(= "문제 없는 이유").
|
||||
|
||||
---
|
||||
|
||||
## 4. "문제 없는 이유" 정리
|
||||
- `MappingDIO`는 `IOInterfaceMapDI` 절대경로를 **그대로** `StreamReader`로 연다. 경로 조립/머신명 치환 로직이 없음 → **코드가 머신에 종속되지 않음.**
|
||||
- 파일이 없으면 예외 없이 로그 후 빈 리스트(`return 0`) → IOInterfaceView가 비어 보일 뿐 크래시 없음.
|
||||
- 그래서 "PTOP를 바라보게" 하는 건 코드 수정이 아니라 **(1) PTOP config 폴더 준비 + (2) 그 안 IO_Board.json 경로를 PTOP로 + (3) DI/DO.csv 존재**로 끝난다.
|
||||
|
||||
---
|
||||
|
||||
## 5. (참고) 별개 이슈 — 소스에 하드코딩된 `ILSOS_PrismaticScanner` 절대경로
|
||||
IO DI와 무관하지만, **PTOP config로 완전 전환** 시 같이 손봐야 할 하드코딩 경로(공유 소스, WeldingCommon/LASA — 수정 시 승인 필요):
|
||||
| 파일 | 용도 |
|
||||
|---|---|
|
||||
| `WeldingCommon/Settings/SystemParameter.cs:17,18` | FieldScanImage, WORK_RECIPE_FILE |
|
||||
| `WeldingCommon/RMS/EDC.cs:171,177` | cellTracker CSV |
|
||||
| `LASA/GUI/DB/RecipeFieldScan.cs:24` | 기본 Scout 이미지 |
|
||||
| `LASA/GUI/Page/MainPage.cs:259,533` | 기본 FieldScan 이미지 |
|
||||
| `WeldingCommon/Views/Manual/Scanner/WDSelectScoutFieldViewModel.cs:47` | 기본 FieldScan 이미지 |
|
||||
> 이들은 모두 `D:\ILSOSConfig\ILSOS_PrismaticScanner\...` 로 박혀 있음. **IOInterfaceView DI 표시에는 영향 없음**(vision/recipe/cellTracker 기본값). 필요 시 `ILSOS_PrismaticRD_PTOP`로 일괄 치환하는 별도 작업으로 진행.
|
||||
|
||||
---
|
||||
|
||||
## 6. 권장 조치 (작업환경)
|
||||
1. `D:\ILSOSConfig\ILSOS_PrismaticRD_PTOP\` 준비(없으면 Scanner 복사 또는 260618 zip 해제).
|
||||
2. `…\_config_device\IO_Board.json` 의 DI/DO 경로를 §3 diff 대로 PTOP로 변경.
|
||||
3. `…\_device\_io\DI.csv`, `DO.csv` 존재 확인.
|
||||
4. 앱 실행 → IOInterfaceView에 PTOP DI 표시 확인. (안 보이면 로그의 파일 경로로 DataPath/파일유무 점검)
|
||||
@ -1,111 +0,0 @@
|
||||
# ILSOS PTOP 알람부(AlarmManager) 종합 분석 — 2026-06-19
|
||||
|
||||
> 계기: 현장 PLC 미연결 상태에서 `SeqComponentTeachingRun` 시작 시 H(중)알람 인터락(202003)으로 차단됨.
|
||||
> 본 문서는 알람부 전체 구조·동작·시퀀스 참조·리스크·개선안을 정리한다.
|
||||
|
||||
---
|
||||
|
||||
## 1. 클래스 구조
|
||||
|
||||
| 클래스 | 위치 | 역할 |
|
||||
|--------|------|------|
|
||||
| `AlarmManager` (base) | `WeldingCommon/Alarm/AlarmManager.cs` | 정적 싱글톤(`_Instance`). 알람 set/조회/시퀀스 정지 |
|
||||
| `AlarmManager_PTOP` | `PTOP/Alarm/AlarmManager_PTOP.cs` | `StopSequenceByAlarm` — H알람 시 AutoRun 정지 |
|
||||
| `AlarmCode` / `AlarmCode_PTOP` | `.../Alarm/AlarmCode*.cs` | 알람 코드 상수. PTOP는 base 상속 후 21xxxx 추가 |
|
||||
| `IAlarmService` (Aurora 프레임워크) | External/Aurora | **활성 알람 목록·설명·레벨(H/L)** 보유 |
|
||||
|
||||
- 알람 **레벨(H/L)** 은 소스 상수가 아니라 **Aurora 런타임 알람 테이블**에 정의됨(코드에 `AlarmLevel.H` 할당부 없음).
|
||||
|
||||
## 2. 핵심 메서드 동작 (주의점)
|
||||
|
||||
- **`Alarm(code)`** (79줄): 이미 활성이면 재set 안 함 → **set-once(중복 없음)**.
|
||||
- **`HasAlarmLevelHigh()`** (172줄): 활성 알람 중 H 하나라도 있으면 true. **⚠️ Simulation이면 무조건 false**(시뮬은 인터락 우회).
|
||||
- **`IsAlarmLevelHigh(code)`** (194줄): 설명 모르는 코드(`desc==null`)는 **위험으로 보고 H 취급** → 미정의 코드도 인터락 유발.
|
||||
- **Clear**: 개별 `ClearAlarm()`은 **빈 함수**(주석만). 실제 해제는 **`ClearAllAlarm()`(전체 일괄)** 뿐.
|
||||
- 트리거: `SYS_ALARM_RESET_ALL_ALARM` / `EVENT_RESET_ALL_ALARMS_REQUEST` → `_AlarmService.ClearAllAlarm()`.
|
||||
- **PLC 알람워드 직접쓰기**(`WriteBit(HeavyAlarmStatusAddr..)`)는 AlarmManager 내에서 전부 **주석 처리**됨(대신 SeqStatusMonitor가 수행).
|
||||
|
||||
## 3. 알람 생성·소멸·전파 흐름
|
||||
|
||||
```
|
||||
[생성] SeqAlarmMonitor (상시 주기 감시)
|
||||
├ PLC: EMO / Heavy / Door / 통신끊김
|
||||
├ Laser/Scanner/LBAD/OCT/Chiller: Deactivated/Disconnect/Error
|
||||
└ IO: Leak / null / deactivated
|
||||
→ AlarmManager.Alarm(code) ← set-only, ❌조건 해소 시 Clear 안 함(LATCH)
|
||||
|
||||
[전파] EquipmentSetup.OnSetAlarm(code, isHeavy) (EquipmentSetup.cs:82)
|
||||
→ isHeavy 면 AlarmManager_PTOP.StopSequenceByAlarm(code) → H면 StopSequence(SeqAutoRun) 비상정지
|
||||
|
||||
[PLC보고] SeqStatusMonitor.UpdateStatus (SeqStatusMonitor.cs:86)
|
||||
→ PC_HEAVY_ALARM_STATUS = HasAlarmLevelHigh(), PC_LIGHT_ALARM_STATUS = HasAlarmLevelLow()
|
||||
→ PLC_ALARM_RESET 입력 시 EVENT_RESET_ALL_ALARMS_REQUEST 발행 → ClearAllAlarm()
|
||||
|
||||
[차단] 각 시퀀스 시작 시 CheckCondition_Interlock() → HasAlarmLevelHigh() H면 시작 거부
|
||||
```
|
||||
|
||||
## 4. 주요 시퀀스별 알람 참조
|
||||
|
||||
| 시퀀스 | 인터락 체크 | 비고 |
|
||||
|--------|------------|------|
|
||||
| **SeqComponentTeachingRun** | `HasAlarmLevelHigh()` → "Clear Heavy Alarms" + 202003 (Door/EMO 주석) | **이번에 막힌 시퀀스** |
|
||||
| SeqTeachingRun (Common) | `CheckCondition_Interlock()` = **빈 체크(true)** | 알람 체크 없음 |
|
||||
| **SeqAutoRunPTOP** | `CheckCondition_Interlock()` = **빈 체크(true)** | 차단은 시작이 아니라 OnSetAlarm→StopSequence |
|
||||
| SeqAutoRunPrismatic / ComponentWeld | 동일 패턴(빈 체크) | |
|
||||
| ScoutNormal/FlyingVision, UploadWeldingList, ReceiveCellInfo, ReportCellResult, MarkGrid, ScannerCalibration | 대부분 빈 체크 | 공통 시퀀스 |
|
||||
| **SeqStatusMonitor** | 알람을 **읽어 PLC 출력** + Reset 처리 | 차단 아님 |
|
||||
| **SeqAlarmMonitor** | 알람을 **생성(set-only)** | latch 원인 |
|
||||
|
||||
> 실제 알람으로 "시작 차단"하는 곳은 `SeqComponentTeachingRun`이 거의 유일. AutoRun 계열은 "운전 중 H알람 발생 시 비상정지" 방식.
|
||||
|
||||
## 5. 알람 코드 표 (추정 레벨 — 권위값은 런타임 테이블)
|
||||
|
||||
| 코드 | 이름 | 용도 | 추정 |
|
||||
|------|------|------|------|
|
||||
| 200xxx~203xxx | ALARM_SEQUENCE_* | 시퀀스 결과/초기조건 실패 | 혼합 |
|
||||
| 203004 | AutoRun_HeavyAlarmOccured | 자동운전 중 중알람 | H |
|
||||
| 210001/2/3 | PLC Deactivated/Disconnect/**EMO** | PLC 상태/비상정지 | H |
|
||||
| 210004/5/6 | PLC Light / **Heavy** / Door Interlock | PLC 경/중/도어 | 210005·6 H, 210004 L |
|
||||
| 210101/2/3 | Scanner Deactivated/Disconnect/Error | 스캐너 | H/혼합 |
|
||||
| 210201~205 | Laser Deactivated/Disconnect/Error/Warning/**EMO** | 레이저 | 205·201 H, 204 L |
|
||||
| 210206/7 | Laser Warning/Error MSG | 레이저 메시지(동적) | L/H |
|
||||
| 210301~303 | LBAD Deactivated/Disconnect/Error | LBAD | H/혼합 |
|
||||
| 210401~403 | OCT Deactivated/Disconnect/Error | OCT | H/혼합 |
|
||||
| 210501~503 | Chiller Deactivated/Disconnect/Error | 냉각기 | H/혼합 |
|
||||
| 210600~604 | IO Null/Deactivated/Disconnect/**Leak**(Scanner/Chiller) | IO보드/누액 | H |
|
||||
| 210605~614 | IO MC/BoxTemp/ChillerLeak/Fan1~6 | (현재 대부분 주석) | 혼합 |
|
||||
| 210700~705 | RMS_* 타임아웃/설정 | 레시피 관리 | L 추정 |
|
||||
|
||||
## 6. 리스크 / 개선 포인트
|
||||
|
||||
1. **알람 Latch (최우선)** — `SeqAlarmMonitor`가 set만 하고 조건 정상화 시 `ClearAlarm` 안 함. → **이번 PLC 미연결 사례**가 정확히 이것: 연결 복구돼도 알람이 남아 차단, 수동 ClearAll 필요.
|
||||
2. **개별 Clear 부재** — `ClearAlarm()`이 빈 함수 → 전체 일괄 해제만 가능, 특정 알람만 해제 불가.
|
||||
3. **Unknown=H 취급** — 미정의 코드 활성 시 무조건 H 차단 → 알람 테이블 누락 시 의도치 않은 인터락.
|
||||
4. **시뮬 우회** — `HasAlarmLevelHigh()`가 Simulation이면 false → 시뮬/현장 동작 차이.
|
||||
5. **인터락 일관성 부재** — TeachingRun만 알람 차단, 나머지 시작 시퀀스는 빈 체크. 안전 정책 제각각.
|
||||
6. **Door/EMO 주석** — SeqComponentTeachingRun·UCMainAutoRunViewModel의 Door/EMO 인터락 주석 → 현재 중알람 1종만 차단.
|
||||
|
||||
## 7. 개선 제안 — SeqAlarmMonitor self-clearing
|
||||
|
||||
각 검사 항목을 "조건 나쁨 → Alarm, 조건 좋음 → Clear" 대칭 구조로. 예(개념):
|
||||
|
||||
```csharp
|
||||
// AS-IS
|
||||
if (!_Laser.IsActivated) AlarmManager.Alarm(ALARM_DEVICE_LASER_DEACTIVATED);
|
||||
else { /* clear 없음 → latch */ }
|
||||
|
||||
// TO-BE (self-clearing) — AlarmManager에 개별 ClearAlarm(code) 구현 전제
|
||||
if (!_Laser.IsActivated) AlarmManager.Alarm(ALARM_DEVICE_LASER_DEACTIVATED);
|
||||
else AlarmManager.ClearAlarm(ALARM_DEVICE_LASER_DEACTIVATED);
|
||||
```
|
||||
|
||||
- 전제: `AlarmManager.ClearAlarm(int code)` 실구현 필요(현재 빈 함수). `_AlarmService`에 단건 해제 API 확인 후 연결.
|
||||
- 효과: PLC 재연결 등 조건 복구 시 알람 자동 해제 → 수동 ClearAll 불필요, 인터락 latch 해소.
|
||||
- 범위: AlarmManager(공통) 수정 → **승인 필요 영역**. 적용 전 별도 협의.
|
||||
|
||||
## 8. 부록 — 이번(PLC 미연결) 사례 요약
|
||||
|
||||
- PLC 미연결 → `SeqAlarmMonitor`가 PLC Deactivated/Disconnect(H) set → latch.
|
||||
- `SeqComponentTeachingRun` 시작 → `HasAlarmLevelHigh()` true → 202003, FORCE_ERROR.
|
||||
- 임시조치: `SeqComponentTeachingRun.CheckCondition_Interlock()`의 H알람 블록 주석(테스트용, **원복 예정**) → 레이저 출사 확인.
|
||||
- 관련: [[axis-position-interlock-todo]]
|
||||
@ -1,82 +0,0 @@
|
||||
# MX Component PLC 연결 설정 분석 — 2026-06-19
|
||||
|
||||
> 계기: 현장 PLC 미연결 → 중알람 latch → TeachingRun 인터락 차단.
|
||||
> PLC를 정상 연결하려면 무엇을 PLC측에 요청하고, PC 소스/설정의 어떤 값을 맞춰야 하는지 분석(수정 없음).
|
||||
> 관련: [[110333_alarm_subsystem_analysis]]
|
||||
|
||||
---
|
||||
|
||||
## 1. 연결 메커니즘 (소스 기준)
|
||||
|
||||
- 드라이버: `AuroraDevices/AuroraMXComponent/MXComponent.cs` — Mitsubishi **MX Component** .NET 컨트롤 `ActUtlType64Class` 사용.
|
||||
- PTOP 등록(`EquipmentSetup.cs:158`):
|
||||
`new PLCControllerPTOP(PLCDevice, ePLCNetType.MXComponent, IsSimulation, PLCMMapFileType.CSV, AuroraEnv)`
|
||||
- 연결 흐름:
|
||||
```
|
||||
PLCBase.DoActivate (PLCBase.cs:80)
|
||||
→ NetworkType == MXComponent
|
||||
→ PLCNet.SetInitParams(connConfig.StationNumber) // = ActLogicalStationNumber
|
||||
→ Open() → _actUtlType.ActLogicalStationNumber = N; _actUtlType.Open()
|
||||
```
|
||||
- **핵심 파라미터 = `StationNumber` (논리국번 / Logical Station Number)**.
|
||||
`MXComponent.SetInitParams(int logicalStationNo)` → `_actUtlType.ActLogicalStationNumber = logicalStationNo` (MXComponent.cs:26~29).
|
||||
- Open 결과: `0x00000000` 성공, 그 외 Hex 에러. `0x0180840B`(타임아웃) 시 1회 재시도(MXComponent.cs:48).
|
||||
|
||||
## 2. 맞춰야 하는 값 — PC측
|
||||
|
||||
### (A) MX Component "Communication Setup Utility" (별도 PC 도구)
|
||||
- MX Component 설치 시 함께 깔리는 **통신 설정 유틸리티**에서 **Logical Station Number** 를 등록.
|
||||
- 등록 시 입력: PLC **CPU 기종**, **접속 경로**(CPU 내장 이더넷 / 이더넷 모듈 / CC-Link IE / USB / 시리얼), **PLC IP/포트**, 네트워크/국번.
|
||||
- 이 유틸리티에 등록된 논리국번이 실제 통신 경로를 정의함. (소스는 "번호"만 들고, 실 경로는 유틸리티가 보유)
|
||||
|
||||
### (B) 소스/설정 파일 — `StationNumber` 일치
|
||||
- 정의: `AuroraDevices/AuroraPLC/PLCBase.Config.cs:37`
|
||||
`PLCMXComponentConnConfig.StationNumber` 기본값 **1** (주석: "Logical station No. (By PC Tool: Communication Setting Utility)").
|
||||
- 실제 값은 **디바이스 config 파일에 저장**: `_config_device/PLC.json`
|
||||
```json
|
||||
{ "ConnConfig": { "StationNumber": 22, "UpdateRateMS": 50 } }
|
||||
```
|
||||
(위는 Gun 예시 = 22. PTOP는 현장 값으로 별도 설정 필요)
|
||||
- **편집 경로**: 프로그램 내 PLC 디바이스 설정 화면(`UCPLCDevice`)에서도 수정 가능, 또는 위 JSON 직접 편집.
|
||||
- ⚠️ **(A)의 유틸리티 논리국번 == (B)의 PLC.json StationNumber** 이어야 연결됨. (현장 PLC.json은 repo에 없음 = 현장 전용)
|
||||
|
||||
## 3. PLC측에 요청해야 할 것
|
||||
|
||||
| 항목 | 내용 |
|
||||
|------|------|
|
||||
| CPU 기종 | Q / L / iQ-R / iQ-F 등 정확한 모델 |
|
||||
| 접속 방식 | CPU 내장 이더넷 / 이더넷 모듈 / CC-Link IE / USB / 시리얼 중 무엇 |
|
||||
| 네트워크 정보 | PLC **IP 주소 / 포트**, 서브넷, (CC-Link IE면) 네트워크No·국번 |
|
||||
| MELSOFT 접속 허용 | 이더넷 "MELSOFT 접속" 오픈 설정, 포트 개방(보통 5007/5006 등), 방화벽 |
|
||||
| 국번 구성 | 멀티 CPU/증설 시 대상 station |
|
||||
|
||||
→ 위 정보를 받아 **(A) Communication Setup Utility에 논리국번으로 등록**하고, 그 번호를 **(B) PLC.json StationNumber** 에 동일하게 넣으면 연결.
|
||||
|
||||
## 4. 메모리맵 CSV (연결과 별개, 데이터 정합용)
|
||||
|
||||
- `PLCMMapFileType.CSV` → `PLCBase.MemMapParser.cs`가 아래 8종 CSV를 읽어 디바이스 주소 매핑:
|
||||
- `External/PLC/PLC_DeviceMap_Bit_Input_B_Device.csv` / `..._Output_B_Device`
|
||||
- `..._Bit_Input_M_Device` / `..._Output_M_Device`
|
||||
- `..._Word_Input_W_Device` / `..._Output_W_Device`
|
||||
- `..._Word_Input_D_Device` / `..._Output_D_Device`
|
||||
- 경로: recipePath 기준 `External\PLC\...` (현장 config 폴더).
|
||||
- 연결(Open)과는 무관하지만, 연결 후 **읽고/쓰는 주소가 PLC 실제 디바이스와 맞아야** 알람/인터페이스가 정상. PTOP는 repo에 맵 CSV 없음(현장 전용) → [[plc-devicemap-260617-pending]] 참고.
|
||||
|
||||
## 5. 점검 순서 (현장)
|
||||
|
||||
1. PLC측에서 **CPU기종·접속방식·IP/포트·MELSOFT 접속 허용** 확보
|
||||
2. PC에서 **MX Component Communication Setup Utility** 실행 → 위 정보로 **논리국번**(예: 1) 등록 → 유틸리티 내 "통신 테스트" 통과 확인
|
||||
3. `_config_device/PLC.json` 의 `StationNumber` 를 그 논리국번과 동일하게 설정 (또는 PLC 디바이스 설정 화면)
|
||||
4. 프로그램 재기동 → PLC Activate → 로그 `PLC Open success` 확인 (`Open: 0x00000000`)
|
||||
5. 연결되면 SeqAlarmMonitor의 PLC Deactivated/Disconnect 알람 조건 해소 → (단, latch라 **ClearAll 1회** 필요할 수 있음, [[110333_alarm_subsystem_analysis]] 참고)
|
||||
|
||||
## 6. 참고 — 에러코드 / 매뉴얼
|
||||
|
||||
- Open/Close 반환값은 MX Component 표준 Hex 에러코드. `0x0180840B` = 타임아웃(소스에서 1회 재시도).
|
||||
- 상세 절차·에러표: `Doc/메뉴얼/공통/PLC/21. MX_Component_V4_프로그래밍_매뉴얼.pdf` (Communication Setup Utility / ActUtlType / 에러코드 장 참조).
|
||||
|
||||
## 7. 요약
|
||||
|
||||
- **연결 핵심 = 논리국번 1개**. PC의 MX Component 유틸리티 등록값 ↔ 소스 `PLC.json StationNumber` 일치 + PLC측 이더넷/접속 허용.
|
||||
- PLC.json·맵 CSV는 **현장 전용**(repo 없음) → 현장에서 값 세팅 필요.
|
||||
- 연결되면 PLC 미연결 중알람 해소 → TeachingRun 인터락 정상화 (latch면 ClearAll 1회).
|
||||
@ -1,68 +0,0 @@
|
||||
# AjinIO.ReadDoBit(int) 미구현 분석 — 2026-06-19
|
||||
|
||||
> 계기: `AjinIO.cs`의 `ReadDoBit(int index)`(bool 반환)가 미구현 스텁(`return true`).
|
||||
> DI 패턴 대비 분석 후, 현 상태는 **스텁 유지 + 구현 주석 보존**으로 결정(현장 반영 예정).
|
||||
> 관련: [[110333_alarm_subsystem_analysis]]
|
||||
|
||||
---
|
||||
|
||||
## 1. 현황
|
||||
|
||||
- 파일: `AuroraDevices/AuroraIO/Vendor/AJINEXTEK/AjinIO.cs` (보호 영역, 신중 수정)
|
||||
- DI/DO 오버로드 4종(`IOUnit` 추상):
|
||||
- `int ReadDoBit(int, ref bool)` (469줄) — `CAXD.AxdoReadOutport` 사용, **구현됨**
|
||||
- `int ReadDiBit(int, ref bool)` (483줄) — `CAXD.AxdiReadInport`, 구현됨
|
||||
- `bool ReadDoBit(int)` (496줄) — **미구현 스텁(`return true`)** ← 대상
|
||||
- `bool ReadDiBit(int)` (501줄) — `CAXD.AxdiReadInport`, 구현됨(실패 시 throw)
|
||||
- 즉 **DO 읽기 API(`AxdoReadOutport`)는 같은 파일에서 이미 검증**됨(469줄·`GetDoArray` 399줄). bool 반환 오버로드만 DO쪽이 비어 있었음.
|
||||
|
||||
## 2. 구현안 (DI 패턴 그대로)
|
||||
|
||||
```csharp
|
||||
public override bool ReadDoBit(int index)
|
||||
{
|
||||
uint data = 0;
|
||||
int err = (int)CAXD.AxdoReadOutport(index, ref data);
|
||||
if (err != (int)AXT_FUNC_RESULT.AXT_RT_SUCCESS)
|
||||
throw new Exception(string.Format("ERR_IO_FAIL_TO_GET_BIT;ERROR CODE:{0}", err));
|
||||
return Convert.ToBoolean(data);
|
||||
}
|
||||
```
|
||||
- `ReadDiBit(int)`(501줄)와 완전 동일 구조, API만 `AxdiReadInport → AxdoReadOutport`.
|
||||
|
||||
## 3. 스텁 의존 호출처 분석 (영향 범위)
|
||||
|
||||
`bool ReadDoBit(int)` 호출처 전수:
|
||||
|
||||
| 호출처 | 위치 | 용도 |
|
||||
|--------|------|------|
|
||||
| `UCInformationPanelViewModel.cs` | 46, 53, 82, 115, 132 (5곳) | ModeKeySolOn / SafetyDoorRelease **상태 표시** |
|
||||
|
||||
- 5곳 모두 **`ePDOAddress`(PAIX 주소)** 사용 → 실제 **PAIX 보드에서 실행**.
|
||||
- **PAIX의 `ReadDoBit(int)`는 정상 구현**(PAIXIO.cs:288, `GetDoArray`로 읽음) → 이 호출처는 이미 정상 동작.
|
||||
- `(int, ref bool)` 오버로드 호출(`UCTestDeviceViewModel.cs:264`)은 Ajin도 구현돼 있어 무관.
|
||||
- **결론: Ajin 스텁(`return true`)에 실제 의존하는 코드는 사실상 없음.** 영향은 "Ajin 보드 장비에서 위 5개 호출이 도는 경우"로 한정되며, 그 경우 오히려 항상 true가 오표시였음(상태 표시용, 안전제어 아님 → 위험 낮음).
|
||||
|
||||
## 4. 현재 결정 상태 (스텁 유지 + 구현 주석 보존)
|
||||
|
||||
```csharp
|
||||
public override bool ReadDoBit(int index)
|
||||
{
|
||||
//현재 사용하지 않아서 추후 구현
|
||||
return true;
|
||||
|
||||
// [추후 구현] return true 스텁 의존 코드 확인 후 아래로 교체 (ReadDiBit(int) 패턴)
|
||||
//uint data = 0;
|
||||
//int err = (int)CAXD.AxdoReadOutport(index, ref data);
|
||||
//if (err != (int)AXT_FUNC_RESULT.AXT_RT_SUCCESS)
|
||||
// throw new Exception(...);
|
||||
//return Convert.ToBoolean(data);
|
||||
}
|
||||
```
|
||||
- 동작 변화 없음(`return true` 유지) → 현장 안전. 구현은 주석으로 보존해 추후 활성화 용이.
|
||||
- 빌드 산출물: **AuroraIO.dll**.
|
||||
|
||||
## 5. 후속 (활성화 조건)
|
||||
|
||||
- Ajin 보드 장비에서 DO 상태 표시 정확성이 필요해질 때, 주석 해제 + 위 5개 호출처 회귀 확인.
|
||||
- 활성화 시 실패 처리(throw) 영향 검토: `ReadDiBit(int)`와 동일 정책이라 일관성은 확보됨.
|
||||
@ -1,59 +0,0 @@
|
||||
# 가이드빔(Guide Beam) 제어 경로 분석 — TruPulse — 2026-06-19
|
||||
|
||||
> 계기: 레시피 Guide Beam 버튼/상태가 현장에서 동작하지 않음. IO(DO)→Laser 순으로 추적.
|
||||
> 결론: 가이드빔은 **Laser(TruPulse) 디바이스 기능**이며, 제어 콜백 **`ExtPilotOnOff`가 미구현(미할당)**.
|
||||
> 관련: [[110333_alarm_subsystem_analysis]]
|
||||
|
||||
---
|
||||
|
||||
## 1. 잘못된 경로였던 IO(DO 17) 시도 요약
|
||||
|
||||
- 레시피 ViewModel(`UCScannerObjectTeachingControlBoxViewModel.cs`)에서 `_IODevice`(메인 IO_Board=PAIX_PTOP)의
|
||||
**DO 17(EX_Red_Control)** 을 read/write 하도록 수정 → 상태 표시(읽기)는 동작 확인.
|
||||
- 그러나 **물리적 가이드빔(적색광)은 출력 안 됨**.
|
||||
- 현장 확인: 번들(DBW-MC Laser SW)의 `RedLight Opened/Closed` 이벤트는 **번들의 RedClosed 버튼 수동 조작** 결과로,
|
||||
우리 DO 17과 무관. `Mod1_IO:000100↔000000` 비트만 DO 17과 일치.
|
||||
- → **DO 17(IO) 경로는 가이드빔 제어가 아님.** (메인 IO_Board와 레이저 가이드빔 입력은 별개)
|
||||
- 현 상태: 원복하지 않고 **주석 토글로 필요시 전환**(도연님 운용). 기존 `_Laser` 코드는 주석 보존됨.
|
||||
|
||||
## 2. 실제 경로 = Laser(TruPulse) 디바이스
|
||||
|
||||
레이저 타입 = **TruPulse** (`eLaserType.TruPulse`, `Laser.cs:70`).
|
||||
|
||||
```
|
||||
_Laser.PilotLaserOn() (베이스 Laser, Laser.cs)
|
||||
└ IsSimul 이면 return E1.OK (no-op) ← 현재 시뮬이라 여기서 멈춤
|
||||
└ 실모드: TruPulse.PilotLaserOn() (TruPulse.cs:817)
|
||||
└ return PilotOnOffFunc(true)
|
||||
└ (Laser.cs:74) core.PilotOnOffFunc = (on) => ExtPilotOnOff(on)
|
||||
└ ExtPilotOnOff(true) ← ★ 레이저 IO 보드 write 의도 콜백
|
||||
```
|
||||
|
||||
상태 읽기:
|
||||
```
|
||||
GetPilotLaserStatus() → PilotLaserEnable ← (TruPulse.cs:174) Di2 & (1<<9)
|
||||
(QueryStatusHwInterface 로 TruPulse 컨트롤러에서 직접 읽음)
|
||||
```
|
||||
|
||||
## 3. ★ 핵심 문제: `ExtPilotOnOff` 미구현(미할당)
|
||||
|
||||
- `Laser.cs` 27~29줄에 `ExtLaserEnable` / `ExtLaserDisable` / `ExtPilotOnOff` **선언만** 존재.
|
||||
- 전체 소스에 **`ExtPilotOnOff = ...` 할당부 없음**(검색 0건). `updateCore` 구독(`UCTruPulseManualViewModel`)도 core 참조만 받고 콜백 미주입.
|
||||
- 결과:
|
||||
- **시뮬(현재)**: 베이스에서 no-op → 빔 안 나옴, 상태 항상 true. (정상)
|
||||
- **실모드**: `ExtPilotOnOff(true)` 호출 시 **null → NullReferenceException** 위험.
|
||||
- → "레이저 IO 보드로 가이드빔 제어"는 **설계 의도이나 구현 미완(TODO)**.
|
||||
|
||||
## 4. 결론 / TODO
|
||||
|
||||
| 구간 | 상태 |
|
||||
|------|------|
|
||||
| 가이드빔 제어 의도 | TruPulse → `ExtPilotOnOff` → 레이저 IO 보드 DO |
|
||||
| 실제 구현 | ❌ 미구현 (`ExtPilotOnOff` 미할당) |
|
||||
| 현재 운영 | 시뮬 → no-op (물리 빔 안 나오는 게 정상) |
|
||||
| 레시피 DO 17(`_IODevice`) 변경 | 잘못된 경로(메인 IO_Board), 원복 안 함 — 주석 토글로 운용 |
|
||||
|
||||
추후 실제 가이드빔 구현 시:
|
||||
- `_Laser.ExtPilotOnOff = (on) => { 레이저IO보드._iOUnit.WriteDoBit(<가이드빔 DO>, on); return 0; };` 구현
|
||||
- "레이저 IO 보드" 디바이스/DO 주소 확정 (메인 PAIX와 별개 여부)
|
||||
- Laser 디바이스 **비시뮬 + Activated**
|
||||
@ -1,155 +0,0 @@
|
||||
# U-Frame 가접 추가 → Recipe 신규 시 SeqAutoRunPTOP.cs 작업 구간 분석
|
||||
|
||||
- 작성일: 2026-06-20
|
||||
- 대상: `Machines/ILSOS_PrismaticRD_PTOP/Sequences/SeqAutoRunPTOP.cs`
|
||||
- 분류: 사전 분석 (소스 미수정)
|
||||
- 관련 메모: PLC DeviceMap 260617 pending, Scout Field 저장 위치
|
||||
|
||||
---
|
||||
|
||||
## 1. 배경 (현장 상황)
|
||||
|
||||
- 어제 U-Frame 용접 시 **밀착(접촉) 불량**으로 용접 품질 미달.
|
||||
- 결론: **가접(tack weld)을 추가**하여 밀착 확보 후 본 용접.
|
||||
- 현재 샘플 1개에 **테이프**로 임시 고정하여 검증 중.
|
||||
- SW 측에서는 결국 **Recipe 1개 추가**가 예상됨 (가접 포함된 신규 레시피).
|
||||
|
||||
### 가접 정의 (현장 확인, 2026-06-20)
|
||||
|
||||
> **가접 = 본 용접(본접) 전에, 부품이 떨어지지 않도록 Dot 또는 짧은 Line을 미리 출사하여
|
||||
> 미리 붙여 고정(pre-fix)하는 작업.**
|
||||
|
||||
즉 가접은 **본접 이전에 선행되는 별도 발진 동작**이다.
|
||||
"미리 붙여넣는다"는 성격상 본 용접 패스와 **시간/순서상 선행**되어야 하므로,
|
||||
아래 4-4의 **[Case B] 별도 선행 패스** 시나리오에 해당할 가능성이 높다.
|
||||
(다만, 가접 Dot/Line을 본 용접 리스트 내 **앞쪽 순서 오브젝트**로 넣어 한 리스트로 처리하면
|
||||
Case A로도 구현 가능 — 가접이 본접과 동일 파라미터/연속 발진으로 충분한지에 따라 갈린다.)
|
||||
|
||||
> 본 문서는 "레시피가 하나 더 추가될 때 SeqAutoRunPTOP 시퀀스의 어느 노드에 손을 대야 하는가"를
|
||||
> 소스 수정 없이 분석한 것이다.
|
||||
|
||||
---
|
||||
|
||||
## 2. 핵심 결론 (요약)
|
||||
|
||||
| 항목 | 소스 수정 필요? | 비고 |
|
||||
|------|----------------|------|
|
||||
| **레시피 선택/전환** (CheckRecipeNo / CheckRecipeNoComp) | **불필요** | 완전 데이터 구동 (`.Id` 직접 1:1 조회, 하드코딩 없음) |
|
||||
| **페이지 처리** (CheckPageNo / CheckPageNoComp) | **불필요** | 활성 레시피 레이어 수로 가변 검증 (260618 반영됨) |
|
||||
| **용접 리스트 업로드** (SetUploadWeldingList) | **조건부** | 가접이 동일 리스트 내 추가 Line이면 불필요 |
|
||||
| **용접 실행** (ExecuteWelding) | **조건부 (핵심 분기점)** | 가접을 **별도 패스/리스트**로 돌려야 하면 여기 수정 |
|
||||
|
||||
**즉, 단순히 "레시피를 추가"하는 것 자체는 소스 수정이 거의 필요 없다.**
|
||||
**진짜 판단 포인트는 "가접을 어떻게 실행하느냐"이며, 그 작업 위치는 `ExecuteWelding` 노드다.**
|
||||
|
||||
---
|
||||
|
||||
## 3. 시퀀스 흐름 복습
|
||||
|
||||
```
|
||||
Enter → CheckInitCondition → CheckRecipeNo → (CheckRecipeNoComp) → CheckPageNo → CheckPageNoComp
|
||||
→ SetUploadWeldingList(Seq) → UploadWeldingList(서브) → GetResult
|
||||
→ WeldingStartReadBit → WaitWeldingStart → ExecuteWelding → CheckCycleStop → ...
|
||||
CheckCycleStop ──루프백──> CheckRecipeNo (매 사이클 레시피부터 재확인)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 노드별 상세 분석
|
||||
|
||||
### 4-1. 레시피 선택은 이미 데이터 구동 → 추가만으로 동작
|
||||
|
||||
`CheckRecipeNoComp` (라인 319~393)에서 PLC가 보낸 `PLC_RECIPE_NO`로 레시피를 1:1 조회한다.
|
||||
|
||||
```csharp
|
||||
var recipe = _RecipeManager.Recipes().FirstOrDefault(x => x.Id == plcRecipeNo);
|
||||
```
|
||||
|
||||
- **하드코딩 없음** (주석에도 "하드코딩 금지" 명시, 라인 343).
|
||||
- 따라서 신규 레시피를 RecipeManager에 등록하고, PLC가 그 번호를 `PLC_RECIPE_NO`로 송신하면
|
||||
**시퀀스 소스 수정 없이** 그대로 선택·활성화된다.
|
||||
- 단, **PLC 측에서 신규 레시피 번호를 매핑/송신**해야 한다.
|
||||
(라인 61/119 주석의 번호 체계: 11/21/22/31/32 → 신규 번호 합의 필요. → PLC DeviceMap pending 메모와 연계)
|
||||
|
||||
> ✅ 결론: 레시피 선택 로직(CheckRecipeNo/Comp)은 **건드릴 필요 없음.**
|
||||
|
||||
### 4-2. 페이지 검증도 가변 → 페이지 수가 달라도 OK
|
||||
|
||||
`CheckPageNoComp` (라인 489~491):
|
||||
|
||||
```csharp
|
||||
int recipePageCount = _ScannerCanvasUserCtrl.Model.Layers.Count();
|
||||
if (plcPageNo > recipePageCount || plcPageNo < 1) { ... 에러 ... }
|
||||
```
|
||||
|
||||
- 활성 레시피의 레이어(=페이지) 수로 동적 검증. 신규 레시피가 페이지 수가 다르더라도 자동 대응.
|
||||
|
||||
> ✅ 결론: 페이지 노드도 **건드릴 필요 없음.**
|
||||
|
||||
### 4-3. 용접 리스트 업로드 — 가접이 "추가 Line"이면 자동 포함
|
||||
|
||||
`SetUploadWeldingList_SeqParams` (라인 552~608)는 현재 페이지 레이어의 오브젝트를 그대로 업로드한다.
|
||||
|
||||
```csharp
|
||||
var layer = _ScannerCanvasUserCtrl.Model.Layers[_CurrentPageNo];
|
||||
_SelectedObjectList = layer.Objects; // Group → SubObjects(Line) 들이 업로드 대상
|
||||
```
|
||||
|
||||
- **가접 = 해당 레이어 티칭에 Line 오브젝트를 추가**하는 형태라면,
|
||||
업로드 로직이 자동으로 가접 Line까지 포함한다. → **소스 수정 불필요.**
|
||||
|
||||
> ⚠️ 단, 가접 Line의 레이저 파라미터(파워/속도/시간 등)가 본 용접과 달라야 한다면,
|
||||
> 그것은 **레시피/티칭 데이터(파라미터)** 영역이지 시퀀스 코드 영역이 아니다.
|
||||
|
||||
### 4-4. ★ 용접 실행 — 진짜 작업 분기점 (ExecuteWelding, 라인 720~855)
|
||||
|
||||
현재는 **단일 리스트 1회 실행** 구조다:
|
||||
|
||||
```csharp
|
||||
_IO...WriteDoBit(CoreLaser_Control, true); // Gate ON
|
||||
_IO...WriteDoBit(RingLaser_Control, true);
|
||||
Thread.Sleep(laserEmissionGateDelayMs); // 15ms
|
||||
_Scanner.ExecuteList(_WeldingScannerListNo); // ← LIST1 단일 실행
|
||||
_Scanner.WaitForListTaskCompleted(1000);
|
||||
_IO...WriteDoBit(CoreLaser_Control, false); // Gate OFF
|
||||
_IO...WriteDoBit(RingLaser_Control, false);
|
||||
```
|
||||
|
||||
가접 처리 방식에 따라 두 갈래로 나뉜다.
|
||||
|
||||
**[Case A] 가접 = 본 용접 리스트에 Dot/짧은 Line을 앞쪽 순서로 함께 발진**
|
||||
- 가접 Dot/Line을 티칭 시 **본접보다 앞 순서**의 오브젝트로 추가하면, 스캐너가 순서대로 발진하므로
|
||||
결과적으로 "먼저 붙이고 → 본접"이 한 리스트로 처리됨. **ExecuteWelding 수정 불필요.**
|
||||
- 단, 가접과 본접이 **동일 레이저 파라미터/연속 발진(같은 Gate 구간)** 으로 충분해야 성립.
|
||||
- 가장 단순. 레시피/티칭 데이터만으로 해결.
|
||||
|
||||
**[Case B] 가접을 별도 선행 패스로 분리 (가접 Dot/짧은 Line 먼저 → 본 용접) ★ 이번 케이스 유력**
|
||||
- 가접이 본접과 **다른 파라미터**(약하게/짧게)거나, **별도 Gate 구간/별도 리스트**가 필요한 경우.
|
||||
- 별도 리스트(예: LIST2)나 별도 파라미터/Gate 타이밍이 필요.
|
||||
- → **이 `ExecuteWelding` 노드가 작업 위치.**
|
||||
- 고려 사항:
|
||||
1. 가접용 리스트 번호 추가 (`eListNo`), 업로드 단계(4-3)에서 가접 리스트도 업로드.
|
||||
2. ExecuteWelding 내에서 **가접 ExecuteList → 완료 대기 → 본 용접 ExecuteList** 순차 실행.
|
||||
3. 각 패스마다 Gate ON/OFF, `WaitForListTaskCompleted`, CorrectionTable 처리 반복 여부 결정.
|
||||
4. TactTime 로그/`_WeldingSpanTime` 측정 구간 재정의.
|
||||
- 또는 노드를 분리(예: `SEQ_EXECUTE_TACK` → `SEQ_EXECUTE_WELDING`)하여 Builder 흐름(라인 153~177)에 한 단계 추가하는 방안도 가능.
|
||||
|
||||
> ★ 결론: 만약 가접을 별도 동작으로 돌려야 한다면 **ExecuteWelding(라인 720)** 이 수정 핵심 구간이며,
|
||||
> 경우에 따라 Builder의 Flow에 가접 전용 노드 1개를 끼워 넣는 설계가 필요하다.
|
||||
|
||||
---
|
||||
|
||||
## 5. 의사결정 체크리스트 (PLC/현장 확인 후 결정)
|
||||
|
||||
- [ ] 가접을 **별도 발진 패스**로 할 것인가, **본 용접 리스트에 합칠** 것인가? (Case A vs B)
|
||||
- [ ] 가접용 레이저 파라미터(파워/속도/체류시간)가 본 용접과 다른가?
|
||||
- [ ] 신규 레시피 번호(`PLC_RECIPE_NO`) 체계는? PLC 측 매핑 완료되었는가? (→ PLC DeviceMap pending)
|
||||
- [ ] 가접 레이어/페이지 구성은 기존 레시피와 동일 구조인가?
|
||||
|
||||
---
|
||||
|
||||
## 6. 한 줄 요약
|
||||
|
||||
> **레시피 추가 자체는 데이터 구동이라 시퀀스 소스 수정 불필요.**
|
||||
> **단, 가접을 "별도 동작"으로 실행해야 한다면 `ExecuteWelding` 노드(라인 720)가 유일한 작업 구간이며,
|
||||
> 필요 시 Builder Flow에 가접 전용 노드를 추가한다.**
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user