MScomm1 Prob sending specific Char Lengh

Hi All

Could one of you experts have a look at the code below I have a problem where I send data though com1 which is 13 chars long and get sent to textbox1 and if the data sent is less than 13 or more than 13, when i send the next data which is 13 chars long for some reason it contains the last char of the data from the data before in front of the new data what i would like for it to reject anything thats less than 13 or more than 13 maybe bring a msg up if it is. sample 12345678901234 is sent but is 14 chars long then after i send 13 chars in the textbox becomes 4123456789012

Option Explicit

Private strRX As String

Private Sub Form_Load()
' Fire Rx Event Every Two Bytes
MSComm1.RThreshold = 1

' When Inputting Data, Input 2 Bytes at a time
MSComm1.InputLen = 13

' 9600 Baud, No Parity, 8 Data Bits, 1 Stop Bit
MSComm1.Settings = "9600,N,8,1"
' Disable DTR
MSComm1.DTREnable = False

' Open COM1
MSComm1.CommPort = 1 ' Set Com Port to 1
MSComm1.PortOpen = True ' Turn on Com Port
MSComm1.InBufferCount = 0 ' Clear Buffers
End Sub

Private Sub MSComm1_OnComm()
'
' Assumes RTHreshold Property is set to a value > 0
' (Recommended value is 1)
'
Static strBuffer As String
Dim strData As String
'Dim strRX As String
Dim boComplete As Boolean
Select Case MSComm1.CommEvent
Case comEvReceive
strData = MSComm1.Input
strBuffer = strBuffer & strData
Do
If Len(strBuffer) >= 13 Then
strRX = Mid$(strBuffer, 1, 13)

Text1.Text = strRX
MSComm1.InputLen = 0
'
' rest of your code goes here - strRX contains the 13 characters sent
' After you've done all your processing add the following code
'
If Len(strBuffer) = 13 Then
strBuffer = ""
boComplete = True
Else
strBuffer = Mid$(strBuffer, 14)
End If
Else
boComplete = True
End If
Loop Until boComplete = True
End Select
End Sub

Regards
Steve

Well it would help if you used code tags around your code so as to retain indentation for readability
It would also help if you used proper terminology. You post says that you are having trouble sending data but your code is for receiving data.

As is it looks like it should parse out 13 characters if 13 or more are sent.

It also looks like someone else wrote this code for you as an example

@DataMiser

Yes correct the code is for receiving data. i am using another computer for sending data

Yes Doogle Wrote the example just waiting for him too have a look I meant to put @doogle instead of Hi All

regards

steve

The problem stems from the Application Protocol (or, rather, the lack of one). When receiving data you have no idea when a complete 'message' has been received. At the moment you're just collecting the first 13 bytes sent. If the device sends less than 13, whatever has been received is buffered until at least 13 characters have been received. If more than 13 are sent, the 14th and following are buffered.
eg
Device sends: 1234567890abcd (ie 14 characters)
You Receive: 1234567890abcd and 'display' 1234567890abc the 'd' is retained in the Buffer
Device then sends: efghijkl
You Receive: efghijkl but wont display anything since there are less than 13 characters in the Buffer (ie it contains defghijkl)

The best you can do is to flush the buffer after receiving 13 characters, but you run the risk of losing data. I can't see a way to tell if and when the device sends an incomplete record without some sort of time out. i.e. If the device is expected to only ever send 13 characters at a time which must be received within, say 10ms, of receiving the first character then you could use a Timer to 'time-out' if 13 characters haven't been receved within that time period. That will introduce all sorts of other issues. (and I don't believe that's the case, looking at earlier posts)

Is there no way that the sending device can be 'persuaded' to always terminate the 'message' with some sort of 'End of Message' signal? At the moment you're trying to solve the age-old problem of 'How long is a piece of String?' :)

@Doogle

Thank you for the reply intresting reading the device is always spose to send 13 characters but ever so often i revcive þ01234567890ab when it should of been 01234567890abc not sure why i am getting þ which is asc code(231) when this happens it buts it all future numbers out of sequance i.e next number will be c123456789ab.

What would I need to do for it to flash the data after 13 characters then I could do some testing to see if this would work, another thought I have is there a way of if it finds þ at the begin of the data then use 2-14 characters instead of 1-13 that should work as well.

Once again thank for you help

Regards
Steve

Steve,

You could add some code at the start of the OnComm event to remove any / all ASC 231 characters before you try to unblock the record

Code:

---

