S7シリーズのSiemens PLCのプログラミングに関する記事を読んで、Habrの検索に飛び込みました。産業オートメーション全般、特にPLCプログラミングのトピックが非常に不十分にしかカバーされていないことに驚きました。 PLCプログラミングの基本原則、特にBeckhoffの制作について説明し、この分野での私の経験を共有してください。
はじめに
ビルディングオートメーションを行います。 そのため、主にBeckhoff PLCに基づいてシステムを構築しています。 この選択は、主にこれらのコントローラーがこれらの言葉の意味で自由にプログラムできるために行われました。 これはどういう意味ですか？ たとえば、TAC Xentaコントローラを取り上げ、独自のプロトコルを使用して、「送信バイト-受信バイト」のレベルでRS232経由で外部デバイスと交換しようとします。 それは動作しません、これらのコントローラはこれを行う方法を知りません-開発者がそれらに定めたプロトコルのみを使用してください。 しかし、ベッコフはできます。 しかし、そのようなジャングルに入る前に、開発環境を見てみましょう。 実際、私たちは何で言語を書くのでしょうか？
IEC 61131-3標準
産業用PLCはIEC 61131-3の言語でプログラムされています。 これらの言語は5つあり、一部のメーカーは独自の言語を追加しています。 言語はまったく似ていないので、同僚を見て、特定の言語の選択は主に、この業界に参入する前に人がしていたことと関係があると思います。
- IL、命令リスト。 アセンブラのように見えます。 私はそれを使用する人を見たことがありませんが、メモリカードをパンチした古い学校のエンコーダーはそれを評価するだろうと思います。
- LD、ラダー図。 リレー自動化回路の開発に携わる人のための視覚言語。
- ST、構造化テキスト。 Pascalに似た点で、「古典的な」プログラミング言語に最もよく似ています。 それが、PLC以前は他の言語やプラットフォームでのプログラミングに携わっていた人、特に私に感謝されている理由です。
- FBD、機能ブロック図。 この種のブロックスキームは、明確にするために、主にプログラミングに入ることを決めた技術者に愛されています。
- SFC、シーケンシャル機能チャート。 グラフィック言語、私は何も言いません。 使用されたことはありません。
サポートされているすべての言語ではありませんが、CFC（連続フローチャート）言語は注目に値します。ベッコフはそれをサポートしています。 これはFBD言語のさらなる発展であり、最も重要な違いの1つは、私の意見では、回路での明示的なフィードバックのサポートです。 なぜこれが必要ですか？ たとえば、このような短パルス発生器はCFCで機能しますが、FBDでは機能しません。
TONブロックは標準ブロックであり、オン遅延のあるタイマーです。 操作の論理：少なくともPTでINにTRUEが入力されると、出力QはTRUEになります。
おそらく最も人気のあるPLC開発環境はCoDeSysです。 多くのメーカーはこれを基礎として、PLCと連携するライブラリを作成するか、環境を自分で完成させます。
PLCはどのように機能しますか？
PLCプログラムはサイクルで実行されます。 サイクル時間は、このPLCに割り当てられているタスクに応じて、ミリ秒単位から秒単位になります。 ほとんどのPLCでは、プログラム開発者がサイクルタイムを設定できますが、一部のモデルでは設定できません。 多くのPLC、特にBeckhoffでは、1つのプログラムで複数の周期的なタスクを作成し、これらのタスクの優先順位を設定できます。 この機会は何を与えてくれますか？
状況を想像してください。PLCが空気処理装置を制御し、制御パネルがRS232を介してそれに接続されています。 部屋の温度はすぐには変化せず、換気制御アルゴリズムを50〜100ミリ秒に1回以上実行するのは意味がありません。 しかし、操作パネルは常にコントローラーをポーリングし、10 msを超えるPLC応答遅延はユーザーインターフェイスの「ブレーキング」で既に表されており、20 msの遅延でハードウェアCOMポートバッファーがオーバーフローします。 いくつかのタスクが存在するため、この問題を美しく解決できます。「高速」タスクをCOMポートで動作させ、2ミリ秒ごとに呼び出します。「低速」タスクは換気ロジックを実装し、50ミリ秒ごとに呼び出します。 すべてがうまく機能し、操作パネルの速度は低下せず、ユーザーは満足しています。
そして、これらの腺には何が入っていますか？
ここにあるものはすべて、メーカーに大きく依存しています。 誰かがRISCプロセッサ（たとえば、国内の牡羊座）で組み込みプラットフォームを作成しています-このアプローチは非常に人気があります。 一方、ベッコフは逆に、Windows CE 5.0がPLC（および公式サイトからファームウェアを更新する場合は6.0）、またはWindows XP Embeddedにインストールされ、PLCタスクはサービスとして機能します。 ファンがWindowsの不安定性について話すのはかなり興味深い反論です。
しかし、これはコントローラーの「ヘッド」ですが、それでも外部と通信するために入力と出力が必要です。 2つのアプローチがあります。
- 「すべて1つのボックス」-ヘッド、特定の入力/出力セット、いくつかの構成オプション-を行うことができます。ここでは、入力が多く、小さく、ヘッドが強力で、弱くなっています。 たとえば、 Carelや他の多くの人もそうです。 小さなプロジェクトでは、このアプローチは何かを正当化するかもしれません。
- しかし、個人的には、異なる柔軟性が異なるアプローチを与えるように思えます。 ヘッドは独立しており、入出力モジュールからダイヤルされたテールがバスを介してヘッドに接続されています。 必要なモジュールを必要な量だけ配置します。 たとえば、ベッコフとシーメンスもそうです。
これが「オールインワンボックス」アプローチの外観です。 Carel pCO3による写真。
そして、別のオプションがあります-CX9000シリーズのBeckhoffヘッド（写真の左）とI / Oモジュールのセット。
とりわけ、ヘッドには特定のバスがあり、PLCをネットワークに統合し、同じネットワークを介してそのプログラムを変更することもできます。 どのようなネットワークになるかは、PLCによって異なります。 これは、産業用ネットワークEIA-485 、 Profibus 、 CAN 、または多分非常に馴染みのあるイーサネットに遭遇したことがない人には馴染みがないかもしれません。 PLCが上位レベル、たとえばSCADAシステムに接続されているのは、フィールドバスと呼ばれるこのネットワークを介してです。 上の写真では、Beckhoffの頭に2つの8P8Cソケットがはっきりと見えています。これはイーサネットであり、Carelには左上に2つの6P4Cソケットがあります（ただし悪くはありません）。 残念ながら、このインターフェイスには共通のコネクタはありません。
それで、まだそれのためのプログラムをどのように書くのですか？
一般に、このトピックは記事ではなく、本全体です。 しかし、私は個人的な経験から私が見たものを教えて、それが軟膏でハエになるようにします。
プロのプログラマーにとって、多くの点でPLCの開発は劣化しているようです。 おっと？ それらはありません。「機能ユニット」と呼ばれるクラスの構造、列挙、および特定の類似性のみがあります。 プライベート、パブリックなどは、すぐに忘れることができます-それは便利になりません。 プログラムのどこからでも、他の場所にアクセスできます。
動的メモリ割り当て？ それらはまったくありません。 どのくらいのデータがあなたに送られるかわかりませんか？ 余裕を持ってバッファを割り当てて、このメモリを忘れてください-解放しても機能しません。 設定されたサイクル時間を達成できた場合は、驚異的なスピードとプロセスデータを即座に表示します。
例外？ あなたは何ですか...私は、フォームの構築を実行している間、固くつるされた奇跡を見ました：
foo, bar: int; baz: real; foo := 2000; bar := 2000; baz := INT_TO_REAL (foo * bar);
オーバーフローがfoo * barを16ビットに適合させないことは明らかですが、なぜ何かがハングしますか？ はい、そして栄養のリセット以外は何も助けにはなりません。
開発環境？ すべてのCoDeSysではなく、多くの人が独自のスレッドをオリジナル化して記述したいと考えています。 そのような自己記述型環境の1つは、数値86400を16ビットINTに書き込もうとすると、ランタイムエラーでクラッシュしました。 そして、あなたはPLCで例外処理を言います。 開発環境では、常に正常に実行できるとは限りません。
しかし！ しかし、ハードウェアをソフトウェアから分離する、その独特なラインを愛する人にとっては、これはITの非常に興味深い分野です。
この短いレビューがお役に立てば幸いです。 このトピックがhabrasocietyに興味がある場合、PLCについて詳しく説明します。