HOME > ソフテックだより > 第155号(2012年2月1日発行) 技術レポート「PLCでModbus TCP通信 〜横河電機社製での実装例〜」

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

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


ソフテックだより 第155号(2012年2月1日発行)
技術レポート

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

1. はじめに

ソフテックだより第133号「PLCでModbus通信 〜横河電機社製での実装例〜」にて、横河電機社製PLCを使用してModbus RTUプロトコルを実装した事例を紹介しました。
今回はその続編として、Modbusのイーサネット拡張バージョンである Modbus TCP プロトコルを実装した事例を紹介したいと思います。
事例紹介を通じて、Modbus TCPとModbus RTUとの違い、横河電機社製PLC FA-M3Vによるソケット通信の実装方法について紹介します。

2. Modbus TCPプロトコル

2-1. Modbus TCPとは

第133号の技術レポート「PLCでModbus通信 〜横河電機社製での実装例〜」でも紹介していますが、Modbus(モドバス)プロトコルには主に表 1に示すバージョンが存在します。

通信モード 特徴
Modbus ASCII 1バイトのデータを2文字のASCIIコードとして送受信を行う。
電文のチェックコードはLRC法を用いる。
Modbus RTU 1バイトのデータをそのままバイナリデータをして送受信を行う。
電文チェックコードはCRC法を用いる。
Modbus TCP TCP/IP上でModbus通信を行うためのプロトコル。
ModbusマスタをTCPクライアント、ModbusスレーブをTCPサーバとして実装し、マルチマスタのシステムを構築することが可能。
Modbus ASCIIおよびModbus RTUと、チェックコードを除いたメッセージフォーマットは同一である。
電文チェックは、TCP、IP、Ethernet層などのプロトコルスタックに任せるため、Modbusメッセージの中にチェックコードは含まれない。

表1. プロトコルの特徴

Modbus TCPは、前回の技術レポートで紹介したModbus RTUを、TCP/IPに拡張したプロトコルとなります。
TCP/IPを用いることで、インターネット環境においてもModbus通信を行うことができます。

2-2. 通信方式

TCP/IPは、クライアント/サーバ方式で通信を行いますが、Modbus TCPにおいては、ModbusマスタがTCPクライアント、ModbusスレーブがTCPサーバとなります。(図1)

クライアント/サーバ方式
図1. クライアント/サーバ方式

Modbus通信は、Modbusマスタが通信の起点となり、Modbusマスタからの要求メッセージに対してModbusスレーブが応答を返すことで1回の通信が完結します。

Modbus TCPでは、TCP/IPがそうであるように、送受信を行う前に接続を確立する必要があります。
Modbusスレーブは、Modbusマスタからの接続要求を受けることで接続が確立します。

2-3. メッセージフォーマット

図2にModbus RTU、Modbus TCPそれぞれの電文フォーマットを記載します。

メッセージフォーマット
図2. メッセージフォーマット

Modbus TCPのメッセージフォーマットは、Modbus RTUのCRCを除く部分を含んだ形となっています。(図 2の網掛け部分)
Modbus RTUでは電文誤りチェックのため、CRCチェックコードを末尾に付加する必要がありましたが、Modbus TCPではTCP/IPプロトコルが持つチェック機構を利用するため不要となります。
Modbus TCPでは、Modbus RTUには存在しなかった、トランザクション識別子、プロトコル識別子、メッセージ長を付加する必要がありますが、その意味を表2に示します。

通信モード 特徴
トランザクション識別子 Modbusマスタがトランザクション管理目的で付加するデータ。Modbusスレーブはコピーを返す。 不要ならば0として構わない。
プロトコル識別子 通信仕様には0固定と記載されており、使用されていない。
メッセージ長 ユニット識別子からデータまでのデータバイト長。
ユニット識別子 Modbus RTUではスレーブアドレスと呼んでいたもの。Modbusスレーブを特定するデータ。
ファンクションコード Modbus RTU同様、要求の種類を表す。
データ ファンクションコードによりフォーマットが規定されている。

表2. メッセージの意味

2-4. ファンクションコード

ファンクションコードの種類は、Modbus RTUと同一となります。
Modbus対応機器によって、サポートするファンクションは異なりますので、通信相手の仕様に合わせて、必要なファンクションを実装する必要があります。
ファンクションの詳細は、参考文献『OPEN MODBUS/TCP SPECIFICATION 』を参照願います。

3. 開発事例

横河電機社製FA-M3VにてModbus スレーブを実装した事例を紹介します。
本事例では、FA-M3Vの継続型応用命令を利用してTCP/IPソケット通信を実装しました。

3-1. システム構成

開発事例のシステム構成を図 3に示します。

システム構成
図3. システム構成

本事例の要件定義は以下の通りでした。

  • Modbusマスタから、一定周期(1sec)でファンクション04(Read Input Register)の要求メッセージを受信。Modbusスレーブは、該当するデバイスデータを格納した応答メッセージを返信する。
  • 複数のModbusマスタが接続可能であること。FA-M3Vの仕様上、最大同時接続7台とする。

PLC構成は、CPUモジュールに標準で搭載している10BASE-T/100BASE-TXコネクタが利用可能ですので、図 4の通りCPUモジュールのみとしました。

PLC構成
図4. PLC構成

3-2. 実装

Modbusスレーブ側ということで、FA-M3VのSOCKET命令を使用してTCP/IPサーバを実装しています。
複数のModbusマスタから接続要求を受け付け、同時に送受信を行うことを考慮し、以下のような処理分けとしました。

処理 役割
接続処理 Modbusマスタ(TCPクライアント)からの接続要求を受け付ける。
送受信処理 接続が確立したModbusマスタと送受信を行う。

処理の手順をフローチャートにすると、図 5の通りです。

処理フロー
図5. 処理フロー

接続処理では、接続クライアント数が最大になるまで、接続要求を受け付けます。
最大接続数は、FA-M3Vの仕様上の最大値である7台としています。

TCPLSN命令を実行すると接続待ち状態となります。
TCPクライアントから接続要求を受け付けると命令が終了し、送受信用のソケットIDを返します。
取得した送受信用のソケットIDはプログラム内部で保持し、送受信処理で利用します。

送受信処理では、接続処理で取得した送受信用のソケットIDに対して順番に受信待ちを行います。
TCPRCV命令で受信データの有無をチェックし、受信データがあればデータを解析後、応答メッセージの送信を行います。受信データが無ければ何もせず次のソケットIDの受信待ちに移行します。

今回、Modbusマスタからの要求メッセージ受信周期が、処理時間に対して十分に余裕があったため、ソケット1つずつ順番に処理を行う設計としました。
更に短い周期で送受信が必要な場合、各ソケットを平行して送受信させるなどの検討が必要となります。

処理手順に関する詳細は、『FA-M3V User's Manual シーケンスCPU説明書 ネットワーク通信機能編 (F3SP71-4N, F3SP76-7N対応)』を参照願います。

4. おわりに

2回に渡り横河電機社製PLCでModbus通信を実装した事例を紹介しました。
弊社では他にも様々な通信ソフトウェア開発の経験がございます。
またの機会にご紹介できればと考えています。

(M.S.)

[参考文献]
『Modbus-IDAホームページ』Modbus-IDA
『OPEN MODBUS/TCP SPECIFICATION Release 1.0, 29 March 1999』Schneider Electric
『FA-M3V User's Manual シーケンスCPU説明書ネットワーク通信機能編 (F3SP71-4N, F3SP76-7N対応)』横河電機株式会社

関連ページへのリンク

関連するソフテックだより

ページTOPへ