diff --git a/docs/작업일지/2026_06_18.md b/docs/작업일지/2026_06_18.md index 43b007e..4f41a46 100644 --- a/docs/작업일지/2026_06_18.md +++ b/docs/작업일지/2026_06_18.md @@ -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 정리까지 **한 번에** 가야 함(별도 과제). 지금은 되돌려 빌드 정상화 우선.