「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。

ソフテックだより（発行日順）のページへ
 ソフテックだより技術レポート（技術分野別）のページへ
 ソフテックだより現場の声（シーン別）のページへ

ソフテックだより第１３３号（2011年3月2日発行）
技術レポート

「PLCでModbus通信～横河電機社製での実装例～」

1. はじめに

PLCアプリケーション開発分野では、外部機器との通信は不可欠となっています。
数ある通信プロトコルの中から、使用機器に合わせたものを採用し実装する必要があります。

今回の技術レポートでは、弊社過去の開発実績の中から、Modbusプロトコルに準拠したソフトウェア開発の事例を紹介します。

本実装例では、横河電機社製FA-M3R(※1)を用いて、ラダープログラムにてModbus通信を実装しています。

2. Modbus（モドバス）とは

Modbus（モドバス）とは、米Modicon社が自社PLC用に1979年に開発した通信プロトコルで、PLCのみならず電子機器間においてもデータ受け渡しの目的で使用されています。
仕様がオープンであり、無償で利用できるなどの特徴から、産業分野のデファクトスタンダードとして広く採用されている通信プロトコルです。
Modbusスレーブ対応機器の例として、電動アクチュエータ、温度調節計といったものが挙げられます。また、Modbusマスタ機能を持つデータロガーのような機器も存在します。

Modbusプロトコルは、マスタ／スレーブ方式で、マスタが通信の起点となります。
スレーブは、マスタから要求された機能を実行し応答メッセージを返します。（図1）

図1. マスタ／スレーブ方式

Modbusプロトコルには、以下2つのバージョンが存在します。

RS-232C、RS-422、RS-485等を物理層とし、シリアルポートを用いて通信を行うバージョン。（以下、「シリアル伝送」）
インターネットネットワーク上で利用することを目的とし、上記バージョンをTCP/IPプロトコルに拡張したバージョン。（以下、「Modbus TCP」）

シリアル伝送のバージョンは、メッセージフレーム中の値表現方法の違いで、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. プロトコルの特徴

3. Modbusプロトコルの概要

本レポートでは、シリアル伝送のバージョンを取り上げ、プロトコルの概要を説明します。

3-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. メッセージフレームの内容

3-2. ファンクション

Modbusプロトコルには多くのファンクションが定義されていますが、一般的に使用するものを表３にまとめます。
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. ファンクションの種類

3-3. Modbusデータフォーマット

ファンクション04（Read Input Register）の、Modbus RTUの場合を例として、データフォーマットについて解説します。
色付き部分が、「3.1 メッセージフレーム」に示した「データ」の部分に相当します。

図4. ファンクション04データフォーマット

ファンクション04は、スレーブのレジスタ状態を読み出すファンクションです。
マスタは要求メッセージに、読み出したいレジスタの開始アドレス、レジスタ数を指定して送信します。
要求メッセージを受けたスレーブは、自身のレジスタ状態を読み出し、データを応答メッセージに付加して返信します。

4. 開発事例

弊社では、Modbus RTUにおいては、マスタ側、スレーブ側ともに開発実績があります。
今回は、弊社開発実績の中から、Modbus RTUのマスタ側の開発事例を紹介します。

4-1. システム構成

開発事例のシステム構成を図5に示します。
1台のマスタに対して5台のスレーブが接続される構成となります。

図5. Modbus RTUシステム構成

弊社はマスタ側を担当し、横河電機社製FA-M3R上で実装しました。
マスタのPLC構成は図6の通りです。
ラダー通信モジュール（F3RZ91-0F）を使用してRS-485を用いた通信を実現しています。

図6. PLC構成

本事例の通信相手であるスレーブ機器は、海外製のPLCとなります。
マスタ側の要件は、以下の2点でした。

タッチパネルによるユーザ操作をトリガに、スレーブ側PLCに接続された機器を制御する。機器の制御には、スレーブ側PLCからDO信号を出力する必要がある。
5台のスレーブに対して、順番にセンサ状態を取得する。センサはスレーブ側PLCに対してDI信号として入力されている。取得した結果はタッチパネル上に表示する。

以上の要件を実現するために、Modbusファンクションは表4に示すものを使用して実装しております。

ファンクション	役割
02 (Read Input Status)	スレーブに接続されたセンサのON/OFF状態(DI)を読み出す。
15 (Force Multiple Coils)	スレーブに接続された機器への出力状態(DO)を変更する。

表4. 事例で使用したファンクション

4-2. 設計

マスタ側プログラムの処理分けは図7の通りとしました。
ユーザ操作の受付や、画面表示など、タッチパネルとのインタフェースを「アプリケーション層」として実装し、「アプリケーション層」からの要求により「Modbus通信層」が、スレーブ側との必要な通信処理を行います。
アプリケーション層とModbus通信層を分離することで、再利用可能なプログラムを意識した実装としています。

図7. プログラムの機能分け

5. 注意点

5-1. 通信相手との仕様取り決めの重要性

Modbusメッセージのデータに含まれる「開始アドレス」の指定方法には注意する必要があります。

ファンクション02を例にすると、Modicon社のModbusプロトコルでは「開始アドレスは10001差し引いた値と指定する」と決められています。
DIのアドレスは10001から始まることを想定しており、Modbusメッセージで0を指定すると、相手側のデバイスアドレス10001を指定したことになります。

例えば、スレーブ側をFA-M3Rで実装した場合、DIに相当する入力リレーは「X00201」といった表記であり、Modicon社のModbusプロトコルの想定とは一致しません。
FA-M3Rに限らず、国内で販売されているPLCのデバイスは、各社独自のアドレス体系を持っています。さらにPLCのみならずModbusに対応した電子機器も同様となります。

以上より、Modbusプロトコル実装の際には、スレーブ側機器のアドレスとModbusプロトコルのアドレスの対応付けをしっかりと取り決め、通信相手と認識を合わせておく必要があります。

5-2. 情報源は国外

ソフトウェアのデバッグ、社内試験の段階で、通信相手の実機が入手できない場合もあります。
このような場合、代わりの通信相手としてシミュレータを用いる必要がありますが、ウェブサイトで公開されているようなフリーウェアおよびシェアウェアは、ほとんどのものが海外製のものとなります。

初めて開発した事例では、通信電文レベルで規定通りの動作をしているかの確認に加え、Modbusプロトコル自体の認識に相違が無いことの確認をModbusシミュレータにて確認しました。
この際に、適切なソフトウェアを海外のウェブサイトから探し出す必要があり、国内の情報源とは違った苦労がありました。

また、プロトコル仕様に関する情報も、正式なものは英語で記述されたものしか存在せず、最低限の英語力が必要となりました。

6. おわりに

本レポートでは、シリアル伝送バージョンの例としてModbus RTUの開発事例を取り上げました。弊社では他にModbus TCPプロトコルを使用した開発実績もございますので、またの機会にご紹介できればと考えています。

（M．S．）

[参考文献]

『Modbus-IDAホームページ』Modbus-IDA

『Modicon Modbus Protocol Reference Guide PI-MBUS-300 Rev. J』Modicon, Inc.

『IM 34M6H22-02 ラダー通信モジュール取扱説明書』横河電機株式会社

[注釈]

※1FA-M3R: 横河電機社製PLC（Programmable Logic Controller）
※2DI: 「Discrete Input」デジタル信号入力
※3DO: 「Discrete Output」デジタル信号出力

「PLCでModbus通信 ～横河電機社製での実装例～」