Phoenix Contactが作成した Think'n'Do と呼ばれる PC ベースの自動化ソフトウェア パッケージを使用しています。これは、リアルタイム処理、入力の読み取り、ロジックの制御、出力の書き込みをすべて最大 50 ミリ秒で実行します。10ms ごとに PLC からタグを読み書きする OPC サーバーがあります。PLC へのタグの書き込みと書き込まれた値の読み取りには長い遅延があります (Think'n'Do (50ms) > OPC サーバー (10ms) > PLC (10ms) > OPC サーバー (10ms) > Think'n'Do (50ms) ) このプロセスは、私の計算では 130ms しかかからないはずなのに、完了するまでに最大 6 秒かかります。
どこを見るべきか、またはなぜそれほど時間がかかるのかについてのアイデアは役に立ちます。
これは、OPCクライアントがデータをプルするように構成されている方法によって異なります。OPCでグループにサブスクライブすると、リフレッシュレートを指定できます。これは、OPCクライアントに応じて、デフォルトで1秒または5秒になる場合があります。OPCサーバーが更新されたデータの頻度に課す可能性のある制限もあります。これは、OPCクライアントがデータ変更イベントをサブスクライブしている場合にのみ適用されます。
もう1つの方法は、OPCサーバーに対して非同期または同期の読み取り/書き込みを行うことです。いくつかの読み取りモードもあります。OPCを使用しているため、任意のOPC互換クライアントを使用してサーバーをテストできます。これにより、問題がThink'n'Doの設定にあるのか、PLC/サーバーにあるのかがわかります。
私が使用した中で最も汎用的なOPCクライアントは、OPCクイッククライアントです。TOPサーバーで入手できます： http： //www.toolboxopc.com/Features/Demo/demo.shtml。TOPサーバーのデモを入手して、OPCクイッククライアントをインストールするだけです。これを使用してOPCサーバーに接続し、タグを参照してデータがどのように表示されるかを確認できます。私が使用した2番目に優れたOPCクライアントは、ここで入手可能なICONICS（OPC Data Spyと呼ばれる）からのものです：http ：//www.iconics.com/support/free_tools.asp 。
OPCクライアントを使用して、データを読み取る速度を確認します。グループのリフレッシュレートを正しく設定してください。ツールはあなたにもいくつかのタイミング情報を提供するかもしれないと思います（しかし、あなたは6秒の遅延をかなり簡単に理解することができるでしょう）。
OPC サーバーでキャッシュを使用していないかのように聞こえます。通常、OPC サーバーにはキャッシュがあります。クライアントが接続し、キャッシュを使用することを指定しない場合、必要なパフォーマンスが得られません。OPC サーバーはデバイスからキャッシュを更新する責任がありますが、更新の基準は OPC サーバーごとに異なる場合があります。
システムが同期読み取り (ブロック I/O 呼び出し) を実行し、次にアプリケーションのロジックを実装し、次に同期書き込み (再びブロック) を実行する場合、PLC への複数の往復があることを考慮する必要があります。
同期読み取りには、App(request) -> OPCServer -> PLC -> OPCServer -> App(result) が含まれます。これは 1 つの項目の読み取りにすぎません (ただし、項目のグループを一度に要求することはできます)。
同様の同期書き込みには、App(Write)->OPCServer->PLC->OPCServer->App(Done) も含まれます。
非同期の読み取りと書き込み、およびグループの読み取りと書き込みは、アプリケーションのブロックを減らすのに役立ちますが、アプリケーションがこの非同期動作に対処できるように注意してください
他に注目すべき点は、PLC の設定です。Allen-Bradley PLC には、外部ネットワーク経由で I/O 要求を処理するために使用されるインタースキャン遅延設定があります。その時間が短く、データの帯域幅が広い場合、速度が低下します。
OPC クライアント構成、OPC クライアント自体、OPC サーバー、または PLC 自体を確認する場所をいくつか示します。
確認すべき事項は次のとおりです。