[Archive] 강좌게시판
[myLV.net 집필진 강좌 – 웅킹킹킹]
안녕하세요. 웅킹킹킹 입니다.
너무 너무 바빠서.. 업데이트가 매번 늦어서 죄송합니다.
2018년 상반기에는 좀더 노력해서 업데이트 할 수 있도록 하겠습니다.
본격적으로 시작하기 전에 사담으로 최근 OOP & Actor Framework 구조로
생산 공정 라인에서 제품 테스트 프로젝트를 진행했습니다.
해당 프로젝트는 기존에 생산자 소비자 구조로 만들어진 프로그램으로
진행하고 있었는데 소스 코드의 라인이 좀 지저분하긴 했지만
매우 잘 만들어진 소스코드였습니다.
하지만 테스트 제품 군의 다양화와 TEST BED를 늘릴수록
생산자 소비자 구조에서는 소비자 패턴을 증가시켜야 하는
필연적인 단점이 있어서 OOP 구조로 변경했습니다.
생산자 소비자 패턴에서는 TEST BED가 늘어남으로
소비자 패턴이 증가되고 제품군의 다양화로 테스트 방식이
변경되거나 추가될 때 모든 소비자 패턴 구조에 같은 소스코드를
작업해야 합니다. 이 작업 도중에 프로그래머의 실수가
발생해서 버그가 생길 요소가 많이 생길 수도 있습니다.
A 소비자 패턴에 했던 작업이 B 소비자 패턴에도 같은
작업이 되어야 하는 데 LabVIEW 특성 상 라인을
틀리게 이을 수도 있고 빠뜨릴 수도 있습니다.
TEST BED의 수에 따라 소비자 패턴이 늘어날 수 밖에 없는
현실인데 TEST BED가 4개라면 4개의 소비자 패턴에 작업을
해야 하며 때에 따라 생산자 패턴도 만들어야 할 경우도 있습니다.
하지만 OOP & Actor Framework에서는 하나의 Actor 클래스만
작업하고 TEST BED의 수에 따라 Actor 클래스를 호출만
하면 되기 때문에 매우 효율적으로 작업이 가능하고
버그 발생 확률도 낯 출수 있습니다.
그래서 이번 프로젝트를 OOP & Actor Framework로 진행했으며
TEST BED의 수도 증가하고 테스트 진행 시간도 단축했습니다.
해당 엔지니어도 매우 만족했고 앞으로 TEST BED를 더
증가시킬 때도 편하게 할 수 있어서 좋다고 하시더군요.
테스트 진행시간도 단축되는 것을 봤을 때
OOP 구조를 사용할 때 컴퓨터의 리소스는
따로 고려해야 할 정도는 아닌 것 같습니다.
사담이 길었네요.
작년에 진행했던 프로젝트 경험을 조금이나마 알려드리면
혹시나 도움이 될 수 있을 것 같아서
주절주절 말이 길었습니다.
이번 시간은 지난 시간에 만든
3개의 Actor 클래스
Ladder Game, Runner, Runner Manager 에 이어서
Non-Actor 클래스인 Ladder Map 클래스를 만들어보겠습니다.
Non-Actor 클래스라는 단어 그대로 Ladder Map 클래스는
Actor 클래스가 아닙니다.
저는 Ladder Game 프로그램을 만들면서
굳이 Ladder Map을 다루는 클래스를 Actor 클래스로
만들 필요는 느끼지 못해서 일반 클래스로 작업했습니다.
단순히 Ladder Map의 정보만을 다루기 때문입니다.
프로그래머의 생각에 따라 Ladder Map을 Actor 클래스로
만들어도 무방합니다.
지난 시간에 만들어둔 버추얼 폴더 “Support Class (non-Actor)에서
새로 만들기 → 클래스를 선택해서
Ladder Map 클래스를 만들어줍니다.
그리고
Ladder Game\Support Class (non-Actors)에서
Ladder Map이라는 폴더를 생성하고
해당 Ladder Map 클래스를 저장합니다.
지난 시간에 했었던 대로
Ladder Map 클래스도 아이콘 작업을 합니다.
Ladder Map 클래스는 Actor 클래스가 아니고
다른 클래스로부터 상속 받지 않기 때문에
상속 설정은 하지 않습니다.
Ladder Map.ctl 선택해서
Data 멤버를 작업합니다.
Ladder Game에서 사용할 Ladder Map은 2D 불리언으로
만들 예정이기 때문에
“Map Info” 라는 이름으로 2D 불리언 컨트롤을 만듭니다.
그리고 Ladder Game에서 각 주자들이 출발할
스타트 지점으로 사용할 데이터인
“Start Position” 이라는 네임으로
위 그림과 같이 I32 숫자형으로 이루어진 클러스터 타입의
배열 컨트롤을 만듭니다.
그리고 Data 멤버를 사용하기 위한
VI를 만듭니다.
위 그림처럼 Ladder Map 클래스에서
“데이터 멤버 접근을 위한 V...”을 선택합니다.
선택을 하면 “접근자 생성”
다이얼 로그 박스가 생깁니다.
다이얼 로그 박스는 위의 그림과 같이
설정을 하고 확인을 선택합니다.
여기서
Data 멤버 접근을 위한 VI는 하위 클래스에서
Overwrite를 해서 사용할 일이 거의 없기 때문에
“정적 접근자” 옵션으로 만들어주고
Accessors 라는 버추얼 폴더에서 해당 접근자 VI가
생성되게 하기 위해서 “Accessors”라는 명칭을
버추얼 폴더 생성하는 옵션에 작성합니다.
접근자 VI를 생성하면 위 그림과 같이
각 Data멤버에 대한 읽기, 쓰기 기능의 VI가
생성됨으로 4개의 VI가 생성됩니다.
각 VI는 아이콘 작업을 해준 다음
Ladder Map 클래스가 있는 폴더에 저장을 합니다.
접근자 VI를 생성하고 난 다음의 프로젝트 모습입니다.
Ladder Map의 역할은
Ladder Game의 Map을 생성하는 것입니다.
먼저 Ladder Map 정보를 초기화하는 Method를 만듭니다.
정적 Method로 생성하고
“Clear Map” 이라고 저장합니다.
해당 Method도 마찬가지로 아이콘을 작업합니다.
* Actor Framework에서 생성하는 모든 VI는 아이콘 작업을
필수적으로 해야 합니다.
Clear Map의 블록다이어그램은 위 그림과 같이 작업합니다.
지난 강의에 첨부했었던 UI의 Ladder Map 사이즈에 맞춘
2D 불리언 배열의 크기 입니다.
Ladder Map을 생성하기 위한
“Create Map” Method를 생성합니다.
정적 Method로 생성합니다.
그리고 아이콘도 작업합니다.
Method의 프런트 패널과 블록다이어그램은
위 그림과 같이 작업을 합니다.
소스 코드에 대한 내용은 대략적으로
Ladder Game의 User 수를 따라서
Ladder Map을 생성하는 것입니다.
소스 코드를 이해할 필요는 없지만
궁금하신 분들은 소스 코드를 보시면서
생각해보시면 될 것 같습니다.
위와 같이 작업을 한 다음
“Create Map” Method를 저장합니다.
이 것으로 Ladder Map 클래스의 작업은 끝났습니다.
이번 시간은 여기까지 입니다.
다음 시간에는 Actor 클래스를 구현하는 작업으로 이어질 것 같습니다.
간단한 프로그램의 Class를 하나 작업하는 과정도
이렇게 텍스트로 표현하니 양이 많네요..
심지어 Actor 클래스도 아닌데..
업데이트가 늦은 만큼 다음 업데이트는
좀 더 빨리 할 수 있도록 노력하겠습니다.
감사합니다.
