再起動は約3分。それでもRaspberry PiをESP32へ替えた

止まったことに気づくまで、ショットは記録されなかった

プレス機は動いていました。NAS上のNode-REDも、ぼくが見るダッシュボードも動いています。それなのに、加工数だけが増えませんでした。

止まっていたのは、プレス機の裏で電源状態とショットを取得していたRaspberry Piです。Raspberry PiがフリーズするとMQTTの信号がNASへ届かず、カウントが更新されません。

ぼくがリアルタイムのダッシュボードを見て、「あれ、おかしいな」と気づくことがありました。作業者が加工完了を送信するとき、カウンターがゼロのままなのを見て、「これ、ゼロのままですよ」と教えてくれることもありました。

復旧作業は難しくありません。コンセントを抜いて挿し直せば、Raspberry PiとNode-REDが起動し、信号送信も再開します。気づいてからなら約3分でした。

問題は、その3分ではありません。止まっていることに気づくまでの時間です。その間に加工したショットは、全く記録されませんでした。

当時は12台のプレス機すべてにRaspberry Pi 3 Model A+を付けていました。OSは32ビットのレガシー版Raspberry Pi OS Liteです。GUIのないヘッドレス構成で、最初は各Raspberry Pi上でNode-REDも動かしていました。

プレス機から取っていた信号は二つだけです。

配線は、コモンを含めて3本です。

Raspberry Piは小さなパソコンです。本来はシャットダウンしてから電源を切るものだという認識があったため、基本的に電源を入れたまま運用していました。

最初の1〜2年は、大きなトラブルなく動いていました。ところが、少しずつフリーズする個体が増えました。安定していた個体は最後まで安定していましたが、よく凍る個体は何度も凍りました。ぼくの感覚では、最終的に1週間に1回ほど、どこかの機械側端末が止まっていました。

大半は電源の抜き差しで戻りました。ただ、1〜2回は起動できなくなり、OSを最初から書き込み、プログラムを入れ直しました。

原因は分かっていません。停電や突然の電源断、microSDへの書き込み、SDカードの品質や寿命、Raspberry Piの個体差、プレス機周辺の高周波や電気的な影響。いくつかの可能性は考えましたが、どれも原因として確認したものではありません。

読み取り専用化、ログの抑制、watchdog、UPSなど、Raspberry Pi側で対策する方法もあったと思います。ただ、原因の分からないものへ対策を重ねるより、信号取得と送信だけに役割を絞った端末へ替える方が自然だと考えました。

2024年2月には、Node-REDの処理をNAS側へ集約していました。機械側に必要なのは、電源ON/OFFとショットを取得し、MQTTで送ることだけです。

そこで使ったのが、ESP32-DevKitC-VEです。ESP32-WROVER-Eを搭載した8MBの開発ボードへ、2系統の信号とコモンを含む3本をつなぎました。

MQTTのトピックとデータ形式はRaspberry Pi時代と同じです。そのため、NAS側のNode-REDは変更していません。機械側の入口だけを、Raspberry PiからESP32へ交換しました。

ESP32は、停電後に電源が戻ると、Wi-Fiへつながり、MQTTへ接続し、二つの信号取得まで人の操作なしで再開します。約1年少し使った現在、ぼくの記憶では、ESP32端末自体がトラブルで止まったことはありません。

ただし、Raspberry PiとESP32の故障率、記録欠損件数、保守時間を比較して計測したわけではありません。ESP32を2年、3年と使った結果もまだありません。ESP32なら必ず安定するという話ではありません。

一番大きく変わったのは、ぼくの頭の中でした。Raspberry Piの頃は、「また凍るかもしれへんな」「電源が落ちたらどうしようかな」という心配が絶えずありました。

ESP32へ替えてからは、その心配自体を忘れています。実際に止まっていたことがあれば、電源が抜けているなど、端末以外の理由でした。

止まらないことは、便利な追加機能ではありません。稼働状況を記録する仕組みのスタートラインです。

現場端末は、できることの多さや新しさだけでは選べません。工場全体の電源が一度落ちた後、誰も見に行かず、Wi-Fi、通信、信号取得まで元の仕事へ戻るか。自社の端末では、どこまで自動で戻るか確認できていますか。