3

私は、同じ OPC サーバーに接続された 3 つの異なる Siemens PLC を管理するシングルスレッド OPC クライアント プログラムで作業しています。

シングルスレッド クライアントは次のようになります。

loop
 begin
  processPLC1;
  processPLC2;
  processPLC3;
end;

各 processPLC プロシージャは、次のような基礎となる OPC ライブラリを呼び出します。

 OPCutils.WriteOPCGroupItemValue(FGroupIf, FHandleItemOpc, Value);

さて、今度は各 processPLC を別のスレッドで呼び出して、並行して作業したいと思います。

私はいくつかの調査を行い、OmniThreadLibrary を使用していくつかのコードを開始しましたが、OPC コードはマルチスレッドセーフではないと思います。それは...ですか？

task.Invoke などを使用する必要がありますか? PLCタグの値を返すReadOPC関数はどうですか？ここでのベストプラクティスは何ですか?

ありがとうございました！！！

4

3 に答える 3

5

私は通常、これが次の 2 つの方法で行われるのを見てきました。

1) アプリケーションには、単一のスレッドが所有する単一の OPC クライアント インスタンスがあります。クライアント アプリケーションによって自動化されているすべての並列プロセスは、OPC 値の読み取り/書き込み時に、OPC クライアントを所有するスレッドとの何らかのメッセージングまたは同期を使用します。

2) 各スレッドは独自のプライベート OPC クライアントを所有し、それぞれが個別に OPC サーバーと通信します。

個人的には、最も使用されているスキームは前者であることがわかりました。クライアントへの同期呼び出しを行うスレッドを持つ 1 つの OPC (または他の独自仕様) クライアント オブジェクト。実際、ほとんどすべてのプロセス制御の状況で、論理的な現実世界のタスクをエレガントにカプセル化し、それを UI から分離する目的でマルチスレッド化しています。パフォーマンスのためではありません。これらのスレッドは、比較的「長い」期間ブロックしてデータを待機する余裕があります。PLC は、必要に応じて 100 ミリ秒の間喜んで砦を保持します。

どちらを選択するかは、アプリケーションの規模と性質に大きく依存します。外部リアルタイム イベントの待機に長時間を費やす多数の軽量スレッドの場合、アプリケーション内に 1 つの OPC クライアント インスタンスを保持し、多数の独立した接続のオーバーヘッドを節約することは理にかなっています。負荷が高く、動きが速く、OPC を集中的に使用する少数のスレッドの場合は、代わりにそれぞれに独自の OPC クライアントを提供することが理にかなっています 。

また、OPC タグのリフレッシュ レートにも注意してください。多くの場合、サーバーは約 100 ミリ秒ごとにしか更新していません。単一のスキャンを実行するだけでも、PLC で少なくとも 10 ミリ秒かかる可能性があります。データがそれほど迅速に更新されない場合、膨大な数のスレッドが毎秒 100 回サーバーを個別にポーリングすることは意味がありません。

プロセス制御ソフトウェアの場合、本当に必要なのは、多くのアイドル状態または低負荷の CPU 時間を確保することです。スレッドが軽いほど優れています。システム全体の応答性が重要であり、ソフトウェアに高負荷の状況を処理させる能力が重要です (OS が HDD のインデックスを作成する時期であると判断している間に、突然多数のタスクが収束します...いわば、ヘッドルームが歯車を潤滑状態に保ちます)。ほとんどのスレッドは、ほとんどの場合、待機しているだけのはずです。イベントとコールバックは、通常、ここで最も意味があります。

また、ここでも PLC プログラミングを考えることが重要です。たとえば、私のマシンには、非常にタイムクリティカルな操作がいくつかありますが、同時に、実行されるたびに一意のタイミングがとられます。 1 秒またはそれ以上であり、1 日に数百から数千回繰り返され、重要ではありますが、実行されるたびに持続時間が異なります。これらが 2 つの方法で処理されるのを見てきました。1 つはソフトウェアで、もう 1 つは PLC です。前者の場合、ソフトウェアはいつ開始するかを PLC に通知し、ソフトウェアが停止するように通知するまで続行します。これには明らかな落とし穴があります。この場合、単純に時間間隔を PLC に送信してタイミングをとらせる方がはるかに優れています。

于 2013-08-04T22:57:11.487 に答える
3

OPC は COM テクノロジに基づいているため、同じ規則が適用されます。異なるスレッドから OPC サーバーにアクセスする場合、各スレッドは独自に CoInitialize と CoUninitialize を呼び出す必要があります。

これは、異なるプロセスから OPC サーバーにアクセスすることとほとんど同じです。OPC サーバー自体がシングルスレッドかマルチスレッドかは問題ではありません。

邪魔になるのは、使用している OPC クライアント ライブラリの抽象化です。

于 2013-08-04T07:24:17.183 に答える
2

私見は、あなたがそれを過度に設計しているようです。物事をできるだけ単純に保つ方が良いですが、スレッドを追加しても物事が単純になるわけではありません。

複数の OPC サーバーがあった場合は、スレッドの方が抽象化が優れていた可能性がありますが、現在は 1 つの OPC サーバーへの接続が 1 つしか必要ないため、複数のスレッドと複数の接続を持つことは、現実世界でのメリットがあまりなく、非常に複雑に見えます。

代わりに、以前と同様に、読み取りと書き込みに通常の OPC サブスクリプション メカニズムを使用します。

于 2013-08-05T06:23:57.240 に答える