11

私がやろうとしていることの背景は次のとおりです。

  1. モバイル デバイスから Bluetooth プリンターへのシリアル ポートを開きます。
  2. EPL/2 フォームを Bluetooth プリンターに送信して、受信しようとしているデータの処理方法をプリンターが理解できるようにします。
  3. フォームが受信されたら、ラベル ストックに印刷されるデータをプリンターに送信します。
  4. 印刷するラベルごとに、手順 3 を必要な回数繰り返します。

ステップ 2 は、フォームが各ラベルの前にある必要がないため、初回のみ発生します。私の問題は、フォームを送信するときに、ラベル データを送信する速度が速すぎると印刷されないことです。送信したデータの代わりに、ラベルに「Bluetooth エラー: 無線が動作しません」と印刷されることがあります。

次のようにして、この問題を回避する方法を見つけました。

for (int attempt = 0; attempt < 3; attempt++)
{
    try
    {
        serialPort.Write(labelData);
        break;
    }
    catch (TimeoutException ex)
    {
        // Log info or display info based on ex.Message
        Thread.Sleep(3000);
    }
}

したがって、基本的には、TimeoutException をキャッチし、一定時間待機した後に書き込みメソッドを再試行できます (3 秒は常に機能しているように見えますが、3 秒未満で、試行ごとに例外がスローされるようです)。3回試行した後、シリアルポートに問題があると想定し、ユーザーに知らせました。

この方法はうまくいくようですが、これを処理するためのより良い方法があると確信しています。SerialPort クラスには、使用する必要があると思われるプロパティがいくつかありますが、適切なドキュメントや使用方法の例が実際には見つかりません。いくつかのプロパティをいじってみましたが、どれも私が達成しようとしていることをしていないようです。

私が遊んだプロパティのリストは次のとおりです。

  • CD保有
  • CtsHolding
  • DsrHolding
  • DtrEnable
  • ハンドシェーク
  • RtsEnable

これらのいくつかの組み合わせが、私がやろうとしていることをより優雅に処理できると確信しています。

私は C# (2.0 フレームワーク)、Zebra QL 220+ Bluetooth プリンター、および Windows Mobile 6 ハンドヘルド デバイスを使用していますが、それによってソリューションに違いが生じる場合があります。

任意の提案をいただければ幸いです。

[アップデート]

また、モバイル デバイスは Bluetooth 2.0 を使用しているのに対し、プリンターはバージョン 1.1 のみであることにも注意してください。速度の違いが原因で、プリンターがデータの受信に遅れをとっていると思います。

4

3 に答える 3

7

すでに与えられた2つの提案に基づいて、これを行う方法を見つけました。シリアル ポート オブジェクトを次のように設定する必要があります。

serialPort.Handshake = Handshake.RequestToSendXOnXOff;
serialPort.WriteTimeout = 10000; // Could use a lower value here.

次に、書き込み呼び出しを行う必要があります。

serialPort.Write(labelData);

Zebra プリンタはソフトウェア フロー制御をサポートしているため、バッファがほぼいっぱいになると XOff 値がモバイル デバイスに送信されます。これにより、モバイル デバイスは XOn 値がプリンターから送信されるのを待機し、送信を続行できることをモバイル デバイスに効果的に通知します。

書き込みタイムアウト プロパティを設定することで、書き込みタイムアウト例外がスローされるまでの転送に許容される合計時間を指定しています。質問のサンプル コードで行ったように、書き込みタイムアウトを引き続きキャッチする必要があります。ただし、ソフトウェア フロー制御がシリアル ポートの書き込み送信を開始および停止するため、毎回書き込みを試みて 3 回 (または任意の回数) ループする必要はありません。

于 2008-10-31T15:57:47.373 に答える
5

ここではフロー制御が正解であり、Bluetooth 接続には存在しない/実装されていない/適用できない可能性があります。

Zebra の仕様を調べて、さまざまなバッファがいついっぱいになるかを確認できるソフトウェア フロー制御 (xon、xoff) が実装されているかどうか、またはオンにできるかどうかを確認してください。

さらに、Bluetooth 無線は、最大で 250k よりも高速に送信できる可能性は低いです。人為的に 9,600bps に制限することを検討することもできます。これにより、無線が再送信、エラー修正、検出、および独自のフロー制御を行うための余裕が生まれます。

他のすべてが失敗した場合、現在使用しているハックは悪くありませんが、あきらめる前に Zebra の技術サポートに電話して、彼らが推奨するものを見つけてください.

-アダム

于 2008-10-21T16:33:54.477 に答える
2

問題はシリアル ポート コードではなく、基になる Bluetooth スタックにある可能性があります。使用しているポートは純粋に仮想であり、ハンドシェイクが実装されている可能性はほとんどありません (ほとんど意味がないため)。CTS/RTS DTR/DSR は、作業中のものには適用されません。

根本的な問題は、仮想ポートを作成するときに、その下で Bluetooth スタックにバインドし、ペアリングされたシリアル デバイスに接続する必要があることです。ポート自体には、それがどれくらいかかるかがわからず、おそらくこれを非同期で行うように設定されています (ただし、それがどのように行われるかは、純粋にデバイスの OEM 次第です)。ペアリングされたデバイスまたはペアリングされたデバイスが範囲外です。

あなたのコードはハックのように感じるかもしれませんが、それはおそらくあなたがしていることを実行するための最良の、最も移植性の高い方法です。

Bluetooth スタック API を使用して、接続する前にデバイスがそこにあり、動作しているかどうかを確認することもできますが、スタック API の標準化は行われていないため、Widcom と Microsoft の API はその方法が異なり、Widcom は独自仕様であり、高い。最終的には、スタックの種類を発見し、適切な検証クラスを動的にロードし、スタックを呼び出してデバイスを探すという混乱が生じます。それを考慮すると、単純な投票はよりクリーンに見え、Widcom SDK のために数千ドルを支払う必要はありません。

于 2008-10-21T16:21:27.950 に答える