2009-02-27 4 views
2

シリアルポートを開き、シリアルポート経由で天びんのデータを正常に送信するには、serialPortオブジェクトの設定が天びんの実際の設定と一致していることを確認する必要があります。Compact Frameworkのシリアルポートと天びん

ここで問題は、設定が異なるために接続が確立されていないことを検出する方法です。 serialPort.Openによって接続が確立されたことを示す例外はスローされません。はい、設定は有効ですが、デバイス(天びん)の設定と一致しない場合。私は暗闇の中でなぜバランスの重さが捕らえられていないのかを知っています。

ここに入力はありますか?

+0

あなたのデバイスから期待されるデータのフォーマットを説明することでこれを拡張することができますか? –

+0

モデル番号を入力することができれば、使用している実際のデバイスに関する詳細があれば、何が間違っているのかを知ることができます。 –

答えて

0

物事が近いが、依然として正しくない場合は、.NETシリアルポートオブジェクトは、偶数(致命的な何かが起こるまでそれが、です)あなたにエラーを与えていないことがあります。

最も一般的なシリアルポートの通信エラーは、ボーレートの不一致のために発生します。あなたが「エコー」を得ることができることを知っているというメッセージがあれば、それをハンドシェイクの取り組みの一環として試してみてください。接続しようとしているデバイスに「ステータス」メッセージが表示されている可能性があります。それを要求することによる害はなく、通信が正しく流れているかどうかを知ることができます。

ソフトウェアハンドシェイク(xon xoff)については、正しく設定されているかどうかを検出することはほとんどありません。シリアルポートオブジェクトは、基本的なシリアルポートドライバの実装に応じて、スレッド例外エラーを完全に無視することから何かを行うことができます。私はxon/xoffを完全に無視するシリアルポートドライバを手に入れ、文字をプログラムに直接渡しました。

ハードウェアハンドシェイクでは、デバイスの動作方法に応じて、ボーレートの基本的なエコー戦略が機能する場合があります。ハードウェアハンドシェイクを行うことがわかっている場合は、それを検出してオンにすることができます。デバイスがハードウェアハンドシェイクを必要とし、それがオンになっていない場合、何も得られず、その逆もあります。

使用頻度の低いもう1つの設定は、DTRピン - データ端末の準備です。一部のシリアルデバイスでは、データの送信を開始するタイミングを示すために、これをアサート(trueに設定)する必要があります。デフォルトではfalseに設定されています。それを渦巻きにする。

シリアルポートオブジェクトは... finickyです。必ずしも必要ではありませんが、変更を加える前にポートを閉鎖することを検討します。

編集:thisがお使いのデバイスであるようにあなたのコメントに

おかげで、それが見えます。これはデフォルトの設定があるべきと言う:

  • 1200ボー
  • 奇数パリティ
  • 1ストップビット
  • ハードウェアハンドシェイク

それはどのように多くのデータビットを指定するのではなく、デバイスはそれが7と8をサポートしていると言います。私はそれらの両方を試してみましょう。また、600,1200,2400,4800,9600、および19200ボーをサポートしています。

ハードウェアハンドシェイクを有効にし、DTRを有効にして(異なるもの)、すべての異なるボーレートを循環させると、それはあなたの設定ではない可能性があります。使用しているシリアルケーブルがお使いのデバイスに正しく接続されていない可能性があります。シリアルケーブルの中には、「パススルー」ケーブルがあります。片側の1〜9ピンと他の1〜9ピンが正確に一致しています。次に、 "TX"と "RX"ケーブルが切り替わる(クロスオーバー)ケーブルがあります。片側が送信されたときに相手側に非常に便利なケーブルが届くようにします。

コマンドテーブルマニュアルの後ろにあります。何らかのエコーバックを取得するために発行できる「印刷ソフトウェアバージョン」コマンドがあります。

+0

私はハンドシェイク=なしを使用しています – sarsnake

+0

ハンドシェイクがデバイスが設定されているものと一致する場合、あなたはうまくいくはずです。 アサートすることが重要かもしれないもう1つは、DTRデータ端末の準備です。私は私の答えを更新します。 –

+0

すべての天びんはシリアルポート経由で通信できますか?ネットシリアルポートの制御で動作することを確認するにはどうすればよいですか? – sarsnake

1

天びんから期待されるデータの形式に関する情報をもう知らなくても、一般的なシリアルポート設定不一致検出技術のみが適用可能です。

UART設定が大幅に間違っていると、フレーミングエラーが多く発生する可能性があります.UARTが1ストップビットを期待している場合、実際には0が表示されます。ErrorReceivedイベントでこれを検出できますポート。

private void OnErrorReceived(object sender, SerialErrorReceivedEventArgs e) 
{ 
    if ((e.EventType & SerialError.Frame) == SerialError.Frame) 
    { 
     // your settings don't match, try something else 
    } 
} 
+0

これは残念ながらエラーを検出しません。 – sarsnake

+0

ミスマッチの性質は何ですか?ビットレートが異なるか、または単にパリティの違い(7E1対8N1)ですか? –

+0

現在、私は設定ファイルにデフォルト設定(ボー、パリティ、ストップビットなど)を保持しています。私たちは一般にすべての残高を同じ方法でプログラムしていますが、若干の奇妙な残高は異なる設定になることがあります。この場合、ポートが正しく開かれていないことをユーザーにきちんと通知する必要があります。 – sarsnake

0

シリアルポートは非​​常に非常に古い通信プロトコル(RS-232という非常に古いプロトコルを使用)を使用します。これはかなり簡単です... 2つのエンドポイントはクロックを同期させており、クロックサイクルごとにライン電圧をテストして、それが高いか低いかを調べます(高い意味0と低いミーイング1大部分の慣習の...再びプロトコルの年齢の人工物)。クロック同期はストップビットの使用によって実現されます。ストップビットは実際にはバイト間の休憩時間です。また、パリティビット、XON/XOFFなどのプロトコルの高度な使い方にはいくつかのものがありますが、それらはすべてこの基本的な通信レイヤーの上に乗ります。シリアルラインの両端のクロックの不一致を検出することはほぼ不可能になります。受信側で間違ったデータを取得するだけです。プロトコルそのものには、この状況を識別するための方法がありません。私は、入力データが不適切な周波数でクロックされていることに気付くほどスマートなシリアルドライバは認識していません。パリティビットなどのエラー検出方式の1つを使用している場合は、確率的にすべてのバイトがエラーと宣言されます。要するに、受信したデータにエラーがないかチェックすることです(パリティエラーはドライバ/ソフトウェアレイヤーで検出する必要がありますが、そのレイヤーから受け取ったデータのエラーはプログラムでチェックする必要があります)後者はchecksumsの使用によって支援することができる)。

+0

"ソフトウェア層で検出されたパリティエラー"とは、初期化時の意味ですか? – sarsnake

+0

いいえ、パリティビットは、シリアルリンクを介して送信されるすべてのバイトとともに送信されます。レシーバーはデータがアプリケーションに渡される前にこれらのパリティー・ビットをデコードし、データが受信されたときにのみエラーが報告されます。 – rmeador

+0

ああ、ちょっと私が明確でない場合には、初期化時にRS-232でデータが送信されることはありません。接続の設定として行われるハンドシェイクまたは他のデータ交換は、アプリケーションレベルのプロトコルの一部であり、基本的なシリアルリンクではありません。 – rmeador

関連する問題