-
June 20th, 2007, 01:51 AM
#1
MSComm_OnComm Event
I have an Atmel AVR that is polling some sensors and sending the data to my PC through the comm port. I am using some code that was posted on these forums to display the received data. Something like this:-
Code:
Private Sub MSComm1_OnComm()
Dim InString As String
If MSComm1.CommEvent = comEvReceive Then
If MSComm1.InBufferCount Then
' Read data.
InString = MSComm1.Input
Text1.Text = InString
End If
End If
End Sub
The microcontroller is actually sending 3 different types of data one after the other. If I put a delay in between sending each piece of data then the above code will show each individual piece of data. But I want this to update as quick as possible. If I remove the delay in the MCU then I get more than 1 piece of data, sometimes all of one piece and part of the next and this varies. So it will be difficult to split the data up into useful pieces.
What I need to do is send some sort of "end of data" character from the MCU and modify the MSComm1_OnComm code to only collect the data till this character is received, send this data to another function, then get the next piece of data, keeping in mind the number of characters sent is not always the same. Hope I explained this OK. Any ideas?
-
June 20th, 2007, 01:59 AM
#2
Re: MSComm_OnComm Event
First
Try using Hyper Terminal to see what is Happening when your Device sends data to Comm Port.
I.E See what is the Starting Character & Last Character
Second
Then in this Forum do a search on Send or Receive SMS through GSM Modem
Which uses the same OnComm Event , U'll find some Answers what is happening in the OnComm Event.
-
June 20th, 2007, 02:13 AM
#3
Re: MSComm_OnComm Event
Originally Posted by RajWolf
First
Try using Hyper Terminal to see what is Happening when your Device sends data to Comm Port.
I.E See what is the Starting Character & Last Character
Thanks for the fast reply. I am writing the code for the device and at the moment I am adding X, Y and Z as the first character of each piece of data. But I am not adding anything at the end. Is there some usual character used to terminate?
In Hyperterminal I just get a continual stream of characters.
I'll do some searches as you suggested. Thanks.
-
June 20th, 2007, 09:06 AM
#4
Re: MSComm_OnComm Event
If the number of bytes of a "message" or datablock is constantly 3 (or any constant number), you could use the MSComm1.RThreshold value to determine the firing of the On_Comm event. If you set this property to 3, then the On_Comm event is fired only after 3 bytes have been received.
If your data type is ASCII, (that is readable characters and digits) then the Carriage Return (chr(13)) would be an end-of-line character to choose.
If your data type is binary, you'd have to tell us what range of values each byte might take...
If you tranfer bnary, you could change to ASCII by converting a byte into two hex characters and transfer them, followed by a CR (13) to indicate end of line.
In the receiver sub you have to reconvert each pair of characters back into binary.
Key to a solution is the type of data you are tranfering and if the number of bytes is constant within a block. Tell us about it.
-
June 20th, 2007, 04:18 PM
#5
Re: MSComm_OnComm Event
Originally Posted by WoF
If the number of bytes of a "message" or datablock is constantly 3 (or any constant number), you could use the MSComm1.RThreshold value to determine the firing of the On_Comm event. If you set this property to 3, then the On_Comm event is fired only after 3 bytes have been received.
Thanks for your help. I have read most of your other posts regarding MSComm before I posted this, but I am still unsure.
The number of bytes per message is not constant. It will vary.
Originally Posted by WoF
If your data type is ASCII, (that is readable characters and digits) then the Carriage Return (chr(13)) would be an end-of-line character to choose.
If your data type is binary, you'd have to tell us what range of values each byte might take...
The data type is ASCII characters. I convert the integers to ASCII on the AVR.
Originally Posted by WoF
If you tranfer bnary, you could change to ASCII by converting a byte into two hex characters and transfer them, followed by a CR (13) to indicate end of line.
In the receiver sub you have to reconvert each pair of characters back into binary.
Key to a solution is the type of data you are tranfering and if the number of bytes is constant within a block. Tell us about it.
I'll stick with ASCII for now and the bytes will not be constant. I need to change my MSComm_OnComm routine so it separates the incoming data at a CR(13). Is that easy to do?
-
June 20th, 2007, 05:21 PM
#6
Re: MSComm_OnComm Event
Well I did this, which worked if I had a small delay in the AVR between sending each message. Without the delay I think it all happens too fast for the VB6 code to keep up with. I set InputLen and RThreshold to 1.
Code:
Private Sub MSComm1_OnComm()
Dim InChar As String * 1
If MSComm1.CommEvent = comEvReceive Then
If MSComm1.InBufferCount Then
InChar = MSComm1.Input
If InChar = vbCr Then
Parse_Data (InString)
InString = ""
Else
InString = InString & InChar
End If
End If
End If
End Sub
Is there a faster way for the messages to be split at the vbCr? I want to work this data as fast as possible.
-
June 21st, 2007, 01:51 AM
#7
Re: MSComm_OnComm Event
Try Using Do While Loop instead of If condition
i.e.
Code:
Private Sub MSComm1_OnComm()
Dim InChar As String * 1
If MSComm1.CommEvent = comEvReceive Then
do
InChar = MSComm1.Input
If InChar = vbCr Then
If len(InString) > 0 then
Parse_Data (InString)
InString = ""
End If
Else
InString = InString & InChar
End If
Loop While Comm1.InBufferCount
End If
End Sub
-
June 21st, 2007, 07:09 AM
#8
Re: MSComm_OnComm Event
Originally Posted by RajWolf
Try Using Do While Loop instead of If condition
Thanks mate, that did it.
-
June 21st, 2007, 11:22 AM
#9
Re: MSComm_OnComm Event
This may or may not help, but I hope it does. I just want to introduce an algorithm that helped me in a recent, similar situation.
You said that the returned data packets are of different sizes. You can use this to your advantage if you use the CR or chr$(13) character as your end of message indicator from the microcontroller.
My problem was I had to poll the same controller for the first 16 channels, which was a 68 character response, and in a separate command, channels 17-24, which returned a 36 character response. Now, sometimes they would run over each other, or the packet would show up in the buffer, starting in the middle of the message.
My solution used the facts: Every message began with 'A', every message ended with 'CR' or ascii chr$(13), the sizes of the packets were either 68 or 36 characters in length.
What I did was increase MSComm1.Rthreshold to about 170, i.e. to guarantee that both messages were in the buffer before the OnComm event fired.
After this, I used the InStrRev function to find the locations of all the carriage returns in the 170 character string. After finding these locations it was easy to find the differences, and wala, my 36 character and 68 character messages were isolated and ready to be converted form hex to decimal for useful display of temperatures, etc. on the GUI.
'Hello World'
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|