プレス機のカウントが変。信号を事務所に送って測った

「ESP32なら安心」と思っていたぼくが、信号を測り直した

プレス機は動いているのに、画面のショット数が増えない。ショットとは、プレスが一回打つことです。その回数を記録しているESP32で、同じ異変が続けて2日ほど起きました。再起動すると数え始めましたが、ESP32自体が固まったのか、通信が止まったのかは分かっていません。

以前、M5Stickを使ったときに不安定になり、Arduino IDEで作ったプログラムでも不安定でした。ESP-IDFという開発環境を使って、ようやく落ち着いた。ぼくはそこで、「ESP32をESP-IDFで動かせば、もう大丈夫」と思い込んでいました。

だから、今回カウントが止まったことは意外でした。電源を入れっぱなしの端末を、午前2時に自動で再起動させよう。そう考えてコードを見直しましたが、試すとうまくいきません。調べるうちに、今度は機械が止まっているのにショット数が増える、逆の異変が見つかりました。

パソコンを置けない場所で、何が起きているのか

プレス機の動きは、信号線を通じてESP32へ伝わります。今回の配線では、通常はHIGH、加工信号が入るとLOWへ切り替わります。それまでのESP32は、この切り替わりを見て「今、1ショットあった」と判断していました。

ただ、ESP32を取り付けた場所は狭く、機械のそばにパソコンを置いて信号を見続けるのは難しい。そこでAIと相談し、ESP32自身が入力の変化を調べて、その結果を事務所へ送る診断用コードを作りました。

いったんESP32を外し、事務所のパソコンでコードを書き込み、またプレス機へ取り付けます。診断結果は、短いメッセージを送るMQTTという通信方法で事務所側へ送り、Node-REDのログ画面で確認しました。送ったのは、信号が切り替わった回数や、LOWの状態がどれだけ続いたかを5秒ごとにまとめた情報です。

パソコンを現場へ持ち込めなくても、プレス機のそばでESP32が見ているものを事務所から確かめられました。

約0.3秒と、0.000007秒

プレス機を動かして測ると、加工時の長く続くLOWは、記録上302.934〜312.392ミリ秒でした。ミリ秒は1,000分の1秒なので、およそ0.3秒です。

一方、短いLOWの最短は7マイクロ秒。マイクロ秒は100万分の1秒なので、0.000007秒です。今回記録された約0.3秒の長い信号と比べると、4万倍以上の差があります。これはショットとショットの間隔ではなく、信号がLOWであり続けた長さの比較です。

なぜ、この差が大事なのか。それまでのコードは、信号がHIGHからLOWへ切り替わった瞬間に1ショットと数えていました。そして、その後600ミリ秒、つまり0.6秒の間に来た信号は数えない方式でした。

短い変動が先に入っても、切り替わった瞬間だけを見ればショットとして数えてしまう可能性があります。さらに、その直後に本物のショットが来れば、0.6秒の間引きで捨ててしまう可能性もあります。短い変動を数え、本物を数えない。そうなり得るコードでした。

「切り替わった」だけでは数えない

そこで、判定方法を変えました。ESP32の加工入力を10ミリ秒ごとに確認し、LOWが50ミリ秒続いたときだけ1ショットと数えます。50ミリ秒は0.05秒。今回測った加工時の長いLOWは最短でも約0.303秒なので、そこまで待っても信号は残っています。

LOWが続いている間は二重に数えません。いったんHIGHへ戻り、その状態が50ミリ秒続いてから、次のショットを受け付けます。一瞬の切り替わりではなく、続いた時間を見て数えるようにしたのです。

診断結果を見てからESP32をもう一度外し、対策したコードを書き込み、プレス機へ戻しました。稼働させると、ぼくが確認した範囲ではショットを正しく取れるようになりました。

最初に「加工中なのに数が増えない」と気づいた原因は、まだ分かっていません。今回の短い変動が、その原因だったとは言えません。それでも、別に見つかった誤カウントには、測った数字を使って手を打てました。

「ESP32をESP-IDFで動かせば安心」という、ぼくの中の思い込みが崩れました。使う場所でどんな信号が入っているかを測り、その信号に合わせて数え方を直す。そこまでやって初めて、現場で使える記録に近づけるのだと思います。