PLCスキャンタイムとは？応答遅れと短縮方法

「入力が入ったはずなのに、出力が一瞬遅れて動く。」

PLC制御では、このわずかな遅れがタクトずれ、検出抜け、位置決め不良の原因になることがあります。

この遅れを理解するうえで重要なのが、PLCが処理を一周する時間であるスキャンタイムです。

スキャンタイムは単なるCPU性能の数値ではなく、入力更新、プログラム実行、出力更新、通信処理が積み重なった結果です。

本記事では、PLCスキャンタイムの仕組み、応答遅れの考え方、短縮方法、実務での確認ポイントを解説します。

1. PLCスキャンタイムとは：PLCが処理を一周する時間

PLCスキャンタイムとは、PLCが入力を読み取り、プログラムを実行し、出力を更新する一連の処理を一周する時間です。

一般にはサイクルタイム、スキャン周期、実行周期などと呼ばれることもあります。

PLCは入力が変化した瞬間に、すべての出力を即座に変えるわけではありません。

多くのPLCは、入力更新、演算処理、出力更新を一定の流れで繰り返しています。

そのため、同じプログラムでもスキャンタイムが長いと、入力変化から出力反応までの遅れも大きくなります。

ただし、スキャンタイムは応答時間そのものではありません。

応答時間は、入力機器、PLC内部処理、出力機器、負荷側の反応まで含めた総合的な遅れです。

スキャンタイムの基本イメージ

PLCの処理は、工場の巡回点検に似ています。

担当者が各設備を順番に見回り、状態を確認し、判断し、操作指示を出す流れです。

見回りの直後に異常が起きると、次の巡回まで発見が遅れます。

PLCでも同じで、入力更新の直後に信号が変化すると、次の入力更新まで反映されません。

この「次の巡回まで待つ時間」が、スキャン方式の応答遅れを考える出発点です。

スキャンタイムと制御周期の違い

スキャンタイムは、実際にPLCが一周処理するのにかかった時間です。

一方、制御周期は、制御処理を何msごとに実行したいかという設計上の周期です。

例えば10ms周期で制御したい場合、実スキャンタイムが12msに伸びると周期制御は破綻します。

特にPID制御や位置決め制御では、周期のばらつきが制御性能に直結します。

スキャンタイムは短ければよいだけでなく、安定していることも重要です。

周期変動が制御応答へ与える影響を深く見る場合は、周波数応答の考え方も役立ちます。

2. PLCの基本処理：入力更新から出力更新まで

PLCのスキャンは、メーカーや機種により細部は異なります。

しかし、基本的な流れは入力更新、プログラム実行、出力更新、通信やシステム処理に分けて考えられます。

この分解ができると、応答遅れの原因を感覚ではなく工程別に切り分けられます。

処理段階	内容	遅れへの影響
入力更新	入力ユニットや通信I/Oの状態をPLC内部に取り込む	信号変化を拾うタイミングを決める
プログラム実行	ラダー、ST、FBなどの制御ロジックを実行する	命令数や演算量で時間が増減する
出力更新	内部演算結果を出力ユニットへ反映する	負荷を動かす開始タイミングを決める
通信処理	HMI、リモートI/O、上位システムとデータをやり取りする	通信量が多いと周期が伸びる場合がある
システム処理	診断、監視、ログ、内部管理などを行う	CPU負荷や設定により変動する

① 入力更新：現場信号を内部メモリに写す

入力更新では、センサ、スイッチ、リミット信号などの状態をPLC内部のI/Oメモリに取り込みます。

PLCはこの内部メモリを見てプログラムを実行するため、入力更新前の変化はまだ判断材料になりません。

高速に変化するパルスや短いON信号は、このタイミングの影響を受けやすくなります。

センサ信号をアナログ値として扱う場合は、A/D変換やフィルタ処理の遅れも加わります。

入力が遅いのか、PLCが遅いのかを切り分けるには、まず入力更新の仕組みを見る必要があります。

② プログラム実行：ラダーやFBを順番に処理する

プログラム実行では、入力情報をもとに内部リレー、タイマ、カウンタ、演算命令などを処理します。

