DeviceNet : 아키텍처, 메시지 형식, 오류 코드, 작업 및 응용 프로그램

DeviceNet 프로토콜은 현재 Rockwell Automation 브랜드가 소유하고 있는 Allen-Bradley가 처음 개발했습니다. 이 프로토콜을 타사 공급업체와 함께 전 세계적으로 홍보하여 ​​개방형 네트워크로 만들기로 결정했습니다. 이제 이 프로토콜은 ODVA Company(Open DeviceNet Vendors Association)에서 관리하여 타사 공급업체가 사용하도록 허용하고 표준을 개발합니다. 네트워크 프로토콜 . DeviceNet은 단순히 컨트롤러 영역 네트워크(CAN) 보쉬에서 개발한 기술입니다. 회사. 이 기술에 채택된 기술은 Allen Bradley가 개발한 ControlNet의 기술입니다. 이것이 Devicenet의 역사입니다. 따라서 이 문서에서는 디바이스넷 프로토콜 – 응용 프로그램 작업.

DeviceNet 프로토콜이란 무엇입니까?

DeviceNet 프로토콜은 다음과 같은 데이터 교환을 위해 제어 장치를 상호 연결하여 자동화 산업 분야에서 사용되는 네트워크 프로토콜의 한 유형입니다. PLC , 산업용 컨트롤러, 감지기 다양한 공급업체의 s, 액추에이터 및 자동화 시스템. 이 프로토콜은 단순히 CAN(Controller Area Network) 미디어 계층을 통해 일반 산업용 프로토콜을 사용하고 다양한 장치 프로필을 포함하는 응용 프로그램 계층을 설명합니다. Devicenet 프로토콜의 주요 응용 프로그램에는 주로 안전 장치, 데이터 교환 및 대규모 I/O 제어 네트워크가 포함됩니다.

특징

그만큼 디바이스넷의 특징 다음을 포함합니다.

• DeviceNet 프로토콜은 2048개의 가장 많은 장치를 포함하여 최대 64개의 노드를 지원합니다.
• 이 프로토콜에서 사용되는 네트워크 토폴로지는 장치를 연결하기 위한 드롭 케이블을 통한 버스 라인 또는 트렁크입니다.
• 121옴 값의 종단 저항은 트렁크 라인의 모든 측면에 사용됩니다.
• 브리지, 리피터 광고 게이트웨이 및 라우터를 사용합니다.
• 네트워크 내에서 데이터를 전송하기 위해 마스터-슬레이브, 피어 투 피어 및 멀티 마스터와 같은 다양한 모드를 지원합니다.
• 유사한 케이블로 신호와 전원을 모두 전달합니다.
• 이러한 프로토콜은 전원이 켜진 네트워크에서 연결하거나 제거할 수도 있습니다.
• DeviceNet 프로토콜은 시스템이 본질적으로 안전하지 않기 때문에 버스에서 8A를 지원합니다. & 고전력 처리.

디바이스넷 아키텍처

DeviceNet은 복잡하고 값비싼 배선을 피함으로써 유도 센서, 리미트 스위치, 광전, 푸시 버튼, 표시등, 바코드 판독기, 모터 컨트롤러 및 운영자 인터페이스와 같은 산업용 장치를 네트워크에 연결하는 데 사용되는 통신 링크입니다. 따라서 직접 연결은 장치 간의 더 나은 통신을 제공합니다. 유선 I/O 인터페이스의 경우 디바이스 레벨 분석이 불가능합니다.

DeviceNet 프로토콜은 단순히 간선 또는 드롭라인과 같은 토폴로지를 지원하므로 노드를 본선 또는 짧은 분기에 직접 쉽게 연결할 수 있습니다. 모든 DeviceNet 네트워크는 노드가 마스터 '스캐너'에 의해 사용되는 모든 곳에서 최대 64개의 노드를 연결할 수 있도록 허용하고 노드 63은 장치에 액세스할 수 있는 62개의 노드에 의해 기본 노드로 따로 설정됩니다. 그러나 대부분의 산업용 컨트롤러는 여러 DeviceNet 네트워크에 연결할 수 있습니다. 연결된 노드의 수를 확장할 수 있습니다.

Devicenet 네트워크 프로토콜 아키텍처는 다음과 같습니다. 이 네트워크는 물리적 계층에서 응용 계층까지 7개의 계층을 사용하는 OSI 모델을 따릅니다. 이 네트워크는 처음부터 CIP의 상위 3개 계층을 활용하는 CIP(Common Industrial Protocol)를 기반으로 하지만 마지막 4개 계층은 DeviceNet 적용으로 수정되었습니다.

