Windows Formsにおけるシリアル通信の極意：計測器連携の「止まらない」アーキテクチャ
製造現場の片隅で、今日もVB.NETが黙々とデータを吸い上げている。
計測器やバーコードリーダーとのRS-232C/USB通信は、一見単純だが、ひとたび「現場のノイズ」や「ケーブルの瞬断」という現実が介入すれば、素人設計のコードは即座にフリーズし、UIを固め、そして死ぬ。
なぜ多くの現場で「通信が止まる」「アプリが応答なしになる」という悲劇が繰り返されるのか。それは、多くのエンジニアが`SerialPort`コンポーネントを単なる「読み書きできる魔法の箱」として扱っているからだ。
今日は、伝説的な堅牢性を備えた非同期通信基盤の構築術を伝授する。
1. UIスレッドの聖域を守れ
シリアル通信において最大の悪は、メインスレッド（UIスレッド）でのブロッキングだ。`ReadLine()`を安易に叩けば、計測器からの応答が遅れた瞬間、画面は白濁し、ユーザーは強制終了という暴挙に出る。
解決策は明確だ。`System.IO.Ports.SerialPort.DataReceived`イベントをトリガーにした、「完全に独立したデータ受信パイプライン」を構築することである。
実装の要諦：非同期スレッド処理
受信バッファにデータが溜まったら、即座にメモリ上のストリームへ退避させ、UIスレッドへは必要最小限の通知のみを送る。
‘ 堅牢なシリアルポートラッパーの骨格
Public Class SerialCommunicator
Private WithEvents _serialPort As SerialPort
Private ReadOnly _syncLock As New Object()
‘ データ受信バッファ（メモリ最適化）
Private _receiveBuffer As New List(Of Byte)()
Public Sub Initialize(portName As String)
_serialPort = New SerialPort(portName, 9600, Parity.None, 8, StopBits.One)
_serialPort.ReadTimeout = 500 ‘ タイムアウトを厳格に設定
_serialPort.Open()
End Sub
‘ イベントハンドラ：ここでの長時間は禁物
Private Sub _serialPort_DataReceived(sender As Object, e As SerialDataReceivedEventArgs) Handles _serialPort.DataReceived
Try
‘ バッファから読み取れる分だけ吸い出す
Dim count As Integer = _serialPort.BytesToRead
Dim buffer(count – 1) As Byte
_serialPort.Read(buffer, 0, count)
‘ データを解析キューへ放り込む（UIには触れない）
EnqueueData(buffer)
Catch ex As Exception
‘ ログ出力および切断検知ロジックへ
HandleCommunicationError(ex)
End Try
End Sub
End Class
2. タイムアウトと「死の検知」のアルゴリズム
RS-232Cの厄介な点は、物理的な切断をOSが即座に通知してくれないことだ。計測器が停止したのか、回線が断線したのかを判断するには、ハートビート（生存確認）タイマーを併用するのが鉄則である。
- Watchdog Timerの実装: 最後にデータを受信してからの時間を監視する。
- 閾値: 5秒間データが来なければ、通信再起動プロセスを自動的にトリガーする。
‘ 通信監視用タイマーのロジック
Private Sub WatchdogTimer_Tick(sender As Object, e As EventArgs)
If (DateTime.Now – _lastReceivedTime).TotalSeconds > 5 Then
‘ 通信途絶とみなして再接続シーケンスを開始
ResetConnection()
End If
End Sub
3. レガシー環境を生き抜く：メモリとオブジェクトの解放
VB.NETのガベージコレクタ（GC）は優秀だが、シリアル通信のような高頻度のI/O処理では、オブジェクトの生成と破棄が溜まるとGCのフリーズ（Stop-the-world）を招く。
- バッファの再利用: `Byte()`配列を毎回`New`してはならない。固定長のリングバッファを使い、メモリを静的に確保せよ。
- IDisposableの徹底: `SerialPort`は必ず`Dispose()`を明示的に呼ぶ。これを怠ると、ハンドルのリークにより、再接続時に「ポートが開けません」というエラーに永遠に苦しむことになる。
Public Sub ResetConnection()
SyncLock _syncLock
If _serialPort IsNot Nothing Then
_serialPort.Close()
_serialPort.Dispose() ‘ ここでOSリソースを確実に解放
_serialPort = Nothing
End If
‘ 再接続処理…
End SyncLock
End Sub
4. チーフアーキテクトからの助言
最後に、現場で戦う君たちに伝えたい。
システムが最も不安定になるのは「正常な時」ではない。「計測器が誤作動した瞬間」と「ケーブルが抜かれた瞬間」である。このエッジケースにおいて、アプリが沈黙するのではなく、ログを吐き出し、自律的にポートを再オープンし、ログを残すこと。これが「伝説的」なアーキテクチャと、単なる「動くコード」の境界線だ。
Windows APIの`ClearCommError`を直接呼び出し、ドライバーレベルのエラー状態をクリアする技術が必要になるかもしれない。だが、まずは上記の「非同期分離」と「明示的なリソース解放」を完遂せよ。
VB.NETは、適切に扱えば、最も泥臭い現場の要求に最も静かに応える最強の道具となる。健闘を祈る。
