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

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

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

「PLCでファイルを扱う～横河電機社製での実装例～」

1. はじめに

近年、多様化するPLCシステムにおいて、上位システムとのネットワーク構築は常識となっています。
また、PLCの性能も飛躍的に向上してきました。PLCでファイルを扱えるようになったのもそのひとつです。

以前は運転データなどの大容量のデータを扱う場合、以下の問題がありました。

PLCは信頼性が高いがメモリが少ない
PC（ハードディスク）は容量が大きいが信頼性が低い

これらの問題を解決する方法として『PLCにファイルを持つ』という手段をとることが可能になりました。
今回の技術レポートでは、PLCで[テキスト形式ファイル]を扱う場合と[バイナリ形式ファイル]を扱う場合の特徴と、過去の開発実績の中からファイルを使用したソフトウェア開発の事例をもとに、上位システム－制御装置間のファイル転送を実装した例を紹介します。

2. 各ファイル形式の特徴

（1）. 2つのファイル形式

PLCで扱うファイルには[テキスト形式ファイル]と[バイナリ形式ファイル]の2つの形式があり、以下のような特徴があります。

	テキスト形式	バイナリ形式
ファイルサイズ（注1）	大きい	小さい
処理速度（注2）	遅い	早い
PC上で編集する場合	テキストエディタで編集ができる。	バイナリエディタで編集できるが、文字データは文字コードでしか表示できない。
PLCでのコーディング量	数値データは1Byte毎に[文字列→数値]変換する必要がある。格納するデータの型が単一のCSV形式なら一括で読書きできる。	データの読書きに際して、データの変換は必要ない。

表1. ファイル形式の特徴

（注1）: テキスト形式で『10000』と記述すると、バイナリ形式では『3130303030』というデータになります（数値も文字コードで保存している）。
バイナリ形式では数値は数値のまま保存するので『10000』というデータはそのまま『10000』で保存されています。
（注2）: テキスト形式は数値を文字列に変換する処理が入るため遅くなります。

（2）. テキスト形式ファイルの特徴

すべてのデータを文字コードで保存してあるため、ファイルサイズが大きくなってしまう反面、PC上では[メモ帳]などのテキストエディタで簡単に編集することができます。

テキストエディタで簡単に内容を参照／編集できる反面、PLCでデータを扱う場合には手間がかかります。

（3）. バイナリ形式ファイルの特徴

ファイルサイズが小さく、処理速度が速い反面、PC上では[メモ帳]などのテキストエディタでは内容を確認することができません。

上位システムでファイルの内容を確認するにはファイルをモニタリングする仕組み、またはアプリケーションを用意する必要があります。

3. ファイルの保存場所

横河電機社製FA-M3R（※1）ではファイルの保存場所として、SDカードとRAMDISKがあります。

それぞれの特徴を活かして保存場所を使い分ける必要があります。

	SDカード	RAMDISK
書込み回数制限	同じアドレスに対して10～数十万回（機種により異なる）	無し
処理速度（注1）	遅い	早い
揮発性	無し	PLCの電源OFFで揮発
容量	最大1GB	4MB

表2. 保存場所の特徴

（注1）: SDカードはPLCからのアクセスに時間がかかるため、遅くなります。

（1）. SDカード

書込み回数制限があることに注意が必要です。

多くのSDカードには損耗平均化アルゴリズムが搭載されており、一概に数十万回で書込み不可能になるということはありません。
したがって、十分な空き領域をもって運用することで寿命を延ばすこともできます。

不揮発性というところに利点がありますが、書込み回数制限があるので、初期設定値などの変化の少ないデータの保存には向いていますが、実績データなどのログデータの保存は寿命を縮める原因となるため不向きです。

その他、SDカードへのファイルアクセスにかかる処理時間は、同じデータ量でも以下の条件で変化します。

ファイル形式（テキスト／バイナリ）の違い
SDカードの容量（容量が大きいほど時間がかかる。）

（2）. RAMDISK

SDカードとは全く逆で、揮発性があり、書込み制限はありません。

定期的に収集するデータの保存に向いています。
ただし、作成したファイルを収集する上位システムが居ることが前提です。

また、早い周期でのデータ収集（ファイル保存）が必要な場合には、一旦RAMDISKにファイルを作成し、すべての収集が終わったところでSDカードに転送するなどの工夫で処理時間を短縮することも可能です。

4. 開発事例システム構成

今回取り上げる開発事例は下図のような構成でした。

ご紹介する例では、横河電機社製FA-M3R（※1）を用います。

開発事例システム構成
図1.システム構成

このときのシステムは以下の構成でした。

制御装置に取り付けているタッチパネルで運転データを作成する。
（作成した運転データはテキスト形式のファイルでSDカードに保存します。）
運転データは上位システムでも作成できる。
（この場合はFTPで制御装置にテキストファイルを転送します。）
制御装置側で実績データ（ファイル）を作成し、定期的に上位システムがファイルを収集する。
（実績データはバイナリ形式のファイルで、RAMDISKに保存します。上位システムへはFTPで転送します。）

（1）. ファイル形式の選定（テキスト形式）

運転データを保存するファイルはテキスト形式を選定しました。

上位システムで手軽に運転データファイルを編集することを目的として、メンテナンス性の向上を図りました。
停電による運転データの損失を防ぐため、保存場所はSDカードとしています。

（2）. ファイル形式の選定（バイナリ形式）

実績を保存するファイルはバイナリ形式を選定しました。

このシステムでは、処理時間が数十時間に及ぶこともあり、実績データは数MBまで膨れ上がる可能性がありました。また、書込み回数も多いので保存場所もRAMDISKとしています。

バイナリ形式はファイルサイズが小さいため、FTPによる転送時間も改善しました。
上位システムで収集したバイナリファイルは、テキストファイルに変換してエクセルなどで自由に閲覧／加工できるように工夫しました。

5. おわりに

PLCで扱うデータはPLCの性能向上に比例し、量の増加に加えて、管理の複雑さも増して来ました。

最初にご紹介させていただいたとおり、PLCでファイルを扱うことで『PLCのメモリの少なさ』『PCの信頼性の低さ』を解決することができます。
その他、上位システムとの通信もFTPを使用することで、別途、通信ドライバを用意する必要もなくなります。テキストエディタなどで直接編集ができることもメンテナンスやデバッグの面で有利です。
しかし、扱うファイルのフォーマットが複雑な場合、PLCは文字列の操作が不得手であるため、プログラムの量が多くなる欠点があります。

今回は横河電機社製FA-M3Rを用いたシステムを例にとってご紹介しましたが、他メーカーのPLCでは特徴が異なり状況も変わってきます。また、システムに求められる仕様にも左右されます。ファイルを扱うシステムとしてはごく一部を取り上げた内容になりますので、実際の運用に際しては、それぞれのマニュアルを熟読されることをお勧めします。

これからファイルを使用したシステムを開発される方に参考にしていただければと思います。

（M．F．）

[注釈]

※1: 横河電機社製PLC（Programmable Logic Controller）