- ST言語でFOR文を書いたら、CPUの「ERROR」ランプが赤く点灯した
- 「WDTエラー」と出たが、原因がわからず設備が完全沈黙した
- とりあえずパラメータで監視時間を延ばしてエラーを消そうとしている
ST言語でレベルアップを図ろうと奮闘し始めた頃、この得体の知れないエラーで出鼻をくじかれる絶望感。現場の人間なら痛いほど分かります。
「せっかく書いたプログラムが止まってしまった」と、WDTを邪魔な敵のように感じているなら、その認識は一度改めてみてください。
実務9年の現場エンジニアである私が断言します。
WDTは敵ではありません。あなたの書いた「過負荷なプログラム」から、高額な設備を守ってくれる「命綱（ヒューズ）」です。
本記事では、WDTエラーの本当の原因と、現場で絶対にやってはいけない対処法、そしてプログラムを極限まで最適化する「3つの解決策」を妥協なく解説します。
この記事を読めば、小手先のエラー回避ではなく、現場の安全を担保する「プロの設計思想」が身につき、客先や上司にも堂々と理論武装できるようになります。
「エラーが出たから、とりあえず設定時間を延ばせばいいや」とパラメータ変更に逃げようとしている方は、一番やってはいけない「大事故に繋がる落とし穴」にハマる前に、必ずこの先を読んでください。
なぜWDTエラーは起きるのか？（番犬が吠える理由）
WDT（ウォッチドッグタイマ）とは、簡単に言えば「1回のスキャン（プログラムの頭からお尻まで実行する時間）が、設定された制限時間内に終わっているかを見張る番犬」です。
PLCは常に以下の3つのステップ（スキャン）を高速で繰り返して設備を制御しています。
- 入力読込（リフレッシュ）： センサやボタンの状態を一斉に読み込む。
- プログラム演算： ラダーやSTを上から下まで実行する。
- 出力反映（リフレッシュ）： 演算結果を実際の出力端子（Yなど）に一斉に反映させる。
もし、FOR文の終了条件を間違えて「無限ループ」に陥ったり、数万件のデータ処理を1回のスキャンに詰め込みすぎたりするとどうなるでしょうか。
PLCの頭脳は「2. プログラム演算」の箱の中に永遠に閉じ込められ、次の「3. 出力反映」や「1. 入力読込」へ進めなくなります。
▶ 最大の恐怖：出力出っ放し＆ボタン操作不能
これが意味するのは、「無限ループに入る直前の出力状態（シリンダ前進など）が物理的に維持され続け、さらに作業者が慌てて停止ボタンを押しても、PLCがそれを読み取れない」という最悪の暴走状態です。
WDTは、「このままだと設備が制御不能になる！」と判断し、自らエラーを出してPLCを強制停止させると同時に、安全のためにすべての出力を強制的にOFF（遮断）してくれます。まさに設備と人を守る命綱なのです。
厳禁！やってはいけない「最悪の対処法」
WDTエラーが出た際、最もやってはいけない対処法があります。 それは、「PLCのパラメータ設定を開き、WDTの監視時間を安易に延ばすこと」です。
デフォルトで「200ms」などに設定されている監視時間を、「エラーが出るからとりあえず1000ms（1秒）にしてしまえ」と変更する。これは根本的な解決から完全に逃げており、異常な時間がかかっているプログラムを放置して、番犬の口を塞いでいるだけです。
▶ なぜ時間を延ばしてはいけないのか？
機械の動力を遮断する「非常停止」はハードウェア回路で組むのが鉄則ですが、設備の一時停止やサイクル停止はPLCのプログラムで制御します。
もし、監視時間を延ばして「1スキャンに1秒かかるプログラム」を許容してしまったらどうなるでしょうか。 作業者が「停止ボタン」を押しても、最悪1秒間はPLCがボタンのONを認識できず、設備が止まりません。 刃物やシリンダが1秒間動き続ければ、大事故に直面します。パラメータの安易な変更は、現場の安全を根底から脅かす行為だと肝に銘じてください。
プログラムを最適化する「3つの解決策」
では、WDTエラーに直面したとき、どのように対処すべきでしょうか。パラメータを変更する前に、以下の3ステップでプログラムの設計を根本から見直します。
解決策①：最悪ケースを想定し、無駄なループを断つ
初心者が書きがちなのが、「目的を達成したのに、無駄に最後までループを回し続けるプログラム」です。
例えば、1,000個のデータ配列の中から「異常フラグ」を探すFOR文を書いたとします。 もし3番目のデータで異常が見つかったなら、残りの997回は検索する必要がありません。条件に合致した時点で、EXIT命令を使って速やかにループから抜け出してください。これだけで、スキャンタイムの無駄な消費を劇的に抑えることができます。
「EXIT命令」を使えば処理は軽くなりますが、それに頼り切るのは危険です。「もし1,000個のデータ全てを検索しても目的のデータが見つからず、一度もEXITが実行されなかった場合（最悪ケース）」でも、WDTエラーにならないように設計しなければなりません。
また、WHILE文などで「センサがONになるまでループで待つ」といった記述は最悪です。センサが断線していたら永遠にループから抜けられません。 「〇〇回繰り返してもダメなら、異常としてループを強制的に抜ける」という安全網（フェールセーフ）を必ず張ってください。
解決策②：重い処理は「しおり」を挟んで複数スキャンに分割する
どうしても1万件のデータ処理が必要で、最悪ケースでは処理時間がWDTを超えてしまう場合。そんな時は、1回のスキャンで全部やろうとするから番犬が吠えるのです。
▶ プロの奥義「時分割処理」
こういう場合は、「1回のスキャンで500件だけ処理して一旦お休みし、次のスキャンで続きの500件から再開する」というように、処理を複数スキャンに分割します。 分厚い本を1日で読み切るのではなく、「しおり」を挟んで毎日少しずつ読むイメージです。
IF文やFOR文を組み合わせて「現在位置を記憶しながら処理を再開する」という具体的なプログラムの組み方は、中級者向けのテクニックとなるためここでは深く踏み込みません。今はただ、プロはこうして「1スキャンあたりの負荷を一定に保つ設計」を行っていることを、頭の片隅に置いておいてください。
解決策③：「常に計算」をやめ、「変化時のみ」実行しろ
毎スキャン、ひたすら同じ複雑な演算（浮動小数点の計算や、文字列の結合など）を繰り返していませんか？
値が変わっていないのに計算し直すのは、PLCの演算能力の無駄遣いです。 「データが更新された瞬間（トリガ入力が入った時）」だけ演算を実行するパルス実行や、変化点検出の接点を使い、普段は重い演算ブロックをスキップさせるように最適化してください。
まとめ：WDT設定変更は「最終手段」である
ここまでの内容を振り返ります。
- WDTの役割： 暴走（出力出っ放し＆入力無視）から設備を守る命綱である。
- 最悪の対処法： 安易にパラメータの監視時間を延ばすこと（停止ボタンの反応が遅れる危険性）。
- 解決策①：
EXITで無駄を省き、最悪ケースを想定した安全網を張る。 - 解決策②： 膨大な処理は「しおり」を挟んで複数スキャンに分割する。
- 解決策③： 毎スキャン計算せず、「変化した時だけ」実行させる。
監視時間を延ばすのは、上記の最適化をすべてやり尽くし、どうしても物理的に処理時間が足りない場合のみに許される「最終手段」です。
WDTエラーは、あなたのプログラムに潜む「無駄」や「危険」を教えてくれるありがたい警告です。設定変更でやり過ごす癖を捨て、プログラムを極限まで最適化して「スキャンタイムを削り出す」安全な設計を目指してください！
