같은 LabVIEW로 만든 프로젝트인데
어떤 건 몇 년을 버티고,
어떤 건 1~2년 만에 손도 못 대는 상태가 된다.

기술 수준의 차이일까?
꼭 그렇지는 않다.

오래 살아남는 프로젝트를 보면
공통적으로 보이는 건
코딩 실력보다 습관이다.

LabVIEW를 오래 쓰는 사람들은
처음부터 거창한 구조를 만들지 않는다.
대신, 망가질 상황을 미리 떠올린다.

1) “지금 말고, 나중”을 항상 같이 생각한다

기능을 하나 추가할 때도
이 질문을 먼저 던진다.

• 이 기능이 하나 더 늘어나면?
• 장비가 바뀌면?
• 요구사항이 조금만 달라지면?

지금은 편한 선택이
나중에는 발목을 잡을 수 있다는 걸
경험으로 알고 있다.

그래서 항상
“조금 덜 편한 쪽”을 택한다.

2) 구조를 바꾸는 걸 미루지 않는다

오래 쓰는 사람들은
구조가 불편해지기 시작하는 시점을 안다.

• VI 설명이 길어질 때
• 수정 하나가 두세 군데를 건드릴 때
• “이거 건들면 무섭다”는 말이 나올 때

이 신호를 느끼면
기능 추가보다 구조 정리를 먼저 한다.

리팩토링은
시간이 남아서 하는 게 아니라
시간을 벌기 위해 하는 거라는 걸 안다.

3) 장비 의존 코드를 반드시 분리한다

장비가 바뀌지 않을 거라는 가정은
항상 틀린다.

오래 쓰는 프로젝트일수록

• 통신
• 초기화
• 타이밍
• 에러 특성

이 부분을 한 덩어리로 묶어둔다.

그래야
장비가 바뀌어도
전체 프로젝트를 다시 보지 않아도 된다.

4) 설명할 수 없는 구조는 만들지 않는다

오래 쓰는 사람들은
자기 코드에 대해 이런 질문을 스스로 던진다.

“이 구조를 말로 설명할 수 있는가?”

• 왜 이 VI가 여기 있는지
• 왜 이 데이터가 이 경로로 흐르는지
• 왜 이 타이밍에 이 판단을 하는지

설명할 수 없다면
그 구조는 아직 완성되지 않은 상태다.

LabVIEW는
보여주기 쉬운 만큼
설명하기 어려운 구조도 쉽게 만들어진다.

5) 문서보다 ‘의도’를 남긴다

모든 걸 문서로 남기지는 않는다.
대신 중요한 선택에는
의도를 남긴다.

• 왜 이 방식을 택했는지
• 어떤 대안을 버렸는지
• 어디까지를 가정했는지

이 한 줄이
몇 달 뒤의 자신이나
다른 개발자를 살린다.

LabVIEW를 오래 쓰는 사람들은
툴을 믿기보다
자기 선택을 더 믿는다.

• 구조를 의심하고
• 편의를 경계하고
• 나중을 먼저 생각한다

그래서 프로젝트도 오래 산다.

이제 LabVIEW 이야기는
여기서 한 번 끊는다.

다음부터는
조금 더 낮은 레벨,
조금 더 날것의 세계로 내려가 보려 한다.

같은 실수가
왜 C에서는 더 크게 터지는지.

그 이야기는
다음 축에서 이어간다.

LabVIEW 프로젝트가 무너질 때를 보면
대부분 기술이 부족해서가 아니다.

“일단 되니까”라는 선택이
조금씩 쌓였을 뿐이다.

이번 글에서는
대규모 프레임워크나 복잡한 패턴 이야기는 하지 않는다.
실무에서 최소한으로 지켜야 할
LabVIEW 구조 설계의 기준만 정리해본다.

LabVIEW 구조의 핵심은 의외로 단순하다.

데이터가 어디서 오고,
누가 책임지고,
어디로 흘러가는지 명확한가

이 질문에 답할 수 있느냐가 전부다.

1) 상태는 흩어지면 안 된다

프로젝트가 커질수록
상태 정보는 늘어난다.

• 장비 연결 상태
• 동작 모드
• 에러 상태
• 사용자 입력 값

