PLCのCPUエラー（ERR LED）の確認と解除手順｜リセット前にエラー履歴を読む
設備が止まってPLCのERR LEDが点いている——現場で最も焦る場面のひとつです。しかしここで反射的に電源を再投入すると、原因究明の唯一の手がかりであるエラー情報を、自分の手で消してしまうことがあります。解除の前に、まず読む。これがCPUエラー対応の鉄則です。
この記事では、PLCのCPUエラーが発生した時に「リセットや電源再投入の前に何を確認・記録すべきか」を、LEDの見方からエラー履歴の読み方、解除後の観察まで、現場のトラブルシュート目線で整理します。
まずLEDの状態を正確に見る｜点灯と点滅は意味が違う
ツールをつなぐ前に、CPUユニットの状態表示LEDが第一情報です。RUN・ERRなどのLEDが「点いているか」だけでなく、点灯なのか点滅なのかまで正確に見てください。多くの機種で、点灯と点滅では異常の重さや種類が区別されています（どのパターンが何を意味するかは機種ごとに違うので、必ずその機種のマニュアルで確認します）。
LEDは「PLCが残してくれた現場の第一報」
救急の現場で最初にバイタルを見るのと同じで、CPUのLEDパターンは機械が発している最初のサインです。この情報は電源を切れば消えてしまうため、「どのLEDが・どう光っているか」をメモかスマホの写真で残してから次の手に進みます。
この時、RUN側のLEDが消えているのか、ERR側だけが光っているのか、他の警告系LEDは出ていないか、といった組み合わせも重要です。あとでマニュアルと突き合わせる時に「ERRが点いていた気がする」ではなく「RUN消灯・ERR点滅」と言えるかどうかで、原因究明のスピードが変わります。
ツールでエラー内容とエラー履歴を確認する
LEDの記録が取れたら、GX Works3などのエンジニアリングツールでPLCに接続し、現在発生中のエラー内容と、エラー履歴を確認します。これがCPUエラー対応の基本手順です。
ここで意識したいのは、エラーコードの番号そのものよりも、「いつ・どんな順番で・何が起きたか」という履歴の流れのほうが原因究明に効くことが多い、という点です。たとえば同じエラーでも、
- 毎回同じ時刻・同じ工程で発生している → 特定の動作・条件と紐づいている可能性
- 直前に別のエラーや警告が連続している → 表に見えているエラーは「結果」で、根本原因は先に起きた方かもしれない
- 今回が初めての発生か、以前から散発していたか → 突発故障か、劣化・環境要因の進行かの切り分け材料
という具合に、履歴は単発のコード番号では見えない文脈を教えてくれます。エラーコード自体の意味は、思い込みで判断せずその機種のマニュアルのエラーコード一覧を参照してください。番号の意味は機種・シリーズによって異なります。
エラーの大分類と考え方｜プログラム系・ハード系・パラメータ系
エラー内容を読む時、大まかな分類の引き出しを持っておくと当たりをつけやすくなります。あくまで一般論としての分類で、確定はエラー内容とマニュアルの照合で行いますが、考え方の軸としては次の3つです。
① プログラム系（演算エラーなど）
特定の回路・特定の条件が成立した時だけ発生するタイプです。たとえばインデックス修飾や間接指定でデバイス範囲を外れた、演算で不正な値を扱った、といったケースが典型です。「エラー発生時に何をしていたか」をモニタや履歴から特定するのが攻め方になります。デバイスの範囲や使い方に不安があれば、三菱PLCのデバイスの種類と使い分けで基礎を押さえておくと読み解きが速くなります。また、二重コイルのようなプログラムの作法違反が絡むトラブルもあるので、ラダー図のルールと書き方の作法も合わせて確認しておきたいところです。
② ハード系（ユニット異常・電源系など）
ユニットの認識異常や電源まわりが疑われるタイプです。この場合はプログラムをいくら眺めても答えは出ません。ユニットの装着状態・コネクタの接触・端子の緩み・盤内の温度や振動といった物理的な環境を疑います。電源を切ってから抜き差しや増し締めを確認する、という地道な作業が効くゾーンです。
③ パラメータ系
CPUやユニットのパラメータ設定と実機の構成が食い違っている時に出るタイプです。改造後・機器入替後・プログラム書き込み後に発生したなら、まずここを疑います。「昨日まで動いていたのに、今朝ユニットを交換したら止まった」という状況なら、パラメータと実機構成の照合が近道です。
解除（リセット）の手順の考え方｜消えるのは「表示」であって「原因」ではない
エラー内容と履歴を確認・記録できたら、エラーの解除（リセット）に進みます。ここで絶対に押さえておきたいのが次の考え方です。
リセットで消えるのは「エラー表示」であって「エラーの原因」ではない
サーマルリレーのリセットと同じで、解除操作は異常の後片付けにすぎません。原因が残っていれば、また同じ条件で再発します。逆に言えば、「解除後に再発するかどうか」自体が貴重な切り分け情報になります。
手順の考え方としては、こうなります。
- 解除の前に：エラー内容・履歴・LEDの状態・発生時の状況（どのワーク・どの工程・直前の操作）を記録する
- 解除の操作：ツールからのエラー解除やCPUのリセット操作など、方法は機種によるためマニュアルの手順に従う
- 解除の後に：すぐ再発するか、特定条件でだけ再発するか、再発しないかを観察する。再発の仕方が次のヒントになる
原因が特定・対処できていない状態で解除して運転再開する場合は、「再発したら今度はここを見る」という次の一手を決めてから復帰させると、同じ場所で二度立ち尽くさずに済みます。
電源再投入に頼る前に｜「再投入で直った」が最も危険なパターン
電源の再投入でエラーが消え、そのまま動き出すことは実際にあります。しかしこれは「原因不明のまま復旧してしまった」状態で、トラブルシュートとしては最も危険なパターンです。
- 原因が残っていれば、いずれ再発します。しかも次は夜勤帯や休日など、対応しづらいタイミングかもしれません。
- 再投入で履歴や発生時の状態が追えなくなると、再発した時にまたゼロから調べ直しになります。
- 「電源を入れ直せば直る設備」という誤った運用ノウハウが現場に定着し、根本原因がどんどん深く埋まっていきます。
やむを得ず再投入で復旧させる場合でも、その前にエラー履歴と発生条件の記録を必ず残すこと。ここまでの手順（LED確認→履歴確認→記録）を済ませてからであれば、再投入は選択肢のひとつになります。順番が逆になるのが問題なのです。
バッテリ・メモリ系の注意｜警告系のLEDも見逃さない
CPUエラーとあわせて意識しておきたいのが、バッテリやメモリまわりの警告です。機種によっては、バッテリ切れの警告を放置するとプログラムやデータが消失するリスクがあります（バッテリレスの機種もあり、リスクの有無・内容は機種によります）。
「設備は動いているから」と警告系のLEDや表示を放置していると、次の停電や電源オフのタイミングで一気に重大トラブルに化けることがあります。ERR系だけでなく、警告系の表示も含めて「普段と違う光り方」を見逃さないこと。そして自分の設備のPLCがバッテリを使う機種なのか、交換周期はどうなっているのかを、平時のうちにマニュアルで確認しておきましょう。
再発防止｜発生時の状態を記録に残す文化が結局早い
CPUエラーの原因究明で最後に効いてくるのは、高度な解析技術よりも記録の積み重ねです。エラーが起きたら、次の項目をメモに残す習慣をつけましょう。
- いつ：日時・シフト・稼働開始からの経過
- 何をしていたか：どの工程・どの動作中か、段取り替えや調整の直後ではないか
- どのワークか：特定の製品・型番の時だけ起きていないか
- 改造履歴：直近でプログラム変更・パラメータ変更・機器入替がなかったか
- エラー内容と履歴：ツールで読んだ内容の控え（画面の写真でも可）
散発的なエラーは、1回分の情報では原因にたどり着けなくても、数回分の記録を並べると共通点が浮かび上がることがよくあります。「記録なんて面倒」と感じるかもしれませんが、原因不明のまま何度も呼び出されることに比べれば、結局これが最も早い道です。
まとめ：解除は「読んで記録してから」
PLCのCPUエラーは、設備停止という最も焦る場面で発生します。だからこそ、反射的な電源再投入をぐっとこらえて、まずエラー内容と履歴を読むことが何より大事です。LEDの点灯・点滅パターンを記録し、ツールで履歴の流れを確認し、プログラム系・ハード系・パラメータ系のどれかの当たりをつける。解除で消えるのは表示だけで原因ではない、再発の仕方も切り分け情報になる——この「読む→記録→解除→観察」の順番を体に入れておきましょう。なお、エラーは出ていないのに設備が動かない、というケースの切り分けはPLCが動かない時のトラブルシューティング手順（全体地図）で整理しています。