Search String must be Specified issue.

[JimVB31]

Hi I am wondering if I could get some insight into a problem that I am having at the moment. Although I am not having trouble receiving 1 type of data, I am at a loss as to receive 2 types and putting the result of the 2 types of data in the appropriate label captions. In other words I am just having the issue with multiple readings--I am able to do it with one. For example I want to receive direction and put the result in a label. And at the same time, put a voltage result in another label. I am also using an RS232 to RS485 converter with auto tx/rx switchover. Below is what I have so far and would appreciate any assistance. Thank you in advance.

Option Explicit
Dim dir1 as string
Dim dir2 as string
Dim V as string
Dim V2 as string
Private Sub Form_load()
mscomm1.rthreshold = 1
mscomm1.inputlen = 2
mscomm1.comport = 2
mscomm1.settings = "9600,n,8,1"
mscomm1.portopen = true
end sub
Private Sub Mscomm1_OnComm()
If Mscomm1.commevent = comevreceive THEN
Dir1 = Mscomm1.input
Dir2 = Mscomm1.input
labelDir.caption = dir1 & dir2 'puts result of direction in label
ELSE
V = mscomm1.input
V2 = mscomm1.input
labelvolts.caption = V & V2 'puts result of Voltage in label
ENDIF
end sub

 

[Foada]

What kind of data are you expecting? You have the receive threshold property set to receive a single character but you are attempting to read 2 characters as the input length is set to 2. The single character threshold is going to fire an event at which point you will be pulling 2 characters from the input buffer into Dir1. Depending on the data that you are expecting you may need to adjust these properties and then read the whole buffer and parse out the data.

If you choose to battle wits with the witless be prepared to lose.

 

[tedsmith]

I presume you mean Type1 sends 1 byte and Type2 sends 2 bytes?

'General declaration
Dim Buffer as String,a as long

In Load - mscomm1.inputlen = 0

Private Sub Mscomm1_OnComm()
If Mscomm1.CommEvent = comevreceive THEN
  For a=1 to 10000:next 'on a fast computer use a small delay  to give it time to read both bytes if there are 2.
If the volts reads the direction increase the delay value above.
  Buffer = Buffer & MsComm1.input
  If len(Buffer)=2 then
    '2 byte received so
     labelDir.caption =Buffer
  else
     '1 byte received
     labelvolts.caption = Buffer
  End if
  Buffer=""
End If
End Sub

Note.

In a fast computer, the Oncomm can fire quicker than the bytes are received so you have to add data in an externally dimensioned buffer until they are the right size or some special end code received like a vbcr thta you find with Instr

Also

If Mscomm1.CommEvent = comevreceive THEN
. . . . .
ELSE
(Nothing will ever happen here except if there is corrupted data)
ENDIF

 

[JimVB31]

Thanks Tedsmith and Foada,

Tedsmith--What I mean by type1 is NE,SE,SW,NW, N, S, E,W. Since I am using a microcontroller, I had to program it to send "Dir1" for N,S,E,W and "Dir2" for E, W as compass directions inbetween. It definitely sends correctly to VB and type2 is the same reasoning, but with "v" being "1", "2", "3" up to 5volts. v2 sends .55, .75 and so on. This also works correctly. It's just writing code so VB knows the difference to put the data in the correct labels. I will give your suggestion a try as it seemed to open my eyes a bit to the problem I am having.

 

[JimVB31]

Tedsmith--I seem to have it working correctly. I had to modify the code somewhat, though. I don't need LEN since I am not dealing with length--just data format(I think that's what you call it). Plus rather than using the FOR/NEXT delay, I always use SLEEP instead and I am not sure if I need the delay in my case. I will show you how in Visual Basic at the end, if you do not know already.

IF Mscomm1.ComEvent = ComEvReceive THEN
For a = 1 to 10000: Next
buffer = buffer & mscomm1.Input

If (buffer) = Dir1 & Dir2 THEN
labelDir.Caption = buffer

ELSE
LabelVolts.Caption = buffer
END IF

buffer = " "
END IF



To use Sleep in VB. EX. Sleep 5000
Option Explicit
Private Declare Sub Sleep Lib "Kernel32" (ByVal dwMilliseconds As Long)