シーケンス制御では、見た目は同時に動いているようでも、PLC内部では命令が順番に評価されます。

命令数が多いほど、また複雑な演算や配列処理が多いほど、プログラム実行時間は長くなります。

同じラダーでも、接点条件の整理や処理ブロックの分割によってスキャンタイムは変わります。

特に生産設備では、後から機能追加を重ねたプログラムがスキャンタイム増大の原因になりやすいです。

③ 出力更新：演算結果を現場へ反映する

出力更新では、プログラム実行で決まった結果を出力ユニットや通信I/Oへ反映します。

リレー出力、トランジスタ出力、ソレノイド、インバータ指令などは、この段階で現場側へ伝わります。

ただし、PLCが出力を更新しても、負荷側がすぐ動くとは限りません。

電磁弁、リレー、モータドライバには、それぞれ固有の動作遅れがあります。

現場で見える応答遅れは、PLCスキャンタイムと機器固有の遅れが合成されたものです。

3. スキャンタイムの計算式：どこで時間が増えるのか

スキャンタイムは、PLC内部で発生する複数の処理時間を合計して考えると理解しやすくなります。

厳密な値は機種や設定で変わりますが、実務上は次のように分解できます。

この式は、PLCが一周する時間を構成要素に分けて見るための考え方です。

カタログ値だけでなく、実機のモニタ値や診断情報で確認することが重要です。

記号	意味	増えやすい原因
	入力更新時間	入力点数増加、リモートI/O、フィルタ設定
	プログラム実行時間	命令数増加、演算処理、ループ、FB多用
	出力更新時間	出力点数増加、通信出力、特殊ユニット
	通信処理時間	HMI更新、上位通信、ログ収集、周期通信
	システム処理時間	診断、内部管理、CPU負荷、設定条件

命令実行時間だけでは判断できない

PLCのカタログには、基本命令の実行時間が記載されることがあります。

しかし、基本命令が高速でも、実スキャンタイムが必ず短くなるとは限りません。

実際には、通信処理、特殊ユニット、HMI更新、データロギングが大きく効くことがあります。

そのため、命令実行速度だけを見てPLCを選定すると、現場で期待した応答が出ない場合があります。

スキャンタイムは、CPU性能とシステム構成の両方で決まると考えるべきです。

平均値より最大値を見る

スキャンタイムは常に一定ではなく、通信量や割り込み処理によって変動する場合があります。

監視画面に表示される平均スキャンだけを見ると、瞬間的な遅れを見落とすことがあります。

実務では、現在値、平均値、最大値、周期ばらつきをセットで確認します。

最大値が大きい場合、通常運転では問題なく見えても、特定操作時だけ遅れる可能性があります。

設備停止や段取り替えのタイミングで通信やログ処理が集中する場合は特に注意が必要です。

4. 応答遅れの考え方：最悪ケースは1スキャン以上遅れる

PLCの応答遅れは、スキャンタイムと同じ値ではありません。

入力信号が入るタイミングによって、次の入力更新まで待たされる時間が変わるためです。

最も悪いケースでは、入力が入力更新の直後に変化します。

この場合、PLCは次の入力更新までその変化に気づきません。

さらにプログラム実行、出力更新、出力機器の反応時間が加わります。

ここで、 は入力更新までの待ち時間です。

入力の発生タイミングによって、ほぼゼロから最大で約1スキャン分まで変わります。

平均応答と最悪応答を分けて考える

平均的には、入力更新までの待ち時間はスキャンタイムの半分程度と見なせます。

しかし、安全や検出抜けを考える場合は、平均ではなく最悪ケースで評価します。

例えばスキャンタイムが20msなら、入力更新待ちだけで最大20ms程度発生します。

さらに出力ユニットやソレノイドの遅れが加わるため、実機応答はもっと遅くなります。

高速搬送や短時間ワーク検出では、この差が不良の原因になります。

短い信号は見逃されることがある

入力信号がスキャンタイムより短い場合、PLCがそのON状態を拾えないことがあります。

例えばスキャンタイムが15msで、センサONが5msだけなら、更新タイミング次第で見逃されます。

このような用途では、通常スキャンではなく高速入力、ラッチ入力、割り込み処理を検討します。

