HOME会社概況業務内容開発分野開発事例CANモジュールソフテックだよりお問い合わせ
HOME > ソフテックだより > 第51号(2007年10月3日発行) 技術レポート「見やすい・わかりやすいラダーにするために3 〜実践編〜」

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

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


ソフテックだより 第51号(2007年10月3日発行)

技術レポート

「見やすい・わかりやすいラダーにするために3 〜実践編〜」

1. はじめに

メールマガジン第5号第13号の技術レポートに続き、「見やすい・わかりやすいラダーにするために」第3弾・実践編として、具体的に「少しの工夫で見やすい回路」をテーマにいくつかご紹介します。

※三菱電機製PLCのラダー作成ツールを使用して説明いたします。

2. マジックナンバーを使用しない

ここで言うマジックナンバーとは、「プログラム中に記述された具体的な値で、値自体からは意味が分からないもの」のことを示します。

マジックナンバーにすると、以下のデメリットがあります。

  • 値の意味が分からないため、解析変更する際の障害となる。
  • プログラムのいたるところで使用していた場合、変更箇所が大量に発生する。

図 1にて具体例を示します。
「縦の長さ」に「実数(E1.618)」を乗じて「横の長さ」を計算していますが、「実数(E1.618)」の数値の意味が分からないため、何を計算しているのかも分かりません。

何の値かが分かりません
図 1. マジックナンバーにしたとき

そこで、図 2のように記述することで改善することができます。
一旦D0へ格納してI/Oコメントをつけることで、その数値の意味とその処理で何をしているのかが分かります。行コメントも合せて記述することで、より分かりやすくなると言えます。

何の値かが分かります
図 2. マジックナンバーにしないとき

3. 検索補助リレーを用意する

ここで言う検索補助リレーとは、「機能単位の検索を補助するリレー」のことを示します。
この工夫により、以下のメリットがあります。

  • 検索補助リレーを検索することで、その処理がどこで行われているのかがすぐわかる。
  • 検索補助リレーを常時ON、OFFで切り替えることにより、その処理の実行、停止の切替が容易に行える。

図 3にて具体例を示します。
縦の長さを基準に黄金長方形の面積を計算するサンプルです。
面積計算の処理のはじめに直接常時ON(SM400)を記述せず、間にM0を絡ませています。これにより、検索、変更がしやすくなります。
例えば、M0を検索することで、その処理がどこで行われているのかがすぐに分かります。
また、デバッグで一時的に処理を行わないようにしたいときは、M0を常時OFFにすることで、簡単に対応できます。

検索だけでなく実行停止の切替が簡単に行えます
図 3. 検索補助リレーを使用した例

4. パルス化は入力側でなく出力側で行う

パルス化を入力側(リレー)で行うと、以下のデメリットがあります。

  • 回路モニタしたとき、ON/OFFの状態がわからない。

図 4にて具体例を示します。
面積計算の処理をパルス化することを考えてみます。
入力側のM0をパルス化していますが、面積計算の回路をモニタしてもM0がONしている状態がわかりません。

ONしていることが分かりません
図 4. 入力側をパルス化した例

これを、図 5のように記述することで回避できます。
面積計算の回路をモニタするだけでM0がONしていることが分かります。出力側でパルス化しているので、動作は図 4と同じです。
この例ではステップ数が少ないため、すぐ上の定義を見ればM0がONしていることが分かりますが、もっとステップが多くなると分からなくなってしまいます。
そのため、パルス化する場合は入力側でなく出力側にしたほうが、分かりやすいと言えます。

ONしていることが分かります
図 5. 出力側をパルス化した例

5. アドレス割付を工夫する

コーディングの仕方を工夫することも大切ですが、それ以前にアドレス割付などの設計時の工夫も大切です。
例えば、アドレス割付を工夫することで、以下のメリットがあります。

  • コーディング量を減らせて、分かりやすくなる。

例として、今まで例に出した処理を、3回アドレスを変えて計算することを考えてみます。
そのとき、ForNextとインデックスレジスタを用いて実装することにします。

ここで、図 6のように、縦の長さ、横の長さ、面積それぞれのアドレスの間隔が2、4、10と異なるようにアドレスを割り付けた場合を考えてみます。

縦は+2、横は+4、面積は+10で割り付けると・・・
図 6. アドレスの間隔が異なるとき

