PLC制御設計の基本 PLC制御プログラムの基本｜ラダー言語の書き方と現場で使える設計パターン

PLC制御の設計現場では、回路や機構の知識と並んで、ラダー言語によるプログラミングのスキルが欠かせません。ラダーは見た目こそ独特ですが、リレー回路図をそのままソフトウェアに置き換えたような構造になっており、電気図面に親しんだエンジニアであれば直感的に理解しやすい言語です。一方で、書き方の自由度が高いがゆえに、命名の不統一や場当たり的な修正が積み重なると、誰も読み解けない「秘伝のラダー」が出来上がってしまうのも事実です。本記事では、ラダー言語の位置づけから基本要素、現場で頻繁に登場する設計パターン、保守性を高めるための書き方の作法、そしてラダー以外の言語との使い分けまでを順を追って解説します。これからPLCプログラミングに取り組む方や、すでに現場でラダーを書いているけれど一度基本から整理し直したいという方を想定した内容です。

ラダー言語の位置づけと特徴

ラダー言語は、リレーシーケンス制御で使われてきた回路図の書き方を、そのままソフトウェアに移植する形で生まれたプログラミング言語です。画面上に縦に伸びた2本の母線があり、その間に接点とコイルを配置して論理を組み立てていく見た目が、はしご（ラダー）に似ていることから名前がつきました。リレー制御に慣れた電気エンジニアが、新しい言語を一から覚え直すことなくPLC制御へ移行できるよう設計された経緯があり、現在も世界中の産業現場で最も広く使われているPLC用言語です。

ラダー言語は国際規格IEC 61131-3でPLC用言語のひとつとして標準化されています。同じ規格にはストラクチャードテキスト、ファンクションブロックダイアグラム、シーケンシャルファンクションチャート、インストラクションリストも含まれていますが、汎用性と読みやすさのバランスから、現場での主流は今でもラダーです。三菱電機、オムロン、キーエンスをはじめとする主要メーカーのPLCはすべてラダー言語に対応しており、メーカーごとに命令や記法に細かな違いはあるものの、基本的な考え方は共通しています。

ラダー言語が現場で支持され続ける最大の理由は、可読性の高さにあります。電気回路の知識があれば、プログラムを読みながら「どの信号が入ったらどの機器が動くのか」を回路図のように追跡できるため、トラブル発生時の原因究明や、ベテラン作業者による現場調整がやりやすいのです。プログラマだけでなく、保守を担当する電気作業員や設備管理担当者にとっても扱いやすい点が、長期間にわたる装置運用において大きな価値を持ちます。

ラダープログラムの基本要素

ラダープログラムは、いくつかの基本要素を組み合わせて作られています。最も基本となるのが接点とコイルで、ここを押さえればラダーの読み書きはおおむね始められます。

接点は条件を表す要素で、ラダー上では2本の縦線で記号化されます。a接点（ノーマルオープン）は対応するデバイスがオンのときに導通し、b接点（ノーマルクローズ）はオフのときに導通します。複数の接点を直列につなげば論理積（AND）、並列につなげば論理和（OR）になり、これらを組み合わせることで複雑な条件式を表現していきます。コイルは結果を出力する要素で、左から右へ条件が成立したときに対応するデバイスがオンになります。出力先は実際の物理出力だけでなく、PLC内部の補助リレー（内部ビット）でも構いません。

タイマとカウンタも、ラダーには欠かせない基本要素です。タイマは設定した時間が経過するとオンになる機能で、装置の動作タイミングを作るのに使われます。タイマには通電遅延・断電遅延・積算といった種類があり、用途に応じて使い分けます。カウンタは入力信号の立ち上がり回数を数える機能で、製品数の計数、サイクル管理、定期動作の生成などに使われます。タイマとカウンタはどちらも設定値と現在値を持ち、現在値が設定値に到達するとオンになる動作が基本です。

これらに加えて、データを扱う命令群もラダーで使うことができます。比較命令、四則演算命令、データ転送命令、シフト命令などを使えば、数値処理を含むやや高度な制御も実現できます。アナログ値の処理、生産数の管理、品種ごとのレシピ切り替えといった用途では、これらのデータ命令を組み合わせてプログラムを構成します。

現場で頻出する設計パターン

ラダープログラムには、現場で繰り返し登場する典型的な設計パターンがあります。これらのパターンを身につけておくと、新しい装置の制御を組むときも、既存装置のラダーを読み解くときも、見通しが格段に良くなります。