Dim intPos As Integer
    Case comEvReceive
        strData = MSComm1.Input
        strBuffer = strBuffer & strData
        '
        ' Remove any / all ASC 231 characters from the buffer
        '
        Do
            intPos = InStr(strBuffer, Chr(231))
            If intPos > 0 Then
                '
                ' Move the data up to but not including the ASC 231
                '
                If intPos <> 1 Then
                    strBuffer = Mid$(strBuffer, 1, intPos - 1)
                    '
                    ' If there's data after it then move that as well
                    '
                    If intPos + 1 <= Len(strBuffer) Then
                        strBuffer = strBuffer & Mid$(strBuffer, intPos + 1)
                    End If
                Else
                    strBuffer = Mid$(strBuffer, 2)
                End If
            End If
            '
            ' Repeat until there's no ASC 231s in the Buffer
            '
        Loop Until intPos <= 0

---

EDIT: You need to find out why it's sending spurious characters and / or whether an ASC 231 means something - eg it's had some sort of problem. Also whether it can send any other 'special' characters which you're not expecting. Do you have any documentation for the device in question that may help you understand what it could possibly send that you're not expecting ? Just 'throwing them away' may not be the right solution.

@Doogle

its a Siemens PLC that sends the data not a computer the person the programed PLC cannot unstand why we getting this character.
i just trying this in a blank project i getting error else without if below (marked in red Below) can I still use strRX has it not mentioned in your new code i also added this not sure if its correct Dim instr As String, Dim intpos As String, I have a timer2 that runs after the data sent
i would like to try as an option to put in there to flash the data

cheers
steve.


Option Explicit

Private strRX As String
Private Sub Form_Load()

' Fire Rx Event Every Two Bytes
MSComm1.RThreshold = 1

' When Inputting Data, Input 2 Bytes at a time
MSComm1.InputLen = 13

' 9600 Baud, No Parity, 8 Data Bits, 1 Stop Bit
MSComm1.Settings = "9600,N,8,1"
' Disable DTR
MSComm1.DTREnable = False

' Open COM1
MSComm1.CommPort = 1 ' Set Com Port to 1
' MSComm1.PortOpen = True ' Turn on Com Port
MSComm1.InBufferCount = 0 ' Clear Buffers
End Sub

Private Sub MSComm1_OnComm()
'
' Assumes RTHreshold Property is set to a value > 0
' (Recommended value is 1)
'
Static strBuffer As String
Dim strData As String
'Dim strRX As String
Dim instr As String
Dim intpos As String
Dim boComplete As Boolean
Select Case MSComm1.CommEvent
Case comEvReceive
strData = MSComm1.Input
strBuffer = strBuffer & strData
'
' Remove any / all ASC 231 characters from the buffer
'
Do
intpos = InStr(strBuffer, Chr(231))
If intpos > 0 Then
'
' Move the data up to but not including the ASC 231
'
strBuffer = Mid$(strBuffer, 1, intpos - 1)
'
' If there's data after it then move that as well
'
If intpos + 1 <= Len(strBuffer) Then
strBuffer = strBuffer & Mid$(strBuffer, intpos + 1)
End If
End If
'
' Repeat until there's no ASC 231 in the Buffer
'
Loop Until intpos <= 0

Text1.Text = strRX
'

If Len(strBuffer) = 13 Then
strBuffer = ""
boComplete = True
Else
strBuffer = Mid$(strBuffer, 14)
End If
Else
boComplete = True
End If
Loop Until boComplete = True
End Select
End Sub
-

I made a change to the original. The complete routine should look like this

Code:

---

Private Sub MSComm1_OnComm()
'
' Assumes RTHreshold Property is set to a value > 0
' (Recommended value is 1)
'
Static strBuffer As String
Dim strData As String
'Dim strRX As String
Dim boComplete As Boolean
Dim intPos As Integer
Select Case MSComm1.CommEvent
    Case comEvReceive
        strData = MSComm1.Input
        strBuffer = strBuffer & strData
        '
        ' Remove any / all ASC 231 characters from the buffer
        '
        Do
            intPos = InStr(strBuffer, Chr(231))
            If intPos > 0 Then
                '
                ' Move the data up to but not including the ASC 231
                '
                If intPos <> 1 Then
                    strBuffer = Mid$(strBuffer, 1, intPos - 1)
                    '
                    ' If there's data after it then move that as well
                    '
                    If intPos + 1 <= Len(strBuffer) Then
                        strBuffer = strBuffer & Mid$(strBuffer, intPos + 1)
                    End If
                Else
                    strBuffer = Mid$(strBuffer, 2)
                End If
            End If
            '
            ' Repeat until there's no ASC 231 in the Buffer
            '
        Loop Until intPos <= 0
        Do
            If Len(strBuffer) >= 13 Then
                strRX = Mid$(strBuffer, 1, 13)
           
                Text1.Text = strRX
                MSComm1.InputLen = 0
                '
                ' rest of your code goes here - strRX contains the 13 characters sent
                ' After you've done all your processing add the following code
                '
                If Len(strBuffer) = 13 Then
                    strBuffer = ""
                    boComplete = True
                Else
                    strBuffer = Mid$(strBuffer, 14)
                End If
            Else
                boComplete = True
            End If
        Loop Until boComplete = True
