ControlLogix Controllers
프로그램 가능 논리 제어기(PLC)는 새로운 기술이 지속적으로 추가되면서 계속 발전하고 있습니다. PLC는 원래 출력의 온/오프 제어뿐 아니라 타이밍 및 카운팅 기능을 수행하기 위해 사용되던 릴레이 뱅크(relay bank)를 대체하기 위한 장치로 시작되었습니다. 이후 다양한 수학 및 논리 조작 기능이 점진적으로 추가되었습니다. 오늘날 확장되는 산업 제어 시스템의 요구를 충족시키기 위해, 주요 자동화 기업들은 프로그램 가능 자동화 제어기(programmable automation controller, PAC)(그림 15-1)라 불리는 새로운 등급의 산업용 제어기를 개발했습니다.
PAC는 물리적 형태는 PLC와 유사하지만, 하나의 프로그래밍 환경 안에 고급 통신 제어, 데이터 로깅(data logging), 신호 처리(signal processing), 모션 제어(motion control), 프로세스 제어(process control), 머신 비전(machine vision) 기능을 통합하고 있습니다.
Allen‑Bradley의 프로그램 가능 자동화 제어기 제품군에는 ControlLogix 시스템, CompactLogix 시스템, FlexLogix 시스템, SoftLogix 5800 컨트롤러, DriveLogix 시스템이 포함됩니다. 소프트웨어는 PAC와 PLC의 본질적인 차이점입니다. 기본적인 래더 논리 구성이 변경되는 것은 아니지만, 명령의 주소 지정 방식(addressing)이 달라집니다. 이후 본 장의 각 절에서는 Logix 제어 플랫폼 컨트롤러에 적용되는 소프트웨어 활용에 대해 다룰 것입니다. 이전 장에서 다루었던 기본 래더 논리 명령 및 기능(bit, timer, counter 등)을 알고 있다고 가정하며, 이 장에서는 이를 반복하지 않습니다.
Part 1 Memory and Project Organization
Memory Layout
ControlLogix 프로세서는 유연한 메모리 구조를 제공합니다. 특정 유형의 데이터나 I/O를 위해 고정적으로 할당된 메모리 영역이 없습니다. ControlLogix 컨트롤러의 내부 메모리 구성은 RSLogix 5000 소프트웨어를 사용하여 프로젝트를 생성할 때 사용자가 직접 구성합니다(그림 15-2). 이 기능을 통해 프로그램 데이터는 특정 메모리 구조에 맞추기 위해 제한될 필요 없이, 응용 요구에 맞게 자유롭게 구성될 수 있습니다. ControlLogix(CLX) 시스템은 단일 새시(chassis) 내에 독립형 컨트롤러와 I/O 모듈만 포함할 수도 있으며, 여러 새시와 네트워크가 함께 동작하는 고도로 분산된 시스템일 수도 있습니다.
Configuration
모듈식 CLX 시스템의 구성(configuration)은 컨트롤러와 공정(process) 간의 통신 링크를 설정하는 작업을 포함합니다. 프로그래밍 소프트웨어는 데이터를 송수신하기 위해 어떤 CLX 하드웨어가 사용되는지 알아야 합니다. 구성 정보에는 사용되는 프로세서(processor) 유형과 I/O 모듈에 대한 정보가 포함됩니다
RSLogix 5000 프로그래밍 소프트웨어는 Allen‑Bradley ControlLogix 컨트롤러의 메모리 구성(memory organization)을 설정하거나 구성(configuration)하는 데 사용됩니다. RSLinx 통신 소프트웨어는 그림 15-3에 나타난 것처럼 RSLogix 5000 프로그래밍 소프트웨어와 ControlLogix 하드웨어 간의 통신 링크를 설정하는 데 사용됩니다. 컨트롤러와 통신을 설정하려면 RSLinx 소프트웨어에서 드라이버(driver)를 생성해야 합니다. 이 드라이버는 하드웨어 장치에 대한 소프트웨어 인터페이스 역할을 합니다. RSWho는 구성된 모든 네트워크 드라이버를 단일 창에서 볼 수 있도록 하는 네트워크 브라우즈 인터페이스(network browse interface)입니다.
그림 15-4는 구성 과정의 일부로 사용되는 ControlLogix 컨트롤러 속성(controller properties) 및 모듈 속성(module properties) 대화 상자(dialog box)의 예를 보여줍니다. 표시된 파라미터는 일반적으로 필요한 기본 정보를 나타냅니다. 컨트롤러 구성 작업이 먼저 완료되면, RSLogix 5000 소프트웨어를 사용하여 I/O 모듈이 구성됩니다. 모듈은 올바르게 구성되지 않으면 동작하지 않습니다. 이 소프트웨어는 모든 ControlLogix 모듈을 구성하는 데 필요한 하드웨어 정보를 포함하고 있습니다.
Project
RSLogix 소프트웨어는 컨트롤러의 프로그래밍 및 구성 정보를 ‘프로젝트(project)’라는 파일에 저장합니다. 그림 15-5는 프로세서의 프로젝트 파일에 대한 블록도(block diagram)를 보여줍니다. 프로젝트 파일은 해당 프로젝트와 관련된 모든 정보를 포함합니다. 프로젝트 파일의 주요 구성 요소는 태스크(task), 프로그램(program), 루틴(routine)입니다. 컨트롤러는 한 번에 오직 하나의 프로젝트만 저장하고 실행할 수 있습니다.
RSLogix 5000 컨트롤러 오거나이저(controller organizer)(그림 15-6)은 프로젝트 구성을 트리(tree) 형식으로 표시하며, 여기에는 태스크(task), 프로그램(program), 루틴(routine), 데이터 타입(data type), 트렌드(trend), I/O 구성(configuration), 태그(tag)가 나타납니다. 각 폴더는 관련 기능을 묶어서 그룹화합니다. 이러한 구조는 전체 프로젝트를 한눈에 조망하고 탐색을 단순화하는 데 도움이 됩니다.
각 폴더 앞에는 ‘+’ 또는 ‘–’ 기호가 있는 아이콘이 표시됩니다. ‘+’ 기호는 폴더가 닫혀 있음을 나타내며, 클릭하면 트리가 확장되어 폴더 내부 파일이 나타납니다. ‘–’ 기호는 폴더가 이미 열려 있고 그 내용이 보이고 있음을 의미합니다. 마우스 오른쪽 버튼을 클릭하면 다양한 상황별(context‑sensitive) 팝업 메뉴가 나타납니다. 이는 속성 창(property window)이나 메뉴 바(menu bar)의 옵션에 빠르게 접근하는 데 유용합니다.
Tasks
태스크(task)는 프로젝트 내에서 스케줄링의 첫 번째 수준입니다. 태스크는 예약된 프로그램들의 집합이며, 하나의 태스크가 실행되면 그와 연결된 프로그램들이 지정된 순서대로 실행됩니다. 이 프로그램 목록을 프로그램 스케줄(program schedule)이라고 합니다. 태스크는 특정 조건에 따른 스케줄링을 제공하며, 자체적으로 실행 가능한 코드는 포함하지 않습니다. 어느 시점에도 한 번에 하나의 태스크만 실행될 수 있습니다. 컨트롤러가 지원할 수 있는 태스크 수는 컨트롤러의 사양에 따라 달라집니다. 태스크의 주요 유형은 그림 15-7과 같으며, 다음과 같이 요약됩니다.
• Continuous task(연속 태스크) 는 중단 없이 계속 실행되지만, 주기적 태스크(periodic task)가 실행될 때 항상 인터럽트(interrupt)를 받습니다. 연속 태스크는 가장 낮은 우선순위를 갖습니다. ControlLogix의 연속 태스크는 SLC 500 플랫폼의 파일 2(File 2)와 유사합니다. 여기에서 연속 태스크는 “Main Task”라는 이름을 가집니다.
• Periodic task(주기적 태스크) 는 시간 기반 인터럽트처럼 동작합니다. 일정한 시간 간격으로 연속 태스크를 인터럽트하며, 고정된 시간 동안 실행됩니다.
• Event task(이벤트 태스크) 역시 인터럽트 방식으로 동작합니다. 그러나 시간 기반이 아니라, 특정 이벤트가 발생하거나 발생하지 않았을 때 이를 트리거(trigger)로 하여 실행됩니다.
Programs
프로그램(program)은 프로젝트 내 스케줄링의 두 번째 수준입니다. Main Task 아래의 폴더들은 어떤 프로그램이 어떤 순서로 실행될지를 결정합니다. 프로그램 자체에는 실행 가능한 코드가 없습니다. 그림 15‑8에서 볼 수 있듯이, 프로그램 내 루틴(routine)은 컨트롤러 오거나이저(controller organizer)의 해당 태스크 아래에 나열된 순서대로 실행됩니다. 예시에서 나열된 순서에 따르면 Main Program이 먼저 실행되고, 그다음 Program_A, 이후 Program_B가 실행됩니다.
태스크에 할당되지 않은 프로그램은 언스케줄드(unscheduled) 상태입니다. 이러한 프로그램은 컨트롤러에 다운로드되지만 실행되지 않으며, 필요할 때까지 언스케줄드 상태로 유지됩니다. RSLogix 5000 소프트웨어 버전에 따라 태스크 하나에 최대 100개의 프로그램을 스케줄할 수 있습니다.
Routines
루틴(routine)은 프로젝트 내 스케줄링의 세 번째 수준이며, 프로젝트의 실제 실행 코드를 포함합니다. 각 루틴에는 특정 프로그래밍 언어에 맞는 논리 요소(logic element)들이 포함됩니다. 루틴을 생성할 때, 해당 루틴은 래더 논리(ladder logic), 순차 기능도(sequential function chart), 함수 블록 다이어그램(function block diagram), 구조적 텍스트(structured text) 중 하나로 지정됩니다(그림 15‑9). 하나의 루틴은 반드시 하나의 언어로만 작성되어야 합니다.
프로젝트 내 루틴의 개수는 컨트롤러 메모리 용량에 의해서만 제한됩니다. 표준 루틴 라이브러리를 생성하여 여러 기계나 응용에 재사용할 수도 있습니다. 루틴은 다음 세 가지 유형 중 하나로 지정될 수 있습니다.
• Main routine(메인 루틴) : 프로그램이 실행될 때 가장 먼저 실행되는 루틴입니다. 각 프로그램은 하나의 메인 루틴을 가지며, 뒤이어 여러 서브루틴(subroutine)이 올 수 있습니다.
• Subroutine(서브루틴) : 다른 루틴에 의해 호출되는 루틴입니다. 복잡하거나 대형 작업 또는 둘 이상의 프로그래밍 언어가 필요한 작업을 처리하는 데 사용됩니다.
• Fault routine(폴트 루틴) : 컨트롤러가 프로그램 오류를 감지했을 때 실행되는 루틴입니다. 각 프로그램은 필요에 따라 하나의 폴트 루틴을 포함할 수 있습니다.
Tags
기존 방식의 컨트롤러와 달리, ControlLogix는 태그 기반(tag‑based) 주소 구조를 사용합니다. 태그(tag)는 단순한 주소가 아니라 실제 응용을 설명하는 의미 있는 이름입니다. 태그는 데이터를 나타내며, 컨트롤러 메모리에서 해당 데이터가 저장되는 위치를 식별합니다. Logix 5000 소프트웨어로 개발된 응용에서는 SLC 500과 같은 사전 정의된 데이터 테이블이 없습니다. 프로그램에서 데이터를 사용하거나 모니터링하려면 그림 15‑10처럼 태그 이름을 사용하여 메모리 위치를 참조합니다. 이를 통해 데이터의 용도를 분명히 나타낼 수 있으며, 자체적으로 문서화(self‑documented)된 논리를 구성할 수 있습니다.
데이터를 묶어서 사용하려면 배열(array)을 생성할 수 있으며, 배열은 동일한 유형의 태그들을 그룹화한 것입니다.
스코프(scope)는 어떤 프로그램에서 특정 태그에 접근할 수 있는지를 결정합니다. 태그를 만들 때 반드시 스코프를 지정해야 하며, 태그 스코프는 프로그램 스코프(program scope)와 컨트롤러 스코프(controller scope)의 두 가지가 있습니다.
• Program scope tag(프로그램 스코프 태그) : 특정 프로그램 내 루틴만 접근할 수 있는 데이터(로컬 데이터)입니다. 다른 프로그램의 루틴에서는 접근할 수 없습니다.
• Controller scope tag(컨트롤러 스코프 태그) : 컨트롤러 내 모든 루틴에서 접근할 수 있는 데이터(전역 데이터)입니다.
그림 15‑11은 프로젝트 내 Program A와 Program B를 보여줍니다. 두 프로그램 모두 동일한 이름(Tag_1, Tag_2, Tag_3)의 프로그램 스코프 태그를 가지고 있지만, 서로 다른 프로그램 스코프이므로 서로 아무 관련이 없습니다. 동일한 태그 이름을 여러 프로그램에서 로컬 변수로 사용할 수 있는 이유는 태그를 생성할 때 그 스코프를 선택하기 때문입니다.
태그(tag)의 스코프(scope)는 태그를 생성할 때 반드시 선언해야 합니다. 그림 15-12는 컨트롤러 오거나이저(controller organizer)에서 프로그램에 할당된 프로그램 스코프 태그와 컨트롤러 스코프 태그가 어떻게 표시되는지를 보여줍니다. I/O 태그는 자동으로 컨트롤러 스코프(controller scope) 태그로 생성됩니다.
태그에는 네 가지 유형이 있습니다: base 태그, alias 태그, produced 태그, consumed 태그입니다. 태그 유형은 프로젝트 내에서 태그가 어떻게 동작하는지를 정의합니다.
Base 태그는 프로젝트의 논리에서 사용할 다양한 유형의 데이터를 저장합니다. Base 태그는 데이터가 저장되는 메모리 위치를 정의합니다. Base 태그의 메모리 사용량은 태그가 나타내는 데이터 유형에 따라 달라집니다. 그림 15‑13의 base 태그 예인 Local:2:O.Data.4는 다음 형식을 기반으로 합니다.
Alias 태그는 태그의 대체 이름(alias)을 만드는 데 사용됩니다. Alias 태그는 이미 존재하는 메모리 위치에 대한 또 다른 이름일 뿐입니다. Alias 태그는 base, alias, consumed, produced 태그를 참조할 수 있습니다. Alias 태그는 실제 입력 또는 출력의 의미 있는 이름을 만들 때 자주 사용됩니다. 그림 15‑14는 alias 태그 사용 예를 보여줍니다. Alias 태그(Fan_Motor)는 base 태그(<Local:2:O.Data.5>)에 연결되어 있으므로, base 태그에 수행되는 모든 동작은 alias 태그에도 동일하게 적용되며 그 반대도 마찬가지입니다. Alias 이름은 이해하기 쉽고 응용에 더 직접적으로 연결되며, base 태그는 ControlLogix 새시(chassis) 내 출력 포인트의 실제 물리적 위치를 포함합니다.
Produced/consumed 태그는 두 개 이상의 장치 간에 네트워크를 통해 태그 정보를 공유하는 데 사용됩니다. Produced 태그는 데이터를 전송하고, Consumed 태그는 데이터를 수신합니다. Produced 태그는 항상 컨트롤러 스코프입니다. 그림 15‑15는 하나의 컨트롤러가 produced 데이터를 생성해 네트워크를 통해 이를 두 개의 소비(consume) 컨트롤러에 전달하는 예입니다. Producing 컨트롤러에는 produced 유형의 태그가 존재하며, consuming 컨트롤러에는 동일한 이름을 가진 consumed 유형의 태그가 존재합니다.
응용을 설계할 때, 시스템 내 다른 컨트롤러로 데이터를 백플레인(backplane)을 통해 전송(produce)하고 다른 컨트롤러의 태그를 수신(consume)하도록 구성합니다. 이를 통해 각 컨트롤러가 어떤 데이터를 송수신할지 선택적으로 관리할 수 있습니다. 또한 여러 컨트롤러가 동일한 produced 데이터를 동시에 공유할 수 있어, 동일한 데이터를 여러 메시지로 전송할 필요가 없습니다.
Logix 컨트롤러는 32비트 기반 연산 구조를 가집니다. Base 태그가 가질 수 있는 데이터 유형에는 BOOL, SINT, INT, DINT, REAL이 있으며, 그림 15‑16 및 아래 목록에서 볼 수 있습니다. 컨트롤러는 모든 데이터를 최소 4바이트 또는 32비트 단위로 저장합니다.
• BOOL 또는 Boolean base 태그는 4바이트 메모리 위치의 비트 0에 저장되는 1비트(bit) 데이터입니다. 나머지 비트 1~31은 사용되지 않습니다. BOOL의 범위는 0과 1이며, 각각 off와 on을 의미합니다.
• SINT 또는 Single Integer base 태그는 8비트의 메모리를 사용하며, 데이터는 비트 0~7(이를 low byte라고도 함)에 저장됩니다. 나머지 3바이트(비트 8~31)는 사용되지 않습니다. SINT의 범위는 -128에서 +127까지입니다.
• INT 또는 Integer base 태그는 16비트이며, 비트 0~15(이를 lower bytes라고도 함)에 저장됩니다. 비트 16~31은 사용되지 않습니다. INT의 범위는 -32,768에서 +32,767입니다.
• DINT 또는 Double Integer base 태그는 32비트(4바이트 전체)를 사용하며, 범위는 -2³¹(−2,147,483,648)에서 +2³¹−1(+2,147,483,647)입니다.
• REAL base 태그 역시 32비트 메모리를 사용하며, 범위는 IEEE 부동소수점(floating‑point) 표준에 기반합니다.
Structures
또 다른 데이터 유형으로 구조체(structure) 가 있습니다. 구조체 타입 태그는 서로 다른 데이터 타입을 하나의 단위로 묶어 특정 목적을 수행하도록 구성됩니다. 그림 15‑17은 RSLogix 구조체 예를 보여줍니다. 구조체의 각 요소는 멤버(member)라고 하며, 멤버는 서로 다른 데이터 타입일 수 있습니다.
ControlLogix 컨트롤러에는 세 가지 구조체 유형이 있습니다:
- 사전 정의(predefined),
- 모듈 정의(module‑defined),
- 사용자 정의(user‑defined).
컨트롤러는 타이머(timer), 카운터(counter), 메시지(message), PID와 같은 사전 정의 구조체를 자동으로 생성합니다. 그림 15‑18은 사전 정의된 카운터 구조체 예로, 여기에 preset 값, accumulated 값, 명령(status bit) 정보가 포함됩니다.
모듈 정의 구조체는 I/O 모듈이 시스템에 구성될 때 자동으로 생성됩니다. 입력 또는 출력 모듈을 추가하면 컨트롤러 태그에 여러 정의된 태그가 자동으로 생성됩니다. 그림 15‑19는 디지털 입력 모듈을 추가한 후 생성되는 두 태그(Local:1:C, Local:1:I)를 보여줍니다.
- 입력 태그 중 Data로 표시된 부분에는 실제 입력 비트가 포함됩니다.
- 구성(configuration) 태그는 모듈의 동작 특성과 설정을 결정합니다.
- Local이라는 이름은 태그가 프로세서와 같은 랙(rack)에 있음을 의미합니다.
- 숫자 1은 모듈이 새시(chassis)의 슬롯(slot) 1에 있음을 나타냅니다.
- I와 C는 각각 입력(input) 데이터와 구성(configuration) 데이터를 의미합니다.
사용자 정의 구조체(user‑defined structure)는 사전 정의 구조체를 보완하여, 특정 데이터를 그룹으로 저장하고 처리하기 위한 사용자 맞춤 구조를 만들 수 있도록 합니다. 그림 15‑20은 저장 탱크(storage tank)에 대한 데이터를 포함하는 사용자 정의 구조체 예를 보여줍니다. 탱크와 관련된 모든 데이터가 하나로 묶여 저장됩니다.
설계 단계에서 프로그래머는 저장 탱크의 모든 요소를 포함하는 일반적인 사용자 정의 메모리 구조를 생성합니다. 각 멤버는 의미 있는 이름을 가지며, 온도는 REAL(부동소수점), 교반기 속도(agitator speed, rpm)는 DINT(정수)와 같이 해당 데이터에 적합한 타입으로 생성됩니다. 설치 및 유지보수 기술자는 탱크 운전과 관련된 모든 데이터를 한 곳에서 쉽게 확인할 수 있습니다.
Creating Tags
태그(tag)를 생성하는 방법은 여러 가지가 있습니다. 프로그램을 작성하기 전에 태그 편집기(tag editor)에서 태그를 생성할 수도 있고, 프로그램을 작성하면서 태그 이름을 입력할 수도 있으며, 태그 이름 대신 물음표(?)를 사용해 나중에 태그를 지정할 수도 있습니다. 그림 15‑21은 새로운 태그 대화 상자(new tag dialog box)에서 생성된 컨트롤러 스코프(controller scope) base 태그의 예를 보여줍니다.
태그를 정의할 때는 다음 정보를 지정해야 합니다.
• 태그 이름(tag name): 알파벳 문자 또는 밑줄(_)로 시작해야 합니다. 이름에는 알파벳, 숫자, 밑줄만 사용할 수 있으며 최대 40자까지 가능합니다. 연속된 밑줄 또는 마지막에 밑줄을 사용할 수 없으며, 대소문자를 구분하지 않고, 공백(space)은 사용할 수 없습니다.
• 선택적 태그 설명(description): 최대 120자까지 입력할 수 있습니다.
• 태그 유형(tag type): base, alias 또는 consumed 중 하나를 선택합니다.
• 데이터 타입(data type): 사전 정의 또는 사용자 정의 데이터 타입 중에서 선택합니다.
• 태그 스코프(scope): 컨트롤러 스코프 또는 기존 프로그램 스코프 중 하나를 선택합니다.
• 태그를 모니터링할 때 사용할 표시 형식(display style): 프로그래밍 소프트웨어에서 제공하는 형식 중 선택합니다.
• 태그를 다른 컨트롤러에서 사용할 수 있도록 할지 여부, 그리고 해당 태그를 소비(consume)할 수 있는 컨트롤러 수.
Monitoring and Editing Tags
태그가 생성된 후에는 그림 15‑22에 나타난 Tag 모니터 창(Monitor Tags window)에서 모니터할 수 있습니다. Monitor Tags를 선택하면 해당 태그들의 실제 값이 표시됩니다. Force Mask 열(column)은 문제 해결(troubleshooting) 과정에서 입력과 출력을 강제(force)하기 위한 기능입니다.
또한 그림 15‑23의 Edit Tags 창을 사용해 기존 태그를 편집하거나 새로운 태그를 생성할 수 있습니다. Edit Tags를 선택하면 새로운 태그를 만들거나 기존 태그 속성을 수정할 수 있습니다.
Array
많은 제어 프로그램에서는 실행 중(runtime) 접근할 수 있는 테이블 형태의 데이터를 메모리에 저장해야 합니다. 배열(array)은 여러 데이터 조각을 포함하는 태그 유형이며, 배열의 각 요소(element)는 동일한 데이터 타입(예: BOOL, SINT, INT)이어야 합니다. 배열은 연속된(contiguous) 컨트롤러 메모리 블록을 차지하며, 값들의 테이블과 유사합니다.
배열 데이터 타입 사용은 ControlLogix 프로세서에서 가장 빠른 데이터 처리량(data throughput)을 제공합니다. 동일한 데이터 타입의 연속적인 메모리 공간을 차지하기 때문에 대량의 데이터를 효율적으로 읽어올 수 있습니다. 배열은 1차원, 2차원, 3차원으로 구성할 수 있으며(그림 15‑24), 포함하려는 데이터의 형태에 따라 적절한 구조를 선택합니다.
배열 내 단일 태그는 배열 요소(element)입니다. 요소는 기본 데이터 타입 또는 구조체(structure)가 될 수 있습니다. 요소 번호는 0부터 시작하여, 전체 요소 수에서 1을 뺀 숫자까지입니다.
그림 15‑25는 다섯 개의 온도 값을 저장하기 위해 생성된 1차원 배열의 메모리 레이아웃 예시입니다. 태그 이름은 Temp이며, 배열 요소는 0~4까지 총 5개로 구성됩니다.
Part 2 Bit-Level Programming
Program Scan
CLX 컨트롤러가 프로그램을 실행할 때에는, 프로세스를 제어하는 외부 장치의 상태가 실시간으로 어떻게 변하는지를 반드시 알아야 합니다. 각 동작 사이클 동안 프로세서는 모든 입력을 읽고, 이 값을 기반으로 사용자 프로그램에 따라 출력에 전원을 인가하거나 차단합니다. 이 과정을 프로그램 스캔이라고 합니다.
그림 15-26은 래더 논리가 실행되는 동안, 컨트롤러의 동작 사이클에서 Logix 컨트롤러로 들어오고 나가는 신호 흐름을 보여줍니다. 프로그램 스캔 중 컨트롤러는 다음과 같이 왼쪽에서 오른쪽, 위에서 아래 방향으로 런(rung)과 분기를 읽습니다.
• 한 번에 하나의 런(rung)만 스캔합니다.
• 프로그램이 스캔되는 동안 입력 상태가 True(1 또는 ON)인지 False(0 또는 OFF)인지 확인합니다.
• 입력으로부터의 상태 신호는 입력 태그(input tag)로 전송되어 저장됩니다.
• 프로세서가 프로그램을 스캔하면서 입력은 True 또는 False 조건인지 확인되고, 이 값에 따라 래더 논리가 평가됩니다.
• 각 런(rung)을 평가한 결과로 나온 ON 또는 OFF 동작은 출력 태그(output tag)로 전송되어 저장됩니다.
• 스캔 중 출력 업데이트 단계에서는 출력 모듈을 통해 해당 출력 값이 프로세스 또는 기계로 전송됩니다.
• I/O 업데이트는 논리 스캔과 비동기(asynchronous) 방식으로 이루어집니다. ControlLogix 프로세서에서는 두 개의 별도 32비트 비동기 프로세스가 동시에 실행됩니다. 이는 모듈이 프로세서가 래더 런(rung)을 실행하는 어느 시점(또는 여러 시점)에서든 필드(field)로부터 입력 태그를 업데이트하고, 출력 태그를 필드로 기록할 수 있음을 의미합니다. 그 결과 입력 필드 장치 데이터가 입력 태그에 업데이트되는 시점과, 해결된 논리 결과가 출력 모듈 및 해당 필드 장치로 전송되는 시점에 대해 더욱 효율적이고 정교한 제어가 가능해집니다.
Creating Ladder Logic
다른 프로그래밍 언어도 사용할 수 있지만, PLC에서 가장 일반적으로 사용되는 프로그래밍 언어는 래더 논리입니다. 래더 논리 프로그래밍의 명령(instruction)은 크게 입력 명령과 출력 명령 두 가지 범주로 나눌 수 있습니다. 가장 일반적인 입력 명령은 계전기 접점(relay contact)에 해당하며, 가장 일반적인 출력 명령은 계전기 코일(relay coil)에 해당합니다(그림 15-27).
래더 I/O 비트 명령을 생성할 때에는 다음 규칙이 적용됩니다.
• 모든 입력 명령은 출력 명령의 왼쪽에 있어야 합니다.
• 하나의 런(rung)에 입력 명령이 포함되어 있다면, 출력 명령으로 런을 시작할 수 없습니다. 이는 컨트롤러가 출력 명령의 값을 결정하기 전에 모든 입력이 True 또는 False인지 검사하기 때문입니다.
• 런에는 입력 명령이 없어도 되지만, 최소한 하나의 출력 명령은 포함되어야 합니다.
• 런에 하나의 출력 명령만 있는 경우, 해당 런은 항상 True가 됩니다.
• 런의 마지막 명령은 반드시 출력 명령이어야 합니다.
• XIC(Examine If Closed) 접점 명령은 입력 값이 1인지 확인합니다. 입력이 1이면 XIC 명령은 True 값을 반환합니다.
• XIO(Examine If Open) 접점 명령은 입력 값이 0인지 확인합니다. 입력이 0이면 XIO 명령은 True 값을 반환합니다.
• OTE(Output Energize) 코일 명령은 런에 논리 연속성이 있을 때 그와 연결된 태그를 True 또는 1로 설정합니다. True가 되면 출력 장치를 동작시키거나 메모리 값을 1로 설정하는 데 사용할 수 있습니다.
ControlLogix PLC는 하나의 런에 여러 출력 명령을 지원합니다. CLX 컨트롤러는 전통적인 전기 하드와이어 회로나 래더 논리에 부합하지 않는 직렬(serial) 논리도 사용할 수 있습니다. 예를 들어, 그림 15-28에 나타난 두 개의 런은 RSLogix 5000에서 모두 유효합니다.
그러나 동일한 구성이 전기 회로에서 직렬로 출력이 연결된 형태라면 동작하지 않으며, RSLogix 500에서도 동일합니다. 두 경우 모두 RSLogix 5000에서는 tagA와 tagB 명령이 True일 때 출력 tag1과 tag2가 동작합니다.
ControlLogix에서는 그림 15-29와 같이 입력 명령 사이에 출력 명령을 배치할 수 있습니다. 이 예에서는 tagA와 tagB 명령이 True일 때 출력 tag1이 동작합니다. 또한 tagA, tagB, tagC 명령이 모두 True가 되어야 출력 tag2가 동작하도록 설정됩니다.
태그 기반 주소지정(Tag-Based Addressing)
Logix 5000 컨트롤러는 태그 기반 주소지정 구조를 사용합니다. 태그(tag)는 컨트롤러 내부의 데이터가 저장되는 영역을 나타내는 문자 기반 이름입니다. ControlLogix 컨트롤러에서 태그 기반 주소가 어떻게 구현되는지에 대한 예는 그림 15-30에 제시되어 있습니다. 태그 이름은 변수의 의미를 명확히 나타내는 방식으로 지정됩니다. 이 예제에서는 정상적으로 닫힌(normally closed) 고리미트 스위치(high limit switch)가 동작하면 프로그램이 고리미트 표시등(high limit output light)을 켜도록 구성되어 있습니다. 주소지정 형식은 다음과 같이 요약할 수 있습니다.
• 태그 Limit_switch의 물리적 주소는 Local:1:I.Data.2(C)입니다. Local은 모듈이 프로세서와 동일한 랙(rack)에 있음을 의미하며, 1은 모듈이 랙의 슬롯(slot) 1에 있음을 나타냅니다. I는 입력(input) 모듈임을 의미하고, Data는 디지털 입력(digital input)임을 나타냅니다. 2는 리미트 스위치가 모듈의 터미널 2에 연결되어 있음을 나타내며, C는 글로벌 접근이 가능한 컨트롤러 태그(controller tag)임을 의미합니다.
• 태그 High_limit_light의 물리적 주소는 Local:2:O.Data.4(C)입니다. Local은 모듈이 프로세서와 동일한 랙에 있음을 의미하며, 2는 모듈이 슬롯 2에 있음을 나타냅니다. O는 출력(output) 모듈임을 의미하고, Data는 디지털 입력(digital input)임을 나타냅니다. 4는 고리미트 표시등이 모듈의 터미널 4에 연결되어 있음을 의미하며, C는 글로벌 접근이 가능한 컨트롤러 태그임을 의미합니다.
태그 기반 주소지정 방식의 장점 중 하나는 프로그램에서 사용하는 변수 이름 지정이 랙/슬롯 또는 랙/그룹 방식의 시스템처럼 특정 메모리 구조의 고정된 메모리 위치에 묶이지 않는다는 점입니다. 초기 개발 단계에서는 태그 이름과 데이터 타입만 지정해도 프로그램 개발이 가능합니다. 태그 별칭(tag alias)을 사용하면 프로그래머는 전기적 연결에 구애받지 않고 코드를 작성할 수 있습니다. 이후 단계에서는 입력 및 출력 필드 장치를 해당 모듈의 핀 번호에 손쉽게 매칭할 수 있습니다.
메인 루틴에 래더 논리 추가(Adding Ladder Logic to the Main Routine)
그림 15-31은 하드와이어드(hardwired) 접촉기(contactor) 방식으로 동작하는 모터 기동/정지 제어 회로의 다이어그램을 보여줍니다. 정상적으로 열려 있는(NO, normally open) 스타트 버튼은 순간적으로 눌러져 접촉기 코일(contactor coil)에 전원을 인가하고, 주 접점을 닫아서 모터를 기동합니다. 접촉기의 씰-인(seal-in) 보조 접점(auxiliary contact)은 스타트 버튼과 병렬로 연결되어 스타트 버튼을 놓은 후에도 기동 코일이 계속 전원이 인가되도록 합니다. 정상적으로 닫혀 있는(NC, normally closed) 스톱 버튼은 순간적으로 열려 접촉기 코일의 전원을 차단하여 모터를 정지시킵니다.
그림 15-32는 모터 기동/정지 제어 회로의 래더 논리 프로그램과 이를 생성하는 데 사용되는 RSLogix 5000 툴바(toolbar)를 보여줍니다. RSLogix 5000의 자유 형식 편집(free form editing) 기능은 다음 명령을 추가하기 전에 명령을 배치하고 주소를 지정해야 하는 과정을 생략할 수 있어 개발 속도를 높여줍니다. 이 예에서는 태그 이름 대신 물음표 [?]를 사용하고, 나중에 태그를 지정하는 방식을 선택했습니다. 두 개의 푸시버튼 입력과 하나의 접촉기 코일 출력에 대한 필드 장치 배선은 그림과 같이 되어 있습니다. 스톱 버튼은 랙의 슬롯(slot) 1에 있는 DC 입력 모듈의 터미널 3에 연결되고, 스타트 버튼은 터미널 4에 연결됩니다. 접촉기 코일은 랙의 슬롯 2에 있는 DC 출력 모듈의 터미널 4에 연결됩니다. 모터 스타터가 동작하기 위해서는 두 버튼이 모두 닫힌 상태여야 하므로, 스타트 버튼과 스톱 버튼 모두 XIC(Examine If Closed, 닫힘 검사) 명령으로 검사합니다.
텍스트 기반(Logix) 시스템에서는 태그(tag) 이름을 사용하여 래더 코드를 문서화하고, 데이터 구성을 실제 응용 프로그램 구조와 유사하게 정리할 수 있습니다. 프로그래밍된 모터 기동/정지 제어 회로에는 Motor_Start, Motor_Stop, Motor_Run의 세 가지 태그가 생성됩니다. 그림 15-33은 New Tag(새 태그) 창에서 Motor_Start 태그가 생성되는 방법을 보여줍니다. 이 창은 래더 논리 프로그램에서 XIC 명령 위의 물음표(?)를 마우스 오른쪽 버튼으로 클릭하여 열 수 있습니다. 이 태그는 입력 필드 장치로부터 전달되는 값을 나타내므로, 모듈을 통해 필드 장치와 연결을 생성해야 합니다. Local:1:I.Data를 선택하면 입력 모듈의 모든 터미널 번호가 표시된 대화 상자가 나타납니다. 프로그램에서 사용되는 태그 이름(Motor_Start)은 필드 장치가 연결된 입력 터미널 번호 3에 연결됩니다.
그림 15-34는 세 개의 태그가 모두 생성된 이후의 래더 논리 프로그램이 어떻게 보이는지를 보여줍니다. 사용자는 별칭(alias)을 사용하여 동일한 데이터를 여러 이름으로 참조할 수 있습니다. 이를 통해 사용 목적에 따라 데이터를 유연하게 다른 이름으로 지정할 수 있습니다. 태그 설명(description)은 태그 이름보다 더욱 의미 있는 설명을 제공하는 데 사용됩니다. 태그 이름은 컨트롤러로 다운로드되어 저장되지만, 설명은 프로젝트 문서의 일부이므로 다운로드되지 않습니다.
그림 15-35는 프로그램 실행 중 모터가 동작할 때, Program and Monitor Tags(태그 모니터) 창에서 확인되는 태그 상태를 보여줍니다. 모터가 동작 중일 때에는 다음과 같은 상태가 나타납니다.
• XIC Motor_Start 명령은 NO(정상적으로 열림) 스타트 버튼이 열린 상태이므로 False이며, 그 값은 0입니다.
• XIC Motor_Stop 명령은 NC(정상적으로 닫힘) 스톱 버튼이 닫힌 상태이므로 True이며, 그 값은 1입니다.
• OTE Motor_Run 명령은 런(rung)에 논리 연속성이 있으므로 True이며, 그 값은 1입니다.
Monitor Tags 창에서 모터가 동작 중일 때의 상태는 다음과 같습니다.
• XIC Motor_Start 명령은 NO(정상적으로 열림) 스타트 버튼이 열려 있으므로 false이며 값은 0입니다.
• XIC Motor_Stop 명령은 NC(정상적으로 닫힘) 스톱 버튼이 닫혀 있으므로 true이며 값은 1입니다.
• OTE Motor_Run 명령은 런(rung)에 논리 연속성이 있으므로 true이며 값은 1입니다.
내부 릴레이 명령(Internal Relay Instructions)
내부 릴레이(internal relay) 명령은 실제 필드(field) 장치가 아닌 다른 요소를 입력 또는 출력 참조 명령으로 사용할 때 사용됩니다. 예를 들어, 런의 논리 결과를 이용해 다른 내부 논리를 제어하려는 경우 출력으로 내부 릴레이 비트가 사용됩니다. ControlLogix 시스템에서 내부 제어 릴레이는 태그를 생성하고(프로그램 태그 또는 컨트롤러 태그), 해당 태그에 Boolean 타입을 지정함으로써 구성됩니다.
그림 15-36은 세 개의 서로 다른 입구 또는 위치에서 방(room) 조명을 켜고 끄는 on/off 제어를 구현하기 위해 내부 릴레이를 사용하는 ControlLogix 프로그램을 보여줍니다. 이 경우 실제 하드와이어드 회로에서 사용되는 두 개의 3-way 스위치와 한 개의 4-way 스위치 대신 세 개의 단극(single pole) 스위치가 입력으로 사용됩니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다.
• 실제 출력 장치를 사용하지 않고 회로의 논리를 실행하기 위해 내부 릴레이가 사용됩니다.
• 모든 입력 스위치가 열린 상태에서는 모든 태그에 저장된 상태 값이 0이 되며, 방 조명은 꺼진 상태가 됩니다.
• Position_1_Switch를 닫으면 해당 XIC 명령의 상태가 false에서 true로 바뀌며, 런 1에 논리 연속성이 형성됩니다.
• 그 결과 내부 릴레이 코일과 그에 대응하는 XIC 접점의 상태가 false에서 true로 변합니다.
• 이로 인해 런 2에 논리 연속성이 형성되어 조명이 켜집니다.
• 세 입력 스위치 중 어느 하나라도 상태가 바뀌면 조명의 현재 상태가 변경됩니다.
래치(Latch) 및 언래치(Unlatch) 명령
OTL(Output Latch) 명령은 유지(retentive) 기능을 가진 출력 명령으로, 출력 값을 유지하거나 래치(latch)하기 위해 사용됩니다. 한 번 OTL 출력이 켜지면, 해당 출력을 동작시킨 입력 논리가 나중에 false가 되더라도 출력은 유지됩니다. OTL 명령은 동일한 태그를 참조하는 OTU(Output Unlatch) 명령이 활성화될 때까지 계속 래치된(on) 상태로 남습니다. OTL 명령은 특히 전원 장애(power failure)나 시스템 오류(system fault)로 인해 시스템이 정지한 뒤에도 특정 변수 값을 유지해야 하는 프로그램에 자주 사용됩니다. 유지 메모리(retentive memory)는 프로그램 실행이 중단되기 직전의 값을 그대로 저장해두었다가 시스템 재시작 시 복구할 수 있게 합니다.
그림 15-37은 배기 팬 모터를 제어하기 위해 OTL과 OTU 명령 쌍을 사용하는 ControlLogix 프로그램을 보여줍니다. 프로그램 동작은 다음과 같이 요약할 수 있습니다.
• OTL 명령은 true가 되면 해당 주소에 1을 기록합니다.
• OTL 명령이 false가 되어도 출력 주소 값은 1로 유지됩니다.
• 이는 프로세서가 전원이 꺼졌다가 다시 켜지더라도 마찬가지입니다.
• 출력 주소 값은 OTU 명령이 0으로 재설정할 때까지 1로 남아 있습니다.
• 출력 주소가 off 상태라면 OTL과 OTU 명령은 모두 활성화되지 않지만, 일단 비트가 on 상태가 되면 입력이 모두 off여도 OTL과 OTU 명령이 모두 활성화된 것으로 표시됩니다.
원샷명령(One-Shot Instruction)
CLX 원샷(ONS) 명령은 입력 명령으로서, 출력이 프로그램 스캔 한 번 동안만 켜지도록 할 때 사용됩니다. 그림 15-38의 프로그램은 ONS 명령을 수학 연산 명령과 함께 사용하여, 계산을 스캔당 한 번만 수행하도록 구성되어 있습니다. 이 프로그램은 리미트 스위치가 닫혀 있는 시간이 얼마나 길든 상관없이, 리미트 스위치가 한 번 동작할 때마다 ADD 함수가 한 번만 실행되도록 합니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다.
• limit_switch_1이 cleared(0) 상태이거나 storage_1이 set(1) 상태인 스캔에서는, 이 런(rung)은 아무 동작도 하지 않습니다.
• limit_switch_1이 set(1) 상태이고 storage_1이 cleared(0) 상태인 스캔에서는 ONS 명령이 storage_1을 set으로 만들고, ADD 명령이 sum 값을 1 증가시킵니다.
• limit_switch_1이 계속 set 상태로 유지되는 동안 sum 값은 더 이상 증가하지 않고 그대로 유지됩니다. sum 값이 다시 증가하려면, limit_switch_1이 한 번 cleared 상태로 되돌아갔다가 다시 set 상태가 되어야 합니다.
Part 3 Programming Timers
Timer Predefi ned Structure
타이머는 출력이 일정 시간 지연 후 켜지거나 꺼지도록 하거나, 정해진 시간 동안 출력이 켜지거나 꺼지게 하며, 출력이 켜져 있거나 꺼져 있는 시간을 기록하는 데 사용됩니다. SLC 500 컨트롤러에서 타이머 주소는 데이터 테이블 주소 또는 심벌(symbol)인 반면, ControlLogix 컨트롤러에서는 타이머 주소가 TIMER 데이터 타입의 사전 정의된 구조체로 구성됩니다. TIMER 구조는 그림 15-41에 나타나 있습니다.
타이머 파라미터 및 상태 비트는 다음과 같습니다.
• Tag Name —타이머에 대해 사용자가 이해하기 쉬운 태그 이름(예: Pump_Timer)을 의미합니다. 타이머를 사용하려면 TIMER 타입의 태그를 생성해야 합니다.
• Preset (PRE) —타이머가 원하는 시간 지연에 도달하기 위해 누적해야 하는 시간 증가값입니다. 완료 비트(DN)가 상태를 변경하기 전에 타이머가 도달해야 하는 값(밀리초 단위)을 지정합니다. 프리셋 값은 이진수(DINT)로 저장됩니다. 시간 기준(time base)은 항상 1ms입니다. 예를 들어 3초 타이머의 경우 PRE 값으로 3000을 입력합니다.
• Accumulator (ACC) —ACC 값은 명령이 활성화된 후 경과된 밀리초(ms)입니다. ACC 값은 ACC 값이 PRE 값에 도달하면 증가가 멈춥니다.
• Enable Bit (EN) —EN 비트는 TON 명령이 활성화되었음을 나타냅니다. 런(rung) 입력 로직이 참(true)이면 EN 비트는 참이며, 런 입력 로직이 거짓(false)이면 EN 비트는 거짓입니다.
• Timer Timing Bit (TT) —TT 비트는 타이밍 동작이 진행 중임을 나타냅니다. ACC가 증가하는 동안에만 TT 비트는 참입니다. TT는 ACC가 프리셋 값에 도달할 때까지 참 상태를 유지합니다.
• Done Bit (DN) —DN 비트는 누적값(ACC)이 프리셋(PRE) 값과 같음을 나타냅니다. DN 비트는 사용하는 시간 접점(time contact) 명령의 종류에 따라 false→true 또는 true→false로 상태가 변하며, 타이밍 동작이 완료되었음을 표시합니다. DN 비트는 가장 일반적으로 사용되는 타이머 상태 비트입니다.
On-Delay Timer (TON)
온딜레이 타이머(ON-Delay Timer, TON)는 런(rung) 조건이 참이 된 후 일정 시간이 지난 다음 동작이 수행되어야 하는 경우에 사용하는 비지속형(nonretentive) 출력 명령입니다. ControlLogix의 TON 온딜레이 명령과 타이머 선택 툴바는 그림 15-42에 나타나 있습니다.
타이머를 사용하려면 TIMER 타입(사전 정의된 데이터 타입)의 태그를 생성한 후 프리셋(preset) 값과 누적값(accumulated value)을 입력해야 합니다. 태그가 먼저 정의되어야 프리셋과 누적값을 입력할 수 있습니다. 프로그램 중에도 ACC 값 입력은 가능합니다. 프로그램이 다운로드되면, 이 값은 첫 스캔에서 타이머에 적용됩니다. TON 타이머가 활성화되지 않으면 ACC 값은 다시 0으로 초기화됩니다. 일반적으로 ACC 값에는 0이 입력됩니다.
그림 15-43은 새 태그 속성(new tag properties) 대화 상자에서 타이머 태그 이름을 선언하는 화면입니다. 태그 이름, 설명(선택 사항), 태그 타입, 데이터 타입, 스코프(scope)를 선택 또는 입력하여 정의를 완료합니다. Solenoid_Delay와 같은 설명이 포함된 태그 이름은 타이머가 제어 시스템에서 어떤 기능을 수행하는지 쉽게 이해할 수 있도록 도와줍니다.
그림 15-44의 프로그램은 10000 ms(10 s) TON 타이머의 예제입니다. 타이머는 워드 레벨(DINT)과 비트 레벨(BOOL) 데이터를 모두 생성합니다. 프로그램의 동작은 Monitor Tags 창을 기준으로 다음과 같이 요약할 수 있습니다.
• 입력 스위치를 OFF에서 ON(1)으로 전환하고 5000 ms(5 s)가 누적된 후 타이머의 모든 명령 상태가 표시됩니다.
• 이 절반 시점에서는 런이 참이므로 EN 비트가 1이며, ACC가 증가 중이므로 TT 비트가 1이고, ACC가 아직 프리셋 값에 도달하지 않았기 때문에 DN 비트는 0입니다.
• ACC가 PRE와 같아지는 순간 누적값 증가가 멈추며, 런이 참인 동안 EN은 계속 1을 유지합니다. 누적값이 더 이상 변하지 않기 때문에 TT는 0이 되고, ACC = PRE이므로 DN은 1이 됩니다.
• 이 시점에서 DN 파일럿 램프(pilot light)는 켜지고 TT 파일럿 램프는 꺼지게 됩니다.
• EN 파일럿 램프는 입력 스위치가 닫혀 있는 한 계속 켜진 상태를 유지합니다.
• 입력 스위치를 어느 시점에서든 열면 TON 명령은 false가 되어 ACC 값이 0으로 리셋되고, EN, TT, DN 비트도 모두 0으로 리셋됩니다. 이로 인해 모든 출력 파일럿 램프가 꺼집니다.
• TON 명령은 자체 리셋(self-resetting) 타이머입니다. 런이 false가 되면 자동으로 타이머가 리셋됩니다. 별도 RESET 명령을 사용할 수 있지만 일반적으로 사용하지 않습니다.
그림 15-45는 TON 타이머가 목표물이 솔레노이드 에너자이즈 센서(solenoid energize sensor)에 의해 감지된 후 3초 후 디버터 게이트 솔레노이드(diverter gate solenoid)를 동작시키도록 지연시키는 예제입니다. 프로그램 동작은 다음과 같이 요약됩니다.
• 목표물이 감지되면 SOL_Energize_Sensor 접점이 닫히고, 타이머 런이 참이 되어 타이밍이 시작됩니다.
• 목표물이 지나가면서 SOL_Energize_Sensor 접점이 열리지만, TON 타이머의 EN 비트를 통해 런은 계속 참 상태를 유지합니다.
• 3000 ms(3 s) 지연 시간이 지나면 딜레이 타이머의 DN 비트가 1로 설정되어 SOL_Gate가 에너자이즈됩니다.
• SOL_Deenergize_Sensor가 순간적으로 목표물을 감지하면 접점이 열리고, 프로그램은 초기 상태로 리셋됩니다.
Figure 15-46은 순간(push) 버튼이 눌릴 때마다 20초 동안 그린 파일럿 램프(green pilot light)를 점등하기 위해 TON 타이머를 사용하는 프로그램을 보여줍니다. 이 프로그램은 TON 타이머 외에도 하나의 런(rung)에 여러 출력 사용, 출력 래치(latch)·언래치(unlatch) 명령, 그리고 타이머 리셋(reset) 명령을 함께 사용합니다. 프로그램의 동작은 다음과 같이 요약됩니다.
• 처음 Timer_Button을 닫으면 그린 파일럿 램프(Green_PL)가 설정(latch)되어 켜지고, Pilot_Light_Timer가 활성화됩니다.
• 버튼을 다시 열어도 Pilot_Light_Timer.EN 비트가 생성하는 논리 경로로 인해 타이머 런은 계속 참(true) 상태를 유지합니다.
• 20000 ms(20 s)이 지나면 타이머 DN 비트가 1이 되어 타이머를 초기 상태로 리셋하고 Green_PL을 언래치하여 램프를 끕니다.
그림 15-47의 ControlLogix 프로그램은 교통신호등 제어를 위해 세 개의 TON 타이머가 직렬(캐스케이드)로 연결된 예제입니다. 사용된 래더( ladder ) 논리는 SLC 500 컨트롤러로 신호등을 구성할 때와 동일합니다. 프로그램에 맞게 생성된 다양한 태그는 그림 15-48에 나타나 있습니다. 프로그램의 동작은 다음과 같이 요약됩니다.
• 빨간불 → 녹색불 → 황색불의 전환은 세 개의 TON 타이머 명령의 EN 및 DN 비트를 서로 연결하여 이루어집니다.
• Red_Light_Timer의 입력은 Amber_Light_Timer.DN 비트에 의해 제어됩니다.
• Green_Light_Timer의 입력은 Red_Light_Timer.DN 비트에 의해 제어됩니다.
• Amber_Light_Timer의 입력은 Green_Light_Timer.DN 비트에 의해 제어됩니다.
• 조명 전환의 시간 순서는 다음과 같습니다:
- Red — 30 s 점등
- Green — 25 s 점등
- Amber — 5 s 점등
• 이 순서는 반복적으로 계속 진행됩니다.
Off-Delay Timer (TOF)
오프딜레이 타이머(Off-Delay Timer, TOF)는 온딜레이 타이머(TON)와 반대 방식으로 동작합니다. 오프딜레이 타이머는 래더( ladder ) 로직의 런(rung)이 참일 때 즉시 켜지지만, 런이 거짓이 된 후 꺼지기까지 지연됩니다. ControlLogix TOF 오프딜레이 타이머 명령은 그림 15-49에 나와 있으며, 기능 블록의 필드(field) 및 태그 참조(tag reference)는 TON 타이머와 동일합니다.
그림 15-50은 순간 버튼을 누를 때마다 20초 동안 그린 파일럿 램프(Green_PL)를 점등하기 위해 TOF 타이머를 사용하는 프로그램을 보여줍니다. 동일한 동작을 TON 타이머로 구현한 프로그램보다 코드가 더 간단합니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다.
• Timer_Button을 처음 닫으면 타이머 런과 명령, 그리고 DN 비트가 모두 참(true)이 됩니다.
• DN 비트는 Green_PL을 켜며, 버튼을 계속 누르고 있는 동안 프로그램은 이 상태를 유지합니다.
• 버튼을 놓으면 Timer_Button 명령이 거짓(false)이 되며 타이밍 사이클이 시작됩니다.
• 램프는 계속 켜져 있고, 타이머는 시간을 누적하기 시작합니다.
• 누적값이 20000 ms(20 s)에 도달하면 타이머 DN 비트가 false가 되어 램프가 꺼집니다.
그림 15-51의 프로그램은 가열 오븐 공정(heating oven process) 제어를 위해 온딜레이와 오프딜레이 타이머를 모두 사용합니다. 프로그램에 맞게 생성된 태그들은 그림 15-52에 나타나 있습니다. 프로그램의 동작은 다음과 같이 요약됩니다.
• Oven_On_Button을 누르면 Oven_On_PL 출력이 에너자이즈되어 래치(latch)되며, TON 및 TOF 타이머 명령이 활성화됩니다.
• TON 타이머의 Timer_Heat.TT 비트가 true가 되어 Warning_Horn을 울려 오븐이 곧 켜질 것을 알립니다.
• TOF 타이머의 Timer_Cooling.DN 비트가 true가 되어 Fan_Motor가 에너자이즈됩니다.
• 10초(10000 ms)가 지나면 Timer_Heat.TT 비트가 false가 되어 Warning_Horn이 꺼지고, Timer_Heat.DN 비트가 true가 되어 Heater_Contactor가 에너자이즈되며 히팅 코일이 켜집니다.
• Oven_Off_Button을 순간적으로 누르면 Oven_On_PL 출력이 false가 되어 파일럿 램프가 꺼지고 래치 경로가 열립니다.
• Timer_Heat 타이머 명령과 그 DN 비트는 false가 되어 Heater_Contactor가 디에너자이즈되고 히팅 코일이 꺼집니다.
• Timer_Cooling 타이머는 시간을 누적하기 시작하고, 팬은 5분(300000 ms) 지연 시간 동안 계속 동작합니다. 이후 Timer_Cooling.DN 비트가 false가 되어 팬이 꺼집니다.
그림 15-52에서 프로그램은 다음과 같이 동작됩니다.
• Oven_On_Button을 누르면 Oven_On_PL 출력이 에너자이즈되어 자체 래치(seal-in)되고, TON 및 TOF 타이머 명령이 활성화됩니다.
• TON 타이머의 Timer_Heat.TT 비트가 true가 되어 Warning_Horn이 울리며 오븐이 곧 가동될 것임을 알립니다.
• TOF 타이머의 Timer_Cooling.DN 비트가 true가 되어 Fan_Motor가 에너자이즈됩니다.
• 10초(10000 ms)가 경과하면 Timer_Heat.TT 비트가 false가 되어 Warning_Horn이 꺼지고, Timer_Heat.DN 비트가 true가 되어 Heater_Contactor가 에너자이즈되며 히팅 코일이 켜집니다.
• Oven_Off_Button을 순간적으로 누르면 Oven_On_PL 출력이 false가 되어 파일럿 램프가 꺼지고, 래치 경로(seal-in logic path)의 연속성이 끊깁니다.
• Timer_Heat 타이머 명령과 그 DN 비트는 false가 되어 Heater_Contactor가 디에너자이즈되고 히팅 코일이 꺼집니다.
• Timer_Cooling 타이머는 시간 누적을 시작하며, 팬은 5분(300000 ms) 지연 시간 동안 계속 동작합니다. 이후 Timer_Cooling.DN 비트가 false가 되어 팬이 꺼집니다.
Retentive Timer On (RTO)
리텐티브 온딜레이 타이머(Retentive Timer On, RTO)는 기본적으로 TON 타이머와 동일하게 동작하지만, 다음과 같은 상황에서도 누적값(ACC)을 유지(저장)한다는 점이 다릅니다.
• 런(rung)이 false가 된 경우
• 프로세서가 프로그램 모드(program mode)로 전환된 경우
• 프로세서에 Fault가 발생한 경우
• 프로세서 전원이 일시적으로 차단되었더라도 배터리가 정상인 경우
ControlLogix의 RTO 리텐티브 온딜레이 타이머 명령은 그림 15-53에 나와 있습니다. 기능 블록의 필드(field)와 태그 참조(tag reference)는 TON 타이머와 동일하지만, 리텐티브 타이머의 누적값을 초기화하려면 반드시 RES(reset) 명령을 사용해야 합니다. 이때 RES 명령에는 리셋하고자 하는 타이머와 동일한 태그 이름을 사용해야 합니다.
(120000 ms) RTO 타이머 예제 프로그램은 그림 15-54에 제시되어 있으며, 프로그램에서 사용된 태그들은 그림 15-55에 나타나 있습니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다.
• 타이머가 처음 리셋된 상태에서 모든 명령의 상태와 값은 Monitor Tags 창에 나타난 그대로입니다.
• Limit_Switch가 1분 동안 닫혀 있었을 때 각 명령의 상태와 값은 다음과 같습니다:
-
- PRE – 120000
- ACC – 60000
- LS_Timer.EN – 1
- LS_Timer.TT – 1
- LS_Timer.DN – 0
- LS_EN_PL – 1
- LS_TT_PL – 1
- LS_Alarm – 0
• Limit_Switch가 1.5분 후에 열렸을 때의 명령 상태와 값은 다음과 같습니다:
-
- PRE – 120000
- ACC – 90000
- LS_Timer.EN – 0
- LS_Timer.TT – 0
- LS_Timer.DN – 0
- LS_EN_PL – 0
- LS_TT_PL – 0
- LS_Alarm – 0
- Limit_Switch(리미트 스위치)가 닫힌 상태에서 타이머가 만료될 때까지 계속 닫혀 있을 경우, 명령어들의 상태와 값은 다음과 같습니다:
- PRE – 120000
- ACC – 120000
- LS_Timer.EN – 1
- LS_Timer.TT – 0
- LS_Timer.DN – 1
- LS_EN_PL – 1
- LS_TT_PL – 0
- LS_Alarm – 1
• 타이머가 만료된 이후 Limit_Switch(리미트 스위치)가 열릴 경우, 명령어들의 상태와 값은 다음과 같습니다:
-
- PRE – 120000
- ACC – 120000
- LS_Timer.EN – 0
- LS_Timer.TT – 0
- LS_Timer.DN – 1
- LS_EN_PL – 0
- LS_TT_PL – 0
- LS_Alarm – 1
• Reset_LS_Timer(리셋 LS 타이머)가 닫히면, 명령어들의 상태와 값은 원래 값으로 초기화됩니다.
Part 4 Programming Counters
Counters
카운터는 타이머와 유사하지만, 타이머가 내부 클록을 사용해 값을 증가시키는 것과 달리 카운터는 외부 트리거 신호의 상태 변화(변화 횟수)를 누적(카운트)한다는 점에서 차이가 있습니다. PLC 카운터는 일반적으로 입력 필드 장치에서 발생하는 false→true(거짓→참) 전환에 의해 해당 래더 런(rung)이 활성화될 때 트리거됩니다. 런이 참 또는 거짓 상태로 얼마나 오래 유지되는지는 중요하지 않으며, 오직 “전환” 자체가 카운트됩니다.
카운터에는 두 가지 기본 유형이 있습니다: 카운트 업(count-up, CTU)과 카운트 다운(count-down, CTD)입니다. ControlLogix CTU 명령과 카운터 선택 도구 막대는 그림 15-57에 나타나 있습니다. 타이머와 동일하게 카운터를 사용하려면 COUNTER 타입(미리 정의된 데이터 타입)의 태그를 생성하고, 프리셋(preset) 값과 누적(accumulated) 값을 입력해야 합니다. 명령어 입력 시 이 태그가 먼저 정의되어야 프리셋과 누적 값을 입력할 수 있습니다. 또한 카운터의 누적 값을 0으로 초기화하려면 해당 카운터와 동일한 태그 이름을 가지는 RES(리셋) 명령이 필요합니다.
모든 카운터는 “보존형(retentive)”이며, 전원 차단이 발생하더라도 리셋 전까지 ACC 값이 유지됩니다. 카운터의 완료(done), 오버플로(overflow), 언더플로(underflow) 비트 또한 동일하게 보존됩니다. ControlLogix의 카운터 파라미터 및 상태 비트는 그림 15-58의 태그 편집 창에 나타나며 다음과 같이 요약할 수 있습니다:
• Preset(PRE) 값 — 완료(done, DN) 비트가 켜지기(1) 전에 카운터가 도달해야 하는 값을 지정합니다.
• Accumulated(ACC) 값 — 카운터 런의 false→true 전환 횟수입니다. 동일한 카운터 주소에 대한 reset(RES) 명령이 실행되면 ACC는 0으로 초기화됩니다.
• CU(Count-Up Enable Bit) — 카운트 업(CTU) 명령이 활성화되었음을 나타냅니다.
• CD(Count-Down Enable Bit) — 카운트 다운(CTD) 명령이 활성화되었음을 나타냅니다.
• DN(Count-Up Done Bit) — ACC 값이 PRE 값과 같거나 크면 1로 설정됩니다. RES 명령에 의해 리셋됩니다.
• OV(Overflow Bit) — 카운터가 상한을 초과했음을 나타냅니다. ACC 값이 +2,147,483,647보다 크면 1이 되며, reset 명령이 실행되면 리셋됩니다. 참고로 ACC 값은 PRE 값에 도달한 후에도 계속 증가할 수 있습니다.
• UN(Underflow Bit) — 카운터가 하한인 –2,147,483,648을 초과했음을 나타냅니다.
카운터 태그 이름은 그림 15-59에 나타난 새로운 태그 속성(new tag properties) 대화 상자를 사용해 선언됩니다. 태그 이름, 설명(선택 사항), 태그 타입, 데이터 타입(대부분 base type 사용), 스코프(scope)를 선택하거나 입력하여 검증을 완료합니다.
Count-Up (CTU) Counter
카운트 업(CTU) 카운터는 카운터 래더 런(rung)에서 false→true(거짓→참) 전환이 발생할 때마다 누적 값(accumulated value)이 1씩 증가합니다. 병 패키지를 계수하기 위해 사용된 카운트 업 카운터 프로그램의 예시는 그림 15-60에 나와 있습니다. 이 프로그램의 동작은 다음과 같이 요약할 수 있습니다:
• Bottle_Sensor(병 센서) 근접 스위치가 열림→닫힘으로 전환될 때마다 카운터는 1씩 증가합니다.
• Package_Counter.CU 상태 비트에 의해 제어되는 Increment_PL은 각 병이 지나갈 때마다 켜졌다 꺼지며 카운터가 증가 중임을 표시합니다.
• 카운터의 누적 값이 24에 도달하면 카운터의 DN 비트가 설정되며 Preset_Reached_PL이 켜집니다.
• Reset_Button(리셋 버튼)을 순간적으로 눌러 폐회로로 만들면 카운터는 리셋됩니다.
그림 15-61에 제시된 프로그램에서는 컨베이어 라인에서 10개 중 5개의 용기를 제거하기 위해 두 개의 CTU 명령을 사용합니다. 이를 위한 다양한 태그는 그림 15-62에 나타나 있습니다. 프로그램 동작은 다음과 같이 요약됩니다:
• Container_Counter_Counts의 프리셋은 6으로 설정되고, Container_Counter_Max의 프리셋은 11로 설정됩니다.
• 컨테이너가 감지되면 두 카운터 모두 누적 값이 1씩 증가합니다.
• 여섯 번째 부품이 도착하면 Container_Counter_Counts 카운터가 완료(done) 상태가 되어, 다섯 번째 이후의 컨테이너에 대해 솔레노이드가 동작할 수 있도록 허용됩니다.
• Container_Counter_Max 카운터는 열한 번째 부품이 감지될 때까지 증가하며, 열한 번째가 감지되면 두 카운터 모두 리셋됩니다.
Count-Down (CTD) Counter
카운트 다운(CTD) 카운터는 CTU 카운터와 정반대 방식으로 동작합니다. CTD 카운터는 카운터 래더 런(rung)에서 false→true(거짓→참) 전환이 발생할 때마다 누적 값(accumulated value)이 증가하는 대신 1씩 감소합니다. ControlLogix CTD 다운 카운터 명령은 그림 15-63에 나타나 있습니다. 기능 블록의 각 필드와 태그 참조에 대한 설명은 CTU 기능 블록과 동일합니다. CTD 명령은 보통 동일한 카운터 구조를 참조하는 CTU 명령과 함께 사용됩니다.
그림 15-64의 응용 프로그램 예시는 버퍼 존(buffer zone)에 저장할 수 있는 부품의 최대 개수를 50개로 제한하는 데 사용됩니다. 여기서는 하나의 CTU 카운터와 하나의 CTD 카운터가 동일한 주소를 사용해 Up/Down 카운터를 구성합니다. 이것이 CTD 카운터의 가장 대표적인 적용 방식입니다. 프로그램을 위해 생성된 다양한 태그는 그림 15-65에 나타나 있습니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다:
• Restart_Button(리스타트 버튼)은 언제든지 순간적으로 눌러 카운터의 누적 값을 0으로 리셋할 수 있습니다.
• 컨베이어가 부품을 버퍼 존으로 이동시킵니다.
• 부품이 버퍼 존으로 진입할 때마다 Enter_Limit_Sw(입력 리미트 스위치)가 동작하며 Counter_1의 값이 1 증가합니다.
• 부품이 버퍼 존(buffer zone)을 빠져나갈 때마다 Exit_Limit_Sw(출구 리미트 스위치)가 동작하며 Counter_1의 값은 1 감소합니다.
• 어느 순간이든 버퍼 존 내의 부품 수가 50개에 도달하면 Counter_1.DN 비트가 설정됩니다.
• 그 결과 Conveyor_Contactor 런(rung)이 false가 되어 컨베이어 접촉기가 비여자(de‑energize)되며, 누적 값이 50보다 낮아질 때까지 추가 부품이 유입되는 것을 자동으로 차단합니다.
Part 5 Math, Comparison, and Move Instructions
Math Instructions
ControlLogix 기본 수학 명령에는 덧셈(addition), 뺄셈(subtraction), 곱셈(multiplication), 나눗셈(division), 제곱근(square root), 그리고 클리어(clear) 기능이 포함됩니다. 그림 15-66은 ControlLogix 컨트롤러의 Compute/Math 도구 막대를 보여줍니다.
ADD 명령은 두 숫자를 더할 때 사용됩니다. 이 명령은 Source A와 Source B의 값을 더합니다. 소스는 상수값 또는 태그(tag)가 될 수 있습니다. ADD 명령의 결과는 목적지(Dest) 태그에 저장됩니다. 그림 15-67은 ADD 명령 런(rung)의 예시와 Monitor Tags 창을 보여줍니다. 런 동작은 다음과 같이 요약됩니다:
• ADD_Sw가 닫히면 런은 true가 됩니다.
• ADD 명령은 Source A(Value_A)의 값과 Source B(Value_B)의 값을 더합니다.
• 결과는 Dest 태그(Total_Value)에 저장됩니다.
• 이 예에서는 25가 50에 더해졌고, 결과(75)가 Total_Value에 저장되었습니다.
SUB 명령은 두 숫자를 뺄 때 사용됩니다. 그림 15-68은 SUB 명령 런의 예와 Monitor Tags 창을 보여줍니다. 런 동작은 다음과 같이 요약됩니다:
• SUB_Sw 또는 Calculate 태그가 true이면 SUB 명령이 실행됩니다.
• Source B(Shipped_Parts)가 Source A(Parts_Stock)에서 뺄셈되고, 결과는 Current_Inventory라는 이름의 Dest 태그에 저장됩니다.
• 이 예에서는 900에서 200이 뺄셈되어 결과(700)가 Current_Inventory에 저장되었습니다.
• Source A와 Source B는 상수(숫자) 또는 태그가 될 수 있습니다.
MUL 명령은 두 숫자를 곱할 때 사용됩니다. 그림 15-69는 MUL 명령 런의 예와 Monitor Tags 창을 보여줍니다. 여러 개의 병이 케이스에 포장될 때, 케이스당 병 수, 케이스 수, 그리고 곱셈 명령을 사용하면 총 병 수를 계산할 수 있습니다. 런 동작은 다음과 같이 요약됩니다:
• Sw_1과 Sw_2가 모두 true이면 MUL 명령이 실행됩니다.
• Source A(태그 Cases_Produced의 값)는 Source B(태그 Bottles_Per_Case의 값)와 곱해지며, 결과는 Dest 태그 Bottles_Produced에 저장됩니다.
• Source A와 Source B는 상수(숫자) 또는 태그가 될 수 있습니다.
DIV 명령은 두 숫자를 나눌 때 사용됩니다.
그림 15-70은 DIV 명령 런(rung)의 예시와 Monitor Tags 창을 보여줍니다. 런의 동작은 다음과 같이 요약할 수 있습니다:
• Source A에는 상수(5), Source B에는 상수(3)가 사용되었습니다. 참고로 Source A 또는 Source B에 태그(tag)를 사용할 수도 있습니다.
• Calculate 태그가 true이면 DIV 명령이 실행됩니다.
• Source A(5)가 Source B(3)로 나누어지며, 그 결과(1.6666666)가 목적지(Dest) 태그 Answer_Real에 저장됩니다. 이 예에서는 Real 타입 태그가 목적지로 사용되었습니다.
그림 15-71의 프로그램은 3개의 컨베이어를 사용하는 부품 추적 시스템의 일부로 사용됩니다. 컨베이어 1의 부품 수와 컨베이어 2의 부품 수를 더해 컨베이어 3의 부품 수를 계산합니다. 프로그램 동작은 다음과 같이 요약됩니다:
• Conveyor_1_Sensor가 동작할 때마다 Counter_1_Parts의 누적 값이 1 증가합니다.
• Conveyor_2_Sensor가 동작할 때마다 Counter_2_Parts의 누적 값이 1 증가합니다.
• ADD 명령은 두 카운터의 누적 값을 합산하여 Conveyor_3_Parts 태그에 저장합니다.
• 두 카운터 중 어느 하나라도 누적 값이 150에 도달하면, 두 카운터의 reset(RES) 명령이 활성화되어 자동으로 ACC 값이 0으로 리셋됩니다.
• Manual_Conveyor_Reset 버튼을 동작시키면 언제든지 두 카운터를 수동으로 리셋할 수도 있습니다.
Comparison Instructions
비교(compare) 명령은 두 값을 비교하는 데 사용됩니다.
두 값이 동일한지, 한 값이 다른 값보다 큰지 또는 작은지 등을 판단할 수 있습니다. ControlLogix 컨트롤러에서 비교 명령은 표현식을 사용하거나 특정 비교 기능을 갖는 명령을 사용하여 수행됩니다. 그림 15-72는 ControlLogix Compare 도구 막대를 보여줍니다.
EQU(Equal) 명령은 두 값이 같은지를 검사합니다.
그림 15-73은 EQU 명령 런의 예시와 Monitor Tags 창을 보여줍니다. 런 동작은 다음과 같습니다:
• Source A에 저장된 값이 Source B에 저장된 값과 비교됩니다.
• 두 값이 같으면 명령은 논리적으로 true입니다.
• 두 값이 다르면 명령은 논리적으로 false입니다.
• 이 예에서는 Source A(25)와 Source B(25)가 같으므로 명령이 true가 되고 Equal_PL이 켜집니다.
• Source A와 Source B는 SINT, INT, DINT, REAL 타입 모두 가능합니다.
NEQ(Not Equal) 명령은 두 값이 서로 다른지를 검사합니다.
그림 15-74는 NEQ 명령 런의 예입니다.
Source A가 Source B와 다르면 명령은 true가 되고, 그렇지 않으면 false가 됩니다. 예시에서는 두 값이 서로 다르므로 Not_Equal_PL이 여자(energized)됩니다.
LES(Less Than) 명령은 한 값이 다른 값보다 작은지를 검사합니다.
그림 15-75는 LES 명령 런의 예를 보여줍니다.
Source A가 Source B보다 작으면 명령은 true가 되며, 그렇지 않으면 false입니다. 예에서는 Value_1(100)이 Value_2(300)보다 작으므로 Less_Than_PL이 여자됩니다.
The greater than (GRT) instruction은 한 소스의 값이 다른 소스의 값보다 큰지를 검사하는 데 사용됩니다. 그림 15-76은 GRT 명령 런(rung)의 예시를 보여줍니다. Source A가 Source B보다 크면 명령은 논리적으로 true가 되고, 그렇지 않으면 false입니다. 이 예에서는 Value_1(1420)이 Value_2(1200)보다 크므로 Greater_Than_PL이 여자(energized)됩니다.
CMP(compare) 명령은 표현식에 지정된 산술 연산 결과에 대해 비교를 수행합니다. 표현식에는 산술 연산자, 비교 연산자, 태그가 포함될 수 있습니다. CMP 명령은 다른 비교 명령들보다 실행 속도가 약간 느리고 더 많은 메모리를 사용하지만, 복잡한 표현식을 하나의 명령으로 처리할 수 있다는 장점이 있습니다. 그림 15-77은 CMP 명령 런의 예시를 보여줍니다. 이 예에서는 표현식에 포함된 비교 연산자가 EQU 명령과 동일한 역할을 하며, Value_1(300)과 Value_2(300)이 동일하기 때문에 비교 결과는 true입니다.
그림 15-78의 프로그램은 카운터의 누적 값에 대한 비교 명령 사용 예입니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다:
• 누적 값(accumulated count)이 5와 10 사이에 있을 때 GRT와 LES 명령이 모두 논리적으로 true가 되어 PL_1 파일럿 램프가 켜집니다.
• 누적 값이 15와 같을 경우 EQU 명령이 logically true가 되어 PL_2 파일럿 램프가 켜집니다.
• PL_3 파일럿 램프는 누적 값이 20일 때를 제외하고 항상 켜져 있습니다. 누적 값이 20이 되면 NEQ 명령이 logically false가 됩니다.
• 누적 값이 25에 도달하면 카운터는 자동으로 리셋되며, Reset_PB를 누르면 언제든지 수동으로 리셋할 수 있습니다.
Move Instructions
MOV(move) 명령은 출력 명령으로, 상수 값 또는 한 메모리 위치의 내용을 다른 메모리 위치로 이동시키는 기능을 수행합니다.
그림 15-79는 ControlLogix 컨트롤러의 Move 도구 막대와 MOV 명령을 보여줍니다. MOV 명령은 소스(source)의 데이터를 목적지(destination)로 복사하는 데 사용됩니다. MOV 명령의 소스와 목적지 데이터 타입은 INT, DINT, SINT, REAL 모두 사용할 수 있습니다.
그림 15-80의 프로그램은 MOV 명령을 사용하여 가변 프리셋(variable preset) 타이머를 구성하는 예제입니다. 프로그램의 동작은 다음과 같이 요약할 수 있습니다:
• PB_10s 버튼을 동작시키면 해당 MOV 명령이 실행되어 10000이 타이머 프리셋 값으로 이동하며, 이는 지연 시간을 10초로 설정합니다.
• PB_15s 버튼을 동작시키면 해당 MOV 명령이 실행되어 15000이 타이머 프리셋 값으로 이동하며, 지연 시간을 15초로 설정합니다.
• Timer_Start 스위치를 닫으면 타이머가 동작을 시작합니다.
• 타이머가 동작하는 동안 파일럿 램프 PL_1은 타이머 프리셋 기간 동안 켜져 있습니다.
• 타이머가 만료되면 PL_1은 꺼지고 PL_2가 켜집니다.
Part 6 Function Block Programming
Function Block Diagram (FBD)
Function Block Diagram(FBD)는 간단하거나 복잡한 블록들을 서로 연결하여 공정(process) 흐름을 그래픽으로 표현하는 방식입니다.
래더( Ladder ) 논리도와 유사하지만, 접점과 코일 대신 기능 블록(function block)을 사용하고 전원 레일(power rails)이 없다는 점이 다릅니다.
FBD 회로는 전기 회로와 비슷하며, 링크와 와이어가 신호 경로를 나타냅니다. 작업 공간은 시트(sheet)라고 하며, 기능 블록들이 와이어(wire)로 연결되어 구성됩니다. 그림 15-81은 기능 블록 프로그램(루틴)의 구조를 보여줍니다.
FBD는 다음 4가지 기본 요소로 구성됩니다:
- 기능 블록(function block)
- 레퍼런스(references)
- 와이어 커넥터(wire connectors)
- 와이어(wires)
와이어를 통해 입력 레퍼런스 또는 커넥터에서 시작된 데이터가 기능 블록 내부를 흐르고 출력 레퍼런스로 전달됩니다.
점선(dash line)은 BOOL 신호(0 또는 1)를, 실선(solid line)은 정수 또는 실수 데이터를 의미합니다.
기능 블록(function block)
기능 블록은 실행 가능한 코드를 그래픽으로 나타낸 것입니다. 하나 이상의 입력을 받아 계산 또는 논리 판단을 수행하고, 하나 이상의 출력 값을 생성합니다. ControlLogix 프로그래밍 소프트웨어에는 다양한 작업을 수행하는 여러 종류의 기능 블록이 포함되어 있으며, 자주 사용하는 논리를 묶어서 Add-On Instruction을 생성할 수도 있습니다. 한 번 정의된 Add-On Instruction은 표준 명령처럼 도구 막대에 나타납니다.
그림 15-82는 BAND(Boolean AND) 기능 블록의 예시입니다. 기능 블록에 대한 정보는 다음과 같습니다:
• 입력은 왼쪽에서 들어오고 출력은 오른쪽으로 나갑니다.
• 블록 내부에 기능 블록 타입이 표시됩니다.
• 블록 위에는 태그 이름이 표시됩니다.
• 블록 내부에는 입력 및 출력 이름이 나타납니다.
• 기본(default) 화면에서는 일부 파라미터만 표시됩니다.
• 블록 우측 상단 버튼을 클릭하면 속성(properties) 창이 표시되며, 입력·출력 파라미터를 설정할 수 있습니다.
• 입력과 출력 옆의 1과 0은 해당 핀의 논리 상태를 나타냅니다.
• 입력 및 출력 핀에 표시된 점(dot)은 BOOL 타입 데이터가 필요함을 의미합니다.
레퍼런스(References)
레퍼런스는 컨트롤러 메모리에 저장된 태그 값을 연결합니다. 그림 15-83은 입력 레퍼런스(IREF)와 출력 레퍼런스(OREF)를 보여줍니다.
• IREF(Input Reference)는 입력 장치 또는 태그의 값을 받아옵니다.
• OREF(Output Reference)는 값을 출력 장치 또는 태그로 보냅니다.
• IREF 또는 OREF를 사용하면 반드시 태그를 생성하거나 기존 태그를 연결해야 합니다.
• 데이터 타입은 어떤 것도 사용할 수 있습니다.
와이어 및 연결(Wires and Connections)
그림 15-84처럼, 기능 블록의 출력 핀에서 다른 기능 블록의 입력 핀으로 와이어를 연결합니다.
• 기능 블록의 왼쪽 핀은 입력, 오른쪽 핀은 출력입니다.
• 첫 번째 블록(A)의 출력 핀을 클릭한 뒤 두 번째 블록(B)의 입력 핀을 클릭하면 연결됩니다.
• 녹색 점(green dot)이 나타나면 유효한 연결입니다.
와이어 커넥터(Wire Connectors)
와이어 커넥터는 와이어 없이 경로를 생성할 때 사용합니다. 기능 블록이 많거나 멀리 떨어진 경우, 와이어 대신 커넥터를 사용하여 흐름을 단순화할 수 있습니다. 또한 같은 루틴의 다른 시트(sheet) 간 연결에도 사용됩니다. 그림 15-85에 예시가 있습니다.
사용 방식은 다음과 같습니다:
• 출력 와이어 커넥터(OCON)는 입력 와이어 커넥터(ICON)로 값을 보냅니다.
• 각 OCON은 적어도 하나의 대응되는 ICON을 가져야 합니다.
• 각 OCON은 고유 태그 이름을 가져야 하며, 해당 ICON은 동일한 이름을 사용해야 합니다.
• 여러 ICON이 하나의 OCON을 참조할 수 있으며, 이를 통해 기능 블록 다이어그램의 여러 위치에서 동일한 데이터를 공유할 수 있습니다.
igure 15-86은 FBD(Function Block Diagram) 프로그램의 신호 흐름(signal flow)과 실행 방식을 보여줍니다.
그 동작은 다음과 같이 요약할 수 있습니다:
• 각 프로그램 스캔(scan)마다 컨트롤러는 신호 흐름의 왼쪽에 있는 FBD 블록부터 시작하여 신호 흐름 방향대로 모든 블록을 평가하고, 최종 출력이 결정될 때까지 계속 실행합니다.
• 블록의 화면 배치 위치는 실행 순서에 영향을 주지 않습니다.
• 블록의 입력은 해당 블록이 실행되기 전에 유효한 데이터가 준비되어 있어야 합니다.
• 기능 블록 간에 와이어가 연결되어 있지 않다면, 블록 간 데이터 흐름이 없으므로 어떤 블록이 먼저 실행되는지는 중요하지 않습니다.
• 블록 간을 연결하는 선의 형태는 해당 연결에서 사용되는 신호의 종류를 나타냅니다.
Data Latching(데이터 래칭)
데이터 래칭은 컨트롤러가 기능 블록 입력에 존재하는 데이터가 유효한지 확인하는 방식입니다.
그림 15-87에 나타난 것처럼, 기능 블록 입력 데이터에 IREF(Input Reference)를 사용하면, IREF의 데이터는 해당 기능 블록 루틴이 실행되는 동안 변경되지 않고 고정(latch)됩니다.
• IREF는 프로그램 범위 태그(program-scoped tags)와 컨트롤러 범위 태그(controller-scoped tags)의 데이터를 래칭합니다.
• 컨트롤러는 각 스캔 시작 시 모든 IREF 값을 업데이트합니다.
하나의 FBD 루틴은 다음 순서로 실행됩니다:
- 컨트롤러가 모든 IREF의 데이터를 래칭합니다.
- 컨트롤러가 다른 기능 블록들을 순서대로 실행합니다.
- 컨트롤러가 OREF(Output Reference)에 출력을 기록합니다.
블록 주변에 피드백 루프(feedback loop)를 생성하려면, 해당 블록의 출력 핀(output pin)을 같은 블록의 입력 핀(input pin)에 연결합니다. 이렇게 하면 입력 핀은 기능 블록이 이전 스캔에서 생성한 출력 값을 받게 됩니다. 루프에는 단일 블록만 포함되므로 실행 순서는 중요하지 않습니다. 그림 15-88은 온딜레이 타이머(on-delay timer)를 리셋하기 위해 사용된 피드백 루프의 예를 나타냅니다. 타이머의 동작이 완료되면(DN 비트) 이 DN 비트가 타이머를 리셋하는 데 사용됩니다.
이 방식으로 타이머는 매번 완료될 때 자동으로 리셋되어 반복 동작을 수행할 수 있습니다.
피드백 루프(feedback loop) 안에 여러 기능 블록(function block)이 포함되어 있을 경우, 컨트롤러는 어떤 블록을 먼저 실행해야 하는지 판단할 수 없습니다. 이 문제는 가장 먼저 실행되어야 하는 기능 블록의 입력 핀(input pin)에 Assume Data Available(데이터 가용 상태 가정) 표시를 추가함으로써 해결됩니다.
그림 15-89의 예에서는 블록 1의 입력이 이전 스캔에서 블록 3이 생성한 데이터를 사용합니다. 따라서 블록 1이 먼저 실행되어야 합니다. 이 표시를 추가하려면, 기능 블록 간 연결선(interconnecting wire)을 클릭한 후 Assume Data Available 옵션을 선택하시면 됩니다.
FBD Programming
그림 15-90은 FBD(Function Block Diagram) 프로그래밍을 설정하는 절차를 보여줍니다.
따라야 할 단계는 다음과 같이 요약됩니다:
• MainProgram 파일을 마우스 오른쪽 버튼으로 클릭한 후, 팝업 메뉴에서 New Routine을 선택합니다.
• Type 창에서 Function Block Diagram 항목을 선택합니다.
• Routine 이름을 입력합니다(예: FBD_Sample).
• 이제 MainProgram 아래에 새로운 프로그램(FBD_Sample)이 표시됩니다.
• FBD_Sample을 두 번 클릭하면 그래픽 개발 창이 열립니다.
• Language Element 도구 막대에서 선택한 FBD 명령어들을 사용하여 프로그램을 작성합니다.
• 현재 시트(sheet)가 가득 찼을 경우, Add Sheet 아이콘을 클릭하여 추가 시트를 만들 수 있으며, 좌·우 화살표를 사용해 시트 간 이동이 가능합니다.
MainRoutine은 RSLogix 5000 소프트웨어에서 항상 래더( Ladder ) 논리 프로그램이며, 다른 모든 루틴은 MainRoutine에서 호출됩니다. 따라서 MainRoutine에는 무조건 실행되는(unconditional) 한 개의 런(rung)이 있으며, 여기에서 JSR(Jump to SubRoutine) 명령으로 FBD_Sample을 호출합니다. FBD 프로그램은 JSR 명령에 의해 실행되며, FBD 내부에서는 별도의 subroutine 또는 return 명령이 필요하지 않습니다.
FBD 프로그램은 래더 프로그램과 유사하지만, 프로세스를 래더 런 대신 기능 블록 형태로 시각화한다는 점이 다릅니다. 그림 15-91은 3입력 AND 래더 런을 기능 블록으로 구현했을 때의 비교를 보여줍니다. 동작은 다음과 같이 요약됩니다:
• Sensor_1, Sensor_2, Sensor_3 입력이 모두 true(값 1)일 때 BAND(Boolean AND) 기능 블록이 true가 됩니다.
• BAND 블록이 실행되어 출력 Caution_PL을 true로 설정하며, 파일럿 램프가 켜집니다.
• 입력 레퍼런스와 출력 핀 오른쪽에 표시되는 0과 1은 논리 상태를 나타냅니다.
- 0은 false
- 1은 true를 의미합니다.
- • 동일한 현장(field) 입력 센서와 출력 파일럿 램프 태그는 래더 프로그램과 FBD 프로그램 모두에서 동일하게 사용할 수 있습니다.
- • XIC(검사 접점)과 OTE(출력 코일) 명령은 FBD에서는 BAND 기능 블록으로 대체됩니다.
그림 15-92는 래더 논리와 이를 FBD로 구현한 2입력 OR 래더 런(rung)을 비교하여 보여줍니다. 래더의 OR 논리와 마찬가지로, 두 입력 중 어느 하나라도 true이면 BOR(Boolean OR) 기능 블록이 true가 됩니다. 이 예에서는 BOR 기능 블록이 true가 되면 출력 레퍼런스 태그 SOL_1이 true가 되어 솔레노이드가 여자됩니다.
그림 15-93은 여러 입력을 조합한 래더 논리와 이에 해당하는 FBD를 비교하여 나타냅니다. FBD의 동작은 다음과 같이 요약됩니다:
• BOR 블록의 입력 In1 또는 In2 중 어느 하나라도 true이면 알람이 여자됩니다.
• BOR 블록의 입력 In2는 세 개의 센서 스위치가 모두 닫혀 있을 때만 true가 됩니다.
• BOR 블록의 입력 In1은 Temp_Sw가 닫히고 동시에 Press_Sw가 열려 있을 때만 true가 됩니다.
• BNOT 기능 블록은 래더 논리의 XIO 명령과 동일한 방식으로 동작합니다. In이 0이면 Out은 1이 되고, 반대로 In이 1이면 Out은 0이 됩니다.
그림 15-94는 모터 기동/정지 제어 회로에 대해 래더 논리와 이에 해당하는 FBD를 비교하여 보여줍니다. 모터의 기동 및 정지 순서는 다음과 같이 요약됩니다:
• Motor_Start 버튼이 닫히면 BOR 블록의 출력이 true가 되고, 이어서 BAND 블록의 출력도 true가 됩니다.
• Motor_Run 출력이 접촉기 코일을 여자시키며, 접촉기의 접점이 닫혀 모터가 기동합니다.
• 이후 Motor_Start 버튼이 열려도, Motor_Run 태그로부터의 피드백 신호가 1이기 때문에 BOR 블록의 출력은 계속 true 상태를 유지합니다.
• Motor_Stop 버튼이 열리면 BAND 블록의 출력이 false가 되어 접촉기 코일이 비여자되고 모터가 정지합니다.
그림 15-95는 10초 TON(온딜레이 타이머)과 TONR(리셋 기능이 있는 온딜레이 타이머)의 래더 논리와 FBD 구현을 비교하여 보여줍니다. FBD의 동작은 다음과 같이 요약됩니다:
• Timer_Sw가 닫히면 TONR 기능 블록 타이머가 true가 되며 시간 누적을 시작합니다.
• 누적 시간은 ACC라는 이름의 출력 레퍼런스 태그에서 모니터링합니다.
• EN(enable bit) 출력이 1로 변하며 EN_PL이 켜집니다.
• TT(timer timing bit) 출력이 1로 변하며 TT_PL이 켜집니다.
• 타이머가 10초에 도달하면 DN(done bit)이 1로 설정되고 DN_PL이 켜집니다. 동시에 TT 비트는 0으로 리셋되며 TT_PL이 꺼집니다.
• Timer_Sw가 계속 닫혀 있는 동안 EN 비트와 EN_PL은 켜진 상태를 유지합니다.
• Timer_Sw를 열면 모든 출력과 누적 값이 0으로 리셋됩니다.
• 타이머는 Reset 입력을 통해서도 리셋할 수 있습니다.
그림 15-96은 버퍼 존(buffer zone)에 저장될 수 있는 부품 수를 50개로 제한하기 위해 사용된 Up/Down 카운터를 래더 논리와 FBD(Function Block Diagram) 방식으로 비교하여 보여줍니다. FBD의 동작은 다음과 같이 요약됩니다:
• CTUD(Count Up/Down) 카운터 기능 블록의 누적 값은 Restart_Button을 순간적으로 동작시켜 초기화됩니다.
• 누적 값은 ACC라는 이름의 출력 레퍼런스 태그를 통해 모니터링됩니다.
• 부품이 버퍼 존으로 들어올 때마다 Enter_Limit_Sw가 동작하고 CUEnable 입력이 true가 되어 누적 값이 1 증가합니다.
• 부품이 버퍼 존에서 빠져나갈 때마다 Exit_Limit_Sw가 동작하고 CDEnable 입력이 true가 되어 누적 값이 1 감소합니다.
• 버퍼 존의 부품 수가 50개에 도달하면 DN 비트가 1로 설정되고, BNOT 기능 블록의 출력이 0으로 리셋됩니다. 이로 인해 Conveyor_Contactor가 비여자되어 컨베이어 모터가 정지하며, 추가 부품이 유입되지 않도록 합니다.
그림 15-97은 카운터의 누적 값을 테스트하는 프로그램에 대해 래더 논리와 이에 해당하는 FBD를 비교한 예를 보여줍니다. FBD의 동작은 다음과 같이 요약됩니다:
• 기능 블록 루틴은 네 개의 시트(sheet)로 나뉘어 구성됩니다.
• 시트의 배치 순서는 기능 블록의 실행 순서에 영향을 주지 않습니다.
• 기능 블록 루틴이 실행되면 모든 시트가 함께 실행됩니다.
• 각 장치별로 별도의 시트를 사용하면 프로그램 구조가 정리되어 이해하기 쉬워집니다.
• ACC라는 이름의 OCON(출력 커넥터)과 ICON(입력 커넥터)을 사용하면 동일한 기능 블록 루틴 내의 서로 다른 시트에서도 값을 공유할 수 있습니다.
• ACC 출력 아래 표시되는 숫자와 문자는 해당 출력이 사용되는 시트 번호와 시트상의 위치를 나타냅니다.
