PLC同士やPLCと周辺機器の通信では、明確な「通信エラー」が出ていなくても、設備動作に不具合が出ることがあります。
例えば、
- 相手PLCへ信号を送っているのに動作しない
- I/Oの反映が遅れているように見える
- たまにだけ動作条件を取りこぼす
- 通信そのものは成立しているのにシーケンスが進まない
- 相手機器の処理待ちと通信遅延の区別がつかない
といったケースです。
このような不具合は、通信設定そのものだけでなく、ハンドシェイク、信号保持時間、PLCスキャン、通信更新周期、相手機器の処理時間などが組み合わさって発生することがあります。
この記事では、PLC通信が正常に見えるのに設備動作がおかしい場合に、どこから確認して切り分ければよいかを実務目線で整理します。
PLC通信が正常でも設備動作に不具合が出る理由
PLC通信で厄介なのは、「通信できていること」と「設備が意図したタイミングで正しく動くこと」は別問題という点です。
PLC同士でデータが送受信できていても、設備側では次のような理由で動作不具合が発生することがあります。
- 必要な信号が相手に届く前にOFFしている
- 通信更新より速くシーケンスが進んでいる
- 相手PLCの処理完了を待たずに次工程へ進んでいる
- ACKなどの応答確認がなく、一方的に信号を送っている
- タイムアウト条件が実際の通信・処理時間より短い
- PLCスキャンと通信更新のタイミングがずれている
例えば通信状態を監視していてエラーが出ていなくても、相手側へデータが反映されるまでには一定の時間がかかります。
そのため、
「通信エラーがない＝通信に関係する問題ではない」
とは限りません。
逆に、通信そのものを疑っていた不具合でも、実際には相手PLC側の処理条件やシーケンスが原因だったというケースもあります。
重要なのは、最初から「通信が遅い」「PLCがおかしい」と決めつけず、
通信そのもの → データ反映 → 相手側処理 → シーケンス条件
の順に切り分けていくことです。
まず切り分けたい「通信異常」と「通信起因の動作不具合」
PLC通信まわりの不具合を調べるときは、最初に
「通信そのものが異常なのか」
「通信は成立しているが、タイミングや条件によって設備動作に不具合が出ているのか」
を分けて考えると切り分けやすくなります。
| 分類 | よくある症状 | 最初に確認すること |
|---|---|---|
| 通信そのものの異常 | 通信エラー、接断、タイムアウト、通信モジュール異常 | エラーコード、診断情報、配線、ネットワーク設定、通信パラメータ |
| データ反映の問題 | 値が遅れて見える、 更新されないように見える | 通信更新周期、PLCスキャン、データ更新タイミング |
| ハンドシェイクの問題 | たまに信号を取りこぼす、 シーケンスが進まない | 要求・応答信号、信号保持時間、ACK確認 |
| 相手側処理の問題 | 通信は正常だが応答が遅い | 相手PLCの処理条件、 完了条件、内部処理時間 |
| 条件設定の問題 | 特定条件だけ異常になる | タイムアウト値、インターロック、シーケンス条件 |
明確な通信エラーがPLCや通信ユニットから出ている場合は、まずメーカーの診断情報やマニュアルを確認するのが基本です。
一方で、通信エラーが出ていないのに設備動作だけがおかしい場合は、通信経路そのものよりも、信号の渡し方や処理タイミングを確認した方が早く原因へたどり着けることがあります。
今回の記事では、特に後者の「通信は成立しているのに設備動作がおかしい」ケースを中心に解説します。
通信は正常なのに設備が動かない主な6つの原因
明確な通信エラーがない場合は、通信経路だけでなく、信号の渡し方・処理タイミング・受信後の条件まで確認します。
原因1｜要求と応答のハンドシェイクがない
一方的に要求信号を送るだけでは、相手側が確実に受信したか判断できません。
重要な動作要求では、次のように要求と応答を確認します。
要求ON
→ 相手が要求を確認
→ ACK（応答）ON
→ 要求OFF
→ ACK OFF
ここでは、ACKを「相手が要求を受理したことを知らせる信号」として説明しています。実際にACKが何を表すかは設備の仕様によって異なり、処理完了を表すとは限りません。受理と完了を別の信号で扱う設備では、送信側がどちらを待っているかを確認してください。上の流れは受け渡しの一例です。
確認したいポイントは次のとおりです。
- 相手が認識するまで要求を保持しているか
- ACKを確認してから要求を解除しているか
- 同じ要求を二重に処理する可能性がないか
- 異常復帰時に要求とACKを初期化しているか
すべての信号に複雑なハンドシェイクが必要なわけではありませんが、取りこぼすと設備停止や誤動作につながる信号では、応答確認を検討します。
原因2｜信号の保持時間が短い
1スキャンや数スキャンだけONする信号は、次の通信更新より前にOFFすると、受信側へON状態が反映されない場合があります。
送信側で信号ON
→ 通信更新前に信号OFF
→ 受信側にはOFFだけが反映される
この問題はタイミングが重なったときだけ発生し、「数十回に1回」のような再現性の低い不具合になることがあります。
確認する項目は次のとおりです。
- 信号が何ms・何スキャンONしているか
- 通信データの更新周期
- 受信側で実際にONを確認できているか
- ACKを使った受け渡しに変更できるか
タイマーで保持時間を延ばすだけでは、通信周期や処理時間の変動によって再発する可能性があります。重要な要求信号では、相手の受信確認を取る方法が安定しやすくなります。
原因3｜通信周期・PLCスキャン・処理周期がずれている
PLCプログラムのスキャン周期と、通信データの更新周期は必ずしも一致しません。
設備が動作するまでには、
送信側PLCの処理
→ 通信データの更新
→ 受信側PLCの処理
→ 条件判定
→ 実際の出力
という複数の処理があります。
「通信周期が10msだから、10ms以内に設備が動く」とは限りません。
送信側と受信側の信号を両方監視し、どの段階から時間差が発生しているかを確認します。
原因4｜相手側の処理や条件成立を待っている
要求が受信側へ届いていても、相手側がすぐに応答できるとは限りません。
例えば、次のような処理待ちがあります。
- インターロックの成立待ち
- ロボットの動作完了待ち
- 画像処理の判定待ち
- バーコード・RFIDの読み取り待ち
- 上位システムからの応答待ち
- 相手PLC内部の演算・工程完了待ち
要求が相手側ですぐ認識されているのに応答が遅い場合は、通信経路よりも受信後の処理を確認します。
原因5｜タイムアウトや条件式が厳しすぎる
通信・PLCスキャン・相手側処理の時間が重なると、正常時でも応答時間にばらつきが出ます。
確認する項目は次のとおりです。
- タイムアウト値の根拠
- 正常時の応答時間とばらつき
- 通信周期とPLCスキャン
- 相手側の処理時間
- どの条件が成立せず停止したか
タイムアウトを長くしすぎると、本当の異常を検出するまで時間がかかります。正常時の処理時間を測定したうえで設定することが重要です。
また、複数の通信データが同時に更新される前提で条件を組んでいる場合、わずかな反映差によって条件が成立しないこともあります。
原因6｜ネットワークや通信設定に問題がある
通信そのものは成立していても、ネットワーク負荷や物理的な問題によって更新時間がばらつく場合があります。
- IPアドレス・通信パラメータ
- 通信周期・更新周期
- 接続数・通信負荷
- ケーブル・コネクタ
- スイッチングハブ
- ノイズ・接地
- タイムアウト・再送設定
- 通信ユニットの診断情報
を確認します。
明確なエラーコードや診断情報が出ている場合は、使用しているPLC・通信ユニットのメーカー公式マニュアルを確認してください。
一方、診断上は正常なのに設備動作だけがおかしい場合は、通信設定だけを追い続けず、ハンドシェイク・信号保持時間・相手側処理まで確認範囲を広げます。
実務で使える切り分け手順
PLC通信に関係しそうな動作不具合が発生したときは、最初から「通信が悪い」と決めつけず、処理を区間ごとに分けて確認します。
| 手順 | 確認すること | 判断のポイント |
|---|---|---|
| 1 | PLC・通信ユニット・相手機器のエラー | 明確なエラーがあれば、先に通信そのものを正常化する |
| 2 | 送信データと受信データ | 送信した値が相手側へ正しく反映されているか |
| 3 | 要求から完了までの各時点 | どの区間から遅れや停止が発生しているか |
| 4 | 要求とACKのハンドシェイク | 相手の受信確認前に要求をOFFしていないか |
| 5 | 受信側の条件・内部処理 | インターロックや周辺機器の完了待ちがないか |
| 6 | 通信周期・スキャン・タイムアウト | 実際の処理時間と設定値が合っているか |
| 7 | 発生時のログ | 再現しにくい不具合の状態を後から比較できるか |
具体的には、次の順番で確認します。
通信エラーの有無
↓
データが相手まで届いているか
↓
どの区間から遅れているか
↓
要求と応答のハンドシェイク
↓
相手側の条件・内部処理
↓
通信周期・スキャン・タイムアウト
↓
再現しにくい場合はログを残す
データが届いているかを両側で確認する
ON・OFF信号だけでは変化を追いにくい場合は、既存のカウンタなど、連続して変化する送受信データを両側で確認します。値が継続して更新されているか、同じデータを監視しているか、正常時と異常時で更新の様子が違うかを調べます。
ただし、周期的に現在値を転送する構成では、受信側が途中の値をすべて観測するとは限りません。モニタ画面で値が飛んだように見えても、それだけで通信データの欠落とは判断できません。また、数値が動いていても、すべての信号が必要なタイミングで届くことの証明にはなりません。
送信側の更新周期、通信方式、受信側の処理、画面やログの収集間隔を踏まえて判断します。新たな確認用データを追加する場合は、設備動作への影響を確認し、定められた変更手順に従ってください。
要求から完了までを分解する
「要求から完了まで500msかかった」という結果だけでは、通信が遅いのか、相手側処理が遅いのか判断できません。
次のように処理を分けて確認します。
送信側が要求を出す
→ 受信側が要求を認識する
→ 受信側が条件を判定する
→ 処理を実行する
→ 完了信号を返す
→ 送信側が完了を認識する
受信側が要求をすぐ認識しているのに完了が遅い場合は、通信よりも受信後の処理を疑います。
反対に、要求が受信側へ反映されるまで時間がかかる場合は、通信周期・ネットワーク・通信設定などを確認します。
時間差を比較するときは、画面の更新間隔やログの収集間隔も確認します。別々のPLCで記録した時刻は、時計がそろっていなければそのまま差し引けません。必要な時間分解能に合った記録方法を使い、比較できる条件で正常時と異常時を確認してください。
再現しにくい場合は状態を記録する
数十回、数百回に1回しか発生しない場合は、次の情報を記録できるようにします。
- 要求・ACKの状態
- カウンタや通信データ
- 発生時刻
- 相手側の処理状態
- インターロック
- 異常発生前後の状態
勘でプログラムや設定を変更する前に、異常が発生した瞬間に何が起きていたかを残すことが重要です。
明確なエラーコードや診断情報がある場合は、使用しているPLC・通信ユニットのメーカー公式マニュアルも確認してください。
実例｜通信状態と処理待ちをどう切り分けたか
通信に関係する動作不具合では、「通信そのものが遅いのか」「通信後の処理に時間がかかっているのか」が分かりにくいことがあります。
実務で経験した一例では、PLC間通信を使った設備で動作遅延があり、通信状態が悪いのか、相手PLC側の処理待ちなのかを切り分ける必要がありました。
通信状態を数値の変化で確認する
ON・OFF信号だけを見ても、通信が正常に更新されているか判断しにくい場合があります。
そこで、送信側PLCで一定周期ごとに数値をインクリメントし、その値をPLC間通信で相手側へ送信しました。
送信側と受信側の両方で数値を監視し、
- 数値が継続して更新されているか
- 送受信データの更新の様子に異常がないか
- 大きな遅れが発生していないか
を確認しました。
その結果、送信側と受信側で数値が正常に追従していたため、少なくとも確認した範囲では、通信経路そのものに大きな問題がある可能性は低いと判断できました。
通信が正常なら次の処理を疑う
通信状態に問題が見られない場合は、その後の処理を確認します。
例えば、
- 受信したデータを使う条件
- 相手PLC内部の処理
- インターロック
- 処理完了待ち
- 要求とACKのタイミング
などです。
このように、通信に関係しそうな不具合でも、いきなり通信設定を変更するのではなく、まず「送ったデータが正常に相手へ届いているか」を確認すると原因候補を減らせます。
今回の方法はあくまで一例ですが、連続して変化する数値やカウンタを利用すると、単純なON・OFF信号より通信状態を追いやすい場合があります。
重要なのは、通信が正常かどうかを感覚で判断するのではなく、送信側と受信側の両方で確認できるデータを使って切り分けることです。
よくある質問
通信エラーが出ていなければ通信は正常と考えていいですか？
必ずしもそうとは限りません。
PLCや通信ユニットに明確なエラーが出ていなくても、通信更新周期や信号保持時間、ハンドシェイク、相手側の処理時間などによって設備動作に不具合が出ることがあります。
エラーの有無だけで判断せず、送信したデータが相手側へどのように反映されているかまで確認することが重要です。
通信遅延か相手PLCの処理遅延かはどう切り分ければいいですか？
要求を出してから完了するまでを一つの時間として見るのではなく、
- 送信側が要求を出した時点
- 受信側が要求を認識した時点
- 相手側で処理を開始した時点
- 処理が完了した時点
- 応答が送信側へ戻った時点
に分けて確認します。
受信側で要求をすぐ認識しているのに応答が遅い場合は、通信より相手側の処理を疑いやすくなります。
逆に、要求が相手側へ反映されるまでに時間がかかっている場合は、通信周期やネットワーク設定などを確認します。
タイマで信号を長くすれば取りこぼしは防げますか？
信号保持時間を長くすることで改善する場合はあります。
ただし、通信周期や処理時間が変動すると再び取りこぼす可能性があるため、重要な信号では相手側の受信確認を取るハンドシェイク方式の方が安定しやすくなります。
単純にタイマを長くするだけでなく、なぜ取りこぼしているのかを確認したうえで対策を決めることが重要です。
まとめ
PLC通信に関係する設備不具合では、明確な通信エラーが出ていなくても、通信周期や信号の渡し方、相手側の処理時間などによって動作がおかしくなることがあります。
不具合が発生したときは、最初から「通信が悪い」と決めつけず、
- PLCや通信ユニットに明確なエラーがないか
- 送信したデータが相手まで届いているか
- どの区間から遅れが発生しているか
- 要求とACKのハンドシェイクが適切か
- 信号保持時間が十分か
- 相手側の処理やインターロックに問題がないか
- 通信周期やタイムアウト設定が適切か
という順番で確認すると原因を絞り込みやすくなります。
特に再現性の低い不具合では、正常時と異常時の状態を比較できるように、カウンタやログなどを残すことも有効です。
通信不具合の切り分けでは、設定値やエラーコードだけを見るのではなく、要求を送ってから設備が実際に動くまでの処理を区間ごとに分けて考えることが重要です。
通信・PLC・相手側処理を一つずつ切り分けることで、原因が分からないままプログラムや通信設定を変更することも減らせます。
通信だけでなく、センサー入力、PLC条件、出力、アクチュエータ、機械動作まで設備全体を確認する順序は「設備が動かないときの原因切り分け手順」で整理しています。
PLC経験を転職でどう評価されるか知りたい方は、「PLC経験は転職で評価される？設備・制御エンジニアの強みになるスキルを解説」も参考にしてください。
次に読みたい記事
PLC通信の切り分けができるようになったら、周辺技術やキャリアへの活かし方も確認しておきましょう。
PLC・制御設計の今後を知りたい方
「PLC制御設計は今後どう変わる？AI・Virtual PLC・ソフトウェア化の最新動向を解説」
トラブル対応経験を転職で活かしたい方
「PLC経験は転職で評価される？設備・制御エンジニアの強みになるスキルを解説」
参考資料
- 三菱電機：CC-Link IE仕様・サイクリック伝送（更新と伝送の仕組みの参考）
- 三菱電機：MELSEC iQ-F データロギング機能（対応機種での記録機能の例）
上記は個別のネットワーク・製品の資料です。使用しているPLCや通信方式の動作・設定は、該当機種のマニュアルで確認してください。