エンコーダパルスやワーク通過信号では、信号幅と入力フィルタ設定も同時に確認します。

見逃し対策は、プログラムだけでなく入力回路とセンサ選定まで含めて考える必要があります。

出力側の応答遅れも無視できない

PLCの出力がONになっても、実際の機械動作には出力機器の遅れが加わります。

リレー出力は機械接点の動作時間があり、電磁弁には吸引時間やエア応答があります。

モータやシリンダを動かす場合は、駆動側の加速時間や機械慣性も効きます。

そのため、スキャンタイムだけ短縮しても、現場の応答が改善しないことがあります。

遅れの大きい要素を順番に分解して、最も効く対策から実施するのが基本です。

5. スキャンタイムが長くなる原因：プログラムだけが犯人ではない

スキャンタイムが長いと聞くと、まずラダーの命令数を疑いがちです。

もちろんプログラム量は重要ですが、実際には通信、I/O構成、特殊ユニット、監視処理も影響します。

現場では、後付けした機能や見える化システムが遅れの原因になることもあります。

原因	起きること	確認ポイント
命令数が多い	プログラム実行時間が増える	使用命令数、FB数、演算処理
ループ処理が重い	特定条件で急に処理時間が伸びる	FOR文、配列検索、全点スキャン
通信が多い	HMIや上位通信で周期がばらつく	通信周期、タグ数、更新レート
リモートI/Oが多い	入力出力の反映に通信遅れが加わる	ネットワーク周期、局数、異常時再送
アナログ処理が多い	変換やフィルタで遅れが増える	移動平均、ローパス、変換周期
ログ収集が重い	一定周期でCPU負荷が跳ねる	保存周期、ファイル書込、上位収集

通信負荷：HMIと上位連携の影響

HMIの画面点数が増えると、PLCから読み出されるデータ量も増えます。

画面更新を速くしすぎると、PLC側の通信処理が増え、スキャンに影響する場合があります。

設備データを上位へ渡す場合は、イベント駆動か周期収集かでも負荷が変わります。

必要のないタグまで高頻度で読みにいく設計は、制御周期を乱す原因になります。

監視用データと制御用データは、優先度を分けて設計することが重要です。

リモートI/O：便利さと遅れのトレードオフ

リモートI/Oを使うと盤間配線を減らせますが、I/O更新は通信周期の影響を受けます。

本体I/Oと同じ感覚で高速信号を扱うと、検出遅れや入力抜けが起きる場合があります。

リモートI/Oの応答は、PLCスキャンタイムだけでなくネットワーク更新周期も含めて考えます。

特に安全停止、位置決め開始、ワーク通過検出などは、どのI/Oに接続するかが重要です。

高速が必要な信号は、専用高速入力や本体近傍のI/Oへ割り当てる方が安全です。

アナログ入力：フィルタ設定が遅れを作る

アナログ入力では、ノイズを抑えるために平均化やフィルタを設定することがあります。

フィルタを強くすると値は安定しますが、変化への追従は遅くなります。

温度や圧力のようにゆっくり変わる信号なら問題になりにくいです。

一方、張力、速度、位置補正などの速い制御では、フィルタ遅れが制御性能を落とします。

ノイズ対策と応答性はトレードオフなので、用途ごとに設定を分ける必要があります。

6. スキャンタイムを短縮する方法：効果が大きい順に対策する

スキャンタイム短縮は、やみくもに命令を削る作業ではありません。

まず現在値と最大値を測り、どの要素が支配的かを特定します。

そのうえで、制御に必要な処理と監視用の処理を分けると効果が出やすくなります。

① プログラムを整理する

条件分岐の重複、使われていない内部リレー、不要な演算を整理します。

同じ条件判定を複数箇所で繰り返している場合は、共通の中間フラグへまとめると見通しも良くなります。

配列全体を毎スキャン検索する処理は、必要なタイミングだけ実行するように変更します。

常時実行が必要な処理と、段取り時だけ必要な処理を分離することも有効です。

短縮と同時に保守性を落とさないよう、コメントやブロック構成は維持しましょう。

② 高速処理と通常処理を分ける

