Hi,
I have had a good look and think about this now and even though I do not have an answer for you here are a few ideas for you to look at and try out:-
1) You have implemented two error capture routines in the timer using Try/Catch which is good. However, what is not good, is the fact that you have not done anything to alert yourself in any of the catch statements if an exception occurs. The program can therefore be running with hundreds of errors and you are never going to know about it.
Let's fix this first then by adding something to the Catch statements to deal with any unknown errors. I suggest adding a textbox to your form with multiline set to true and having a vertical scroll bar. In the two Catch statements add the following code:-
Try
.....
Catch ex As Exception
With TextBox1
.Text += "Data Read Error: " & ex.Message & vbCrLf & vbCrLf
.BackColor = Color.Red
End With
End Try
2) As mentioned before there are a lot of external function calls after the data is received that do something with the data so it's difficult to narrow down if the code is at fault. My gut feeling however seems to tell me that the code is correct since you get correct data 95% of the time.
I think that you therefore need to concentrate your efforts on the actual data that is being received from the serial port each time the timer is used. You have already mentioned that you think it maybe the timer that is causing the issue and I think I agree since by using a timer to interrogate the serial port you could very well pick up an incomplete transmitted package.
I think you should test this theory by adding a list to the timer (declare the list private within the form and not the timer so that you do not keep overwriting it) then each time the timer fires add the RAW data, not the data after your code processing, to the list. i.e.:-
Public Class Form1
Dim myRawDataList As New List(Of String)
.....
.....
Data = KommPort.ReadExisting
myRawDataList.Add(Data)
Buffert &= Data 'Reading into buffer
The next time that you then notice the GUI showing your invalid data you then need to interrogate the Raw data saved in the list to determine if it is the raw data from the serial port which is incorrect and not the code. You can get your raw data by adding a textbox and a button to the form and adding the following code to the button:-
Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
For Each strRaw As String In myRawDataList
TextBox2.Text += strRaw & vbCrLf
Next
myRawDataList.Clear()
End Sub
By comparing the two you should at least be able to rule out whether it is the serial port or the code that is the source of the error.
3) Once the above is done and you have your answer you then need to decide where to go next:-
3.1) If it is a serial port error then we can assume that it is the timer causing the issue and I therefore suggest that you need to change the code to interrogate the serial port on the SerialPort.DataReceived Event. Have a look here:-
SerialPort.DataReceived Event (System.IO.Ports)
3.2) If it is not a serial port error then I would suggest that you use the List capture idea we used with the serial port to capture the results of each manipulation of the Buffert variable so that you can again interrogate the result of each routine and therefore narrow down where you need to concentrate your efforts. We can then look into each routine in more depth as we need to.
4) Just as an additional afterthought you test for data on the serial port using If KommPort.BytesToRead > 0. If there is no data then you set Buffert ="" which effectively resets your buffer waiting for your next packet. Sounds good in theory but what if there is a tiny delay on the serial port, being anything more than 100ms, it will rest buffert and in theory give you the truncated results you have seen. On the basis that you receive data packets every few seconds why not try slowing down the timer to overcome any delay on the serial port. Say 300ms?
There is plenty here for you to try and good luck.
Let us know how you get on.
Cheers,
Ian