DeviceNet의 '물리적 계층'은 주로 트렁크라인-드롭라인 토폴로지 내의 노드, 케이블, 탭 및 종단 저항의 조합을 포함합니다.

데이터 링크 계층의 경우 이 네트워크 프로토콜은 장치와 컨트롤러 간의 모든 메시지를 단순히 처리하는 CAN(Controller Area Network) 표준을 활용합니다.

이 프로토콜의 네트워크 및 전송 계층은 주로 장치의 MAC ID 및 메시지 ID를 포함하는 노드에 대한 연결 ID를 통해 장치에 의한 연결을 설정합니다.

노드는 총 64개의 가능한 연결을 제공하는 0에서 63까지의 DeviceNet에 대한 유효한 범위를 지정합니다. 여기서 연결 ID의 주요 이점은 DeviceNet이 MAC ID를 확인하고 고정이 필요한 사업자에게 신호를 보내 중복 주소를 인식할 수 있다는 것입니다.

DeviceNet 네트워크는 배선이 덜 필요하여 배선 및 유지보수 비용을 절감할 뿐만 아니라 다양한 제조업체의 DeviceNet 네트워크 호환 기반 장치를 허용합니다. 이 네트워크 프로토콜은 통신 프로토콜로 알려진 CAN 또는 Controller Area Network를 기반으로 합니다. 주로 필드 장치 간의 최대 유연성 및 다양한 제조업체 간의 상호 운용성을 위해 개발되었습니다.

이 네트워크는 네트워크 장치를 통한 아날로그 장비 통신 및 높은 진단 능력을 포함하는 바이트 수준의 통신 및 고속이 특징인 장치 버스 네트워크와 같이 구성됩니다. DeviceNet 네트워크에는 0 – 63에서 시작하는 모든 노드 주소의 단일 장치를 포함하여 최대 64개의 장치가 포함됩니다.

이 네트워크에는 굵고 가는 두 개의 표준형 케이블이 사용됩니다. 굵은 케이블은 트렁크 라인에 사용되는 반면 가는 케이블은 드롭라인에 사용됩니다. 가장 높은 케이블 길이는 주로 전송 속도에 따라 다릅니다. 이 케이블에는 일반적으로 검정, 빨강, 파랑 및 흰색과 같은 4가지 색상의 케이블이 포함됩니다. 검은색 케이블은 0V 전원 공급 장치용, 빨간색 케이블은 +24V 전원 공급 장치용, 파란색 케이블은 CAN 로우 신호용, 흰색 케이블은 CAN 하이 신호용입니다.

Devicenet은 어떻게 작동합니까?

DeviceNet은 다음을 사용하여 작동합니다. CAN(컨트롤러 영역 네트워크) 데이터 링크 레이어 및 유사한 네트워크 기술은 스마트 장치 간의 통신 목적을 위해 자동차 내에서 활용됩니다. DeviceNet은 DeviceNet 네트워크에서만 최대 64개의 노드를 지원합니다. 이 네트워크에는 단일 마스터와 최대 63개의 슬레이브가 포함될 수 있습니다. 따라서 DeviceNet은 모니터링, 제어 및 구성을 위한 명시적 메시징뿐만 아니라 I/O를 사용하여 마스터/슬레이브 및 피어 투 피어 통신을 지원합니다. 이 네트워크 프로토콜은 제어 장치와의 통신에 의한 데이터 교환을 위해 자동화 산업에서 활용됩니다. CAN 미디어 계층을 통해 공통 산업 프로토콜 또는 CIP를 사용하여 다양한 장치 프로필을 포괄하는 응용 프로그램 계층을 정의합니다.

다음 다이어그램은 장치 네트워크 내의 장치 간에 메시지가 교환되는 방식을 보여줍니다.

Devicenet에서는 기기간 입출력 데이터 통신이 이루어지기 전에 먼저 Master 기기가 슬레이브 기기에 연결 대상을 설명하는 명시적 메시지의 연결로 연결해야 합니다.

위의 연결에서 명시적 메시지 및 4개의 I/O 연결에 대해 단일 연결을 제공하기만 하면 됩니다.

