Receiving data on serial port not doing as expected

[roxydogg]

I have 2 computers communicating via serial port. I wrote a simple vb6 app using the MScomm object. The two computers talk to each other and what I send from one appears correctly in a text box on the other computer and vice versa. I went to write the text to a text file and each letter appears on a new line.
I changed the incoming string length attribute of MScomm to 25. now the text file entry is a single column 8 characters wide.

Is there something simple and basic that I am missing here? Is there any sample code that demonstrates this?

Thanks

[DataMiser]

Most definitely but since you did not show any code all we could do is guess. most likely you are not writing to the file correctly to get the output you want and that is the source of your issue

[roxydogg]

Most definitely but since you did not show any code all we could do is guess. most likely you are not writing to the file correctly to get the output you want and that is the source of your issue

Here's the code you asked for
Note that the text1 box shows the complete string all on one line
but the file has each letter on a new line.

Private Sub MSComm1_OnComm()
	Dim InBuffer as String
	Dim bytesIn as Integer
	Dim idx as Integer
	
	bytesIn = MSComm1.InBufferCount
	
	InBuffer = MSComm1.Input
	
	Sleep 500

	me.text1.text = InBuffer

	call Write_log_file(InBuffer)
	
End Sub


public Sub write_log_file(inString as String)
	Print #fhandle, inString
End Sub

Private Sub Form_Load()
	MSComm1.CommPort = 1
	MSComm1.Settings = "9600,n,8,1"
	MSComm1.PortOpen = True
	MSComm1.RThreshold = 1
End Sub

[DataMiser]

Print # adds a new line after each call. If you want the new line suppressed then you need to add a ; to the end of the statement.

Like so

Print #fhandle, inString;

Why do you have a sleep statement in your receive event?
That probably should be removed

[roxydogg]

Print # adds a new line after each call. If you want the new line suppressed then you need to add a ; to the end of the statement.

Like so

Print #fhandle, inString;

Why do you have a sleep statement in your receive event?
That probably should be removed

Thank you. I took out the sleep and added the semi-colon

The file is being populated correctly. But now the text1.text box is missing the first 8 characters of every string that is received on the comm port.

[dilettante]

Most communications media in Windows are not message oriented.

Each time you receive data you might get 1, 3, 5, or whatever bytes or characters of input. You have to assemble the incoming stream and parse off "messages" according to some prearranged protocol.

Some use delimiters, some use a message-length prefix, and some use fixed-length messages. But in all cases you have to assemble the incoming data and then parse out complete messages as you have them assembled into your stream buffer.

You appear to be just taking whatever is available and then overwriting your text1.text with it. If things are arriving 1 byte/char at a time then all you'll see is the last one you got.

[DataMiser]

Well you have to remember that when reading from a com port you may not get all the characters at once. Your code over writes the text of the text box with what just arrived so if you get 8 characters then 10 more your text box will show only the last 10 because you have coded it to do that.

You should buffer incoming data until you have a complete transmission. Usually you would look for a delimiter or terminator character to know when you have the full data of the transmission and can process it.

Static InBuffer as String

	InBuffer=Inbuffer &  MSComm1.Input

This will cause data that arrives to be appended to the inbuffer variable rather than replacing what was last received.
Of course at some point you most likely will need to either clear the data from the var or remove a portion of it. Can't say for sure without details of the communications being done.

[roxydogg]

Well you have to remember that when reading from a com port you may not get all the characters at once. Your code over writes the text of the text box with what just arrived so if you get 8 characters then 10 more your text box will show only the last 10 because you have coded it to do that.

You should buffer incoming data until you have a complete transmission. Usually you would look for a delimiter or terminator character to know when you have the full data of the transmission and can process it.

Static InBuffer as String

	InBuffer=Inbuffer &  MSComm1.Input

This will cause data that arrives to be appended to the inbuffer variable rather than replacing what was last received.
Of course at some point you most likely will need to either clear the data from the var or remove a portion of it. Can't say for sure without details of the communications being done.

I control the code and thus the message formatting on the other side as well. I can format the message as is needed to make this work. I'll add a terminator to the message.

Has anyone got any sample code available to receive and parse what is incoming on the COM port? Lets say I just terminate the string with a CHR(13).

Thanks again for all the advice.

[DataMiser]

It is pretty simple, assuming you buffer the incoming data with a staic var as shown above then once you add the latest data to the var you would check to see if that terminator character exists in the string. If so parse the string and process the data up to the CR then leave any additional data that may be present in the buffer

Static InBuffer As String
Dim Transaction As String, Pos As Integer

InBuffer = InBuffer & MSComm1.Input

Pos = InStr(InBuffer, vbCr)
If Pos > 0 Then
    Transaction = Left$(InBuffer, Pos - 1)
    Debug.Print "Transaction=" & Transaction
    If Len(InBuffer) > Pos  Then
        InBuffer = Mid$(InBuffer, Pos + 1)
    Else
        InBuffer=""
    End If
