DeviceNet : アーキテクチャ、メッセージ形式、エラー コード、動作とそのアプリケーション

DeviceNet プロトコルは当初、現在 Rockwell Automation ブランドが所有する Allen-Bradley によって開発されました。このプロトコルをサードパーティ ベンダーとグローバルに推進することで、オープン ネットワークにすることが決定されました。現在、このプロトコルは ODVA Company (Open DeviceNet Vendors Association) によって管理されており、サードパーティ ベンダーが使用できるようにし、標準を開発しています。 ネットワークプロトコル . DeviceNet は単純に コントローラ エリア ネットワーク (CAN) ボッシュが開発した技術。会社。この技術で採用されている技術は、同じくAllen Bradley氏が開発したControlNetのものです。これがDevicenetの歴史です。したがって、この記事では、 Devicenet プロトコル – アプリケーションの操作。

DeviceNet プロトコルとは何ですか?

DeviceNet プロトコルは、制御デバイスを相互接続してデータを交換することにより、オートメーション産業分野で使用されるネットワーク プロトコルの一種です。 PLC 、産業用コントローラ、 センサー 、さまざまなベンダーのアクチュエーターおよび自動化システム。このプロトコルは、CAN (Controller Area Network) メディア レイヤー上で通常の産業用プロトコルを単純に使用し、さまざまなデバイス プロファイルをカバーするアプリケーション レイヤーを記述します。 Devicenet プロトコルの主なアプリケーションには、主に安全装置、データの交換、および大規模な I/O 制御ネットワークが含まれます。

特徴

の デバイスネットの特徴 以下のものが含まれます。

• DeviceNet プロトコルは、最大数の 2048 デバイスを含む最大 64 ノードをサポートします。
• このプロトコルで使用されるネットワーク トポロジは、デバイスを接続するためのドロップ ケーブルを介したバス ラインまたはトランクです。
• 幹線のいずれかの側で 121 オーム値の終端抵抗が使用されます。
• ブリッジ、リピーター、ゲートウェイ、ルーターを使用します。
• ネットワーク内でデータを送信するために、マスタースレーブ、ピアツーピア、マルチマスターなどのさまざまなモードをサポートしています。
• 同様のケーブルで信号と電力の両方を伝送します。
• これらのプロトコルは、電力を供給されているネットワークに接続したり、ネットワークから削除したりすることもできます。
• DeviceNet プロトコルは、システムが本質的に安全ではないため、バス上で 8A をサポートするだけです。高電力処理。

Devicenet アーキテクチャ

DeviceNet は、誘導センサー、リミット スイッチ、光電、押しボタン、インジケータ ライト、バーコード リーダー、モーター コントローラー、オペレーター インターフェイスなどの産業用デバイスをネットワークに接続するために使用される通信リンクであり、複雑でコストのかかる配線を回避します。そのため、直接接続により、デバイス間の通信が向上します。有線 I/O インターフェースの場合、デバイス レベルの分析はできません。

DeviceNet プロトコルは、幹線または支線のようなトポロジをサポートするだけなので、ノードを幹線または短い分岐に直接簡単に接続できます。すべての DeviceNet ネットワークでは、ノードがマスター「スキャナー」によって利用される場所に最大 64 のノードを接続でき、ノード 63 は、デバイスにアクセス可能な 62 のノードによってデフォルト ノードとして確保されます。しかし、ほとんどの産業用コントローラーでは、複数の DeviceNet ネットワークに接続できます。相互接続されたノードの数を拡張できます。

Devicenet ネットワーク プロトコル アーキテクチャを以下に示します。このネットワークは、物理層からアプリケーション層までの 7 つの層を使用する OSI モデルに単純に従っています。このネットワークは CIP (Common Industrial Protocol) に基づいており、最初から CIP の 3 つの上位層を利用しますが、最後の 4 つの層は DeviceNet のアプリケーションに合わせて変更されています。

DeviceNet の「物理層」には、主に、幹線 - ドロップライン トポロジ内のノード、ケーブル、タップ、および終端抵抗の組み合わせが含まれます。

データ リンク層の場合、このネットワーク プロトコルは、デバイスとコントローラ間のすべてのメッセージを単純に処理する CAN (Controller Area Network) 標準を利用します。

