「三菱PLC 通信プロトコル支援機能を使った調節計更新」

私が担当した案件で「三菱PLCの通信プロトコル支援機能＋シリアルコミュニケーションユニットを使用した調節計更新」を行った事例についてご紹介したいと思います。

既設システムですが、下記のようにデジタル指示調節計の通信はRS-485、いっぽうPLC側はCC-Linkユニットを使用し、PLCと調節計の間にRS-485/CC-Link変換器を使って通信を行っているシステムでした。

RS-485/CC-Link変換器

：横河電機社製　NC210

デジタル指示調節計

：横河電機社製　UT/UPシリーズ

三菱電機社製ＰＬＣ

：QシリーズPLC+CC-Linkユニット(QJ61BT11N)

この通信変換器のNC210は2013年3月に販売終了しており、後継機種も発売されておりません。そのためPLCと調節計を通信するためには直接RS-485通信を行う必要があります。

更新後のシステムでは、調節計とPLCはRS-485通信で直接通信する形に更新することでRS-485/CC-Link変換のNC210が不要になります。

デジタル指示調節計

：横河電機社製UTシリーズ

三菱電機社製ＰＬＣ

：QシリーズPLC+シリアルコミュニケーションユニット

今回使用した調節計は横河電機社製のUT32Aを使用し、RS-485通信をサポートしている物を使用しています。この調節計はRS-485通信を使った場合、modbus通信、パソコンリンク通信、ラダー通信の3種類のプロトコルをサポートしていますが、今回はmodbus通信を使っています。

• プロトコルの実装は通信プロトコル支援機能を使ってmodbus通信をする

  メリット：

  ラダープログラムでプロトコルの実装をする必要が無い

  メリット：

  送受信データは指定デバイスでやり取り出来る



• ラダーサポートツールはGX DevelopperではなくGX Works2を使用する

  メリット：

  通信プロトコル支援機能はGX Developperではオプション機能だが、GX Works2では標準機能としてサポートしている

GX Works2を使ってまずは通信プロトコル支援機能を使ってみます。GX Works2のツールメニューから下図のように通信プロトコル支援機能を選択し、シリアルコミュニケーションユニットを選択します。

下記のように通信プロトコル支援機能の画面が立ち上がり、プロトコルを追加することで下記の様な画面が表示されます。通信プロトコル支援機能では様々なメーカーのプロトコルに標準対応しています。今回はmodbus通信を使いたい為、メーカーは「シュナイダーエレクトリック」、型式は「modbus」を選択して、使いたいプロトコル名を選択します。
今回は調節計との通信では以下プロトコルを使用します。

プロトコルの追加を行うとパケット設定が行える様になり、送受信に使うデバイスを下記の様に設定することで指定したデバイスに値を設定して送信、もしくは受信データが指定デバイスに書き込まれるようになります。ここまでがプロトコルを使う為の下準備になります。

次にGX Works2に戻り、インテリジェント機能ユニットにシリアルコミュニケーションユニットを追加してスイッチ設定を行います。伝送設定は調節計と通信出来るように通信速度その他の設定を合わせ、更新プロトコル設定を「通信プロトコル」を選択します。

またRS-485通信で通信プロトコル支援機能を使う場合にはエコーバック禁止(自分が送信したデータが受信データとして入ってきた場合に無視する)設定をする必要がありますので、各種制御指定でエコーバック禁止を選択します(今回使用したシリアルコミュニケーションユニットでは1CHと2CHの2チャンネル分の通信ポートがありますが、CH2側のみエコーバック禁止の設定が行える為、CH2側を使用しています)

ラダープログラム側では、NC210を使っていた時と同様の事を行える様にするために、modbusのプロトコル3種類(03：RD Holding Registers,05：WR Single Coil, 06：WR Single Registers)を使って下記の実装を行っています。

次にラダー側でプロトコル「06：WR Single Registers」を使って書込みするプログラムを書きます（ユニットなどの初期化プログラムは本メルマガでは省略します）M0がONしたら、下記を実行するプログラムになります。

実行結果は、専用命令GP.CPRTCLの引数で設定しているD10480、M10300に結果として帰ってきますので、その結果によって適切な処理を実装する必要があります。

特に重要なのは、通信失敗時もしくは無応答などの通信エラー処理になります。本件を担当したときには、まれに通信エラーが発生し、下記の様にエラー処理追加、及び通信設定などの見直を行っております。

• 通信速度は応答時間を考慮して設定
  調節計との通信で期待する応答速度があると思います。制御周期にも関係してきますが、その応答速度を満たす事ができる通信速度に設定する必要があります。
  
  今回の場合では初めは38400bpsで設定して出荷しましたが、まれに通信異常が発生し調節計との通信が失敗する症状が発生しました。
  
  プロトコルアナライザーを入れて調査したところ、送信データに対する応答データが帰ってこない場合が発生しており、調節計が正しくデータを受け取れていないと判断しています。
  
  その調査結果で、通信速度の見直しを行い38400bps→19200bpsに設定変更したことで問題は解決しました。通信速度見直しによって調節計からの応答速度は変更前後で約7msとほとんど差はありませんでした。
  
  よってこれらの経験から、期待する応答速度をたもてる範囲で通信速度を落とした方が通信エラー発生を抑えられる事が分かりました。
  
  
• 通信エラー処理実装の重要性
  通信プロトコル支援機能命令を実行した時に成功/失敗の状態が帰ってくるので、考えられるエラー処理は実装していたのですが、無応答時の処理に不足がありましたので、追加しています。
  
  テストでは、ケーブルを抜いたり、通信速度を想定しているものから変えてみたり、PLCの電源を入り切りしてみたりなど、どのような状況からでもエラー処理を経由して正しい状況に復帰できるようにする必要があります。
  
  通信処理で正しく動いている時は、一目瞭然なので分かりやすいのですが、まれに発生する異常ケースの場合、処理漏れがあると意図しない不適合に繋がります。
  
  エラー処理の実装は通信処理の安定性を決める重要な部分になります。
  

通信という目に見えないものをプログラムし、それが正しく処理されているか？という確認は思いのほか大変な作業です。

今回はシリアルユニット＋通信プロトコル支援機能を使う事で、送受信データは指定したデバイス経由でやり取りすることが出来るため比較的シンプルなプログラムで済みましたが、プロトコル支援機能がどのような動きをするのか？エラー処理はどうなるのか？などきちんと動作を理解していないと、エラー処理実装を正しく行えないという事を学びました。

まれに発生するトラブルというのは、どの様な場面でも厄介なものですが、それが発生しないように設計時点で考慮し、未然に防げるような仕事をしていきたいと考えます。