最も基本となるのが自己保持回路です。押しボタンを一度押すと出力がオンになり、ボタンを離してもオン状態を保ち続け、別の停止信号が入るとオフになる構造で、装置の運転・停止制御の根幹をなします。実装としては、起動条件と停止条件のb接点、そして自分自身のa接点を組み合わせるのが定番の形です。装置に何台ものモータがあれば、その台数分の自己保持回路がラダーのなかに並ぶことになります。

次に頻出するのがインターロック回路です。複数の動作が同時に成立してはならない、ある条件が満たされなければ動作してはならない、といった安全上・機能上の制約を、論理的に保証する仕組みです。たとえば、装置のドアが開いているときはモータを動かさない、上昇出力と下降出力を同時に出さない、原点復帰中は手動操作を受け付けない、といったインターロックは装置の安全性を支える基盤になります。設計の初期段階でインターロック条件を洗い出し、漏れなくラダーに織り込んでおくことが、後のトラブルを大きく減らします。

非常停止回路も、産業設備では必須のパターンです。非常停止ボタンが押されたら、すべての動作出力を即座に停止し、復帰には所定の手順を要求する、という構造を作り込みます。法令や安全規格への対応もあるため、非常停止については単にラダー上で表現するだけでなく、安全リレーや安全PLCといった専用機器と組み合わせて二重に守る設計が一般的になっています。

工程歩進制御は、装置が複数のステップを順番に進めながら動作するタイプの制御で、組立装置や搬送装置、加工装置などで頻繁に登場します。ステップ番号を管理するデバイスを用意し、各ステップごとに「このステップでは何を出力するか」「次のステップに進む条件は何か」を明確に書いていくことで、複雑な動作を整理された形で記述できます。歩進制御をきれいに書けるようになると、装置全体のラダーが格段に読みやすくなり、後の改造や仕様変更にも強くなります。

異常検出と復帰の処理も、現場のラダーで重要な位置を占めます。センサ異常、過電流、タイムアウト、上位通信切断などの異常をどう検出し、検出時にどう装置を停止させ、復帰のための手順をどう用意するか。異常処理はラダーの規模を大きく膨らませる要因にもなるため、設計の初期段階で異常項目をリストアップし、共通の処理パターンを決めておくと、コード量を抑えながら抜け漏れを防げます。

保守性を高めるラダーの書き方

ラダープログラムは「動けば良い」というレベルでは十分ではありません。装置の寿命は10年、20年と長く、そのあいだに改造、仕様変更、トラブル対応が何度も発生します。書いた本人ではない誰かが、数年後にラダーを開いて理解し、修正できる状態に保たれていることが、現場で価値あるプログラムの条件です。

最初に意識したいのが命名規則とデバイスコメントです。PLCで扱うデバイス（X・Y・M・Tなど）には番号が振られているだけで、それぞれが何を意味するのかは命名されていません。M100が何を表すデバイスなのか、ラダーを読む人がすぐ分かるように、すべてのデバイスにコメントを付ける運用を徹底するだけで、可読性は劇的に向上します。さらに、入力デバイスは何に使うか、内部リレーは機能ごとにどの範囲を使うか、というデバイスマップをプロジェクト全体で統一しておくと、複数人で開発する場合も衝突を防げます。

ラダーの分割とモジュール化も、保守性を支える重要な作法です。長大な一枚のラダーをだらだらと書くのではなく、機能単位でプログラムをファイル分割し、運転制御・各軸制御・通信処理・異常処理・タッチパネルインターフェース、といった単位で整理しておきます。メーカーが提供するファンクションブロックやサブルーチンの機能を活用すれば、繰り返し登場する処理を一箇所にまとめ、修正コストを下げることもできます。同じ動きを複数箇所に書き散らすのは、最も避けたいアンチパターンです。

予備接点・予備デバイスの確保も、現場では重要な習慣です。装置が稼働を始めてから「センサを1つ追加したい」「補助の出力をひとつ取りたい」といった要求が必ずと言って良いほど発生します。そのときに、入力ユニットや出力ユニットに空きがなければ、ユニットの追加や配線のやり直しという大掛かりな作業が発生してしまいます。設計段階で1〜2割の余裕を持たせておくことで、後の改造を低コストでこなせるようになります。

