PLCプログラムのデバッグ手順｜「動かない」「止まる」を素早く原因特定する方法

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

設備の立上げ中、操作パネルのスタートボタンを押した。何も動かない。エラーランプも点灯していない。

こういうとき、何を見ればいいかわからずにプログラム全体を見回してしまう人は多い。しかし、デバッグには「絞り込む順番」がある。 その順番を知っているかどうかで、原因特定にかかる時間が5倍以上変わる。

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

PLCの制御は、以下の流れで動いている。

センサ信号（入力）→ PLCプログラム → 出力指令 → アクチュエータ（動作）

「動かない」という現象が起きたとき、問題はこの流れのどこかにある。

デバッグの基本は、この流れを入力側から順番に確認して、「ここまでは正常」「ここから先がおかしい」と絞り込むことだ。

3パターン別の確認手順

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

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

• アラームが出ているか → PLCのアラーム履歴を確認する。アラームコードから原因を絞る
• タイムアウトか → タイマーの完了を待っているが、次の動作のセンサが反応していない
• 自己保持が解除されているか → 途中でリセット条件が成立していないか確認
• エア圧・電源電圧が低下していないか → 機械的な問題がプログラムに見えるケース

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

• チャタリングか → センサ信号が短時間でON/OFFを繰り返していないか。ラダーモニタで確認
• コイルが複数箇所で使われていないか → 同じコイルに複数の書き込みがある「コイル二重コイル」はバグの原因
• タイミングのズレか → スキャン周期より速い動作を想定していないか

4ラダーモニタの使い方：これだけ知れば十分

ほとんどのPLCプログラミングソフト（GX Works、Sysmac Studio、CX-Programmer等）はオンラインでラダーを監視できる。

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

「出力が出ない」原因をラダーで見つける手順：

1. 出力コイル（例：Y10）を探す
2. コイルがONしているか確認
3. OFFなら、コイル直前の接点を右から左へたどる
4. OFFの接点を見つけたら、その接点のデバイス番号（X・M・D等）を確認
5. そのデバイスがなぜOFFなのか追跡する

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

後から困らないために、プログラムを書く段階から意識すること。

アラームを細かく出す

「動かない原因」を外から見てわかるように、インターロック条件が成立しない場合のアラームを出力する設計にする。

例：シリンダ前進条件が5秒経っても揃わない → アラームコード「A102：シリンダA前進インターロック未成立」を表示

これだけで「どの条件が足りないか」がパネルからわかるようになり、ラダーを開かなくても原因を特定できる。

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

M100 ではなく「シリンダA前進完了フラグ」、D200 ではなく「レシピ品種番号」と名前をつける。他者が読んでも・自分が1年後に読んでも理解できるプログラムになる。

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

タッチパネルやHMIがある場合、デバッグで頻繁に確認するデバイスの値を一覧で表示できるモニタ画面を作っておく。ラダーを開かずに状態確認できるため、立上げ速度が大幅に上がる。

6よくある失敗パターン

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

エラーランプが点灯していなくても、インターロック条件が成立していないためにプログラムが意図した動きをしていないケースは頻繁にある。

PLCはエラーがなくてもプログラム通りに動く。 プログラムが「動かない条件」で書かれていれば、正しく「動かない」状態が続く。

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

「センサが壊れた」と思って交換したが、実はPLCのプログラムで入力信号を読んでいなかった（アドレスのミス）。交換後も症状が変わらず、余計な時間とコストがかかった。

ハードウェアを疑う前に、PLCのI/O状態を必ず確認する。 入力モジュールのLEDがONしているならPLCは信号を受け取っている。プログラムでその信号を使っているかを確認する。

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

「昨日まで動いていたのに今日は動かない」という状況で、「プログラムは変えていないから問題ない」と判断してハードウェアばかり見た。実は前日の作業でプログラムが誤って書き換えられていた。

プログラムの変更履歴・バックアップとの差分確認を最初のステップに入れる。

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

• 現場へ：「動かないときはまず操作パネルのアラーム番号を確認してください。番号から原因が特定できます。アラームが出ていない場合は電気担当に連絡してください」
• メーカーへ：「アラーム履歴のCSVエクスポートと、問題発生時刻のPLCデバイスモニタのスクリーンショットを送ってください。現地に行く前にプログラム側の確認をします」
• 上司へ：「デバッグに時間がかかった原因はアラーム設計が不十分だったためです。次の設備からは動作不成立の原因を番号で表示する設計を標準にします」

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

まず確認すること（5分以内）：

• PLCがRUN状態か
• エラー・アラームコードが出ているか
• プログラムが最近変更されていないか（バックアップと比較）
• 電源・エア圧・通信が正常か

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

• 入力信号（センサ・ボタン）がONしているか
• 出力コイルがONしているか
• コイルがOFFの場合、どの接点がOFFか（右から左に追う）
• タイマー・カウンタが正しく動作しているか

9まとめ

PLCデバッグの基本は「入力→プログラム→出力」の流れを順番に確認して問題箇所を絞り込むことだ。

ラダーモニタを使えば、インターロック条件のどこが成立していないかを視覚的に確認できる。「出力コイルを見つけ → コイルがOFFなら接点を右から左に追う」 この手順を覚えるだけで、原因特定の速度が大きく変わる。

アラーム設計を最初から作り込んでおくと、現場が自律的に初期確認できるようになり、電気担当への問い合わせが減る。

10関連記事

• PLCとは何か？ — PLCの仕組みとメーカー選定
• ラダー図の基本 — 接点・コイル・タイマーの読み方
• インターロック設計の基本 — 動作条件・禁止条件の設計方法