안녕하세요. 오유 독자님들! 어제 근로자의 날은 잘 보내셨는지요?
저는 아들이랑 와이프 데리고 난생처음 회전초밥 집에 가봤습니다. 스시라는건 결혼식 뷔페 아니면 안먹다보니..
대학생때는 스시뷔페가 있어서 친구들이랑 자주 가보긴 했는데, 기대한 만큼의 맛은 아니었죠.
와이프에게 돈 따지지 말고 먹고싶은거 다 먹자! 선언하고 눈 꼭 감고 막 퍼먹었습니다.
총 21접시에 나무판 9개를 먹었더군요. (접시: 1900원 나무판: 3000원)
배부르게 먹고보니 66,900원 나오더라구요. 뭐 다 같이 먹기에 싸지도...그렇다고 생각만큼
엄청나게 많이 나온 가격도 아니라...제 기준에서 싸지 않은건 맞지만 배부르게 다 먹으면 막 50접시는
나올거라 생각했거든요. 한 접시에 해봐야 2피스, 4피스 정도 아닙니까...ㅋ
어쨌든, 가족끼리 외식하기엔 나쁘지 않았습니다. 무엇보다 좋은건 뷔페에서 나올때 느끼는 더부룩한
포만감이 없었습니다. 접시에 조금 담겨 있으니 양조절은 확실히 되더라구요.
사회초년생 분들은 정말 땡기는 날에는 혼자 회전 초밥집 가보는것도 나쁘지 않을것 같습니다.
저는 돈 벌면서 자기 보상 같은건 안하고 살았나봐요 ㅎㅎ 늘 우두커니 바라만 보다가 김밥O국 가고는 하던
저랑은 다르게 사회생활 하시길....
-----------------------------------------------------------------------------------
이번에 맡게된 두번째 불끄기 미션.
이것만 꺼주면 3파트의 파트장(팀장)으로 승격되는 미션.
드디어 나만의 팀으로, 현경의 코드 구조를 가지고 대국을 이끌어 나갈 수 있다..!
L사 관련 일이지만 실제 공장은 L사가 아니었음. 청주에 OO텍 이라고 L사의 1차 협력사가
있는데, 여기에 납품된 2대의 필름검사기가 우리 회사 장비였음.
여기서 만들고 검사된 제품이 L사로 넘어가는 것. 그러다보니 설비의 개조 관련해서
L사에서 직접적으로 관여는 하지 않지만 은근히 압박이 들어오곤 했음.
도게자 팀장이 사고친 후 2달가량 억지로 억지로 퀵실버 대리를 투입하여
여러 시도를 해 보았으나 모두 실패. 조만간 비전총괄 전무가 L사로 방문하여 조율이라 쓰고
혼나러 들어가는 상황이었음.
햄릿: 이번에는 청주 필름검사기 문제야..2달동안 퀵실버 대리가 진행했는데 잘 안된데.
나: 와..2달이나 안되는 장비라니...
햄릿: 문제는 이거 해결 안되면 3주후에 전무님이 L사에 가야 해.
나: 그럼 2주안에는 끝내야 겠네요.
햄릿: 가능...하겠어..?
나: 한번 해봐야죠. ㅋ 일단 퀵실버한테 코드부터 받아보겠습니다.
.......................
................
회의실..
나: 퀵실버 대리. 얘기는 들었지? 청주 공장 검사기 잘 안된다며?
퀵실버: 네..
나: 그래서 이번에 이사님께서 나보고 한번 도와주라고 하시더라고.
퀵실버: 네..들었...습니다..얼마전에는 보거스 대리...것도 처리....하셨다고 들었습니다..
나: 어. 어쩌다보니 그리 됬네. ㅋ
퀵실버: 왜...대리님이 나서시는....건가요...?
나: 내가 나선게 아니라 위에서 나보고 하라던데?
퀵실버: 못하겠다고...하시면 안되나요...? 대리님이야 처리하시면...대리님께 좋은일...이지만...
그 덕분에...기존의 개발자는....죽는거 아닌가요...? 당장에 보거스 대리만해도...
나: 보거스가 죽었어? 회사 옥상에서 뛰어내리기라도!? ㅋ
퀵실버: 그게 아니라...기존 개발자가 완전 병O.....된다는 거죠....
나: 병O이 병O소리 듣는게 문제가 있어? 보거스는 간단히 처리할 수 있는 업무를 자기만의 편협한 판단으로
교묘하게 안되는 일로 주장했고. 그 덕분에 우리 회사는 S사라는 대기업한테 대단히 무능력한 회사로 기억 될 뻔 했는데?
그뿐이냐? 100대 넘어가는 장비 빼기라도 하게? 그 비용은!? 누가 감당하는데?
퀵실버: 어차피...S사는...신규 거래 안되는....떠난 패...아닙니까..
나: 그걸 왜 일개 SCV들이 판단하냐고. 그런 소리를 하니까 나한테 SCV소리를 듣는거야. 제대로 판단을 못해 애들이ㅡㅡ;
돈은 못벌어도 잃지는 말아야 할거 아냐.
퀵실버: 대리님....저는 이번 프로젝트...대리님이 안 나셨으면 합니다....이사님께도 거부의사...표현했습니다...
솔직히 저도 바쁘거든요...코드 설명드릴 시간에...제 일을 하는게...
나: 니가 판단할 일이 아니라니까? 그리고 말하는거보면 이 프로젝트나, 이 코드가 마치 니 것인양 말한다? 회사 재산 아니야?
그정도 책임감이 있었으면 겁날 이유가 있냐? 오히려 좋아해야 하는거 아냐?
퀵실버: 대리님은...제 밥그릇을...건드시는....
나: 야. 너 나한테 한따까리 하고싶냐?
퀵실버: .....;;;;;
나: 닥O고 코드 내놔. 밥그릇 같은 소리하네. 그래 2년동안 끼고 돌던 밥그릇 구경 좀 해보자.
니가 그간 얼마나 열심히 살아왔는지 코드보면 알겠지.
퀵실버: .......;;;;;
***
퀵실버: 여기에...제어서버 1개에...검사프로그램 2개입니다...양이 꽤 많아요..바로 다 파악은 어려우실거 같습니다...
특히나 1개의 서버에서 2개의 클라이언트와 통신하는게 햇갈리실거에요.
나: 이게 다야?
퀵실버: 네..?
하아...Roll to roll을 안해봤으니 이 정도 프로젝트가 코드양이 많다고 생각하는구나...우린 1개에 32개 클라이언트다..
전혀 무리될게 없어...;; 이건....걍 하루면...아니 반나절이면...다 파악돼...
나: 우리는 1개 서버에 32개 클라이언튼데? 너는 니 일만 보고, 다른 회사 코드는 일절 관심이 없어?
니 선배들이 무슨일 하는지 궁금한적도 없어? 니네들은 그냥 니네 눈앞의 세계가 전부인양 그렇게 회사생활 하는거야?
솔직히 코드보고 많이 실망스러워서 그래.
퀵실버: ............
나: 니네들 대리 달았다고 창희 한테 맞먹으려 들고...근데 고작 이정도 프로젝트 하면서.....회사생활 힘들다고 징징거리고
관리자 만만하다고 오후 4시 5시에 맘대로 퇴근하고. 뭐? 받은 만큼 일한다고?
이게 받은만큼 일하는 양이야? 이래놓고 포청천 팀장 욕했어?
퀵실버: 아직 코드도 다 안보셔놓고 그렇게....속단 하시면....안되죠.......
나: 우선. 모르나본데 나는 시작부터 호카게 팀 출신이 아니야. 니네들 2파트 팀이었지.
이건 내가 사원 때 대만에서 보던 코드 베이스야. 누구보다 나한테 익숙한 코드라는 거지.
이미 제어 서버는 70%는 안봐도 알아. 검사프로그램은 기존에는 없던 형식이긴 하네.
근데 고작 검사 프로그램이잖아? 별거 있겠어?
퀵실버: 대리님이 회사를 오래 다니신 덕에.......
나: 나 여기 4년 다녔다. 넌? 3년 가까이 다녔지 않아? 니가 나보고 오래 다녔다고 할 정돈 아니지. 너도 마찬가지로 오래 다닌거니까.
퀵실버: 그러시면...굳이 저한테...... 코드설명 들으실 필요도 없겠네요...
나: 와...요놈봐라? 상식을 벗어나면 물어보게 되겠지.
퀵실버: 어쨌든...아무리 대리님 이시라도...저는...협조 못합니다...그 시간에...저는 제 방식대로....수정할 겁니다...
나: 허참. 그냥 같이해서 같이 해결했다고 가는게 낫지 않겠냐?
퀵실버: 저는...이사님께..도움 필요 없다고 분명히...말씀드렸습니다..제가 따로 해결...할 겁니다...
나: .........그래...어찌보면 2가지 솔루션 가지고 가는것도 나쁘진 않을거야....(이 회사 대리들은 어째 정상인이 없냐;;)
기존 담당자의 업무내용 공유없이 프로그램을 수정하는건 어찌보면 2배로 시간을 할애해야하는
상황이겠으나, 이렇게까지 본인에게 철벽을 치는데는 분명히 이유가 있을거라고 생각이 들었음.
니들이 아무리 벽을 쳐도. 나는 그 벽....
박.살.내.고. 들어간다...!!!
***
코드를 보니 왜 퀵실버가 안된다고 난리를 친건지 대략적인 이해는 갔음.
1개였던 판정 센서가 이제는 2개가 되는건데. 제어 서버의 UI는 최후의 판정 때
판정 결과 디스플레이 창, 불량 이미지 창, 데이터 로그창에 결과가 업데이트 되는 방식으로 짜여 있었음.
근데 이제는 판정 센서가 2개가 되니 판정 결과 창도 2개, 불량 이미지 창도 2배로 늘고, 데이터 로그창도 2개....잉?
같은 로그 창이라면...그냥 거기에 둘다 기록을 하는게 맞는데....
데이터 로그창을 왜 2개 만들어놨지...? ㅋㅋㅋㅋ
퀵실버.....얼마나 일이 하기 싫었으면...생각이라는걸 아예 하지 않았구나...
퀵실버가 회사에 강력히 주장하던게 이거였음.
어쨌든 판정 센서의 값에 따라 판정 동작이 이루어 지기에 판정 센서부의 코드는 Thread로 구현이
되었음. 그리고 이 Thread는 센싱이 되던 아니던간에 계속 돌고있음. 자원의 낭비다....
대략 코드는 이런식..
-------------------------------------------------------------------------------------------------
주석으로 나의 황당함을 코멘트 달겠음.
UINT ThreadReadJudgeSensor_1(LPVOID lParam)
{
................
.................
while(1)
{
if(IsReadSensor(6) == 1)
{
......................
...................... // 6번 센서 신호가 들어오면 쭉- 코드 실행 (여기서 UI컨트롤을 업데이트하고 하는 모든 코드가 다 때려박혀있음.)
Sleep(2500); // 이게 뭐지!?
WriteSignal(0, 1); // 0번 I/O로 신호 1 날리기 -> 컨베어 제어
}
Sleep(50); // ???? 뭐지 이건??
}
}
함수 작명 센스 봐라.... 귀찮다고 그저 뒤에다가 넘버링이나 때려두고ㅡㅡ;
이런 경우라면 넘버링 보다는 앞쪽에 있느냐 뒤쪽에 있으냐를 알 수 있는 이름을
만들어 두는것이 '배려' 임. 먼 훗날 내 자신에 대한 배려이자, 이후 후임자들을 위한 배려.
UINT ThreadReadJudgeSensor_2(LPVOID lParam)
{
................
.................
while(1)
{
if(IsReadSensor(7) == 1)
{
......................
...................... // 7번 센서 신호가 들어오면 쭉- 코드 실행(여기서 UI컨트롤을 업데이트하고 하는 모든 코드가 다 때려박혀있음.)
Sleep(1000); // 이게 뭐지!?!?!??
WriteSignal(1, 1); // 1번 I/O로 신호 1 날리기 -> 컨베어 제어
}
Sleep(50);
}
}
뭐...뭐지!? 이미 상식을 벗어난 느낌...
----------------------------------------------------------------------------------------------
즉시 퀵실버를 불러야 했음. 코드본다던 사람이 10분만에 자기를 부르니 약간 의기양양한 퀵실버..
'것봐. 코드 분석 안되지?'
하는 느낌...
퀵실버: 왜 벌써 부르셨어요...? 벌써 코드 다...보신...건가요?
나: 아니 ㅋㅋ 딱 보는데 상식을 벗어나서 안되겠더라고 ㅋㅋ
퀵실버: 어떤거요....?
나: 여기 Sleep(2500)은 뭐냐...?
퀵실버: 이래서..설비를...봐야 코드를...이해할 수 있는건데...
나: 쓸데없는 소리 하지말고 이유나 말해봐.
퀵실버: 판정센서가 판정 한 뒤에 컨베어까지 가는동안 거리가 있어요...
그 거리를 특정할 수 없기 때문에 타이밍을 맞춰본 시간인거죠..
나: 그럼 저기 Sleep(1000);은 뭐야? ;;
퀵실버: 저건 확인할 방법이 없어서.... 임의로 넣어둔 타이밍 시간이에요.
현장 가서.... 체크 해야죠..바코드 검사 후에 판정센서 까지의 타이밍을....
나: 아?? 대단하구만;; 그럼 Sleep(50);은 뭐냐...내가 이런 Sleep 걸린 Thread는 본적이 없네;;
퀵실버: 저건 저렇게 안해두면..... 센서가 두번 센싱 될....... 위험이 있어서 크게 잡아 둔거에요...
나: 센서가 센싱되고 무조건 Thread는 2.5초 혹은 1초 동안 멈추는데? ㅋㅋㅋㅋㅋㅋ 저 Sleep(50);이 의미가 있어? ㅋㅋㅋ
퀵실버: ......!?......;;;;;
나: 와....도대체 어디서 부터 잘못된건지....;;
퀵실버: 어쨌든....저게 안되는 원인은....아니죠....원래부터 50이었어요....제가 짠게...아니라...
나: 너가 안된다고 생각하는 이유가 저렇게 Thread 2개에서 하나의 UI컨트롤을 건드니까 충돌나서 안된다고 한거냐?
퀵실버: 네....그래서...하나씩 더 추가를 하려는데....UI 공간이 안나와요....
나: 너 CriticalSection이나 mutex 같은건 아냐?
퀵실버: 락을 걸면...한쪽이 자원을 쓰는동안.....다른쪽은 사용 못하고 대기 상태가 되잖아요....그러니 쓸 수 없죠....
나: 고작 UI 업데이트 하는데 뭐 얼마나 잡고있다고?
퀵실버: 해 보시면...알아요...
나: 알았다;; 일단 궁금한건 알았어....
ThreadReadJudgeSensor_1 : 판정 관련 UI 업데이트 동작 및 결과 처리
ThreadReadJudgeSensor_2 : (새로 추가된 판정센서) UI 업데이트 동작 및 결과 처리
기존에 퀵실버는 그냥 하나의 UI 컨트롤로 2개의 Thread에서 데이터 처리를 하려고 했음.
근데 1개의 자원을 2개의 Thread에서 동시 접근을 하게 되면 프로그램은 죽음.
이런거임.
철수라는 스레드와 영희라는 스레드가 있음. 앞에는 커피가 있음.
철수가 한잔 먹고 내려놓은 다음 영희가 마시면 문제가 없는데. 철수와 영희가 동시에 커피를 쥐면
서로 먹겠다고 경합하는 상황이 됨. 프로그램은 이런 상황이면 죽는다고 생각하면 됨.
이걸 막으려면 누구라도 커피를 마시는 상황이되면 나머지는 커피에 손을 못대도록 중간에 '문'을 만들면 되는데
이런걸 동기화를 시킨다고 표현함. 혹은 락을 건다고도 함.
철수가 문열고 들어가서 문을 닫고 커피를 마심. 영희는 못들어가고 기다려야함.
철수가 커피 다 먹고 문열고 나오면 영희가 들어가서 문 닫고 커피를 마심. 이런 식으로...
(문닫고 여는 만큼의 미세한 지연이 조금 발생함, 실시간으로 도는 장비에서 이런 미세한 지연은
시퀀스를 꼬이게 만들고 코드 충돌이나 프로그램이 죽을 수도 있음, 따라서 신중해야함. 개발자의 판단이 중요한것.)
퀵실버는 이런 부분에서 프로그램이 죽기 때문에 무식하게 컨트롤을 하나씩 더 추가 해 놓은것.
로그창을 2개로 만든 이유는.....그런데서 나온것... 하나의 로그창에 값을 쓰면 충돌나서 죽으니까..??
문제는 또 있었음. UI화면은 크기가 정해져 있고, 거기에 맞게 컨트롤의 크기나 배치가 이루어져 있는데
이걸 무식하게 2개씩 만들려니 컨트롤 배치 공간이 안나옴.
[정말....이게 대리급이 맞나!? 동석아...너도 오늘부터 대리 해라...]
그리고 마지막.....저 정체를 알 수 없는 Sleep(2500);...
정말 지금 생각해도 환상적인 코드 컨트롤 능력이라..
판정센서를 거친 후, 한참을 진행 하다보면 상/하로 컨트롤 되는 컨베어에 도달함.
제품이 센서를 지나 해당 컨베어에 닿기 전,
PC에서 I/O신호를 주면 컨베어가 아래로 열리며 밑으로 NG 제품이 내려가 적재되는 원리였음.
이걸 정상적으로 컨트롤 하기 위해서는
판정 센서를 거친 후, 해당 컨베어 앞으로 필름이 도달했다는 측정 '기준'이 있어야함.
그런데 이 장비에는 당장에 눈에 보이는 '기준'이 없었음. 그러다보니 코드를 어떻게 짜 놓았나?
판정 센서 이후 Sleep(2500); 이후 강제로 컨베어에 I/O신호를 주고 있었음. ㅋㅋㅋㅋ
Sleep(2500);.. 즉 2.5초후에 제품이 아마도 컨베어 앞에 도달 할 것이다.....
실제로 제품이 있던 말던 일단 컨베어에 신호를 줘버리는거.
그럼 지 혼자 내려가든 올라가든 하겠지...
히야~~~일 정말 멋지게 했네.
그런데 이번엔 판정 센서가 중간에 하나 더 추가되고, 상/하 제어 컨베어도 하나 더 추가 되었기 때문에
코드에 Sleep(2500); 외에 또 다시 Sleep을 추가해야 하는 상황.
퀵실버는 지금 이 추가 될 Sleep을 몇초로 만들어야 할지 고민하고 있는것.
일단 모르니까 Sleep(1000); 때려박아놓고 현장에서 확인해 보겠다는 대범함.. 상남자.
과거부터 여러 코드들을 보며 한가지 느낀것은...실패한 장비에는 공통점이 있었음.
Sleep() 타이밍 제어가 많다는 것. 물론 이걸 원해서 짜는 프로그래머는 없다는건 사실임.
그들도 분명 좋은 코드를 짜고 싶었겠으나, 고객사의 말도 안되는 억지...영업적으로 사고쳐서 떠맡게된
기이한 컨셉, 쫓기는 시간.... 현장에서 겪게 되는 현자타임..
이런 것들이 결국은 일단 설비부터 돌려놓고 보자는 상황을 만들어냄.
어쨌든 그런 이유들이야 많겠지만 경험상 Sleep은 15 이상의 값이 들어가면 안된다는 생각임.
반드시 그 이상의 시간이 들어가야 한다면...방법을 바꾸어야 한다고 생각함.
하물며 2500(2.5초)이라니...이미 실패한 컨셉임..
그렇다면 프로그래머는 요청을 해야함. 이런 부정확한...말도 안되는 타이밍을 쓰기보다는
차라리 센서 하나를 더 추가해 달라거나 다른 방법을 찾아내야 하는것.
기존 코드는 매우 조잡하긴 했지만, 판정 센서가 1개였던 컨셉이라면 무난하게 돌아갔을 코드...
문제는 하나가 더 붙으며 완전히 망겜이 되버린것.
프로그래머와 도게자 팀장이 얼마나 서로간에 소통이 없었는가...
이건 둘다 사고를 친거나 마찬가지임.
상대를 무시하고 말해봤자 모를거라 생각하며 애초에 말을 해주지 않는 프로그래머나..
모르면서 막 나대는 도게자 팀장이나...
어쨌든 퀵실버가 어려워하는 이유는
1. 판정센서 관련 Thread가 추가 됨으로 써 기존 UI컨트롤을 동시 접근하여 처리가 불가능하니
노가다 식으로 나머지 컨트롤들을 무작정 새로 추가한다. 그러다보니 디자인 부터 시작해서 여러가지 손댈
부분이 많아서 엄두가 안난다.
2. 컨베어를 적절한 시점에 제어해야 하는데 애초에 Sleep(2500) 같은 코드로 타이밍 운빨로 제어해오다 보니
새로 추가 될 컨베어의 제어를 도대체 어떻게 할지 모르겠다.
1시간도 안되어 제일 핵심 파트에 대한 분석이 끝났음. 어차피 다른곳이야 기존에도 잘 돌던 곳 아닌가.
안되는건 이 파트 뿐.. 나머지 코드야 그냥 쭉- 훑듯이 봐도 충분했음.
일단 본인은 고객사가 요청하는 컨셉부터 다시 생각했음. (바코드 검사가 우선 이루어 지고, 이물/기포 검사로 넘어감.)
바코드 불량과....이물/기포 검사를 분리하여 적재 하겠다....
뭔가 잘못 되었음. 그럼 저렇게 바코드 불량을 적재하면? 다 버릴꺼야!? 아니잖아.
근데 저런 컨셉으로 분리 해버리면 바코드 불량은 이물/기포 검사 구간을 통과하지 못함.
그럼 결국은 다시 검사를 해야함. 이물/기포가 있는지. 효율충들인 대.기.업이 장비를 저렇게 쓴다고!?
저건 분명 어떤 모지리들이 책상머리 앞에서 되도않는 브레인 스토밍하다가 그냥 한번 해보까?
해서 나온게 분명함. 설비가 익숙하지 않은 초짜 담당자가 비슷한 사람들이랑 즉흥적으로 생각한 아이디어라는 것.
보통 그런 자들의 최후는 똑같음. 실컷 만들어 놓고 위에 보고했다가 '책임'급 담당자 선에서 컷-
선임자 한테 욕이란 욕은 다 처먹으며 다시 설비 원상복구 테크 ㅋㅋㅋㅋ
이 컨셉은 아마도...두 달을 못갈 것이다..!
고로 이 조잡한 코드를 구조부터 다시 잡을 대 공사는 필요치 않다. 최소한의 수정으로 일단 돌아가게만 만들어놓고
결과를 지켜본다. 어차피 원복 될 가능성이 다분한 결과가 예상가능 했음.
애초에 컨셉을 문제 삼으면 고객사는 기분 나빠서 말을 안들어먹음.
결국은 말도 안되는 컨셉을 해주고. 자기들 스스로 판단해서 다시 원복 요청을 하도록 만드는게
L사를 다루는 메뉴얼임. 통풍이가 제일 잘하던 방법....ㅋㅋ
***
일단 판정센서 Thread에서 잡다한 UI 컨트롤 업데이트 하는 코드들은 불필요 했음.
센서가 On 이 되었다는 Signal만 있으면 굳이 Thread 에서 부득부득 UI 컨트롤로 접근하여 억까를 칠 필요가 없다는 거임.
결국은 ThreadReadJudgeSensor_1 스레드와 ThreadReadJudgeSensor_2 스레드에서 필요한건
센서가 On이 되었다는 Signal 뿐..
UI 컨트롤 코드만 제외한다면 나머지는 결국 UI에 표기될 '상태'만이 남게 됨.
이 '상태' 데이터를 구조체나 클래스 같은 데이터 덩어리로 만듦.
이 데이터를 메세지화 하여 Queue에 담는다.
이 상태 데이터는 결국 센서가 On이 되었을 때 전달되기 때문에
결국은 Signal도 될 수 있다는거니까.
이렇게 2개의 Thread에서 발생된 데이터가 Queue에 들어가게 되겠지.
Queue에 들어간 데이터는 자동으로 줄을 선게 됨. 즉 동기화가 된거나 마찬가지 개념.
그럼 프로그램은 Queue에 데이터가 쌓이면 그냥 그 상태 데이터를 꺼내어 UI 컨트롤에 그대로 업데이트만 하면
동시 접근의 위험성 없이 무탈하게 원하는 바를 행할 수 있음.
이렇게 1번 문제 해결.
문제는 2번...Sleep(2500)이라는 억까 코드를 제거해야 하는데...
일전에 언급된 적이 있는데...에피소드 99화 렌야의 OLED 검사기 촬영 문제가 있었을 때..
---------------------------------------------------------------------------------------------------------------------
헬보이: 후훗. 거기 for문을 4개씩 건너 뛰면서 돌려보세요^^. 저도 얼마전 청주공장 필름 검사기 하면서
비슷한 문제가 있어서 처리해 봤거든요. 거기 원리랑 지금 OLED 필름 검사기랑 같은 원리 거든요^^
---------------------------------------------------------------------------------------------------------------------
그렇다면 검사기의 카메라는 항시 Live로 켜두고 촬영하고 있다는 뜻. 그렇다면 제품이 들어오지 않더라도
컨베어를 통한 엔코더 펄스는 계속 발생하고 있고, 그 펄스에 맞게 카메라는 지속적으로 이미지를 촬영하고 있다는 것.
라인 스캔 카메라는 현재 1frame을 256 라인으로 잡고 있을 것이라 예상가능.
(512일 수 도 있으나 보통 우리 회사는 256으로 해둠)
만약 카메라의 레졸루션이 1픽셀당 1mm라고 한다면 256라인은 256mm가 됨.
즉 1 frame은 256mm라는 소리.
검사 카메라는 컨베어가 돌아가면 Live 모드로 카메라를 촬영하기 때문에
엔코더의 신호에 따라 지속적으로 1, 2, 3, 4, 5 이런 식으로 frame수를 카운팅 할 수 있음.
만약 10frame 이라면? 2560mm거리 만큼 컨베어가 진행했다는 사실을 알 수 있음.
(독자님들이 알아듣기 쉽게 1픽셀당 1mm라고 한겁니다^^)
한마디로 검사 프로그램에서 얻어지는 현재 프레임 넘버를 제어 서버로 실시간 전송을 하고.
제어 서버는 판정 센서가 센싱된 시점부터 검사프로그램으로 부터 넘어오는 프레임 넘버를 카운팅 한다면
센서에서 부터 상/하 컨베어 까지의 제품 진행 거리를 측정 가능하다는 소리가 됨.
즉. 이 장비는 기준이 없는것이 아니라. 애초에 해당 촬영 방식을 택했을 때 부터 기준이 존재해 왔다는것.
사장님과 연구소장님은 이미 이렇게 사용하고자 프로그램을 개발 하신거니까.
문제는 이 '묘리'를 제대로 이해하고 설비를 대하는 사람이
오우거 과장, 호카게 팀장, 콩과장, 정과장 외에는 없었다는 것.
확실히 고인물 과장들이 지금의 회사 쓰레기 멤버들 보다 몇 십배 일을 잘 했다는 생각이 들었음.
헬보이와 퀵실버는 이런걸 전혀 파악하지 않았기에
Sleep(2500); 이라는 말도 안되는 코드를 간뎅이 크게 박아놓은 거였음.
이렇게 2번도 해결.
결국 코드를 받은지 3시간도 안되어 모두 처리할 수 있었음.
........................................
나: 이사님. 일단 수정 완료 했습니다. 퀵대리는 같이 안하고, 자기 방식으로 수정하겠다고 하길래 그러라고 했어요.
햄릿: ...어!? 벌써? 근데 걔는 왜그러냐? 둘이 같이 보는게 낫지않아?
나: 이상한 고집 피우더라구요. 제 도움 필요없다고.
햄릿: 이상한 놈이네. 그럴거면 빨리빨리 대응하던가. 2달이나 질질 끌어놓고선;;
나: 아무튼 솔루션이 2개로 나가면 어찌보면 좋을 수도 있죠. 제꺼가 무조건 된다고 보장은 못하니까.
햄릿: 좀..더...신중히 보면 안되냐..? 상식적으로 너무 빠른데;;;
나: 체크는 해보겠습니다.
가자. 이거만 끝내면 내가 팀장이다...!!
