2009-03-10 10 views
0

シリアルポートを使用して、シンクライアントに接続されたスケールからデータを読み取っています。 99%のケースでは、データが正しく読み取られます。つまり、規模に関係なく、アプリケーションによってキャプチャされたデータです。 ただし、データが破棄されたように見えることがあります。たとえば、90.007ではなく、0.007と読み替えられます。私はReadLine関数を使用しています:Readline()でシリアルポートをドロップする

private void CaptureWeight() 
    { 
     globalCounter++; 
     string value = ""; 
     _sp.DiscardInBuffer(); 

      while (!this._processingDone) 
      { 
       try 
       {      

        value = this._sp.ReadLine();      

        if (value != "") 
        { 
         if (value == "ES") 
         { 
          _sp.DiscardInBuffer(); 
          value = ""; 
         } 
         else 
         { 
          this.Invoke(this.OnDataAcquiredEvent, new object[] { value }); 
         } 
        } 
       } 
       catch (TimeoutException) 
       { 
        //catch it but do nothing 
       } 
       catch 
       { 
        //reset the port here? 
        MessageBox.Show("some other than timeout exception thrown while reading serial port"); 
       } 
      } 
    } //end of CaptureWeight() 

答えて

1

"ES"はいつ来ますか? DiscardInBuffer()を呼び出すため、「ES」の直後の値が正しく読み取られない可能性があります。その時間にバッファに次の読みの一部が含まれているとします。 90.007の9、9は破棄され、0.007を読みます。

最後のCR LFの前のすべてを廃棄してください。しかし、不完全な行を残す。

+0

ESは残高によって返送されるエラーコードです。私はエラーコードを飲みたいです。私の前提は、ReadLineは行を読みます(意味がありますか?)、もしES \ n \ rが読み込まれていれば、それを飲み込むでしょう。なぜ次の行を正しく読むことができないのですか?私はこの記事をコメントし、これが役立つかどうかを見ていきます。 – sarsnake

+0

わかりませんが、並行性の問題になる可能性があります。基礎となるスレッドは、シリアルポートデータをバッファに書き込んでいます。それが起こった場合は、DiscardInBufer()を呼び出す前に終了していません。始め、例えば90.007の – siddhadev

2

DiscardInBufferを呼び出さないでください。オペレーティングシステムのバッファにはasynchronouslyが入力され、データはUARTからシフトインされます。あなたがそれを捨てる時にバッファに何が入っているか知る方法がないので、すべてのデータを読んでそれに応じて行動してください!

+0

の9は動作しません。データの読み込みがサンプルのデータグリッドと一致するように、Inバッファをクリアします。ユーザーがPrintを何度も押した場合、どのサンプルがどのサンプルに属しているのかを識別する方法はないので、読み取ったバッファをクリアします。 readlineの後にDiscardInBuffer()を呼び出すほうがよいですか? – sarsnake

+0

+1 - 私は同意します:DiscardInBufferを呼び出さないでください。ユーザーがPrintを何度も押した場合は、他の方法で処理する必要があります。上に書いたように、あなたはいつも誰が最初にそこに着くのかを見るために港をレースしています。 – dwc

関連する問題