@@ -0,0 +1,16 @@
|
||||
Server
|
||||
|
||||
config -> TRANS4 -> startup -> database.properties
|
||||
interface.properties ( environment, server.domain.(mcs).host 개인꺼로 바꿔주기 )
|
||||
( 위 두 파일 설정만 맞춰주면 됨 )
|
||||
|
||||
UI
|
||||
TM18_Client -> plugins -> config.TM18 -> ui.properties
|
||||
|
||||
|
||||
UI_Listener -> MCS 입장에서의 Client들이 보내는 TIB 메시지를 받음
|
||||
Host_Listener -> '' Host가 보내는 TIB 메시지를 받음
|
||||
|
||||
|
||||
MCS에서 JOB은 출발지, 최종목적지에 대한 정보를 의미
|
||||
|
||||
@@ -0,0 +1,17 @@
|
||||
IB: OHT OHS 등
|
||||
|
||||
SEM?
|
||||
Stocker SEM 이러면 뭔가 Stocker 동작 규약? 그런 뜻인가 봄
|
||||
|
||||
TSC??
|
||||
Transfer SC
|
||||
|
||||
SC? System Control? <---> Semi Conductor?
|
||||
|
||||
OP: Stocker Crane이 닿을 수 있는 최종 ==Out Port==
|
||||
LP: OHT, OHS에 붙어있는 Port ==Loading Port==
|
||||
|
||||
OP <-> LP는 알아서 움직일 수 있다.
|
||||
|
||||
EAP가 반도체설비 대신 물류관련(IB, SC) 설비를 관리하고,
|
||||
반송관련 Order를 내릴 수 있어야 하기 때문에 별도의 DB를 가진다고 생각하면 될 것 같음.
|
||||
@@ -0,0 +1,8 @@
|
||||
|
||||
Area
|
||||
└
|
||||
FACTORY -> AREA -> <U>SHOP</U> -> BAY
|
||||
(Hynix) 잘안씀 많이씀
|
||||
|
||||
INTERSTORAGE 에서 SHELF를 뺀 것 (LIFTER)
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
|
||||
MCS가 TIB으로 누구랑 연결되어 있는지 확인 필요 (이전 교육내용중에 있었음, 교육자료 보면 될듯)
|
||||
|
||||
AbstractMessage
|
||||
└TransferMessage
|
||||
└ TransportMessage
|
||||
둘 다 반송관련 메시지임. 개별 스토커내부의 반송명령에는 TransportMessage를 쓴다.
|
||||
모든 반송명령 메시지는 TransferMessage (혹은 그 자식 클래스)로 처리한다.
|
||||
이 둘의 구분은 명확하지 않다. 이부분에 대해서는 명확하게 확정해주는게 필요하다.
|
||||
|
||||
Heuristic Delay는 별도의 Daemon Server를 통해 주기적으로 계산한다.
|
||||
(하지만 이 기능 자체를 잘 안쓴다고 함)
|
||||
|
||||
alternate, recovery 두가지의 대체반송이 있음
|
||||
alternate는 job이 있고 recovery는 별도의 job이 없다
|
||||
|
||||
@@ -0,0 +1,35 @@
|
||||
SEM 문서를 기반으로 개발진행
|
||||
SEMI SPEC 문서랑 굉장히 비슷해보임
|
||||
|
||||
MCS가 close connection 하는것과
|
||||
UI에서 offline 처리하는 것은 다르다. (S1F15)
|
||||
|
||||
Carrier cancel은 동작중일때는 캔슬불가
|
||||
(Cancel은 취소, Abort는 중단)
|
||||
|
||||
차세대MCS에서는
|
||||
Client <-> MCS WebServer 이렇게만 통신하게 할 예정
|
||||
이 둘은 HTTP를 쓸거같고 MCS WebServer가 TS든 CS든 얘네들하고 TIB통신을 할듯함
|
||||
|
||||
기존 MCS에서는
|
||||
UI(Client) <-> TS, CS 두곳과 TIB통신으로 직접 통신했었음.
|
||||
|
||||
기존 UI는 메인 화면 띄울때 버벅이는게 있었고
|
||||
설비수가 천대를 넘어가는 큰 사이트의 경우에는
|
||||
처음 화면 띄울때 켜놓고 나갔다와야할 정도라고..
|
||||
한번띄워놓으면 그다음부터는 좀 낫다고..
|
||||
|
||||
Crane이 out of service되면 Crane이 접근가능한 port들도 같이 out of service가 된다.
|
||||
(Crane이 없으면 해당 port들에 접근할 방법이 없으므로)
|
||||
Crane이 in service가 되면 port들도 같이 in service가 된다.
|
||||
|
||||
(Machine)AlarmSet
|
||||
UnitAlarmSet
|
||||
AlarmCleared 순서로? 세트로 발생된다함
|
||||
|
||||
Machine Alarm, Unit Alarm이 각각 의미하는 바가 있나봄
|
||||
Machine은 설비 그자체,
|
||||
Unit은 Machine에 포함된 Port같은 유닛들을 의미
|
||||
|
||||
Rail OHT는 (일반적으로)Port가 없고
|
||||
Interail은 있다. ?
|
||||
Reference in New Issue
Block a user