このプロトコルのネットワークとトランスポート層は、主にデバイスの MAC ID とメッセージ ID を含むノードの接続 ID を介して、デバイスによる接続を確立します。

ノードは、合計 64 の可能な接続を提供する 0 ～ 63 の範囲の DeviceNet の有効な範囲をアドレス指定します。ここで、接続 ID の主な利点は、MAC ID をチェックし、修正が必要であることをオペレーターに通知することで、DeviceNet が重複アドレスを認識できるようにすることです。

DeviceNet ネットワークは、必要な配線が少なくなるため、配線とメンテナンスのコストが削減されるだけでなく、さまざまなメーカーの DeviceNet ネットワーク互換ベースのデバイスも使用できます。このネットワーク プロトコルは、通信プロトコルとして知られるコントローラ エリア ネットワークまたは CAN に基づいています。主に、フィールド デバイス間の最大の柔軟性とさまざまなメーカー間の相互運用性のために開発されました。

このネットワークはデバイス バス ネットワークのように編成されており、その特徴はバイト レベルの通信と、ネットワーク デバイスを介したアナログ機器通信と高い診断能力を含む高速性です。 DeviceNet ネットワークには、0 ～ 63 で始まるノード アドレスごとに 1 つのデバイスを含む、最大 64 のデバイスが含まれます。

このネットワークでは、太いケーブルと細いケーブルの 2 つの標準タイプのケーブルが使用されます。太いケーブルは幹線に使用され、細いケーブルはドロップラインに使用されます。最大ケーブル長は、主に伝送速度に依存します。これらのケーブルには通常、黒、赤、青、白の 4 色のケーブルが含まれています。黒色のケーブルは 0V 電源用、赤色のケーブルは +24 V 電源用、青色のケーブルは CAN Low 信号用、白色のケーブルは CAN High 信号用です。

Devicenet はどのように機能しますか?

DeviceNet は次を使用して動作します CAN (コントローラーエリアネットワーク) そのデータ リンク層と同様のネットワーク技術は、スマート デバイス間の通信目的で自動車内で利用されています。 DeviceNet は、DeviceNet ネットワークのみで最大 64 ノードをサポートします。このネットワークには、1 つのマスターと最大 63 のスレーブを含めることができます。そのため、DeviceNet は、I/O を使用したマスター/スレーブおよびピアツーピア通信と、監視、制御、構成のための明示的なメッセージングをサポートします。このネットワーク プロトコルは、オートメーション業界で制御デバイスとの通信によるデータ交換に使用されます。 CAN メディア レイヤー上で Common Industrial Protocol または CIP を使用して、さまざまなデバイス プロファイルをカバーするアプリケーション レイヤーを定義します。

次の図は、デバイス ネット内のデバイス間でメッセージがどのように交換されるかを示しています。

Devicenet では、入力/出力データ通信がデバイス間で発生する前に、マスター デバイスはまず、接続オブジェクトを記述する明示的なメッセージの接続を使用してスレーブ デバイスに接続する必要があります。

上記の接続では、明示的メッセージ用の 1 つの接続と 4 つの I/O 接続を提供するだけです。

したがって、このプロトコルは主に、マスター デバイスが I/O データおよび情報交換コマンドに応じてスレーブ デバイスと接続する接続方法の概念に依存します。マスター コントロール デバイスをセットアップするには、関連する 4 つの主要な手順があり、各手順の機能を以下で説明します。

デバイスをネットワークに追加

ここでは、ネットワークに含めるスレーブ デバイスの MAC ID を提供する必要があります。

接続の構成

スレーブ デバイスの場合、I/O 接続のタイプと I/O データの長さを確認できます。

接続を確立する

接続が確立されると、ユーザーはスレーブ デバイスを介して通信を開始できます。

I/O データへのアクセス

スレーブデバイスによって通信が完了すると、同等の読み取りまたは書き込み機能を介して I/O データにアクセスできます。

明示的な接続が確立されると、接続レーンは、1 つのノードを使用して他のノードに広範な情報を交換するために使用されます。その後、ユーザーは次のステップで I/O 接続を行うことができます。 I/O 接続が確立されると、マスタ デバイスの要求に基づいて、DeviceNet ネットワーク内のデバイス間で I/O データを簡単に交換できます。そのため、マスター デバイスは、4 つの I/O 接続手法のいずれかを使用してスレーブ デバイスの I/O データにアクセスします。スレーブの I/O データを回復および送信するために、ライブラリは簡単に使用できるだけでなく、DeviceNet の多くのマスター機能も提供します。