End If

[roxydogg]

It is pretty simple, assuming you buffer the incoming data with a staic var as shown above then once you add the latest data to the var you would check to see if that terminator character exists in the string. If so parse the string and process the data up to the CR then leave any additional data that may be present in the buffer

Static InBuffer As String
Dim Transaction As String, Pos As Integer

InBuffer = InBuffer & MSComm1.Input

Pos = InStr(InBuffer, vbCr)
If Pos > 0 Then
    Transaction = Left$(InBuffer, Pos - 1)
    Debug.Print "Transaction=" & Transaction
    If Len(InBuffer) > Pos  Then
        InBuffer = Mid$(InBuffer, Pos + 1)
    Else
        InBuffer=""
    End If
End If

Ok I'm getting incrementally closer and closer to a solution.

Here's my code implemented as suggested. The string in the transaction variable is correct. but when written to the log file it is a string of asian characters, japanese or chinese.

Private Sub MSComm1_OnComm()
   Static InBuffer As String
   Dim transaction As String
   Dim pos As Integer

   termFlag = False
   
   InBuffer = InBuffer & MSComm1.Input

   pos = InStr(InBuffer, vbCr)

    If (pos > 0) Then
        transaction = Left$(InBuffer, pos - 1)
        Debug.Print "transaction =>" & transaction
        Text2.Text = transaction
        If (Len(InBuffer) > pos) Then
            InBuffer = Mid$(InBuffer, pos + 1)
        Else

            InBuffer = ""
        End If
   End If
        
    Call write_log_file(transaction)

End Sub



Public Sub write_log_file(inString As String)
	Print #fhandle, inString;
End Sub

[DataMiser]

What are you using to view the log file? What font are you using?

Your call to write_log_file seems out of place. Why create a function with only one line of code in it? You end up with 4 lines of code instead of one, extra sub routine and an extra variable name none of which is needed.

Apparently you open the file elsewhere and use a global variable for the filenumber. I definitely would not do it this way.

Still whatever is in the var is what will be written to the file.

[roxydogg]

What are you using to view the log file? What font are you using?

Your call to write_log_file seems out of place. Why create a function with only one line of code in it? You end up with 4 lines of code instead of one, extra sub routine and an extra variable name none of which is needed.

Apparently you open the file elsewhere and use a global variable for the filenumber. I definitely would not do it this way.

Still whatever is in the var is what will be written to the file.

I use Notepad to view the file.

I use the sub call numerous places in my code to write debug statements to the file.

When I go to open the file in MSWord it says it is Unicode. Wordpad will not open it.

I can look at the transaction variable in the debugger and it is correct. I moved the write_log_file statement up into the onComm event Sub and it still prints chinese to the log file.

[DataMiser]

So basically you are receiving unicode from your com port and writing that to a file?

As for the sub. It doesn't matter how many places you call it from it should not be done like that. Is a waste of code and makes your program slower.

Consider this

' other code
Call write_log_file(transaction)
End Sub

Public Sub write_log_file(inString As String)
	Print #fhandle, inString;
End Sub

The code below would do exactly the same thing. the difference is you have 1 line instead of 4 and you do not need to call an additional sub routine nor pass an additional variable, The line of code is also shorter than the line you use to call it in your existing code.

' other code
Print #fhandle, transaction
End Sub

[techgnome]

So basically you are receiving unicode from your com port and writing that to a file?

As for the sub. It doesn't matter how many places you call it from it should not be done like that. Is a waste of code and makes your program slower.

Consider this

' other code
Call write_log_file(transaction)
End Sub

Public Sub write_log_file(inString As String)
	Print #fhandle, inString;
End Sub

The code below would do exactly the same thing. the difference is you have 1 line instead of 4 and you do not need to call an additional sub routine nor pass an additional variable, The line of code is also shorter than the line you use to call it in your existing code.

' other code
Print #fhandle, transaction
End Sub

It's debatable... having it in one spot like that allows for ease of shutting it off (deleting the code) and/or redirecting it to something else (console, database, etc) ... At this level, it's more academic and a style choice.

For the record, neither approach is how I'd do it ... but then I have a ready-to-go debugging helper class I can re-use when I need to. It's specific to our app domain language, but it allows me to switch where I log things to.

-tg

[DataMiser]

Don't get me wrong I use a logging function often but the function is self contained and portable.
The part that bothers me is the public file number and the fact that the file is opened and closed somewhere else.

[roxydogg]

Don't get me wrong I use a logging function often but the function is self contained and portable.
The part that bothers me is the public file number and the fact that the file is opened and closed somewhere else.

Understood. It is opened and closed when I start the executable passing in a debug flag argument.