「ボタンを押しても何も動かない」

設備の立上げ中にスタートボタンを押しても動かず、エラーランプも点灯しない場面を考える。

確認箇所を決めずにプログラム全体を眺めると、原因候補を絞りにくくなる。期待する動作と信号の経路を整理し、観測した値を順に照合する。 原因特定の時間は、不具合の内容、観測手段、担当者の知識などで変わり、一定倍率の短縮を保証するものではない。

デバッグの基本思想：「どこまで正常か」を絞り込む

PLCのデバッグでは、物理的な信号とプログラム内の状態を分けて追う。

センサ・ボタン
    ↓
入力回路・I/O割付
    ↓
CPUの入力値
    ↓
プログラムの条件
    ↓
出力指令
    ↓
出力回路
    ↓
負荷・配線・電源
    ↓
実際の動作

基本は、同じ信号IDと動作段階について、期待する状態と観測した状態を順番に照合することだ。 入力側から追う方法に加え、動くはずの出力から成立条件をさかのぼる方法も使う。「値が違う」という事実と、「センサ故障ではないか」という仮説を分けて記録する。

接続する設備・CPU・I/Oモジュール・ソフトの型式と版、回路図・I/O表・プログラムの版を先に確認する。本記事は通常制御の切分けを扱う。画面の点灯は電圧測定や安全機能の検証の代わりにはならない。配線・端子・負荷側の点検は、担当者が設備の安全手順に従って行う。原因確認のために安全条件を迂回したり、出力を安易に強制したりしない。

パターン別の確認手順

パターン①：「アクチュエータが動かない」

動作しないことと、PLCの出力指令が出ていないことは別である。次の順に観測箇所を分ける。

確認の順番：表示・論理・実負荷を分ける
STEP 1｜CPUと対象プログラムの実行状態
RUN/STOP・エラーコードを確認し、対象タスクやプログラムが実行される条件も調べる。RUN表示だけで対象処理の実行を決めない。
STEP 2｜信号源・入力LED・CPU値
センサ等の状態、入力モジュールのLED、I/O表の割付先、CPUが参照する入力値を対応させる。不一致なら配線や電源、割付・通信・更新条件を切り分ける。
STEP 3｜その段階の論理条件
a接点・b接点、直列・並列、比較命令などの成立を確認する。開始前と動作中の期待値を分け、OFFのデバイスを一律に故障原因としない。
STEP 4｜最終的な出力指令と割付
コイルの種類、同じデバイスへの別命令・別タスク等の書込み、実行順序、最終値と出力先を確認する。1箇所の点灯だけで物理出力を断定しない。
STEP 5｜出力回路と負荷側
出力LEDの意味を機種資料で確認し、負荷電源・コモン・配線・出力回路・アクチュエータを調べる。LED点灯だけで負荷への通電や動作は保証されない。

三菱電機のFX3G教材（JY997D41501E、2-4〜2-7）は入力・内部回路・外部負荷電源を分けて説明している。また、CODESYSのI/Oドライバ説明では、割付値の更新が設定や使用タスクに依存する。機種をまたいで同じアドレス・設定・更新タイミングと考えない。

パターン②：「途中で止まる（一度は動いたが止まった）」

  • アラームは何を検知したか → 発生順・時刻・工程を確認し、原因候補を絞る。後続アラームが最初の原因とは限らない
  • 待ち条件と時間監視は何か → 次の入力を待っているのか、設定時間を超過したのかを分け、動作要求・完了信号・タイマー状態を照合する
  • 保持・解除の条件は何か → 自己保持やSET/RESET等のどの解除条件が、いつ成立したかを確認する
  • 機器側の状態はどうか → 電源・エア圧・通信・駆動機器の異常を、プログラム内の値とは別に確認する

パターン③：「誤作動する（意図しない動きをする）」

  • 短い信号変化か → 入力応答・フィルタ、I/O更新、タスクの実行周期を確認する。短いパルスはCPUへ取り込む前に失われることがある
  • 他から書き込まれていないか → クロスリファレンス等で同じデバイスの書込み元を調べる。複数書込みが意図した構成か、後の処理で値を上書きしていないかを確認する
  • 観測方法が合っているか → 通常モニタの画面更新と、PLCの処理周期やトレースの取得周期を区別する。画面で見えなかったことだけでは未発生と判断しない

三菱電機FAQ12152は対象のMELSEC-F機種で入力フィルタと演算時間による取りこぼしを説明している。そこで示される時間を別機種へ一律に適用せず、信号幅と使用機器の仕様を照合する。

