電卓と紙からの脱却：C#とBluetoothで実現した、工場の重量計測DXと規格の罠（Classic vs BLE）

M.O

20 時間前

読了時間: 7分

こんにちはM.Oです。

今回は、最近私が担当した、工場の生産ラインにおけるハンディターミナル（HT）と計測器（秤）を連携させるプロジェクトについてのお話です。

規模こそ小さいものの、現場の作業を劇的に変えた「カイゼン（DX）」の実例と、その開発過程でハマったハードウェア連携特有の強力な技術的罠、そしてそれを解決したC#の実装について共有します。

今回は、システム全体を統括するエンジニアリング会社様の提案に基づき、弊社がHT側のアプリとデータ連携部分の「システムの一部」の実装を担当した事例です。

１．現場の課題：「秤、電卓、紙」の世界

システムを導入した現場は、大きな工場の生産ラインです。

しかし、そこでの作業は、スマートファクトリーといった言葉からは程遠い、非常にアナログで泥臭いものでした。作業は、製品の出荷前に行う品質管理において重要な「重量計測」です。

カイゼン前は、以下のような手順で行われていました。

秤で測る: 作業者が重量物の秤の上に製品を載せ、表示をじっと読み取る。

風袋データを表から探す: 容器（風袋）の重量を、現場の壁に貼られた一覧表から探し出す。

電卓で引く: 電卓で、総重量から風袋重量を手計算して正味重量を出す。

作成個数を計算する: さらに単位重量で割り、作成個数を算出する。

紙に書く: 計算結果を、紙の管理表にペンで手書き記入する。

エクセルへ転記: 後日、別の担当者がその紙の管理表を事務所でエクセルに手入力する。

２．エンジニアリング会社の提案： HTで全てを解決。風袋引きもDB登録も「自動化」

エンジニアリング会社様が提案されたのが、キーエンス製のハンディターミナル（HT）を活用した「計測データ自動収集・処理システム」の導入でした。

コンセプトは、「作業者は秤に物を載せるだけ」です。

HTとBluetoothに対応した秤を使って、以下のように一変させる構想です。

自動データ取得: 作業者が秤に製品を載せ「計量」ボタンを押すと、HTがBluetoothを介して重量データを自動取得。

自動風袋引き: データ取得後HT内のアプリがDBから自動的に風袋データを引き、正味重量と作成個数を瞬時に計算。

リアルタイムDB登録: 確認ボタンが押されると、データは工場の無線LANを介してデータベース（DB）へリアルタイム登録。紙への記入も、転記作業も消滅します。

これにより、ミスの最大の温床だった手作業と手計算を徹底的に排除し、正確なリアルタイムデータの収集を実現しようという提案です。

弊社は、ハンディターミナル側のアプリケーション開発と、データベースへのリアルタイムデータ連携部分の実装を担当しました。弊社の書いたC#の技術がいかに現場の課題を解決したか、その舞台裏を共有します。

３．技術解説＆トラブルシューティング：異なるBluetooth規格との戦い（社内検証での発覚と解決）

ここからは、ハードウェア連携特有の「罠」と解決に至る泥臭い過程の話です。

最大の技術的ハードルは、HTと秤の間のBluetooth通信でした。

現場立ち上げをスムーズに行うため、社内検証段階で実機の秤とHTを送ってもらい、接続確認を行うことにしました。

社内で秤側のBluetooth機器とHTをペアリングしようとしましたが、何度やっても接続できません。エラーも出ず、ただ「接続できませんでした」というメッセージが出るだけ。

双方スペック表を隅から隅まで読み直しました。そして、ある一つの小さな記述に目が釘付けになりました。

秤側のBluetooth機器: Bluetooth 5.0 (BLE) 対応

HT: Bluetooth 4.x (Classic) 対応

皆さんはご存知でしょうか。「BLE（Bluetooth Low Energy）」と「Classic Bluetooth」の決定的な違いを。

これらは、名前に「Bluetooth」と付いていますが、物理層から通信方式までが全く異なる別の規格です。BLE機器はClassic Bluetoothとは互換性がありません。マルチベンダー開発では、こうした想定外が起こり得ます。

現場スケジュールも進んでおり、ハードウェアの変更は不可能です。辿り着いた代替案は、秤の昔からある標準的なRS232Cポートを利用することでした。

新構成: 秤 (RS232C) ➔ RS232C-Classic Bluetooth変換器 ➔ HT

しかし、また別の規格違いでハマるのは避けたい。選定したRS232C-Bluetooth変換器のデモ機を借り、社内で検証を行いました。

構成は、秤 (RS232Cポート) ➔ [変換器] ((( Classic BT ))) ➔ HT。

秤の上に重りを載せます。秤から送られてくるデータが、変換器を介してHTに届き、画面に表示されました。接続できることを確実に確認した上で、正式に変換器の購入へと踏切りました。

社内での綿密な検証とデモ機での確実な動作確認が、現地立ち上げトラブルを未然に防いだのです。

４．C#による実装：信頼性の高いシリアル通信クラスの設計

解決策が決まれば、あとは実装です。 HT側からはBluetooth変換器が「シリアルポート（COMポート）」として見えるため、C#での実装には、標準の System.IO.Ports.SerialPort クラスを使用します。

再利用性とメンテナンス性を高めるために、今回作成したラッパークラス SerialControl の実装を紹介します。設定のXML外部化、IDisposable によるリソースの確実な解放、イベント駆動によるデータ受信など、堅牢なハードウェア連携アプリのためのエッセンスを詰め込んでいます。

【SerialControl クラスの実装】

【コードの解説とエンジニアのこだわり】

ポイントを解説します。

IDisposable インターフェースとDisposeパターンの実装: シリアルポート（アンマネージド・リソース）の確実な解放は、メモリリークやポートが掴まれたままになるトラブルを防ぐ最重要ポイントです。

設定の外部化 (XML): ポート名などをハードコーディングせず、XMLファイルから読み込む設計にしました。再ビルドすることなく設定変更が可能です。

イベント駆動によるデータ受信: DataReceived イベントをハンドルすることで、UIスレッドをブロックせずにデータ受信を行います。画面がフリーズすることなく快適な操作性を実現します。

ReadExisting () によるバッファ管理の簡潔化: シリアル通信では、秤のような機器はデータを連続して送ってくるため分割受信がよくあります。今回は秤が「改行コード（\r\n）」を付けて送ってくる仕様だったため、ReadExisting () を使用しました。改行コードが届くまで待ってくれるため、複雑なバッファ管理ロジックを書かずに済みます。

このクラスをコアに据え、C#の業務ロジック（個数計算や、工場の基幹DBへのSQLを用いたリアルタイム登録）を実装することで、電卓も紙も不要な重量計測DXアプリを完成させました。

５．導入効果：ミスはゼロに、作業時間は大幅短縮、そして「データの一元管理」へ

導入効果をビフォーアフターでまとめます。

	カイゼン前（電卓・紙）	カイゼン後（HT・自動化）
ミス（計算、打ち間違い、転記）	月末にデータが合わないことがある	物理的にゼロに。秤からの自動取得のみ。
作業時間（1計測あたり）	数分かかる	大幅短縮。秤に載せるだけ（数秒）。
データ管理	紙ベース、後日転記。リアルタイム性なし。	DBへリアルタイム登録。一元管理。