Devicenet メッセージ形式

DeviceNet プロトコルは、特にそのデータ リンク層に、典型的なオリジナルの CAN を単純に使用します。したがって、これはデータ リンク層で CAN が必要とするかなり最小のオーバーヘッドであり、DeviceNet はメッセージを処理する際に非常に効率的になります。 Devicenet プロトコルでは、パッケージングと CIP メッセージの送信に使用されるネットワーク帯域幅が最小になり、デバイスがそのようなメッセージを送信するために必要なプロセッサのオーバーヘッドも最小になります。

ただし、CAN の仕様では、データ、リモート、オーバーロード、エラーなど、さまざまなタイプのメッセージ形式が定義されています。 DeviceNet プロトコルは、主にデータ フレームのみを使用します。したがって、CAN データ フレームのメッセージ フォーマットは以下のとおりです。

上記のデータ フレームでは、フレーム ビットの開始が送信されると、CAN ネットワーク上のすべてのレシーバーがレセッシブ状態からドミナント状態への移行と連携します。

フレーム内の Identifier と RTR (Remote Transmission Request) ビットの両方がアービトレーション フィールドを形成します。このフィールドは、メディア アクセスの優先度を支援するために使用されます。デバイスが送信すると、一度に送信するすべてのビットをチェックし、送信されたすべてのビットを受信して​​、送信されたデータを認証し、同期された送信を直接検出できるようにします。

CAN コントロール フィールドには主に 6 ビットが含まれ、2 ビットの内容は固定され、残りの 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 ユニットの LED が点灯することを確認します。
• DeviceNetユニットのLEDが点灯している場合は、LEDのエラー内容を確認し、対処してください。
• Devicenet のどの LED もオンにならない場合は、ライトが故障している可能性があります。そのため、コネクタのピンが破損または曲がっていないかどうかを確認する必要があります。
• DeviceNet を接続に注意して接続します。

Devicenet 対 ControlNet

Devicenet と ControlNet の違いを以下に示します。

Devicenet対Modbus

Devicenet と Modbus の違いを以下に示します。

Devicenet エラー コード

63 番号未満および 63 番号を超える DeviceNet エラー コードを以下に示します。ここで、63 未満の数字はノード番号として知られ、63 を超える数字はエラー コードまたはステータス コードとして知られています。ほとんどのエラー コードは、1 つまたは複数のデバイスに適用されます。これは、コードとノード番号を交互に点滅させることで示されます。複数のコードとノード番号を表示する必要がある場合、表示はノード番号順に表示されます。

次のリストでは、色付きのコードは単に意味を説明しています

• 緑色のカラーコードは、ユーザーのアクションによって引き起こされる正常または異常な状態を示します。
• 青色のカラー コードは、エラーまたは異常な状態を示します。
• 赤色のカラー コードは重大なエラーを示しており、おそらく交換用のスキャナーが必要です。

ここでは、必要なアクションを含む Devicenet エラー コードを以下に示します。