따라서 이 프로토콜은 주로 I/O 데이터 및 정보 교환 명령에 따라 마스터 장치가 슬레이브 장치와 연결해야 하는 연결 방식 개념에 의존합니다. 마스터 제어 장치를 설정하려면 4가지 주요 단계가 필요하며 각 단계 기능은 아래에 설명되어 있습니다.

네트워크에 장치 추가

여기서 네트워크에 포함할 슬레이브 장치의 MAC ID를 제공해야 합니다.

연결 구성

슬레이브 장치의 경우 I/O 연결 유형 및 I/O 데이터 길이를 확인할 수 있습니다.

연결 설정

연결이 이루어지면 사용자는 슬레이브 장치를 통해 통신을 시작할 수 있습니다.

I/O 데이터 액세스

슬레이브 장치에서 통신이 완료되면 동등한 읽기 또는 쓰기 기능을 통해 I/O 데이터에 액세스할 수 있습니다.

명시적 연결이 이루어지면 연결 레인은 한 노드를 사용하여 다른 노드로 광범위한 정보를 교환하는 데 사용됩니다. 그 후 사용자는 다음 단계에서 I/O 연결을 할 수 있습니다. I/O 연결이 이루어지면 마스터 장치의 요구에 따라 DeviceNet 네트워크 내의 장치 간에 I/O 데이터를 간단히 교환할 수 있습니다. 따라서 마스터 장치는 4가지 I/O 연결 기술 중 하나를 사용하여 슬레이브 장치의 I/O 데이터에 액세스합니다. 슬레이브의 I/O 데이터를 복구 및 전송하기 위해 라이브러리는 활용이 간단할 뿐만 아니라 DeviceNet의 많은 마스터 기능을 제공합니다.

디바이스넷 메시지 형식

DeviceNet 프로토콜은 특히 데이터 링크 계층에 대해 일반적이고 원래의 CAN을 사용합니다. 따라서 이것은 메시지를 처리하는 동안 DeviceNet이 매우 효율적이 되도록 데이터 링크 계층에서 CAN에 필요한 최소한의 오버헤드입니다. Devicenet 프로토콜을 통해 CIP 메시지를 패키징하고 전송하는 데 가장 적은 네트워크 대역폭이 사용되며 이러한 메시지를 전송하는 장치를 통해 최소한의 프로세서 오버헤드가 필요합니다.

그럼에도 불구하고 CAN의 사양은 데이터, 원격, 과부하 및 오류와 같은 다양한 유형의 메시지 형식을 정의합니다. DeviceNet 프로토콜은 주로 데이터 프레임만 사용합니다. 따라서 CAN 데이터 프레임의 메시지 형식은 다음과 같습니다.

위의 데이터 프레임에서 프레임 비트의 시작이 전송되면 CAN 네트워크의 모든 수신기가 열성에서 우세한 상태로의 전환을 조정합니다.

프레임의 식별자 및 RTR(원격 전송 요청) 비트는 미디어 액세스 우선 순위를 돕기 위해 단순히 사용되는 중재 필드를 형성합니다. 장치는 일단 전송하면 동시에 전송하는 모든 비트를 확인하고 전송된 모든 비트를 수신하여 전송된 데이터를 인증하고 동기화된 전송을 직접 감지할 수 있습니다.

CAN 제어 필드는 주로 2비트 내용이 고정된 6비트를 포함하고 나머지 4비트는 0에서 8바이트의 향후 데이터 필드 길이를 지정하기 위한 길이 필드에 주로 사용됩니다.
CAN의 데이터 프레임 뒤에는 프레임 오류 및 다양한 프레임 포맷 구분자를 식별하기 위한 CRC(Cyclic Redundancy Check) 필드가 옵니다.

CRC 및 자동 재시도와 같은 오류 제한 기술뿐만 아니라 다양한 종류의 오류 감지를 사용하여 오류 노드가 n/w를 방해하는 것을 방지할 수 있습니다. CAN은 매우 강력한 오류 검사와 오류 제한 용량을 제공합니다.

도구

DeviceNet 프로토콜을 분석하는 데 사용되는 다양한 도구에는 Synergetic의 SyCon, Cutler-Hammer의 NetSolver, Allen-Bradley의 RSNetworX, DeviceNet Detective 및 CAN 트래픽 모니터 또는 Peak의 CAN Explorer 및 Vector의 Canalyzer와 같은 분석기가 포함됩니다.

Devicenet 프로토콜의 오류 처리

