<< Click to Display Table of Contents >> マニュアル > 機器接続ガイド > 共通項目 |
概要
共通的なデバイス接続の内容として、以下の項目について記述しております。
本パッケージでは、1ライセンスで複数台・異機種PLCとの通信が同時に行えます。
以下は、デバイスドライバの選択画面
1台のPLCと接続する場合です。 |
|
|
|
複数台のPLCと接続する場合です。各PLCとの通信は独立しており、並列的に通信されます。たとえ1台のPLCが通信不能になったとしても、他のPLCの通信に対して影響は及びません。 |
PLCとの通信設定は以下の2箇所で行います。
■ユニット 各PLC固有の接続設定を行います。
|
|
■フォルダ 各PLC固有のネットワークに関連する設定を行います。 右側に表示される「ネットワークの書式」に従い設定を行って下さい。
|
|
RS-422でのマルチドロップ接続や、各メーカー固有のネットワーク(MELSECNETなど)でPLCが連結されている場合、フォルダの「ネットワーク設定」により、PLC固有のネットワーク上にある異なったPLCをフォルダごとに区別できます。 |
接続テストを行うには、ユニットの通信設定を開き、「接続テスト」のタブから行います。
例)三菱QシリーズEthernet
ユニットの接続設定には必ず「接続テスト」タブがあり、ネットワーク設定を行い「テスト実行」ボタンによりテストを開始します。
ネットワーク開始と終了は、ネットワーク上にある複数のPLCに対して連続的にテストを行います。
1台のみのテストの場合は、開始と終了を同じ設定にして下さい。
テスト実行を行うと、テスト結果が表示されます。接続NGの場合は、エラーメッセージの内容を確認してください。
接続しているPLCとの通信が切れた場合、ユニットの状態はデバイスダウンという状態に移行します。そのためデバイスダウンとなっていれば、通信及びPLC側に異常が発生したと判断できます。
デバイスダウンの設定は通信設定のデバイスダウン項目より行います。
デバイスダウンの認識方法
デバイスダウンの認識方法は以下の3つから選択します。
▪「どんな場合でもデバイスダウンと認識しない」
この設定はデバイスダウンを認識したくない場合に選択します。この場合、システムプロパティのAliveでデバイスのダウンを取得することができません。
▪「リフレッシュ通信が連続して失敗したらデバイスダウンとする(フォルダ毎/ユニット毎)」
ユニットの通信が指定回数失敗したらデバイスダウンとします。この設定はフォルダ単位とユニット単位で選ぶことができます。フォルダごとに異なるPLCに対して接続を行っている場合は、フォルダ毎としてください。それ以外の場合はユニット毎となります。
回数は以下の数値を変えることで変更できます。デフォルトでは3回です。
フォルダごとに異なるPLCへ接続している状態で、ユニット毎を選択していると、複数あるフォルダのどれか1つがデバイスダウンになると、他のフォルダもデバイスダウン状態になります。 そのため、異常が発生していないPLCとの通信もできなくなってしまうためフォルダ毎を選択する必要があります。
|
デバイスダウンまでの秒数はユニットの詳細設定で設定された待ち時間とリトライ回数に依存する場合があります。 例えば、
・1秒周期で通信タグの更新を行っている ・待ち時間:3秒 リトライ回数:3回 ・通信に失敗した回数:3回
とした場合、12秒(3秒のリトライが4回発生)×3回の計算となり、約36秒後にデバイスダウンと認識されます。 |
デバイスダウン中の処理
デバイスダウンへ移行した後の処理は以下の3つから選択します。
▪「デバイスダウンになっても特に何もしない」
デバイスダウンになったという情報をシステムプロパティAliveで認識したい場合のみ選択します。それ以外の場合は通常選択しません。
▪「デバイスダウン処理Aを行う(推奨)」
デフォルトではこの設定が選択されています。
この設定は、デバイスダウン中、Read/Writeの通信要求がきた場合、実際に通信を行わず、即座に通信失敗と認識させます。そのため、Read/Write 要求に対して、通信タイムアウト時間待たされるといったことはありません。
デバイスの復活は、指定した周期毎に復活確認を行い、復活確認が成功したら通信を再開します。
▪「デバイスダウン処理Bを行う」
デバイスダウンの復活は、処理A同様で指定した周期ごとに復活確認を行い、復活確認が成功したら通信を再開します。
この周期と合わせて、Read/Writeの通信要求がきた場合、実際に通信を発生させ、通信が成功すればデバイスダウンが解除されるため、即座に通信復帰したい場合はこちらを選択します。
デバイスダウンまでの秒数はユニットの詳細設定で設定された待ち時間とリトライ回数に依存する場合があります。 例えば、
・1秒周期で通信タグの更新を行っている ・待ち時間:3秒 リトライ回数:3回 ・通信に失敗した回数:3回
とした場合、12秒(3秒のリトライが4回発生)×3回の計算となり、約36秒後にデバイスダウンと認識されます。 |
特別な理由がなければ、デフォルトの処理Aが推奨であるため、こちらを選択してください。 |
通信エラー、復活確認、復活確認OKまでの情報は全てOutputLogに出力することができます。 |
PLCとの通信のためのプロトコルはメーカーによって異なります。ほとんどのPLCはビット単位やワード単位での読み、書きのためのプロトコルが用意されています。本パッケージではそれらのプロトコルを使用し、かつ、最高の速度で通信が行えるように内部で最適化を行っています。
メーカーのプロトコル仕様によっては、書き込み時に注意が必要な場合があります。それは、ビット単位での通信プロトコルがサポートされていないデバイスに対して、ビット単位での書き込みを行う場合に生じる問題です。
例えば、メーカー固有の仕様によりワード単位などのまとまった単位での通信プロトコルしか用意されていない場合です。
ビット単位で読込みたい場合は、ワード単位で読み込んで相当するビットの部分を抜き出せば問題ありません。
しかしながら、書き込み時にワード単位でしか処理を行えないため、相当する一部分のビットのみ変更したい場合、他のビットに影響がないような方法を取らなければなりません。
そのための方法として、以下の三つのレベルが考えられます。
▪レベル1
前回通信を行ったときの値を覚えておき、相当するビットの部分のみを書き換えて書き込みを行います。
しかし、ここでの「前回」とは100ms前かもしれませんし、1分前かもしれません。したがって、その間にPLCが値を変更していた場合、PC側は変更を検知できないため、前回値で書き換えてしまうとPLCが変更した部分を元の値に書き換えてしまう可能性があります。
PLCが値を書き換えないことが明確な場合には、この方法が一番簡単です。
▪レベル2
書き込みを行う直前に現時点のPLCの値を取得して、取得した直後に、変更対象としたいビット部分のみを置き換えた値で書き込みを行います。
この方法は、通信が2回発生するデメリットがありますが、書き込みを行う直前の値(実質は約20~60ms前)が必ず使われるため、この数十msの間にPLCが値を変更しない限り、確実な値を書き込むことができます。この方法は最も一般的です。
▪レベル3
より厳密な制御を行う必要がある場合、レベル2の方法でも問題になる可能性があります。問題が絶対に発生しないようにするためには、PLCのラダープログラムを工夫する必要があります。
この方法としては二つ考えられます。
一つは、ワード単位でしか書き込みができないデバイスをPCから直接書き換えるのではなく、絶対にPLC側が変更する可能性のないデバイスや、ビット単位の書き込みをサポートするデバイスを間接的に用意し、そのデバイスを書き換えることによって、間接的に制御を行う方法です。
もう一つの方法は、「ハンドシェイクフラグ」を使う方法です。任意のビットデバイスをPCとPLC間のハンドシェイクフラグとして用意しておき、PLCはそのビットをOn/Offすることによって書き込みの可否状態をPCへ通知します。PCは、定周期通信によりフラグの値を監視して、OnのときだけPLCへの書き込みを行います。PLC側ではハンドシェイクフラグがOnのときには、パソコンの書き込み対象となるデバイスの近辺の値(ワード単位内の値)を書き換えないことが保証されたロジックとしておきます。
具体的には、周期通信を行うタグ(ハンドシェイクフラグ)を1つ作成して常時監視し、そのビットがOnになったことを確認したら、そのときに必要な書き込みを行います。書き込みが終了したら、パソコン側からそのハンドシェイクフラグをOffにして、書き込みが終了したことをPLCへ通知します。
本パッケージでは、各メーカーのプロトコル仕様でワード単位の書き込みしかサポートしていないデバイスについて、ワード中の一部のビットにのみ書き込みを行う場合には、内部的に「レベル2」の処理を行っています。
「レベル3」の制御を行う場合は、PLCのラダープログラムも関係するため、制御のレベルはユーザーの判断にて選択してください。
尚、メーカー側がビット単位の通信をサポートしている場合は、本パッケージはビット単位の書き込みを行うため、本件については問題となりません。
▪本件のまとめ |