短時間の事象は、対応機器のトレース・記録機能で、対象変数、取得周期、トリガ、保存期間を決めて記録する。例えばCODESYSでは、通常モニタの更新間隔とは別に、選択タスクの何周期ごとに取得するかを設定する。トレースも離散的な記録なので、取得間隔の間の変化や、入力段で取りこぼした信号を必ず記録できるわけではない。

同製品のTrace説明には採取によるタスク周期への影響もある。新たな記録設定は担当者の承認と運転への影響確認を経て使い、取得条件と時刻の基準を記録に添える。実電気信号の確認が必要な場合は、測定方法を含めて担当者へ引き継ぐ。

ラダーモニタの使い方：値と条件を分けて読む

PLCプログラミングソフトには、ラダーやデバイス値をオンラインで監視する機能がある。例えばGX Works2の回路・デバイスモニタは、前掲の三菱電機教材3-32〜3-34で確認できる。利用できる機能や表示の意味は、実際のCPU・ソフト版のマニュアルで確認する。

ラダーモニタで確認すること：

表示・情報 読み取ることと限界
接点・回路の色や強調表示 ソフトの凡例が示すデバイス値や論理の成立状態。色だけで実電流や物理接点の状態を決めない
接点に対応するビット値 通常のa接点命令はTRUEで、b接点命令はFALSEで条件が成立する。直列・並列全体の条件も読む
コイル表示と書込み先の値 通常コイル、反転、SET/RESET等の命令を区別する。表示位置の論理と、他の書込みを含むデバイス値を照合する
タイマー・カウンタの値 設定値・現在値・完了状態に加え、開始/リセット条件と時間単位・数えるイベントを確認する

CODESYSの接点とコイルの説明は、BOOLの論理と代入を扱うものだ。また、OMRON FAQ02892はCX-Programmerについて、別命令による上書きや反転出力、表示の版による違いを説明している。画面の点灯と、出力端子から負荷へ電流が流れていることを同一視しない。

動かない原因候補をラダーで絞る手順：

  1. 対象の出力デバイス・変数を、I/O表と回路図から特定する。Y10などの表記や番号体系は使用機種に合わせる
  2. 現在の工程・運転モードでは、その出力に何を期待するか確認する。対象処理が実行中かも調べる
  3. 出力側から条件をさかのぼり、a/b接点・比較・直列/並列などの論理全体を読む
  4. 未成立条件のデバイス値を、入力割付や上流の処理と照合する。FALSEが正しい条件もあり、故障とは限らない
  5. 別の命令やタスク等による書込み、最終出力値、出力先を確認し、物理側の観測へつなぐ

デバッグを速くする設計習慣

後から困らないために、プログラムを書く段階から、期待状態と確認する信号を追えるようにしておく。

アラームの対象と不足条件を分けて出す

どの工程・条件群が未成立かを表示し、必要な個別条件と発生時の値を確認できる設計にする。

説明用の仮定例： 前進要求後、前進の許可条件が5秒以内に揃わなければ「A102：シリンダA前進インターロック未成立」を表示する。5秒とA102は例であり、実設備の許容時間・コードは動作仕様に基づいて決める。

A102だけで分かるのは、前進に必要な条件群が未成立だったことまでである。どの条件が不足したかは、条件別の状態や発生時の記録から確認する。例えば同じ前進許可の不足でも、CPUの入力値が期待と違うのか、設定・工程状態が違うのかで次の確認先が変わる。個別条件が分かっても、センサ故障・配線・割付等の根本原因が確定したとは限らない。

コメントを入れる（M・D番号に意味のある名前をつける）

例えばM100に「シリンダA前進完了フラグ」、D200に「レシピ品種番号」というコメントや対応する名称を付ける。名前に加え、成立条件・単位・参照する図面や仕様の版を残すと、後から意味を追いやすい。これらの番号は説明用であり、使用機種のデバイス体系に合わせる。

変数の状態をモニタリングできる画面を作る

タッチパネルやHMIがある場合、確認に使う値・信号ID・現在の工程を表示すると、ラダーを開く前の状況把握に使える。ただし、現在値の画面と発生時の履歴は別である。通信・画面更新が遅れたり途絶えたりしていないかも分かるようにする。

診断記録には、版、期待状態、観測事実、未確認事項、確認担当を結び付ける。次は仮想の記入例で、実在設備の測定結果ではない。

  • 対象：設備A、プログラムRev.3、I/O表Rev.2、条件ID C-12「前進開始許可」。CPU・モジュール・ソフト型式/版と発生時刻を記入する
  • 期待と観測：開始要求時は入力X10=TRUEを期待したが、モニタ値はFALSE。モジュールLEDは点灯。取得間隔は未確認
  • 未確認と次の担当：割付先と更新条件、発生時の信号状態を制御担当が確認する。断線やセンサ故障とはまだ判定しない。担当者名と確認期限を確定する

