views:

598

answers:

2

I am using serial port to read the data off the scale that is attached to the thin client. In 99% of cases the data is read correctly - ie whatever is on the scale is what is captured by the application. However, sometimes, it looks like data is dropped. For instance instead of 90.007 it will be read as 0.007. I am using ReadLine function:

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  A: 

When does "ES" come? It is theory possible that the value immediately after "ES", is not read correctly, because you call DiscardInBuffer(). If in that time the buffer contains part of the next reading, e.g. the 9 in 90.007, the 9 gets discarded and you read 0.007.

Try discarding only everything before the last CR LF. But leave incomplete lines.

siddhadev
ES is the error code that is sent back by the balance. I want to swallow the error code. My assumption is that ReadLine reads a line (makes sense?), so if ES\n\r is read, I will swallow it. Why wouldn't it read the next line properly? I will comment out this piece and see if this helps.
gnomixa
Not sure, but could be a concurrency issue - the underlying thread is writing the serial port data in to the buffer, and if it happens, that it didn't finished a before you call `DiscardInBufer()`, you just lose the beginning, e.g. the 9 in 90.007
siddhadev
+1  A: 

Don't call DiscardInBuffer. The operating system buffer is filled asynchronously as data is shifted in through the UART. Read all of the data and act on it accordingly because you have no way of knowing what is in the buffer at the time you discard it!

Judge Maygarden
that's not going to work. I clear the In buffer so that the data read matches the datagrid of samples. There's no way 2 identify which weight belongs to which sample if the user presses Print too many times, so I clear the buffer b4 each read. Is it better to call DiscardInBuffer() after readline?
gnomixa
+1 - I agree: do not call DiscardInBuffer. If the user pressed Print too many times you'll have to deal with it some other way. As written above you're always racing the port to see who gets there first.
dwc