이 상태들이
전역 변수, 로컬 변수, VI 내부에 흩어지기 시작하면
프로젝트는 바로 복잡해진다.

핵심은 하나다.

상태는 한 곳에서만 관리한다

클러스터든, 상태 구조든
형태는 중요하지 않다.
“여기서만 바뀐다”는 규칙이 중요하다.

2) UI는 판단하지 말고, 전달만 한다

LabVIEW에서 가장 흔한 실수 중 하나는
UI 로직이 판단까지 맡아버리는 경우다.

• 버튼이 직접 장비 제어
• UI 이벤트 안에서 비즈니스 로직 처리
• 화면 업데이트와 로직이 뒤엉킴

이 구조는
처음엔 직관적이지만
나중엔 수정이 가장 어려운 구조가 된다.

UI는 역할이 명확해야 한다.

• 입력을 받는다
• 상태를 보여준다
• 요청을 전달한다

판단은 항상
UI 밖에서 이뤄져야 한다.

3) 책임은 VI 단위로 나눈다

하나의 VI가
여러 역할을 동시에 맡기 시작하면
그 VI는 빠르게 비대해진다.

좋은 기준은 이 질문이다.

“이 VI를 설명할 때 문장이 하나로 끝나는가?”

• “이 VI는 장비 초기화를 한다”
• “이 VI는 데이터 저장만 담당한다”

설명이 길어지기 시작하면
책임이 섞였다는 신호다.

4) 에러는 흐르게 두지 말고, 해석한다

에러 클러스터를
그냥 연결만 해두는 경우가 많다.

문제는
에러가 발생했을 때
아무도 판단하지 않는다는 점이다.

• 이 에러는 무시해도 되는가
• 재시도가 필요한가
• 사용자에게 알려야 하는가

이 판단이 없는 구조는
운영 단계에서 반드시 문제를 만든다.

에러는 단순한 신호가 아니라
의사결정의 트리거다.

5) 구조를 단순하게 유지하는 게 최고의 최적화다

LabVIEW에서는
구조를 깔끔하게 유지하는 것 자체가
성능 최적화인 경우가 많다.

• 불필요한 데이터 복사 제거
• 명확한 데이터 흐름
• 반복 구조 최소화

복잡한 최적화보다
구조 하나 정리하는 게
효과가 더 큰 경우가 많다.

LabVIEW 구조를 살리는 데
정답 패턴은 없다.

다만 피해야 할 방향은 분명하다.

• 상태가 보이지 않는 구조
• 책임이 섞인 VI
• 판단이 없는 에러 처리

이 세 가지만 피해도
프로젝트는 훨씬 오래 버틴다.

다음 글에서는
이 구조를 실제로 오래 쓰는 사람들이
어떤 습관을 가지고 있는지 이야기해보려 한다.

툴이 아니라
태도의 이야기다.

LabVIEW로 프로젝트를 시작할 때는 항상 단순하다.
VI 몇 개 만들고, 프론트 패널 붙이고,
“일단 돌아가네?”에서 출발한다.

문제는 그 다음이다.

기능이 하나둘 늘고,
장비가 추가되고,
요구사항이 바뀌는 순간
프로젝트는 급격히 무거워진다.

그리고 이상하게도
무너지는 지점은 항상 비슷하다.

처음엔 편한 구조가, 나중엔 발목을 잡는다

초기 LabVIEW 프로젝트에서 자주 보이는 패턴이 있다.

• 전역 변수로 상태 공유
• 모든 로직을 하나의 큰 VI에 몰아넣기
• 에러 클러스터는 형식적으로만 연결

처음엔 개발 속도가 빠르다.
하지만 규모가 커지면
수정 하나가 전체를 흔들기 시작한다.

1) 전역 변수 남용

전역 변수는 당장 편하다.
어디서든 값에 접근할 수 있고,
와이어도 깔끔해 보인다.

하지만 프로젝트가 커지면
이 편의성은 그대로 위험이 된다.

• 누가 값을 바꿨는지 알 수 없고
• 언제 바뀌었는지 추적이 어렵고
• 사이드 이펙트가 눈에 안 보인다

디버깅 시간은
기능 구현 시간보다 더 길어진다.

2) 책임이 섞인 VI 구조

하나의 VI가

• UI 제어
• 장비 통신
• 데이터 처리
• 로그 기록