Thanks for the push in the right direction Tedsmith.

 

[tedsmith]

Strange
I always though the ComEvent = ComEvReceive (value of 2) when valid uncorrupted data was received.
If not you aren't receiving the data so how can you get anything valid after ELSE?

What value is ComEvent after ELSE?

Usually if you get something after ELSE if you have garbage caused by a different baud rate in the transmitter to the computer.

If you can reprogram the microcontroller, it might be better to end each bit of data by a unique character to denote what type of data it is Eg Chr(1) & Chr(2)
Use a character not otherwise sent.

You don't then need a delay
-----------
Declare Buffer as string 'at top of page

Sub
IF Mscomm1.ComEvent = ComEvReceive THEN
buffer = buffer & mscomm1.Input 'accumulate data
If Right(buffer,1)=Chr(1)) then
labelDir.Caption = Left(buffer,(len(Buffer)-1)'remove chr(1) from end if it is visible
buffer = " "
end if
If right(buffer,1)=Chr(2)) then
labelVolts.Caption = Left(buffer,(len(Buffer)-1)
buffer = " "
end if
End IF
if Len(Buffer)>3 then Buffer="" 'or max length +1 of any of your data. Start again just in case no end chr is detected
END Sub

 

[JimVB31]

Tedsmith--yeah it appears I jumped to the conclusion that it worked correctly. Once I programmed the micro-controller for both data activities, the VB GUI put both results into the same label.caption, LOL. In addition the data does get corrupted everytime there is a change in the data activity. However after about a second the data does appear correctly since I have the micro-controller sending the data sequencially. I will look into what you wrote previously and get back to you either way. thanks!

 

[JimVB31]

TedsSmith--sure thing! Programming the micro-controller to send those characters at the end helped quite a bit and ensured the data to go where it is supposed to. Thank you very much. I will keep this thread in mind if I should have another question, since I believe an Email is generated to you. This knowledge will help me to be a better programmer. Thanks again.

 

[tedsmith]

I started programming on microprocessors in 1981 but once PCs became available havent used them for many years.

Being retired, I am interested in fiddling with microcontrollers but wonder what one to use.

What controller do you find the most useful and what software do you use to write programs?

I have in mind an application to show a flashing speed limit LED sign out the front of schools, morning and afternoon during only school days but not when there is a holiday.

Because certain public holidays are on different days each year, it would need a date clock and calendar that could be changed on site every 5 years by say a removable cheap camera memory card and would be powered by a solar panel.

To save power and attract attention, I would flash the numbers and have the red circle "rotating" so only a few LEDs were on at a time.

 

[JimVB31]

You're in luck. parallax.com just came out with resonably priced solar accessories.

Tedsmith--I am using a Basic Stamp II with a MAX485 chip to send & receive information over 200' of RJ45 to a RS232 to RS485 converter on my laptop. I am just about done with what I am doing and right on schedule to finish in a couple of months. The Basic stamp is the only micro-controller I have played around with since I only have about 4yrs experience in robotics and technology. I didn't get my electromechanical technology degree until I was 28. I wish I would have taken an interest earlier in my life.

There are many types of controllers and some you probably are familiar with; such as, 8051, AVR, Atom and Atmel.

The stamp can be interfaced with just about anything imaginable, including speed radar. Another reason I like the Stamp is because any pin can be used to send and receive data with SEROUT & SERIN. You can find more info--along with learning kits--at parallax.com. You probably shouldn't have too many issues with the "PBASIC" Stamp language since you have a lot of experience in programming.

 

[tedsmith]

What I said earlier is not quite correct.
The vb6 OnComm fires when the number of characters received equals the Inputlen setting.

If you set the inputlen to the length of the expected data batch, you can get problems if a character is missed due to noise or weak signal and you dont get enough characters to fire the sub. When the next batch of data arrives the first few bytes become attached to end of the first batch and everything gets out of sync.
Better to set input len to 0 so the sub fires as soon as possible on each byte or after a few bytes if sending at high baud rates.
Then you use the software to accumulate the data and sort out batches are always received correctly and clear the buffer for the next batch as per my example.