「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
PLCアプリケーション開発分野では、外部機器との通信は不可欠となっています。
数ある通信プロトコルの中から、使用機器に合わせたものを採用し実装する必要があります。
今回の技術レポートでは、弊社過去の開発実績の中から、Modbusプロトコルに準拠したソフトウェア開発の事例を紹介します。
本実装例では、横河電機社製FA-M3R(※1)を用いて、ラダープログラムにてModbus通信を実装しています。
Modbus(モドバス)とは、米Modicon社が自社PLC用に1979年に開発した通信プロトコルで、PLCのみならず電子機器間においてもデータ受け渡しの目的で使用されています。
仕様がオープンであり、無償で利用できるなどの特徴から、産業分野のデファクトスタンダードとして広く採用されている通信プロトコルです。
Modbusスレーブ対応機器の例として、電動アクチュエータ、温度調節計といったものが挙げられます。また、Modbusマスタ機能を持つデータロガーのような機器も存在します。
Modbusプロトコルは、マスタ/スレーブ方式で、マスタが通信の起点となります。
スレーブは、マスタから要求された機能を実行し応答メッセージを返します。(図1)
図1. マスタ/スレーブ方式
Modbusプロトコルには、以下2つのバージョンが存在します。
シリアル伝送のバージョンは、メッセージフレーム中の値表現方法の違いで、Modbus ASCII、Modbus RTUの2種類の伝送モードに分かれます。
各伝送モード、およびModbus TCPの特徴を下表にまとめます。
通信モード | 特徴 |
---|---|
Modbus ASCII | 1バイトのデータを2文字のASCIIコードとして送受信を行う。電文のチェックコードはLRC法を用いる。 |
Modbus RTU | 1バイトのデータをそのままバイナリデータをして送受信を行う。電文チェックコードはCRC法を用いる。 |
Modbus TCP | TCP/IP上でModbus通信を行うためのプロトコル。マスタをクライアント、スレーブをサーバとして実装し、マルチマスタのシステムを構築することが可能。Modbus ASCIIおよびModbus RTUと、チェックコードを除いたメッセージフォーマットは同一である。電文チェックは、TCP、IP、Ethernet層などのプロトコルスタックに任せるため、Modbusメッセージの中にチェックコードは含まれない。 |
表1. プロトコルの特徴
本レポートでは、シリアル伝送のバージョンを取り上げ、プロトコルの概要を説明します。
メッセージフレームは、伝送モードに応じて以下のように定められています。
●Modbus ASCII
図2. Modbus ASCII メッセージフレーム
●Modbus RTU
図3. Modbus RTUメッセージフレーム
伝送モード | 特徴 |
---|---|
開始 | Modbus ASCII 開始文字を”:”とする。 Modbus RTU 3.5文字分のサイレントインターバル。 |
アドレス | マスタが要求するスレーブアドレスを表す。 スレーブアドレスは”1”〜”247”が指定可能。 ”0”はブロードキャストクエリを表し、ファンクションによって指定可能。 |
ファンクション | 要求の種類を示す。 |
データ | ファンクションに対応するデータフォーマットが定められている。 |
LRC/CRCチェック | Modbus ASCII LRCチェック Modbus RTU CRCチェック |
終了 | Modbus ASCII 終了文字として“CR/LF” Modbus RTU 3.5文字分のサイレントインターバル。 |
表2. メッセージフレームの内容
Modbusプロトコルには多くのファンクションが定義されていますが、一般的に使用するものを 表 3 にまとめます。
Modbus対応機器によって、サポートするファンクションは異なりますので、通信相手の仕様に合わせて、必要なファンクションを実装する形となります。
その他のファンクション及び、ファンクションの詳細は、参考文献『Modicon Modbus Protocol Reference Guide PI-MBUS-300 Rev. J』を参照願います。
コード | 名称 | 概要 |
---|---|---|
01 | Read Coil Status | スレーブのDO(※3)のON/OFF状態を読み出す。 |
02 | Read Input Status | スレーブのDI(※2)のON/OFF状態を読み出す。 |
03 | Read Holding Registers | スレーブの保持レジスタの内容を読み出す。 |
04 | Read Input Registers | スレーブの入力レジスタの内容を読み出す。 |
05 | Force Single Coil | スレーブのDO状態を変更する。 |
06 | Preset Single Register | スレーブの保持レジスタの内容を更新する。 |
08 | Diagnostics | マスタ−スレーブ間の通信診断、スレーブ機器の診断に使用する。 |
11 | Fetch Comm. Event Ctr. | スレーブが正しくメッセージを処理したことを知る目的で使用する。 |
12 | Fetch Comm. Event Log | スレーブの通信イベントログを読み出す。 |
15 | Force Multiple Coils | スレーブの連続した複数のDOの状態を変更する。 |
16 | Preset Multiple Registers | スレーブの連続した複数の保持レジスタの内容を変更する。 |
17 | Report Slave ID | スレーブ機器の情報を読み出す。 |
表3. ファンクションの種類
ファンクション04(Read Input Register)の、Modbus RTUの場合を例として、データフォーマットについて解説します。
色付き部分が、「3.1 メッセージフレーム」に示した「データ」の部分に相当します。
図4. ファンクション04データフォーマット
ファンクション04は、スレーブのレジスタ状態を読み出すファンクションです。
マスタは要求メッセージに、読み出したいレジスタの開始アドレス、レジスタ数を指定して送信します。
要求メッセージを受けたスレーブは、自身のレジスタ状態を読み出し、データを応答メッセージに付加して返信します。
弊社では、Modbus RTUにおいては、マスタ側、スレーブ側ともに開発実績があります。
今回は、弊社開発実績の中から、Modbus RTUのマスタ側の開発事例を紹介します。
開発事例のシステム構成を図5に示します。
1台のマスタに対して5台のスレーブが接続される構成となります。
図5. Modbus RTUシステム構成
弊社はマスタ側を担当し、横河電機社製FA-M3R上で実装しました。
マスタのPLC構成は図6の通りです。
ラダー通信モジュール(F3RZ91-0F)を使用してRS-485を用いた通信を実現しています。
図6. PLC構成
本事例の通信相手であるスレーブ機器は、海外製のPLCとなります。
マスタ側の要件は、以下の2点でした。
以上の要件を実現するために、Modbusファンクションは表4に示すものを使用して実装しております。
ファンクション | 役割 |
---|---|
02 (Read Input Status) | スレーブに接続されたセンサのON/OFF状態(DI)を読み出す。 |
15 (Force Multiple Coils) | スレーブに接続された機器への出力状態(DO)を変更する。 |
表4. 事例で使用したファンクション
マスタ側プログラムの処理分けは図7の通りとしました。
ユーザ操作の受付や、画面表示など、タッチパネルとのインタフェースを「アプリケーション層」として実装し、「アプリケーション層」からの要求により「Modbus通信層」が、スレーブ側との必要な通信処理を行います。
アプリケーション層とModbus通信層を分離することで、再利用可能なプログラムを意識した実装としています。
図7. プログラムの機能分け
Modbusメッセージのデータに含まれる「開始アドレス」の指定方法には注意する必要があります。
ファンクション02を例にすると、Modicon社のModbusプロトコルでは「開始アドレスは10001差し引いた値と指定する」と決められています。
DIのアドレスは10001から始まることを想定しており、Modbusメッセージで0を指定すると、相手側のデバイスアドレス10001を指定したことになります。
例えば、スレーブ側をFA-M3Rで実装した場合、DIに相当する入力リレーは「X00201」といった表記であり、Modicon社のModbusプロトコルの想定とは一致しません。
FA-M3Rに限らず、国内で販売されているPLCのデバイスは、各社独自のアドレス体系を持っています。さらにPLCのみならずModbusに対応した電子機器も同様となります。
以上より、Modbusプロトコル実装の際には、スレーブ側機器のアドレスとModbusプロトコルのアドレスの対応付けをしっかりと取り決め、通信相手と認識を合わせておく必要があります。
ソフトウェアのデバッグ、社内試験の段階で、通信相手の実機が入手できない場合もあります。
このような場合、代わりの通信相手としてシミュレータを用いる必要がありますが、ウェブサイトで公開されているようなフリーウェアおよびシェアウェアは、ほとんどのものが海外製のものとなります。
初めて開発した事例では、通信電文レベルで規定通りの動作をしているかの確認に加え、Modbusプロトコル自体の認識に相違が無いことの確認をModbusシミュレータにて確認しました。
この際に、適切なソフトウェアを海外のウェブサイトから探し出す必要があり、国内の情報源とは違った苦労がありました。
また、プロトコル仕様に関する情報も、正式なものは英語で記述されたものしか存在せず、最低限の英語力が必要となりました。
本レポートでは、シリアル伝送バージョンの例としてModbus RTUの開発事例を取り上げました。弊社では他にModbus TCPプロトコルを使用した開発実績もございますので、またの機会にご紹介できればと考えています。
(M.S.)
関連ページへのリンク
関連するソフテックだより