오류 처리는 프로그램 내에서 오류 조건에 대응하고 복구하는 절차입니다. 데이터 링크 계층은 CAN에 의해 ​​처리되기 때문에 결함 노드 감지 및 결함 노드 종료와 관련된 오류 처리는 CAN 네트워크 프로토콜에 따릅니다. 그러나 DeviceNet의 에러는 주로 DeviceNet의 유닛이 제대로 연결되지 않았거나 디스플레이 유닛에 문제가 있는 경우 등의 이유로 발생합니다. 이러한 문제점을 극복하기 위해서는 다음과 같은 절차를 따라야 한다.

• DeviceNet 장치를 올바르게 연결하십시오.
• DeviceNet의 케이블을 분리하십시오.
• 모든 디스플레이 장치에 대해 전원 공급 장치를 측정해야 합니다.
• 전압은 정격 전압 범위에서 조정해야 합니다.
• 전원을 켜고 DeviceNet 장치의 LED가 켜져 있는지 확인합니다.
• DeviceNet 유닛의 LED가 켜져 있으면 LED 오류 내용을 확인하고 그에 따라 문제를 수정하십시오.
• Devicenet의 LED가 켜지지 않으면 표시등에 결함이 있을 수 있습니다. 따라서 커넥터 핀이 부러지거나 구부러져 있는지 확인해야 합니다.
• 주의를 기울여 DeviceNet을 연결에 연결하십시오.

Devicenet 대 ControlNet

Devicenet과 ControlNet의 차이점은 다음과 같습니다.

Devicenet 대 Modbus

Devicenet과 Modbus의 차이점은 다음과 같습니다.

Devicenet 오류 코드

63개 미만 및 63개 초과의 DeviceNet 오류 코드는 아래에 나열되어 있습니다. 여기서 < 63개의 숫자는 노드 번호로 알려진 반면 >63개의 숫자는 오류 코드 또는 상태 코드로 알려져 있습니다. 대부분의 오류 코드는 하나 이상의 장치에 적용됩니다. 따라서 이것은 코드와 노드 번호를 번갈아 깜박임으로써 표시됩니다. 여러 코드 및 노드 번호를 표시해야 하는 경우 노드 번호 순서 내에서 표시가 순환됩니다.

다음 목록에서 색상이 있는 코드는 단순히 의미를 설명합니다.

• 녹색 색상 코드는 사용자의 동작으로 인해 발생하는 정상 또는 비정상 상태를 나타냅니다.
• 파란색 코드는 오류 또는 비정상 상태를 나타냅니다.
• 빨간색 코드는 심각한 오류를 나타내며 스캐너를 교체해야 할 수 있습니다.

필요한 조치가 포함된 Devicenet 오류 코드는 다음과 같습니다.

00에서 63까지의 코드(녹색): 디스플레이에 스캐너 주소가 표시됩니다.
코드 70(파란색): 스캐너 채널의 주소를 수정합니다. 그렇지 않으면 장치의 주소가 충돌합니다.
코드 71(파란색): 스캔 목록은 잘못된 데이터를 재구성하고 제거해야 합니다.
코드 72(파란색): 장치가 연결을 확인하고 확인해야 합니다.
코드 73(파란색): 정확한 장치가 이 노드 번호에 있는지 확인하고 장치가 스캔 목록에 배열된 전자 키와 동일한지 확인합니다.
코드 74(파란색): 허용되지 않는 데이터 및 네트워크 트래픽에 대한 구성을 확인합니다.
코드 75(녹색): 스캔 목록을 생성 및 다운로드합니다.
코드 76(녹색): 스캔 목록을 생성 및 다운로드합니다.
코드 77(파란색): 목록을 스캔하거나 적절한 송수신 데이터 크기에 맞게 장치를 재구성합니다.
코드 78(파란색): 네트워크에서 장치를 포함하거나 삭제합니다.
코드 79(파란색): 스캐너가 하나 이상의 다른 노드에 의해 적절한 네트워크에 연결되어 있는지 확인합니다.
코드 80(녹색): 스캐너 명령 레지스터 내에서 RUN 비트를 찾고 PLC를 RUN 모드로 설정합니다.
코드 81(녹색): PLC 프로그램과 스캐너의 명령 레지스터를 확인합니다.
코드 82(파란색): 장치의 구성을 확인하십시오.
코드 83(파란색): 스캔 목록 항목을 확인하고 장치 구성을 확인합니다.
코드 84(녹색): 장치별 스캔 목록 내 통신 초기화
코드 85(파란색): 장치를 더 작은 데이터 크기로 정렬합니다.
코드 86(파란색): 장치 상태 및 구성을 확인합니다.
코드 87(파란색): 기본 스캐너의 연결 및 구성을 확인합니다.
코드 88(파란색): 스캐너의 연결을 확인하십시오.
코드 89(파란색): 이 장치의 배열을 확인하거나 ADR을 비활성화하십시오.
코드 90(녹색): 스캐너의 PLC 프로그램 및 명령 레지스터를 확인하십시오.
코드 91(파란색): 시스템에서 실패한 장치를 확인합니다.
코드 92(파란색): 드롭 케이블이 스캐너 DeviceNet의 포트에 네트워크 전원을 공급하는지 확인합니다.
코드 95(녹색): FLASH 업데이트가 진행 중일 때 스캐너를 제거하지 마십시오.
코드 97(녹색): 스캐너의 래더 프로그램 및 명령 레지스터를 확인합니다.
코드 98 및 99(빨간색): 모듈을 교체하거나 서비스를 받으십시오.
코드 E2, E4 & E5(빨간색): 모듈을 교체하거나 반환합니다.
코드 E9(녹색): 복구하려면 SDN의 명령 레지스터 및 전원을 확인하십시오.
스캐너는 디스플레이가 있는 모듈인 반면 장치는 네트워크의 다른 노드이며 일반적으로 스캐너의 스캔 목록에 있는 슬레이브 장치입니다. 이것은 스캐너의 슬레이브 모드 특성을 하나 더 만들 수 있습니다.