를 모두 맡기 시작하면
그 VI는 점점 건드리기 어려운 존재가 된다.

작은 수정 하나가
전혀 상관없는 동작을 깨뜨린다.
결국 “일단 건들지 말자”가 된다.

이 순간부터 프로젝트는 늙는다.

3) 에러 처리가 형식으로만 남는다

에러 클러스터는 연결돼 있지만
실제로는 아무 판단도 하지 않는 경우가 많다.

• 에러가 나도 그냥 통과
• 로그 없이 무시
• UI에는 아무 표시도 없음

문제는
실제 장비 연동이나 장시간 운용에서는
이 작은 방치가 치명적인 장애로 이어진다는 점이다.

4) 하드웨어 의존 로직이 퍼져 있다

장비 제어 코드가
여기저기 흩어져 있으면
장비가 바뀌는 순간 프로젝트는 흔들린다.

• 포트 설정
• 타이밍
• 초기화 순서

이 로직이 분리돼 있지 않으면
유지보수는 사실상 불가능해진다.

5) 구조를 바꾸는 타이밍을 놓친다

LabVIEW 프로젝트는
“아직 쓸 만한데?”라는 이유로
리팩토링 타이밍을 계속 미룬다.

하지만 어느 순간 오면
이 선택지는 둘 중 하나가 된다.

• 구조를 뜯어고치거나
• 기능 추가를 포기하거나

대부분은 그때서야 깨닫는다.

“조금만 일찍 정리했어도…”

LabVIEW 프로젝트가 오래 가려면
속도보다 구조가 먼저다.

• 상태는 명확하게 관리하고
• 책임은 VI 단위로 분리하고
• 에러는 반드시 의미 있게 처리한다

이 세 가지만 지켜도
프로젝트 수명은 눈에 띄게 늘어난다.

돌아가는 코드보다
견딜 수 있는 코드가
결국 가장 빠른 코드다.

오늘은 랩뷰에서 시퀀스 구조 사용하는 방법에 대해서 알아보겠습니다.,

이 시퀀스 구조는 언제 사용할까요?

프로그램이 동작할 때, 무언가를 수행한 후 다른 동작을 수행해야 할 때가 있습니다.

이렇게 명확하게 순서가 필요할 경우 시퀀스 구조를 사용합니다.

이렇게 플랫 시퀀스 구조를 선택하여 만들어주면 시퀀스 구조가 만들어집니다.

이 플랫 시퀀스 구조는 무엇을 말할까요?

이렇게 영화 프레임처럼 가로로 프로그램 순서를 지정해 줄 수 있습니다.

이 플랫 시퀀스는 한눈에 보기 좋다는 장점이 있죠.

하지만 프로그램이 복잡해지고 단계가 많아지면 옆으로 쭉 늘어나서 이동이 힘들죠.

그래서 우리가 페이지를 넘기듯 사용할 수 있는 다층시퀀스를 사용할 수도 있습니다.

변경방법은 마우스 우클릭해서 다층 시퀀스로 대체를 눌러주시면 되요

그러면 이처럼 페이지가 보이는 다층 시퀀스로 변경이 됩니다.

이렇게 해서 프로그램을 차면 한 눈에는 못봐도 모니터가 작고 페이지가 많을 때는 훨씬 프로그램짜기 쉽겠죠

이 다층시퀀스에서 데이터를 다음 페이지로 넘길 때 쓰기 위한 방법도 알아보겠습니다.

이렇게 시퀀스 로컬추가를 해주면 다음페이지에 데이터를 넘길 수가 있습니다.

이렇게 데이터가 넘어갔단 의미로 화살표가 있죠

위 사진과 화살표 방향이 반대입니다.

이렇게 앞선 페이지의 데이터를 받아 올 수 있습니다.

이상 랩뷰에서 시퀀스 구조에 대해서 알아봤습니다.

pc와 장비간 통신이 이루어질 때, 가장 흔하고 오래된 통신 방식인 시리얼통신을 랩뷰에서 구현해보고자 한다.

가장 먼저 ni max에서 필요한 드라이버가 설치되어져 있는지 확인한다.

위에 표시된 ni-488.2, ni-visa가 설치되어 있으면 드라이버는 설치되어 있다고 보면 된다.

