vb.net and rs232 port communication string length

Hello experts, I am using a vb.net app to read a value from the rs232 port, we are having issues with part of the string being broken.  The app needs to read a 13 character string, what is happending; is it is being broken into two reads 8 characters one time 5 the next.  This problem only occured on a older computer, my app runs fine on my computer.  I wonder if this is a windows issue.  Because we used hyper terminal trying to read a 16 character string and only 14 could be read at one time.  Could this be a serial port issue?
Public WithEvents comhold As Rs232 'declare rs232 class with events

 Sub openport(ByVal timeval As String)
        'Rs232 class contains all the constructs and windows api calls
        'that are needed to communicate through a serial port
        comhold = New Rs232
            ' Setup parameters
            With comhold
                .Port = 1
                .BaudRate = 19200
                .DataBit = 8
                .StopBit = Rs232.DataStopBit.StopBit_1
                .Parity = Rs232.DataParity.Parity_None
                .Timeout = 500
            End With
            comhold.Open() 'Open the port
            ' Set state of RTS / DTS
            comhold.Dtr = 1
            comhold.Rts = 1

        Catch Ex As Exception
            MessageBox.Show(Ex.Message, "Connection Error", MessageBoxButtons.OK)
        End Try
    End Sub

Here is the event that reads the value
 Public Sub comhold_CommEvent(ByVal source As Rs232, ByVal Mask As Rs232.EventMasks) Handles comhold.CommEvent
        Dim sread As String
            sread = comhold.InputStreamString
            lblint.Text = sread.Length
            lbltdowntime.Text = sread.Substring(0, 3) + "." + sread.Substring(3, 1)
            lblwdowntime.Text = sread.Substring(4, 3) + "." + sread.Substring(7, 1)
            lblttarget.Text = sread.Substring(8, 2)
            lblwtarget.Text = sread.Substring(10, 3)
        Catch ex As Exception
        End Try
    End Sub
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

There are a lot of things that can affect how much data is read during communications such as buffer length, error correction, noise, communication speed.

I suggest your CommEvent should continue to read all data until it receives a 'stop byte', some character you define to let the client know that all of the data has been sent. Or if you know your data packet will always be 13 characters you continue to read until all 13 characters have been received and then concat the resulting string and return it.

The com control itself usually has settings to define your maximum buffer length (ie: how many characters are read before the Event is triggered) but this does not mean that the event HAS to be triggered only when it reaches the maximum.

Hope this helps,

Brad D.

tentavariousAuthor Commented:
Still kinda lost as to why this works fine on my computer but not on the users computer after I install the app?
Normally, Serial Data flows from machine to machine byte by byte. The Com control establishes a simple 'protocol' that checks the port  every so many clock ticks if a byte exists it appends it to the buffer if the buffer is a maximum or the timeout has expired it fires the CommEventand passes the contents of the buffer to the program to use as desired.

So suppose the port is checked every 15 clock ticks and the timeout is 0.5 seconds

I don't know the actual #'s and I am sort of oversimplifing and will probably be corrected.

Now let's suppose for example, we have Machine A doing two million clock ticks a second, so in one second the port is checked over 133333 times.

On machine B there are only 1 million click tics a second, so the port is only checked half as many times.

Machine B may go for 0.5 seconds and never 'see' the data on the port so a timeout occurs and the ComEvent is fired.

Machine A never goes a whole 0.5 seconds without seeing any data so it goes until the ComEventffer is full and then fires the ComEvent

Of course other things again could affect how often the port is checked, etc, but it is beComEventread the data one byte at a time and develop your own protocol.

Some examples can be found at http://www.devhood.com/tutorials/tutorial_details.aspx?tutorial_id=320&printer=t

Hope this helps,

Brad D.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.