すべての処理を同じスキャンで実行すると、高速応答が必要な部分まで影響を受けます。

高速入力、割り込みタスク、定周期タスクを使い、必要な処理だけを高優先で実行します。

ただし、高速タスクに多くの処理を入れすぎると、通常タスクが遅れて全体が不安定になります。

高速タスクには、入力取り込み、ラッチ、最小限の判定だけを置くのが基本です。

重い演算や画面更新は、通常周期や低優先周期へ逃がします。

③ 通信周期と画面更新を見直す

HMIや上位システムの全タグを高頻度で更新する必要はありません。

操作に必要な現在値、警報、インターロック条件は優先して更新します。

履歴表示、集計値、保全用データは、更新周期を長めにしても実害が少ない場合があります。

通信タグ数を減らし、画面ごとに必要なデータだけを読む設計にすると負荷を下げられます。

制御用通信と見える化用通信を同じ感覚で扱わないことが大切です。

④ I/O割り当てを見直す

高速で拾うべき信号は、本体I/Oや高速入力ユニットへ割り当てます。

低速でよい信号はリモートI/Oや通信入力でも問題ない場合があります。

入力信号の重要度を、停止、安全、品質、監視に分けると設計判断がしやすくなります。

PWM制御のように周期やデューティが関係する処理では、通常スキャンで扱うべきか専用機能を使うべきかを確認します。

PLC本体の負荷だけでなく、I/Oユニット側の機能も活用することが短縮につながります。

7. 実務での確認方法：モニタ値と現場波形を両方見る

スキャンタイムの確認は、PLCソフトのモニタ値だけで完結しません。

PLC内部では問題なく見えても、現場信号の波形や出力機器の反応に遅れがある場合があります。

実務では、PLCの診断値、入出力モニタ、オシロスコープ、実機動作を組み合わせて確認します。

PLCソフトで現在値・最大値を確認する

多くのPLC開発ソフトには、スキャンタイムの現在値や最大値を確認する機能があります。

まずは通常運転、段取り替え、異常発生時、画面操作時の値を比較します。

最大値だけが大きい場合は、特定イベントで重い処理が走っている可能性があります。

平均値が高い場合は、常時実行されている処理そのものを見直す必要があります。

値を一度だけ見るのではなく、運転条件ごとに記録して比較することが重要です。

出力トグルで実測する

PLC内部の特定箇所で出力を反転させ、外部計測器で周期を測る方法もあります。

例えば毎スキャンで補助出力をON/OFFさせると、波形から周期のばらつきが見えます。

ただし、実設備の出力を不用意に使うと誤動作につながるため、検証専用の出力やシミュレーションで行います。

実測値は、PLCソフトの表示値と一致しない場合があります。

その差は、出力更新、ユニット応答、計測方法の影響として切り分けます。

入力信号の幅を確認する

検出抜けが疑われる場合は、PLC側だけでなくセンサ信号そのものを確認します。

ワーク通過時のON時間、チャタリング、ノイズ、入力フィルタ設定を測定します。

PLCスキャンタイムより十分長い信号なら、通常入力でも安定して拾いやすくなります。

一方、信号幅が短い場合は、センサ位置、検出距離、ワーク速度の見直しが必要です。

プログラム変更だけで解決しようとせず、機械条件と電気条件を同時に確認します。

応答遅れを工程別に分解する

応答遅れは、入力、PLC、出力、機械動作に分けて測ると原因が見えます。

例えば入力信号が遅いのか、PLC判断が遅いのか、ソレノイドの動作が遅いのかを分けます。

この分解をしないままスキャンタイムだけ短縮しても、改善しないことがあります。

特にエア機器やモータ駆動では、機械側の遅れが支配的な場合も多いです。

電気制御と機械動作を合わせて見ることが、実務でのトラブル解決に直結します。

関連記事

instant.engineer

8. 設計上の注意点：短ければ短いほど良いとは限らない

スキャンタイムは短いほど応答性には有利です。

しかし、無理に短くしすぎると、CPU負荷、通信負荷、保守性の面で問題が出ることがあります。

重要なのは、必要な応答時間に対して十分な余裕があるかどうかです。

高速処理が必要な部分だけを速くし、通常処理は読みやすく保守しやすい構成にするのが理想です。