시리얼 통신 관련 vi들은 인스트루먼트i/o->시리얼로 들어가면 볼 수 있다.

이와 같이 시리얼통신은 ni-visa를 사용하기에 ni-visa가 필수로 설치되어 있어야한다.

위 블록다이어그램과 같이 하면 간단하게 시리얼 통신이 가능하다.

이는 랩뷰 예제에서 쉽게 찾아볼 수 있는 형태이다.

이를 응용하여 자신이 원하고자 하는 프로그램에 적용하면 랩뷰를 이용한 시리얼 통신은 간단하게 가능하다.

위 소스내용중에 주의 할 점은 딜레이 쪽인데 장비와의 소통시간이 필요하기때문에 딜레이는 필수로 들어가야한다.

딜레이가 없을 시 데이터는 vi가 종료된 후 날라올 것이기 때문에 확인이 불가능하다.

딜레이가 싫은 사람은 옆에있는 Bytes at Port를 이용해서 while문과 함께 사용해도 된다.

이렇게 하면 500ms동안 데이터가 들어오는지 안들어오는지 확인을 하게 된다.

500ms동안 보는 것을 만들어놓은 이유는 해당 부분이 없으면 장비가 정상연결이 안되어있으면 무한루프에 빠질 수 있기 때문이다.

오늘은 랩뷰 GPIB 통신에 대해서 보려고하는데요.

우선 GPIB통신이 무엇인지 부터 알아야겠습니다.

GPIB의 약자 같은거는 굳이 알 필요는 없겠죠.

단순하게 장비와 통신하기위한 방법이라고만 알고 있으면 되겠습니다.

GPIB 통신을 하기위해서 장비와 PC간 연결이 잘되었는지 확인을 해야합니다.

이것은 NI MAX에서 연결되어진 장비를 확인해 볼 수 있습니다.

연결되어진 장비가 있으면 디바이스와 인터페이스에 확인이됩니다.

GPIB로 연결되어진게 있으면 GPIB::02::INSTR 대략 이런식으로 되어 있는것을 볼 수 있습니다.

GPIB로 연결되어 있으면 대부분 VISA 방식을 이용해서 하는데요.

랩뷰에는 이것이 되게 쉽게 잘 되어 있습니다.

기존 C기반의 언어들을 보면 VISA32.DLL 같은 것들 넣고 어쩌고 복잡한 과정을 해줘야 하는데요.

랩뷰는 기본적으로 다 구성되어져 있어서 가져다 쓰기만하면됩니다.

이렇게 VISA 관련 내용들이 다 있죠.

C언어에서 쓰듯이 OPEN 하고 쓰고 읽고 하면 됩니다.

OPEN은 VISA 고급을 눌러보면 확인이 가능합니다.

그러면 이제 이 VISA 통신 예제를 확인해볼게요.

랩뷰 예제를 보면 쉽게 확인 됩니다.

이렇게 GPIB를 VISA를 사용해서 하는것에 대해 예제프로그램이 있습니다.

이것을 입맛에 맞게 변형해서 사용하면 쉽게 되겠죠

이렇게 간단하게 사용할 수 있습니다.

간단하게 드래그 앤 드롭으로 GPIB 통신이 되죠.

할 것은 GPIB 커맨드만 확인해주면 되겠습니다.

간혹 장비마다 터미널 문자가 틀리면 동작이 안 할 때가 있는데 그 때는 문자열에 다 추가해주면되겠죠.

이상 GPIB VISA 방식에 대해서 알아봤습니다.

날씨가 많이 덥네요.

카페에와서 일하다가 심심하니 랩뷰관련 글하나 작성합니다.

C언어로 코딩할 때, 많이 쓰는 기능 중 하나죠.

이벤트.

프로그램이 수행 중 특정 행위가 필요할 때, 이 이벤트 구조를 많이 사용합니다.

이벤트 구조 굉장히 다양한 방법으로 사용을 할 수가 있는데요.

랩뷰에서 가장 간단하게 사용하는 방법을 이번에 적어보겠습니다.

이벤트 호출이니 기본적으로 멀티스레드로 돌아가는게 가장 좋겠죠.

그래서 랩뷰에서 WHILE 구조 하나를 넣고 그안에 이벤트 구조를 넣으면 랩뷰에선 간단하게 이벤트 호출 준비가 완료됩니다.

