古いFANUC制御のNC工作機械を、RS-232Cでパソコンとつないでプログラムを送受信している現場は今でも珍しくありません。今回は、その通信環境を Windows 7 から Windows 10 のパソコンに入れ替えた途端に「087 バッファオーバーフロー」が出るようになった トラブルを、原因の切り分けから解決まで実際の手順で記録しておきます。
「NCも、ケーブルも、通信ソフトも何も変えていないのに、パソコンをWin10にしたら通信できなくなった」——同じ状況で困っている方の役に立てば幸いです。
発生した環境
NC側
- FANUC（古い機種、0系相当）
- RS-232Cでプログラム送受信
- 発生アラーム：087 バッファオーバーフロー
旧パソコン（正常だった環境）
- Windows 7
- 通信ソフト：Comnc Ver5.16
- USB-RS232C変換ケーブル：SANWA USB-CVRS9
- → 問題なく送受信できていた
新パソコン（トラブル発生）
- Windows 10
- 同じ Comnc Ver5.16
- 同じ USB-CVRS9
変わったのは Windows のバージョンとドライバまわりだけ。NCもケーブルも通信ソフトも同一、という点が今回の切り分けの重要な手がかりになりました。
症状
- ほとんどの場合、送信開始直後に「087 バッファオーバーフロー」 が出る
- 一度だけ途中まで読めたことがあったが、数行欠けた状態で途中からプログラムが書き込まれた。その後は再現せず
この「送信直後に出る」「たまに数行欠ける」という挙動が、後で原因を特定する決め手になります。
そもそもアラーム087とは何か
087は文字どおり「バッファオーバーフロー」ですが、正確には フロー制御（ハンドシェイク）が間に合わなかったとき に出るアラームです。仕組みはこうなっています。
- NCがプログラムを受信し、内部の受信バッファに溜め込む
- バッファが満杯に近づくと、NCはパソコン側へ XOFF（DC3, ASCII 19） を送って「送信を止めろ」と指示する
- パソコン側が 10文字以内で送信を止めれば オーバーフローしない
- NCがバッファを処理し終えると XON（DC1, ASCII 17） を送り、送信が再開される
つまり087は、NCが「止まれ」と言った後もパソコンが送り続けてしまう ことで起きます。「送信直後に出る」「一瞬だけ効いて数行欠ける」という症状は、まさにこのXOFFへの反応が間に合っていない典型的な挙動でした。この時点で、原因はフロー制御の応答速度にあると当たりがつきます。
ここで重要なのが、古いFANUC（0系）ではボーレートとストップビットしかパラメータで設定できず、XON/XOFF（DC1〜DC4）の処理は通信ソフトではなくUART＝ドライバ側で行われる という点です。言い換えると、XOFFに反応して送信を止めるのは Comnc ではなく USBシリアル変換のドライバ の仕事。ここが今回の核心です。
効かなかった対策
原因の見当をつける前に、定番とされる対策をひととおり試しましたが、いずれも改善しませんでした。
- COMポートの変更（COM3 → COM1）
- FIFOバッファの有効／無効の切り替え
- 送信・受信バッファを最小／最大に振る
- ボーレートを2400へ変更 → そもそも通信が始まらない
補足すると、ボーレートを2400にして通信が始まらなかったのは、NC側のパラメータが4800のままで、パソコン側だけ2400にしたための不一致 が理由です。087が出ている＝4800はボーレートとしては合っている証拠(不一致なら086/085系の枠エラーになる)なので、下げるなら NC側パラメータも同時に2400へ揃える 必要があります。
本当の原因：Windows10のドライバ
NC側は何も触っていないので、変わったのは Windows・ドライバ・USBシリアル変換の応答速度だけ。そして前述のとおり、087の原因であるXOFFへの反応を担うのはドライバです。
USB-RS232C変換器は、XON/XOFFの反応が遅く087を起こしやすいことが、CNC通信の界隈では以前から知られています。今回はさらに、新パソコンで最初にドライバが未認識だったため、付属CDに入っていた古い「Win_8」ドライバ をインストールして「ATEN USB to Serial Bridge」として認識させていました。この古いドライバの応答特性が、Win10環境ではXOFFに間に合わず087を出していた——というのが結論です。
つまり「Windows10とドライバの相性」と「ハンドシェイクの遅延」は、別々の問題ではなく 同じ一つの現象を別角度から見たもの でした。
実際に解決した方法
型式は USB-CVRS9 を使っていましたが、SANWAのサイトには USB-CVRS9HN 用のドライバしか置いていませんでした。中身のチップ（ATEN UC-232A系）はほぼ共通なので、ダメ元でこの HN用のWindows10ドライバ を入れてみたところ——
あっさり通信できるようになりました。
古い付属CDのドライバより新しいドライバの方がXOFFへの応答が速く、087が出なくなった、という理屈です。087の原因がフロー制御の応答遅延だったことを、結果が裏付けてくれた形になりました。
ポイント：手持ちの型式（USB-CVRS9）のドライバが見つからなくても、後継・派生型式（USB-CVRS9HN）のWindows10用ドライバ を試す価値があります。チップが同じなら流用できることが多いです。
同じ症状で困っている人へ｜チェックリスト（優先度順）
「Windows10に替えたらFANUCで087が出る」場合、次の順で試すのがおすすめです。
- USBシリアル変換のドライバを、Windows10用の新しい版に入れ替える 付属CDの古いドライバは要注意。メーカーサイトから最新版を入手する。手持ち型式が見つからなければ、後継・派生型式のドライバも試す（今回はこれで解決）。
- FIFOバッファ／Latency Timerを最小化する デバイスマネージャー → 該当COMポート → プロパティ → ポートの設定 → 詳細設定。FIFOを無効、または受信バッファを最小(1)に。Latency Timer の項目があれば 1ms に下げる。
- ボーレートを両側で下げる NC側パラメータとパソコン側の両方を揃えて下げる(例：両方2400)。低速化はXOFF応答に余裕を与える。
- 通信ソフトに送信ディレイ(行間ウェイト)を入れる 1ブロックごとにわずかな待ちを入れられると回避できることがある。
- FTDIチップ製の変換器に替える FTDIはドライバレベルでXON/XOFFを確実に処理し、Latency Timerも調整可能。恒久対策の本命。
- PCIe/PCIのネイティブシリアルカードを使う USBを介さないのが原理的に最も安定。固定の現場PCならこれが確実。
まとめ
- FANUCの 087 バッファオーバーフロー は、NCのXOFF（止まれ）に送信側が間に合わないと出る フロー制御のトラブル
- 古い0系ではXOFFの処理は ドライバ側 が担うため、Windows7→Windows10でドライバが変わると発症しやすい
- NC・ケーブル・通信ソフトが不変で、パソコンの入れ替えだけで発症したら、まずドライバを疑う
- 今回は USB-CVRS9HN用のWindows10ドライバ を入れることで解決した
古い設備を使い続けるうえで、RS-232C通信は避けて通れない場面が多くあります。「パソコンを替えたら通信できなくなった」は本当によくあるトラブルなので、同じところで止まっている方の手がかりになればうれしいです。
コメント