docs: 작업일지 - PLCAddress 모호참조/IO null 분석 및 수정 기록

This commit is contained in:
노도연 2026-06-18 20:32:35 +09:00
parent a312e4ec8a
commit 0ca485eab2

View File

@ -171,3 +171,132 @@
- 프로그램 시작 시 Manual - Laser Power Control의 Power 파라미터 초기값 변경: **Percent 10 → 0, Watt 300 → 0**.
- 위치: `UCScannerLaserControlViewModel.InitVariable()` (`LaserPower1Percent`, `LaserPower1Watt`).
- 커밋 `5eebe96`.
## 19:44
### SeqAutoRunPTOP.cs — PLCAddress 애매모호한 참조(CS0104) 분석 (퇴근 후 작업용 / 소스 무수정·diff 프리뷰만)
> 요청: `docs/260618_18_40_이후에_확인할_소스.txt`
> ① 애매모호한 참조 ② PLCAddress error 해결 ③ 시퀀스 타이밍차트 ④ 분석/정리. **바로 수정 X, diff 프리뷰만.**
**■ 근본 원인 (한 줄): `using static` 두 개가 같은 이름의 enum 4종을 동시에 끌어와 충돌.**
- `SeqAutoRunPTOP.cs` 상단:
- L22 `using static ILSOS_PrismaticRD_PTOP.Device.PLCControllerPTOP;`
- L23 `using static WeldingCommon.Devices.PLCController;`
- 그런데 `eBitInput / eBitOutput / eWordInput / eWordOutput` **4종이 두 클래스에 똑같은 이름으로 각각 정의**되어 있음:
- `WeldingCommon.Devices.PLCController` (base) — `PLCController.Address.cs`
- `ILSOS_PrismaticRD_PTOP.Device.PLCControllerPTOP : PLCController` (파생) — `Device/PLC/PLCController.Address.cs`
- 두 정의는 **값/멤버가 완전히 동일**(260617 "PLCController.Address 통일" 커밋으로 PTOP에 복제됨).
- 결과: 코드에서 `eBitOutput.PC_AUTO_STATUS`처럼 **수식어 없이** 쓰면 컴파일러가 둘 중 무엇인지 못 정함 → **CS0104 '모호한 참조'**. 파일 내 `eBitInput/eBitOutput/eWordInput/eWordOutput`을 쓰는 **모든 줄이 동일 에러**.
**■ 헷갈리면 안 되는 점 — 같이 쓰는 다른 enum들은 충돌 아님 (그대로 둘 것)**
- `eCommonBitInput/eCommonBitOutput/eCommonWordInput/eCommonWordOutput` → **프레임워크(AuroraPLC) 공용 enum**. `using AuroraPLC;`로 들어옴. base `PLCController.Logic.cs`의 `WriteBit(eCommonBitOutput …)` 등이 이걸 받음. **`using static`와 무관 → 충돌 없음.** (`RestoreDeviceStatus`가 이걸 사용. `PC_RECIPE_CHANGE_COMPLETE`는 15:30 작업에서 공용 enum에 동기화 완료.)
- `eADOAddress` → `AjinIO.IOModuleInfo` (L21 `using static …AjinIO.IOModuleInfo;`). 충돌 없음.
- `ePrismaticDOAddress` → 이 파일 안에서 로컬 정의. 충돌 없음.
**■ 왜 `(int)` 캐스트한 줄은 멀쩡해 보였나 (중요 포인트)**
- PTOP는 자기 enum용 타입드 오버로드를 따로 가짐 — `Device/PLC/PLCController.Logic.cs`:
- `ReadBit(eBitInput)`, `ReadOutBit(eBitOutput)`, `WriteBit(eBitOutput,…)`, `ReadWord(eWordInput)`, `WriteWord(eWordOutput,…)`, `WriteDWord(eWordOutput,…)`, `ReadWords(eWordInput,eWordInput)`.
- 즉 **타입 자체는 PTOP enum이 맞는데**, `using static` 중복 탓에 *이름 해석 단계*에서 먼저 막힌다. 그래서 `(int)eBitOutput.X`(캐스트)든 `eBitOutput.X`(논캐스트)든 **둘 다 CS0104**. (캐스트 유무가 원인이 아님 — 원인은 오로지 이름 모호성.)
**■ 해결안 (가장 단순·안전) — L23 한 줄 제거**
```diff
using static AuroraIO.AJINEXTEK.AjinIO.IOModuleInfo;
using static ILSOS_PrismaticRD_PTOP.Device.PLCControllerPTOP;
- using static WeldingCommon.Devices.PLCController;
using Application = System.Windows.Application;
```
- 근거: 이 파일의 `_PLC`는 `PLCControllerPTOP` 타입이고, 4종 enum은 PTOP 정의가 base와 **값까지 동일**하므로 PTOP 쪽만 남기면 전부 정상 해석됨. `eCommon*`는 `using AuroraPLC`로 유지되므로 `RestoreDeviceStatus`도 안전.
- **부작용 점검 필요(퇴근 후 확인)**: L23를 지웠을 때 base `PLCController`의 *static 멤버/상수*를 수식어 없이 쓰는 곳이 있는지. → 현재 파일에서 base에서만 오는 비수식 심볼은 안 보임(전부 PTOP/AuroraPLC/로컬). VS Rebuild로 최종 검증.
**■ 대안 (L23를 꼭 남겨야 한다면)**
- 파일 상단에 별칭으로 못박기: `using eBitOutput = ILSOS_PrismaticRD_PTOP.Device.PLCControllerPTOP.eBitOutput;` (4종 각각). → 장황함. 1안(L23 제거) 권장.
- 더 근본책: PTOP `PLCController.Address.cs`의 **중복 enum 정의 자체를 삭제**하고 base 것을 상속해 쓰기. 단 PTOP Logic의 `ReadBit(eBitInput)` 등 오버로드 시그니처가 base enum을 받도록 바꿔야 해서 변경 범위 큼. **지금은 1안으로 끊고, 통일은 별도 과제**( [[plc-devicemap-260617-pending]] 와 함께 ).
**■ 적용 전 확인 체크리스트 (퇴근 후)**
1. L23 제거 후 VS **Rebuild** (이 파일뿐 아니라 같은 패턴 쓰는 `SeqAutoRunPrismatic.cs`, `SeqTestRun.cs`, `SeqWaitWeldOrChangePage.cs` 동반 점검).
2. `eCommon*` 사용부(`RestoreDeviceStatus`)가 그대로 빌드되는지.
3. 런타임 동작 변화 없음(이름 해석만 바뀜) — 단 빌드 통과 자체가 목적.
---
### SeqAutoRunPTOP 시퀀스 타이밍 차트 (1 사이클)
플로우(Builder): `Enter → CheckInitCondition → CheckRecipeNo →(REQ ON) CheckRecipeNoComp / (REQ OFF) ─┐ → CheckPageNo → CheckPageNoComp → SetUploadWeldingList → [Sub]UploadWeldingList → GetResult → WeldingStartReadBit → WaitWeldingStart → ExecuteWelding → CheckCycleStop →(loop) CheckRecipeNo`
저장 경로: `… → SaveResultData → WriteCompletionPLCBit → Complete → (다시 Enter)`
```
PC(=우리) PLC 설명
│ ◀── RECIPE_CHANGE_REQ(0x09) ── [CheckRecipeNo] 논블로킹 1회 peek
│ OFF → 현 Recipe 유지하고 PageNo로 점프
│ (REQ ON 시에만 아래 Comp 진입)
│ read PLC_RECIPE_NO(D, idx2) ×3 [CheckRecipeNoComp] 200ms×3 검증
│ ActivateRecipe + 반영 폴링(10ms) .Id 1:1 조회 후 활성, 일치까지 대기
│ ── PC_RECIPE_NO 에코 ──▶
│ ── PC_RECIPE_CHANGE_COMPLETE=false ─▶ (Page 미러형: COMPLETE 비트만)
│
│ ◀── PAGE_CHANGE_REQ(0x08) ON 대기 ── [CheckPageNo] ON까지 무한대기(10ms 폴링, 60s마다 로그)
│ read PLC_PAGE_NO ×3 (200ms) [CheckPageNoComp] 3회 검증
│ 페이지 상한 = Layers.Count()로 가변검증 (1..N, 범위밖이면 return null)
│ CellId/LotId read, _CurrentPageNo=Page-1
│ ── PC_PAGE_NO 에코 ──▶
│ ── PC_PAGE_CHANGE_COMPLETE=false ─▶
│ EVENT_AUTO_RUN_UPDATE_PAGENUM 발행
│
│ [SetUploadWeldingList] _CurrentPageNo로 Layer 선택 → 용접리스트 파라미터
│ [Sub:UploadWeldingList] 스캐너 리스트 업로드
│ [GetResult] Success=false면 return null(중단)
│
│ ◀── WELD_READY_REQ(0x10) ON 대기 ── [WeldingStartReadBit] ON까지 무한대기
│ ── (page1) PC_WELD_READY_ACK=1, BUSY=1 ─▶ [WaitWeldingStart] 200ms 후 COMPLETE=0
│ ── (page2) PC_WELD_P_READY_REQ=1, P_BUSY=1 ─▶ 〃 P_COMP_ACK=0
│
│ ┌───────────── [ExecuteWelding] ─────────────
│ IO DO9(Core)=1, DO13(Ring)=1 (Laser Gate ON)
│ ── Gate ON Delay 15ms (매뉴얼 ≥10ms) ──
│ Scanner.ExecuteList(LIST1)
│ Scanner.WaitForListTaskCompleted(1000ms)
│ IO DO9=0, DO13=0 (Laser Gate OFF, 완료 즉시)
│ JumpAbs(0,0) + SelectCorrectionTable(1) 원복
│ ── (page1) READY_ACK=0 → BUSY=0 → COMPLETE=1 (각 5ms) ─▶
│ ── (page2) P_READY_REQ=0 → P_BUSY=0 → P_COMP_ACK=1 ─▶
│ └─ TactTime 로그(예: ~285ms)
│
│ [CheckCycleStop] → 항상 CheckRecipeNo로 루프백 (정지조건 미구현 TODO)
│ ※ 정상 종료 경로(Save→WriteCompletionPLCBit→Complete)는
│ 현재 CheckCycleStop이 무조건 루프백이라 도달 안 함 — 흐름 확인 필요.
```
**타이밍차트에서 같이 눈에 띈 것 (참고, 이번 에러와 별개):**
- `WaitWeldingStart`/`ExecuteWelding`의 page 분기 비트 네이밍이 음/양극에서 엇갈려 보임(`PC_WELD_P_READY_REQ`를 ACK 의미로 ON). PLC 사양과 1:1 재확인 권장.
- `CheckCycleStop`이 무조건 `SEQ_CHECK_RECIPENO` 반환 → `SaveResultData~Complete` 정상경로 미도달. 의도된 건지 확인 필요(카운트 업데이트/결과저장이 안 탈 수 있음).
- 위 2건은 **이번 PLCAddress 에러와 무관** — 별도 검토 항목으로만 메모.
### [적용] L23 제거 + 빌드 검증
- **적용함**: `SeqAutoRunPTOP.cs`에서 `using static WeldingCommon.Devices.PLCController;`(L23) 제거. (1안 그대로)
- 빌드 검증(MSBuild CLI, x64-Debug):
- **PTOP standalone 빌드 → CoreCompile 통과** (CS0104 사라짐, post-build `xcopy`만 `SolutionDir`=`*Undefined*`로 실패 — 산출물은 생성됨). ⇒ `SeqAutoRunPTOP.cs` 정상 컴파일 확인.
- SolutionDir 지정 2차 빌드에서 **WeldingCommon `_wpftmp`(WPF 임시컴파일) 패스가 `eCommonBitInput/Output/WordInput/WordOutput`을 CS0246**으로 못 찾음 → 이 enum들은 레포 소스에 정의 없음(External/Aurora 프레임워크 어셈블리 타입). **내 수정과 무관**(WeldingCommon은 PTOP 파일 미참조), CLI 환경/참조 이슈로 판단.
- **최종 검증은 VS Rebuild 권장**(Aurora 바이너리가 `_out\x64-Debug`에 정상 배치된 상태). 동일 패턴 파일(`SeqAutoRunPrismatic.cs` 등)은 이번에 미수정 — 추후 동반 점검.
### [정정·최종] 진짜 근본 원인 = HEAD 커밋 `89e9a02 "PLCController.Address 통일"`의 미완성 리네임
- 앞서 CS0246(`eCommon*` 없음)을 "CLI 환경 이슈"로 본 것은 **오판**. VS에서도 동일 에러. 추적 결과 **커밋 `89e9a02`가 base `WeldingCommon/…/PLCController.Address.cs`의 enum 선언만 리네임**한 게 원인:
- `eCommonBitInput→eBitInput`, `eCommonBitOutput→eBitOutput`, `eCommonWordInput→eWordInput`, `eCommonWordOutput→eWordOutput`
- **소비처(~10파일·60+곳)는 여전히 `eCommon*`** (base `PLCController.Logic.cs`의 타입드 API, `SeqExecutePlcBitInterface`, `RMSHandler`, `AlarmManager`, `AlarmMonitoring`, PTOP `SeqTestRun/SeqWaitWeldOrChangePage/SeqAutoRunPrismatic/SeqAutoRunPTOP`) → 전부 CS0246.
- 덤으로, base가 `eBitOutput`을 갖게 되며 PTOP `eBitOutput`과 `using static` 2개에서 충돌 → 처음 보고된 **CS0104**까지 이 커밋이 유발. (도연님 메모: PTOP와 통일하려 복붙하다 base 표기까지 덮인 것.)
- **해결(채택: 커밋 되돌리기)**:
- `git checkout 89e9a02^ -- WeldingComponents/WeldingCommon/Devices/PLC/PLCController.Address.cs` (base를 `eCommon*`로 원복, 워킹트리만)
- `SeqAutoRunPTOP.cs` **L23 `using static WeldingCommon.Devices.PLCController;` 복구**(=내 임시수정 원복). `RestoreDeviceStatus`의 `eCommonBitOutput`이 이걸 통해 해석됨.
- 구조 환원: **base=`eCommon*`, PTOP=`eBit*/eWord*`** (이름이 달라 `using static` 2개 공존해도 충돌 없음).
- **빌드 검증**: `ILSOS_PrismaticRD_PTOP.csproj` (Debug|x64, SolutionDir 지정) **MSBuild EXITCODE=0, error 0건**. WeldingCommon 포함 정상 컴파일 확인.
- 변경 파일: `PLCController.Address.cs`(원복) 1개뿐. `SeqAutoRunPTOP.cs`는 HEAD와 동일(diff 없음). **미커밋** — 도연님 커밋 권장.
- 후속: "Address 통일"을 정말 하려면 base 리네임 + 소비처 60+곳 일괄 교체 + PTOP 중복 enum 정리까지 **한 번에** 가야 함(별도 과제). 지금은 되돌려 빌드 정상화 우선.