End Select
End Sub

---

If it's always an ASC 231 then it's most likely a 'problem' with the PLC code (if it was 'electrical noise' I'd expect it to be a random value). If it's any help, ASC 231 (Hex E7) is the character '7' (Hex 37) with the top bit set. There may be some 'untidy' PLC code which is not always assembling the characters correctly. (No offence to the PLC Programmer intended !)

EDIT:
I'm guessing that the PLC RS232 code is not running within an Interrupt routine so it could be possible that an Interrupt is being serviced by the PLC whilst it's assembling the characters to send. This could cause an issue if that Interrupt routine modifies something that the RS232 code doesn't expect to change. It could be a simple matter of disabling Interrupts within the PLC whilst the RS232 code is executing and then turning them back on when it's finished. (But if they're going to have to modify the PLC code, perhaps you could persuade them to stick a Carriage Return at the end of each message whilst they're at it - it would make your life so much simpler !)

Another possible problem could be the timing loop within the PLC. If it's 'creeping' it's possible that a bit could be misrepresented (ie it's sending a one instead of a zero. This could be caused if the start bit is too short)

You may like to add something at the end of the OnComm Event before the End Select - this will notify you if there's been a Framing Error on Receive.

Code:

---

    Case comEventFrame
        MsgBox "Framing Error"
   
End Select

---

Below post

@doogle
I am sending þ280620122858 but the þ still apears in the Textbox

I just tried it with asc 77 which is a M that worked not working with 231 if you do ALT 231 on keyboard you get þ but some reason it cannot find þ

I have a timer2 that runs after the data sent i would like to try as an option to put in there to flash the data like we mentioned before

Regards
Steve

That spurious character is not ASC 231 it's ASC 222. Change Chr(231) to Chr(222) in the code I posted and it should 'go away'

EDIT: There doesn't seem to be much correlation between the ASC Code and the keyboard input. ALT+231 produces þ but Debug.Print Chr(231) produces ç whereas ALT+222 produces Ì but Chr(222) produces þ

EDIT2: BTW all that extra code I put in to remove the spurious character can be replaced with one statement, the code now looks like this::

Code:

---

Private Sub MSComm1_OnComm()
'
' Assumes RTHreshold Property is set to a value > 0
' (Recommended value is 1)
'
Static strBuffer As String
Dim strData As String
'Dim strRX As String
Dim boComplete As Boolean
Dim intPos As Integer
Select Case MSComm1.CommEvent
    Case comEvReceive
        strData = MSComm1.Input
        strBuffer = strBuffer & strData
        '
        ' Remove þ characters if there are any
        '
        strBuffer = Replace(strBuffer, Chr(222), vbNullString)
        Do
            If Len(strBuffer) >= 13 Then
                strRX = Mid$(strBuffer, 1, 13)
           
                Text1.Text = strRX
                MSComm1.InputLen = 0
                '
                ' rest of your code goes here - strRX contains the 13 characters sent
                ' After you've done all your processing add the following code
                '
                If Len(strBuffer) = 13 Then
                    strBuffer = ""
                    boComplete = True
                Else
                    strBuffer = Mid$(strBuffer, 14)
                End If
            Else
                boComplete = True
            End If
        Loop Until boComplete = True
End Select
End Sub

---

Also BTW, where the device is sending þ280620122858 what should the first character be?

Removing the þ leaves you with 12 characters which implies it's not a 'spurious' character but rather, a mal-formed byte. You'll pick up the first character of the next transmission as the 13th byte of the previous transmission. That will give you incorrect results and you'll always be at least 1 character out in subsequent transmissions. I think you need to find out what's going on in the PLC and get it fixed.

Is it possible to do any 'independent' checks to confirm that the PLC is actually sending the þ rather than some sort of 'corruption' on the way to the receiver ?

When it does appear, is it always the first byte of the transmission or does it appear in 'random' positions ? If it is always the first byte and you can confirm that the device is actually sending þ, then there's a strong implication that there's a timing issue in the PLC code when sending the first Start Bit.

@doogle þ still shows up in textbox

would i put this in timer2 to flush the buffer after receiving 13 characters strRX = ""

Steve: Can you post the code you're using please? The 'Replace' should be removing the þ (BTW I've edited my previous post)

Its work with 254 got info from here

http://www.fileformat.info/info/unic...r/fe/index.htm

when the þ gets removed I am getting my 13 characters and what i do is i use MSComm1.Output = strRX so PLC verifys i got the correct data so its doing what i want and its not losing the a character I.e i am getting 13 characters and not 12

Yup, that also produces a þ. It's a very suspicious value (Binary '11111110') which may interest your PLC Programmer.

@Doogle

Thank you for your help again