この記録は通常制御の切分け用であり、安全要求の検証完了を意味しない。安全機能に関わる条件なら、その要求IDと検証記録に対応付けて担当者へ引き継ぐ。

よくある失敗パターン

パターン①：エラーランプが出ていないのでプログラムが正しいと思った

エラーランプが点灯していなくても、インターロック条件が未成立で、動作指令が出ていない場合がある。

エラー表示がないことは、期待した動作になる証明ではない。 CPUの運転状態、対象プログラムの実行、工程と成立条件を照合する。仕様上正しく待機しているのか、信号やプログラムの条件が仕様と違うのかを分ける。

パターン②：現象だけ見てハードウェアを交換した

入力の参照先が誤っている場合は、センサを交換してもプログラムが期待する信号を読めるようにはならない。交換を決める前に、信号源、配線、割付、参照アドレスを照合する。

交換前に、可能な観測から故障候補を切り分ける。入力モジュールのLEDと、CPUが参照する値・アドレスを対応させる。 LEDが点灯していても、割付・通信・更新条件・参照先の一致までは証明できない。モジュールの診断情報と回路図も確認する。

パターン③：「前は動いていた」を信じすぎた

「昨日まで動いていた」という情報だけで、現在のプログラムが同じだと判断しない。変更の申告がなくても、承認済みの保存版と実機側の版を照合し、変更の有無を確認する。

プログラムの変更履歴・バックアップとの差分確認を初期確認に入れる。GX Works3のプロジェクト照合のような機能を使う場合も、PC内の保存版同士を比較したのか、実PLCから取得した対象と比較したのかを明記する。差がないことだけで、設定・保持データ・機器側を含む設備全体の同一性は保証されない。

復元が必要なら、現状を保全したうえで、戻す承認済みの版、変更理由、作業担当・承認者、対象機器との適合を確認する。プログラムとパラメータだけでなく、レシピ・補正値・保持データの保存対象と初期化範囲も確認する。ABBのCODESYSデータ保持説明のように、保持方式や操作によって値の残り方は異なる。古いプログラムを戻せば現在値もすべて戻る、とは考えない。

OMRONのCompoNetマニュアルW456（xvii・xix）は、変更・転送前の安全確認、プログラムの実行確認、ユニット交換後のDM/HR等の復旧データに注意を求めている。復元後は設備に定めた手順で、初期状態・停止条件・通常動作と影響範囲を検証し、版・結果・未確認事項と再稼働の承認を記録する。「書込み完了」を「再稼働してよい」と読み替えない。

社内で説明するときの言い方

  • 現場へ：「アラーム番号、発生時刻、止まった工程を記録してください。番号は確認先を絞る情報です。安全を確保して電気担当に引き継いでください」
  • メーカーへ：「対象の型式・版、信号ID、発生時の履歴と取得条件を整理します。機密と送付許可を確認した範囲で共有し、未確認の箇所を相談します」
  • 上司へ：「条件群のアラームだけでは不足条件を特定できませんでした。条件別の値と発生時の記録を確認できる設計を検討します」

デバッグ時の確認チェックリスト

まず確認すること：

  • 安全な確認範囲と担当者、対象設備・CPU・モジュール・ソフトの型式/版を確認したか
  • RUN/STOP・診断コードと、対象プログラムの実行状態を分けたか
  • 発生時刻・工程・変更履歴・比較した版を記録したか
  • 電源・エア圧・通信の状態を確認したか

モニタと信号経路で確認すること：

  • 信号源・入力LED・割付・CPU値を同じ信号IDで対応させたか
  • a/b接点、直列/並列、命令の種類と実行条件を読んだか
  • 別の書込み元・最終出力値・出力先と、物理負荷の状態を分けたか
  • タイマー等の開始・完了・リセットと、観測周期の限界を確認したか
  • 観測事実と原因候補、未確認事項・担当・期限を分けて記録したか
  • 変更や復元を行う場合、承認・保持データ・復元後の検証と再稼働条件を確認したか

まとめ

PLCデバッグでは、入力信号・CPU内の値・論理条件・出力指令・実際の負荷を順番に照合する。モニタの色や1つのアラームだけで、物理故障まで確定しない。

条件をさかのぼるときは、接点のON/OFFだけでなく、命令の種類と現在の工程での期待状態を見る。短時間の事象は、入力・処理・表示・記録の周期を分けて確認する。

信号IDと発生時の記録を残せば、次の担当者が確認先を追いやすくなる。変更や復元は版とデータの扱いを明確にし、復元後の安全・動作確認と再稼働の判断までつなげる。

関連記事