디바이스넷의 장점

DeviceNet 프로토콜의 장점은 다음과 같습니다.

• 이러한 프로토콜은 더 저렴한 비용으로 사용할 수 있고 높은 신뢰성을 가지며 널리 수용되며 네트워크 대역폭이 매우 효율적으로 사용되며 네트워크에서 사용 가능한 전원이 공급됩니다.
• 이들은 프로젝트 비용을 크게 증가시키지 않고 많은 양의 데이터를 수집할 수 있습니다.
• 설치 시간이 덜 걸립니다.
• 일반 점대점 배선에 비해 비용이 많이 들지 않습니다.
• 때때로 DeviceNet 장치는 일반 또는 스위치 장치에 비해 더 많은 제어 기능을 제공합니다.
• 대부분의 Devicenet 장치는 시스템의 문제 해결을 매우 쉽게 만들고 가동 중지 시간을 줄일 수 있는 매우 유용한 진단 데이터를 제공합니다.
• 이 프로토콜은 모든 PC 또는 PLC 또는 기반 제어 시스템과 함께 사용할 수 있습니다.

DeviceNet 프로토콜의 단점은 다음과 같습니다.

• 이러한 프로토콜에는 최대 케이블 길이가 있습니다.
• 그들은 제한된 메시지 크기와 제한된 대역폭을 가지고 있습니다.
• 모든 DeviceNet 문제의 90~95%는 주로 케이블 문제로 인해 발생합니다.
• 각 노드에 대한 더 적은 수의 장치
• 메시지의 제한된 크기입니다.
• 케이블 거리가 훨씬 짧습니다.

DeviceNet 프로토콜 애플리케이션

그만큼 DeviceNet 프로토콜 애플리케이션 다음을 포함합니다.

• DeviceNet 프로토콜은 액추에이터, 자동화 시스템 , 센서 및 개입이 필요 없는 복잡한 장치
• I/O 블록 또는 모듈.
• DeviceNet 프로토콜은 산업 자동화 애플리케이션에 사용됩니다.
• DeviceNet 네트워크 프로토콜은 데이터 교환을 위한 제어 장치를 상호 연결하기 위해 자동화 산업에서 활용됩니다.
• DeviceNet 프로토콜은 모터를 제어하는 ​​데 사용됩니다.
• 이 프로토콜은 매니폴드를 제어하기 위한 근접, 간단한 리미트 스위치 및 푸시 버튼에 적용 가능합니다.
• 이것은 복잡한 AC 및 DC 드라이브 애플리케이션에 사용됩니다.

따라서 이것은 DeviceNet 개요 PLC, 산업용 컨트롤러, 센서, 액추에이터 및 자동화 시스템과 같은 멀티 벤더의 여러 장치를 연결하는 데 사용되는 멀티 드롭, 디지털 Fieldbus 네트워크입니다. 건축. 여기 당신을 위한 질문이 있습니다. 프로토콜이란 무엇입니까?