メモ

最近、私が作るシステムは、パソコン（PC）とシーケンサ（PLC）を両方使うケースが増えています。

もちろん、システムの規模（制御内容、点数）にもよりますが、

PC にI/O ボードを積んで制御するよりも、PLC でI/O 制御し、

PLC <-> PC 通信で動作コントロールする方がメリットが様々なメリットが有ります。

一般的なI/O ボードの場合、コネクタ等で結線する為、I/F 端子台等への引き回しが必要になったりします。

PLC の場合、ユニットに端子がついていたり、配線関係機器も豊富です。

また、軸制御が必要な場合、最近のPLC はMC ユニット等が優れている為、

設定、制御、調整（ティーチング）等が軸制御ボードに比べ楽に出来ます。

金額的なメリットは・・・

I/O 点数が16 点以内の場合は、小型PLC の金額とI/O ボードの金額は同じ位でしょう。

モーション制御が必要な場合は、2軸まではボードの方が安いと思いますが、

2軸以上で、更にI/O 制御が32点以上有る場合は、PLC と金額差が無くなってきます。

部品代ではボードの方がメリットが有りますね^^;

では、何故この様な（PC・PLC 混合）システム設計を行うのか？

やはり、速度ですかね・・・

PLC のサイクルタイムは、一定（通常のラダーだけで考えれば）で、

I/O リフレッシュが早い為、外部機器とのI/F や、センサ信号の取り込み等が早く安定している。

制御にとって、この部分は大変重要です。

一時期（数年前）は、PLC 制御からPC 制御に移行しようとしていましたが、

やはり、PC 制御では出来ない事が出て来てしまいました。

○ PC 制御での問題事例

　 ピッチ移動しているワークをセンサでピッチを検出し、個数をカウントする。

　 設定個数に到達したら画像処理装置（外部機器）にトリガをかける。

　 トリガタイミングのバラつきが発生したり、カウントミスが発生する。

低速でのピッチ送りではもちろん問題が発生しませんでしたが、

送り速度の高速化で問題が出てきました。

また、それに対応させる為に、ボードを高速タイプに変更したり、

パルス入力ボードに変えたりすると、コストもかかりますし、

結局カウントが早くなっても、トリガ判断をPC ソフトで行う場合は、OS に依存する事になります。

その為、このシステムは、高速化改造でPC・PLC 化する事にしました。
　
○ センサカウント部位と画像処理装置I/F をPLC 制御化

○ カウント設定値、動作開始、生存確認等をPC・PLC I/F

○ PC <-> PLC I/F は、RS232C 専用プロトコルにてBit Device 及びDM を読み出し、書き込み
　
このケースでは、センサ部位、画像I/F 部位のみのPLC 化なので、マスターはPC のままで、
PLC を１機器（モジュール）として扱いました。
別のケースの画像検査装置では、設計段階から検査タクト、メカタクトの関係上、
PC・PLC の混合制御で設計を行いました。
　
○ 画像処理ユニット（トリガ関係）、X軸、Y軸、Θ軸、ワークチャックをPLC にて動作制御
○ 光源ユニット、画像処理ユニット（画像処理パラメータ関係）、UI をPC にて制御
　
さて、この構成の場合、問題となるのがマスターの役割分担です。
基本的に、パラメータやティーチング値、UI をPC が負担する為、
マスター（我々は、スーパーバイザーと呼ぶ）をPC に設定したい所です。
しかし、動作条件の管理や、動作管理等を行うのはPLC です。
ココでスーパーをPC にするか、PLC にするかでソフトは大きく構成が変わったと思います。
現状では、PC 側をスーパーバイザーにして、PLC は「周辺機器」として扱っています。
しかし、PC もPLC も両方とも「コントローラ」なので、PLC で画像ユニットをコントロールする事も可能です。
その場合、PC はタッチパネルの様な役割のみになります。
実際に、どちらの方式が正解かは判断できません。
ソフトウェアは、こう言った部分がソフトですね^^;
最終的に、動けばどちらでも良いのですが・・・
　
さて、ココからは少し気合いを入れて！！
　
オブジェクト指向的に設計すると・・・
軸制御関係は完全にPLC のスレーバーなので、ユニット的にはPLC 管理下に置きます。
と、なると、軸関連の責任はPLC に持たせます。
状態管理、動作管理はPLC。
画像処理ユニットは・・・
コイツの振る舞いは、軸動作に影響します。
アライメント指令、検査指令、軸の動作と検査が同期します。
と、言う事はPLC の管轄に入れるべきでは・・・
ココで、PC の役割ですが！！
先ずはUI。
ユーザーはPC でこのシステムとアクセスします。
つまり、ユーザー的には、このシステムの操作は、このPC の操作になります。
かと言って、タッチパネルと違い、UI だけでは無い訳です。
PLC の状態を管理し、運転指令をコントロールしたり出来ます。
つまり、PLC の振る舞いをPC がコントロールする事が出来ます。
また、画像検査ユニットからの検査結果や画像等の通信も有り、
システム的にはPC ユニットが重要なポイントになります。
が・・・
本当にPC はスーパーバイザーなんだろうか？？？
PC とPLC が有った場合、固定概念で、PC がマスターと考えていないだろうか？？？
思い切って、PLC をマスターに設定し、PC はタッチパネルに毛が生えた的なユニットとして扱った方が良いのか？
それとも、もっとPC に制御を負担させ、軸の振る舞いまでPC が管理した方が良いのか？
または・・・
PLC の管理下ではPLC がスーパーとなり、責任分担し、
PC はPLC をひとつのモジュールとしてプログラム内にクラス化して取り込むべきか・・・
結論的に言えば、「どっちでも良い」と言う事ですが（笑）
　
それをふまえたうえで重要なポイントが有ります。
ソレはPLC 側のプログラムに言える事です。
PLC プログラムのモジュールは、動作単位で考えがちです。
「何々動作」等、動作単位でモジュールを区切り、その上にスーパーバイザーを設定し、
スーパーバイザーからの動作指令を行う。
このスーパーバイザーも含めたモジュール化が必要と言う事が最重要ポイントです。
モジュール単位、ユニット単位でも良いのですが、必ずスーパーを作りましょう。
ココで、状態管理と、外部モジュールとのI/F を作る。
コレが肝心です。
私の考えでは、スーパーが複数あっても良いと考えます。
コレが、先程のPC、PLC どっちがマスター論に繋がるのですが、
個々のモジュールが責任分担されている事と、状態、振る舞いがモジュール内で管理されている事が肝心です。
後は、そのモジュールを組み合わせてコントロールするだけです。
システム的には、管理者が多い日本的なプログラムになります。
プログラム工数も多く、リソース使用量も増えがちですが・・・
コレが後から効いて来ます！！
デバッグ、改造、仕様変更、リピート、
モジュール化（オブジェクト化）は、その場（ケース毎）のメリットよりも、
継続的なメリットが有ります。
PC プログラムは比較的オブジェクト指向に作られますが、
（もちろん、担当者のスキルや思考にもよるが）
PLC プログラムもオブジェクト指向化する事でPC、PLC ハイブリッド制御や、
他にも様々な可能性を持った制御方式に対応出来て行くと思います。
　
長くなりましたが・・・
今度、会社のホームページに説明の図も含めてUP したいと思います。