前回は、構成についてお伝えしました。
１つでも、３つでも、５つでも・・と
ユニットを組み合わせた構成にすることで、
分かりやすいシステムが構築できる。
シーケンス制御の全体像が見えてきましたでしょうか。
そこで、今回は異なるユニットの制御の中を、
共通の構造にすることを考えていきます。
ユニットを分けても、統一した構造にすることで
メリット・デメリットがあります。
メリットは、
１．他のメンバーに分りやすいプログラムになる。
２．チームメンバーで分担が可能になる。
３．機能の抜け漏れが防止、改善が進む
などなどがあります。
特にメンバー間でコミュニケーションが充実できることで
ユーザー様の使い方が論点になり、評価が高くなります。
デメリットは、
プログラムサイズが大きくなることです。
しかし、昨今はCPUの進化でプログラム単位で分けることができるタイプが普及したことと、プログラミングツールの進化で組合せ編集が容易になりました。不要なユニットはCPUに書き込まないこともできます。
結果的にデメリットは再利用の意識が向上し、生産性向上に転換します。
では、どのような構造になるのでしょうか。
たとえば、機能を枠として捉える方法です。
以下のような５つの機能を備える枠を用意します。
１．操作釦、ランプ表示
２．モード選択、設定
３．自動運転シーケンス
４．アラームメッセージ
５．手動運転、動作出力
ユニット毎で、使用する入出力点数が大きく異なっても構造は共通です。
これらの構造を決めてメンバーで共有することで
誰が見ても、見やすい構造になります。
担当以外のメンバーによるサポートも可能になります。
お金をかけないで、品質と納期が安定する構造が見えてきます。
１つのユニットが自立して運転できるような構造にすることで
３，５，８の複数のユニットでも
１つずつが並列動作する構造でシーケンス制御が構成できます。
この時、大事なことはデバイスをどうするか？
という問題が浮上します。
最大８ユニットまでとした理由はここにあります。
デバイスマップをつくるということが登場します。
従来からデバイスの割付けは、決めていると思いますが、
８つ分の構成にするという制限を設けたことで、
デバイスの枠組みが１つのプログラムだけでなく、
着脱できる構造として、見通しのよいデバイスマップを
目指すことになります。
１つのプログラムにまとめるのではなく、
常に8つのプログラムを意識したマップにすることで
１つでも複数でも共通のデバイスマップとして利用できるようになります。
たとえば、
ユニット１、２、３、４、５に対しては
Mデバイス：M100番台、M200番台・・M500番台
Dデバイス：D110番台、D120番台・・D150番台
などです。
その他、T、C、なども８分割でデバイスマップを考えます。
この時、注意すべきは操作関係です。
オペレータや保守の視点で操作を優先して検討し、
デバイスの枠組みをしておくことが大切です。
操作機能は、わからないことが多いと思いますが、
最初に仮設することで、何が分からないかが見えてきます。
分かりやすい、使いやすいシステム構築を目指す上でも、
最優先で操作の枠組みを検討することをお勧めします。
これらは、参考元からデバイス一覧をつくる場合と
参考元がない場合がありますが、完全なアドレス表にしないことが
ポイントです。
ユニット毎でデバイスのサイズ感の共通にすることを目的として、
全体像が見えるカタチにすることをお勧めします。
デバイスマップに興味を持つ方には、
完全無料プログラムで紹介していきます。
構造化についてユニット毎の共通フレーム対応をお伝えしましたが、
それ以外に、固有となるメインとサーボがあります。
その他、計測など専用ハードウェアの課題もありますが、
システム全体を構築することを優先して、
構成から構造についてお伝えしてきました。
メインや専用機能などについては別枠で、お伝えしていきますが、
その前に大切なのが構図です。
この構図がラダープログラムの真の問題に迫りますので、
もっとも重要な要素として扱います。
次回は、その構図についてお伝えしていきます。
今日も一日、
明るく朗らかに、喜んで働きます。