そのとき、ラダーで処理を実装すると、図 7のようになります。
縦の長さ、横の長さ、面積それぞれでインデックスレジスタを使わなければいけなくなり、ステップ数も増えて分かりづらくなってしまいます。

インデックスレジスタが3つ必要になり、ステップ数が増えてしまいます
図 7. アドレス割付が悪い例

そこで、図 8のように縦の長さ、横の長さ、面積それぞれのアドレス間隔を均等に割り付けるとどうなるでしょうか?

縦、横、面積すべて+4で割り付けると・・・
図 8. アドレスの間隔が同じとき

図 9のように、インデックスレジスタもZ0ひとつで済みます。
図 7と比べても分かるように、ステップ数も少なく、簡潔に実装できます。

インデックスレジスタは1つで済み、簡潔に実装できます
図 9. アドレス割付が良い例

このように、見やすく分かりやすいラダーにするために、アドレス割付を工夫することも大切です。

6. 出力側のアドレス順で記述する

デバッグ時に出力データを確認するときは、回路モニタで「出力側のアドレス順に確認していく」ことが多いと思われます。このようなときは、出力側のアドレス順で確認しやすいように出力側のアドレス順でコーディングしていると便利です。

図 10のように、時系列2点と表示項目2点の簡略化した帳票の例で説明します。
表示データのデバイス割付は、図にも示すとおりD2000〜D2003とします。
0時になるとM1000が、12時になるとM1001がそれぞれONするものとします。ラダーでは、M1000がONしたら瞬時値データのデバイスの値をD2000とD2001へ、M1001がONしたら瞬時値データのデバイスの値をD2002とD2003へそれぞれMOVすることにします。

帳票のイメージ
図 10. 帳票のイメージ

図 11は、入力側(M1000とM1001)のアドレス順で回路をまとめた例です。
入力側のリレーは2箇所にまとめられるのでコーディング量は少なくなりますが、出力側(D2000〜D2003)がアドレス順でないため、出力側のアドレス順に確認しづらいといえます。

リレーのコーディング量は少なくなるが、アドレス順で無いためデバッグのとき分かりづらい
図 11. 入力側のアドレス順でまとめたとき

図 12は、出力側(D2000〜D2003)のアドレス順で回路をまとめた例です。
入力側のリレーのコーディング量は図 11と比べると増えてしまいますが、出力側のアドレス順でまとめられているため、出力側のアドレス順に確認しやすいといえます。

リレーのコーディング量は増えるが、アドレス順のためデバッグのとき分かりやすい
図 12. 出力側のアドレス順でまとめたとき

7. 標準的な書き方をする(自己保持回路の例)

見やすい・分かりやすいラダーにすることには、標準的な書き方に従うことが大切です。標準的な書き方をすることで他の人が見ても理解しやすくなります。
ここでは、自己保持回路を例に説明します。自己保持回路にはセット優先とリセット優先がありますが、ここではリセット優先を例にしています。

標準的な自己保持回路を図 13に示します。
自己保持回路の入力条件、切断条件、自己保持コイル、自己保持リレー、その他の出力は、それぞれ図 13に示す位置に書くことが標準的です。

自己保持回路の標準的な書き方
図 13. 自己保持回路の一般的な書き方

図 13に示す書き方をしないと、どれが入力条件でどれが切断条件か、などが分かりづらくなる可能性があります。

8. まとめ

いかがだったでしょうか?

ちょっとした工夫で見やすく・分かりやすいプログラムになる事がわかったと思います。
見やすく・分かりやすいプログラムを作るためには、今回ご紹介したような小さな工夫を常日頃から考えて積み重ねていくことが大切だと私自身は考えています。
また、複数人で開発するプロジェクトでも、今回ご紹介したような見やすく・分かりやすいプログラムを作るための工夫を開発者全員で共有して実施していくことで効果を発揮していけると考えています。

ただし、今回ご紹介した内容はメリットばかりではありません。
たとえば、「2. マジックナンバーを使用しない」「5. アドレス割付を工夫する」でご紹介した方法では、「デバイスを無駄に使用する」というデメリットがあります。
また、「2. マジックナンバーを使用しない」には、「デバイスに値を入れる処理が増えるため、スキャンタイムが増える」というデメリットもあります。

このようなデメリットもありますが、私はデメリットよりもメリットのほうが大きいと考えたら、今回ご紹介した方法を取るようにしています。

以上、簡単ではありましたが、少しでもPLCソフトを作成する方の参考になれば幸いです。

(T.N.)


関連ページへのリンク

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