　
PLC の新人がやらかすミスは無数にある。
ただ、その中で私が実際に見たことのある 3つを紹介する。

・LDP を羅列してしまう
・微分結果を 2 重微分してしまう
・同じ条件を “念のため” 重ねてしまう

これらはまったく別の原因から生まれるミスやけど、
どれも “新人が最初に必ず踏む地雷” という共通点がある。

この記事では、
「なぜそのミスが起きるのか」を
コードと文化の両面から解説する。

第1章：LDP を羅列してしまう問題

■ 新人が実際にやるコード

（R000の微分で行う処理が100行近くあった…）

LDP R000
処理A

LDP R000
処理B

LDP R000
処理C

LDP R000
 ︙
 ︙

■ ここが落とし穴

LDP は LD より重い命令

・内部で「前回値」を保持するため内部メモリを消費
・比較処理＋前回値更新が入るため実行コストも高い

新人はこれを知らず、
“軽い条件文” のように連打してしまう。

結果として：

・内部メモリが無駄に増える
・スキャン時間が伸びる
・可読性も落ちる

■ 正しい書き方

LDP R000
OUT MR000

LD  MR000
処理A

LD  MR000
処理B

LD  MR000
処理C

LD  MR000
 ︙
 ︙

・微分は 1回だけ
・以降は軽い LD で参照
・コスト最適化 × 安定性 × 可読性

■ まとめ

LDP は “乱用すると死ぬ命令”。
必要なときだけ 1 回だけ使う。

第2章：タイマの 2 重微分問題

■ 新人が実際にやるコード

（微分型のクロックが必要だった…）

LDB T0
TMR #0 #555

LD T0
DIFU MR000 ;  ← “微分結果“ の微分

LD MR000
微分処理・・・

■ ここが落とし穴

・タイマは設定時間に達した瞬間だけ ON（1スキャンだけ）
・次のスキャンで自動的に OFF
→ つまり自然に微分している

新人はこれを知らず、
“タイマの立ち上がりも DIFU で取るんやろ” と考えてしまう。
　
その結果：

・自然微分 + DIFU = 2 重微分

■ 正しい書き方

LDB T0
TMR #0 #555

LD T0
微分処理・・・

■ まとめ

自然微分を知らずに DIFU を置くと地獄？を見る。

【余談：ｻﾝﾌﾟﾙｺｰﾄﾞのﾀｲﾏ値 555 の話】


……で、タイマの置き値が 555 になってる理由やけど。

別に深い意味はない。  
ただ、現場の人間は 555 を見ると、  
昔触った NE555 の感触がふっと蘇るだけや。

あの頃の電子工作の匂いというか、  
“タイマと言えば 555” みたいな身体の記憶が残ってる。

だから 555 を置くと、なんか気持ちがいい。  
ただそれだけの話。

文化って、だいたいそんなもんや。（笑）

第3章：同じ条件を重ねてしまう問題（念のため癖）

■ 新人が実際にやるコード

LD R000 ;  ← “念のため”の重複
AND R001
AND R002
OUT MR000

LD R003
AND R004
OUT MR001

LD MR000
AND MR001
AND R000 ;  ← “念のため”の重複
SET R500

■ ここが落とし穴

・「条件が抜けたら怖い」という心理
・その結果、論理を二重化してしまう
・しかし実際には意味がないどころか、可読性を壊す

新人の頭の中はこう：
「R000 が抜けたら怖いし、念のためもう一回入れとこ」

でも現場文化ではこう：
論理は一度成立すれば十分。
重ねるのは“安心感”であって“意味”ではない。

■ まとめ

“不安”で書いたコードは、後で必ず自分を刺す。

第4章：3つのミスの本質はどこにあるのか

3つは “同じ原因” ではない。
それぞれ別の本質を持っている。

■ 共通点

「考えずに書く」ことが事故の原因。

技術者は破天荒であれ。

この記事が、必要な人へ。
困っている人に、届きますように。

作者
圓空（えんくう）
https://yenqoo.com/spices/
https://yenqoo.com/monologue/

キーエンスPLCを中心に、
“技術 × 美学 × 遊び心” をテーマにした技術文化を発信しています。