加えて、設計意図のコメントを残すことも忘れたくない作法です。「なぜこのインターロックを入れているのか」「なぜここで0.5秒待っているのか」といった、ラダーを見ただけでは分からない判断の背景をコメントとして残しておくと、後任者がラダーを修正する際に安全な判断ができるようになります。プログラムは書いた瞬間から自分のものではなく、装置の寿命のあいだずっと誰かが触り続ける資産だ、という意識でラダーを書くと、自然と保守性の高いコードに近づきます。

ラダー以外の言語の使い分け

ラダー言語は強力ですが、すべての処理に向いているわけではありません。複雑な数式の計算、文字列処理、ループや条件分岐の多い処理は、ラダーで書くと冗長になりがちです。こうした処理には、IEC 61131-3で標準化された他の言語を組み合わせるのが有効で、近年は主要メーカーのPLCが複数言語の混在に対応しています。

代表的な選択肢がストラクチャードテキスト（ST）で、PascalやC言語に似た構文を持つテキストベースの言語です。数値演算、条件分岐、ループといった処理を簡潔に書けるため、座標計算、温度補正、生産データの集計といった用途で活躍します。ラダーで書くと数十行になるような計算式が、STなら数行で済んでしまうこともあり、可読性と保守性の両面で大きな利点があります。

ファンクションブロックダイアグラム（FBD）は、機能を箱として並べ、入出力線でつないでいく図的な言語です。PID制御やフィルタ処理、信号処理といった、機能のまとまりが明確な処理に向いています。シーケンシャルファンクションチャート（SFC）は、工程歩進制御を視覚的に記述するのに優れた言語で、複雑なシーケンスを状態遷移図のように描けます。

実際の現場では、装置全体の論理制御はラダー、複雑な計算はST、信号処理はFBD、明示的な工程歩進はSFC、というように使い分けるのが現実的です。すべてをラダーで頑張る必要はなく、適材適所で言語を選ぶことで、プログラム全体の見通しと保守性が大きく向上します。ただし、混在させすぎるとかえって読み手が混乱するため、プロジェクトとして使う言語の範囲を決めておくのが望ましい運用です。

デバッグと現地調整のコツ

PLCプログラムは机上で書き終わるだけでは完成しません。実機を相手にしたデバッグと、現場での立ち上げ調整を経て、はじめて装置として動き始めます。この段階の作業効率は、ラダーの書き方そのものと同じくらい、最終的な品質と納期に影響します。

最も基本となるのが、開発ソフト上のモニタ機能の活用です。三菱電機のGX Works、オムロンのSysmac Studio、キーエンスのKV STUDIOといった各社の開発環境では、ラダーを実行中の状態で開き、接点の導通状態やコイルのオンオフ、デバイスの現在値をリアルタイムに観察できます。期待通りに動かない箇所があれば、まずモニタで信号の流れを追いかけ、どの条件が成立していないかを特定するのが定石です。

強制ON/OFFの機能も、現地調整では強力な武器になります。実機の入力信号が出ていない状態でも、PLC側のデバイスを強制的にオンにして次の動作を確認したり、出力を強制的にオフにして安全な状態に固定したりといった操作ができます。ただし、強制操作は安全装置を一時的に無効化することにもつながるため、使用ルールを決めて慎重に運用することが必要です。

ログ取得の仕組みも、現場での不具合解析を大きく助けます。再現性の低い不具合に遭遇したとき、装置の動作履歴や異常発生時のデバイス値が記録されていれば、原因究明のスピードが格段に上がります。最近のPLCはデータロギング機能を標準で備えており、設計の初期段階で「何を記録するか」を決めておくことで、立ち上げ後のトラブル対応コストを抑えられます。

動かすだけが目的ではない

PLCのラダープログラミングは、接点とコイル、タイマとカウンタといった基本要素を理解したうえで、自己保持・インターロック・非常停止・工程歩進・異常処理といった頻出パターンを組み合わせて作り上げていきます。動かすだけなら難しくない言語ですが、装置の長い寿命を見据えると、命名規則・モジュール化・予備の確保・設計意図のコメントといった保守性を高める作法が決定的に重要になります。さらに、ラダー一辺倒ではなくSTやFBD、SFCといった他の言語を適切に組み合わせ、モニタや強制操作、ログ取得といったツール群を使いこなすことで、現場で長く価値を持ち続けるPLC制御プログラムに仕上がります。