品質に効く信号を優先する

すべての入力を同じ重要度で扱う必要はありません。

ワーク位置、異常検出、停止条件、品質判定に関わる信号は優先度が高いです。

一方、表示用ランプ、稼働時間、保全カウンタなどは数百ms単位でも問題ない場合があります。

優先度を分けることで、スキャンタイム短縮と保守性を両立できます。

何を速くするかを決めないまま全体最適を狙うと、設計が複雑になりやすいです。

可読性を犠牲にしすぎない

スキャンタイム短縮のために、処理を極端に詰め込むと保守性が下がります。

後から別の担当者が見たとき、条件の意味が追えないプログラムはトラブル復旧を遅らせます。

高速化よりも、異常時に短時間で原因を追えることが重要な設備もあります。

短縮する処理と、読みやすく残す処理を分ける判断が必要です。

保守担当者が現場で安全に扱える構造にしておくことも、制御設計の一部です。

排他処理や待ち条件に注意する

複数の処理が同じデータや装置を扱う場合、排他や待ち条件が必要になることがあります。

ただし、排他制御の設計が悪いと、待ち時間やデッドロックが応答遅れの原因になります。

特に通信データ、バッファ、レシピ切替、ログ処理は、制御処理と衝突しやすい領域です。

待ち条件を入れる場合は、タイムアウトと異常処理を必ず設計します。

待ち続けるプログラムは、スキャンタイム以前に設備停止のリスクになります。

9. PLCスキャンタイム短縮のチェックリスト

スキャンタイム短縮は、現場で一つずつ潰していく作業です。

次のチェックリストを使うと、プログラム、通信、I/O、機械側の切り分けがしやすくなります。

確認項目	見るポイント	対策例
現在スキャン	通常運転時の平均値	目標応答に対して余裕を確認する
最大スキャン	段取り替えや通信集中時のピーク	ピーク時だけ走る処理を分離する
入力信号幅	センサON時間と入力フィルタ	高速入力やラッチを使う
プログラム量	常時実行される命令やFB	不要処理を削除し条件実行にする
通信タグ数	HMIや上位との読出点数	更新周期を分ける
アナログ処理	平均化やフィルタ設定	応答性と安定性を用途別に調整する
出力機器	リレー、電磁弁、ドライバの遅れ	機器応答を測定し支配要因を特定する
保守性	短縮後も読みやすいか	コメントとブロック構成を維持する

まず測定し、次に分解する

最初にやるべきことは、感覚で遅いと判断することではありません。

現在値、最大値、信号幅、出力応答を測定し、遅れの位置を明確にします。

PLC内部が遅いのか、入力が短いのか、出力機器が遅いのかで対策は変わります。

測定せずにプログラムだけ触ると、改善しないまま保守性だけ悪くなることがあります。

制御トラブルでは、現象を時間軸で並べることが最も有効です。

改善後は異常時も確認する

短縮後は、通常運転だけでなく異常時や通信異常時も確認します。

正常時は速くなっても、異常処理でスキャンが跳ねる場合があります。

アラーム発生、通信断、データ保存、手動操作、非常停止後の復帰などを確認します。

量産設備では、まれにしか起きない状態こそ復旧時間に影響します。

改善後の最大スキャンと応答遅れを記録し、設計変更の根拠として残しておきましょう。

関連記事

instant.engineer

10. まとめ

PLCスキャンタイムは、PLCが入力更新、プログラム実行、出力更新を一周する時間です。

応答遅れはスキャンタイムだけで決まらず、入力更新待ち、出力機器、通信、機械動作も含めて決まります。

最悪ケースでは、入力変化が次のスキャンまで拾われず、1スキャン以上の遅れになることがあります。

短い入力信号や高速搬送では、通常入力だけでなく高速入力や割り込み処理の検討が必要です。

スキャンタイムが長い原因は、プログラム量だけでなく通信負荷、リモートI/O、アナログ処理にもあります。

短縮するときは、まず現在値と最大値を測定し、遅れを工程別に分解しましょう。

PLC全体の基本や、制御ロジックの考え方を合わせて確認すると理解しやすくなります。