이렇게 해서 이벤트 호출 준비는 완료됩니다.

이렇게 하면 일정시간마다 이벤트가 발생하는 이벤트 구조가 만들어집니다.

위 사진은 무한대기입니다. 이것을 100ms 마다 이벤트가 발생하게 바꿔보겠습니다.

화살표로 표시해둔 곳의 시간을 변경하면 됩니다.

저는 이 구조를 이용해서 장비의 자동모델 변경을 하는데 사용하고 있습니다.

장비에 연결되어 있는 장비가 변경되는지 설정되어있는 시간마다 확인을 하는거죠.

그럼 키보드 이벤트 호출도 한 번 해볼까요?

이벤트 구조에 마우스 커서를 가져가 대서 오른쪽버튼을 누른 후 이벤트 케이스 추가를 눌러줍니다.

이런 창이 뜨는데 위 사진에서 키 앞에 +(더하기) 버튼이 보일겁니다.

여기에서 +버튼을 눌러서 키다운을 선택하고 확인을 눌러줍니다.

그러면 우리가 키보드를 누를때마다 해당 이벤트가 실행이 됩니다.

여기에서 이제 원하는 동작을 하게 만들어주면 됩니다.

여기서 조합키와 플랫폼 조합키는 무엇인지 확인해 볼까요?

인디케이터를 생성해보니 이렇게 있네요.

저는 단순하게 Ctrl + x를 누르면 프로그램이 종료하게 하는 것을 만들어 보겠습니다.

위의 문자가 아스키코드를 받아오기 때문에 위와 같이 처리를 해줍니다.

대소문자 상관없이 실행되게 하기 위해서 xX 이 두개를 다 처리해줍니다.

이상 랩뷰에서 이벤트 호출하기 였습니다.

LABVIEW에 대해서 아시나요??^^

LABVIEW는 National Instrument 에서 만들었죠.

저도 대학다닐 때까지만 해도 몰랐습니다.

회사에 입사하고 팀이 바뀐 후에 알았죠..

그곳에서 pxi라는 장비를 들여왔더라구요..

당시 아무도 이 장비를 만질 수 있는 사람이 없었죠..

그래서 이 장비를 들여온 주체가 제가 속한 팀이었고...

저는 소프트웨어를 담당하고 있다보니 제가 속해있는팀 제가 속한 파트에서 맡기로 합니다.

그 때, 처음으로 labview를 접하게 되었죠..

위 장비 보시면 꼭 컴퓨터 같죠..

번호가 붙어 있는 곳에 모듈이 하나씩 들어가는데요.

그 모듈 하나하나가 우리가 사용하는 계측장비가 들어가게 되요..

양산을 위한 테스트나 칩 테스트를 할 때, 이장비를 사용하는 거죠..

칩이 나왔을 때, 사람이 하나하나 손으로 테스트 하잖아요..

Manual Test라고.. 이것을 대신하기도 하는 장비죠..

제가 다녔던 회사에서 이 장비를 산 이유는 양산을 위해서 테스트 하러 갔을 때, 불량이 나면 비용이 너무 많이 소모된다는 것이죠.

저 장비 하나를 다채우면 1억이 넘게 드는데 그게 더 이익이라는 판단이 나왔던 거죠.

저 장비를 컨트롤 할 때 쓰이는 툴이 teststand라는 거구요..

이 teststand안에서 또 명령을 내리는 모듈 프로그램을 만들어야하는데 그것이 랩뷰로 만들어진답니다..

teststand는 순서를 정해주는 프로그램이구요..

labview의 장점은 gpib, 시리얼통신 등 장비와 통신하는 프로그램을 만드는데 진짜 좋아요.

자동차에 쓰이는 can통신 하는 모듈도 있다고 하더군요...

저는 사용해보지 않았지만요..

전 저 장비를 사용할 때, 파워서플라이, 스코드, 디지털 멀티미터, adc, 스위치, 정도로 써본 것 같네요..^^

무엇인가 더 있었던 것 같기도한데...ㅋㅋㅋㅋㅋㅋ

기억이 안납니다..

다음 포스팅에서는 랩뷰 내부를 한 번 보기로 할게요..^^