00 ～ 63 のコード (緑色): ディスプレイにスキャナのアドレスが表示されます。
コード 70 (青色): スキャナー チャネルのアドレスを変更します。そうしないと、デバイスのアドレスが競合します。
コード 71 (青色): スキャン リストを再構成し、不正なデータを削除する必要があります。
Code 72 (青色): デバイスは接続を確認して確認する必要があります。
コード 73 (青色): 正確なデバイスがこのノード番号にあることを確認し、デバイスがスキャン リスト内に配置されている電子キーと等しいことを確認します。
コード 74 (青色): 許容できないデータおよびネットワーク トラフィックの構成を確認します。
Code 75 (緑色): スキャン リストを作成してダウンロードします。
Code 76 (緑色): スキャン リストを作成してダウンロードします。
コード 77 (青色): リストをスキャンするか、デバイスを再構成して、適切な送受信データ サイズにします。
コード 78 (青色): デバイスをネットワークに含めるか、ネットワークから削除します。
コード 79 (青色): スキャナが少なくとも 1 つの他のノードによって適切なネットワークに接続されているかどうかを確認します。
コード 80 (緑色): スキャナ コマンド レジスタ内の RUN ビットを見つけて、PLC を RUN モードにします。
コード 81 (緑色): PLC プログラムとスキャナのコマンド レジスタを確認します。
コード 82 (青色): デバイスの構成を確認してください。
コード 83 (青色): スキャン リストのエントリを確認し、デバイスの構成を確認してください
コード 84 (緑色): デバイスによるスキャン リスト内の通信を初期化中
コード 85 (青色): データ サイズが小さくなるようにデバイスを調整します。
コード 86 (青色): デバイスのステータスと構成を確認します。
コード 87 (青色): プライマリ スキャナと構成の接続を確認します。
コード 88 (青色): スキャナーの接続を確認してください。
コード 89 (青色): このデバイスの配置を確認/ADR を無効にします。
Code 90 (緑色): スキャナの PLC プログラムとコマンド レジスタを確認してください
コード 91 (青色): 障害のあるデバイスについてシステムを確認します
コード 92 (青色): ドロップ ケーブルがスキャナの DeviceNet のポートにネットワーク電力を供給しているかどうかを確認します。
Code 95 (緑色): FLASH の更新が進行中の場合は、スキャナーを取り外さないでください。
コード 97 (緑色): スキャナのラダー プログラムとコマンド レジスタを確認します。
Code 98 & 99 (赤色): モジュールを交換または修理してください。
コード E2、E4 & E5 (赤色): モジュールを交換または返却してください。
コード E9 (緑色): SDN のコマンド レジスタとサイクルの電源を確認して回復します。
スキャナはディスプレイを備えたモジュールであり、デバイスはネットワーク上の他のノードであり、通常はスキャナのスキャン リスト内のスレーブ デバイスです。これは、スキャナーのもう 1 つのスレーブ モードのパーソナリティです。

デバイスネットのメリット

DeviceNet プロトコルの利点には、次のようなものがあります。

• これらのプロトコルは低コストで利用でき、信頼性が高く、広く受け入れられており、ネットワーク帯域幅が非常に効率的に使用され、ネットワーク上で電力が利用可能です。
• これらは、プロジェクトのコストを大幅に増加させることなく、大量のデータを収集できます。
• インストールにかかる時間が短くなります。
• 通常のポイントツーポイント配線に比べてコストがかかりません。
• 場合によっては、DeviceNet デバイスは、通常のデバイスやスイッチド デバイスと比較して、より多くの制御機能を提供します。
• ほとんどの Devicenet デバイスは、システムのトラブルシューティングを非常に簡単にし、ダウンタイムを短縮する、非常に役立つ診断データを提供します。
• このプロトコルは、任意の PC または PLC またはベースの制御システムで利用できます。

DeviceNet プロトコルの欠点には、次のようなものがあります。

• これらのプロトコルには最大ケーブル長があります。
• メッセージのサイズと帯域幅が制限されています。
• すべての DeviceNet の問題の 90 ～ 95% は、主にケーブルの問題が原因で発生します。
• 各ノードのデバイス数が少ない
• メッセージの制限されたサイズ。
• ケーブル距離が大幅に短縮されます。

DeviceNet プロトコル アプリケーション

の DeviceNet プロトコル アプリケーション 以下のものが含まれます。

• DeviceNet プロトコルは、アクチュエータなどのさまざまな産業用デバイス間の接続を提供します。 自動化システム 、センサー、および複雑なデバイスを介在する必要なしに
• I/O ブロックまたはモジュール。
• DeviceNet プロトコルは、産業オートメーション アプリケーションで使用されます。
• DeviceNet ネットワーク プロトコルは、オートメーション業界で制御デバイスを相互接続してデータを交換するために利用されています。
• モーターの制御には DeviceNet プロトコルを使用します。
• このプロトコルは、マニホールドを制御するための近接、単純なリミット スイッチ、およびプッシュ ボタンに適用できます。
• これは、複雑な AC & DC ドライブ アプリケーションで使用されます。

したがって、これは DeviceNetの概要 これはマルチドロップのデジタル フィールドバス ネットワークであり、PLC、産業用コントローラー、センサー、アクチュエーター、自動化システムなどのマルチベンダーの複数のデバイスを接続するために使用されます。建築学、建築物、建築様式。ここで質問があります。プロトコルとは何ですか?