MSCOMM Problems, maybe??

[CIMTEET]

There are three identical systems. I have a barcode scanner hooked up to a serial port on each system. Two of the systems catch everything the barcode is sending and sends it through the code. One system captures the data in the mscomm1.input but does not always transfer it into the strSerial string. Help. What could cause this and what can I do to prevent it.

Greg

 

[CIMTEET]

The 3 systems are not identical. The code is the same. The system that is having problems has much more software on it. It seems that this system does run a little slower. Is there any tricks out there for trapping data in a variable quickly?

Greg

 

[vb5prgrmr]

Don't quite know what you are doing but for test purposes I have used a text box and the change event to capture info from a barcode reader letting the system process the message and "Paste" the information into the text box, but it sounds that you are doing a higher volume than the occasional scan. So check out what services (or other programs) are running and taking up processing and memory.

Good Luck

 

[Diederik]

As you stated yourself "It seems that this system does run a little slower".
Most probably the following is happening:
The scanner sends all data in 1 go, however, as the system is busy assigning CPU-time to all the running processes, the data is NOT put in MSCOMM1.Input completely. Check the input buffer a second time to 'capture' the remaining data...

Diederik

 

[CIMTEET]

Diederik
All the information actually is making it to the MSCOMM1.input. Getting it to the variabe seems to be the issue. Right Now I have the following code:

DO
strSerial = mscomm1.input
counter =counter +1

loop until strSerial <> &quot;&quot; OR Counter >20

Sometimes, the loop will run through 20 times and still not pick it up. Other times strSerial will not catch all the data so I only get 4 or 8 characters. I am going to try, in the loop until statement, len(strserial) > 8. Anyways it seems like the more string processing code I put after the fact the less likely I am to capture the string from the input.

I tried putting the mscomm1.input statement in multiple times outside of a loop and still did not get the results I was wanting.

Thank you
Greg

 

[LazyMe]

Getting incomplete data is not so surprising; Not all bytes may have already arrived at the input buffer, so you'll get the ones that are already in and leave the ones that are yet to be written to the input buffer.

And how do you know that it IS in the mscomm.input, but not put in the string? That is impossible. Are you maybe watching this property by hovering the mouse over it or something like that (which will clear the property....)

Do you know upfront how many characters must be arived in the input buffer for the string to be complete? Or is there maybe a terminating character? Better wait for the number of chars then, or the terminating character....

And last, but not least:
Why are you using a counter in the loop? Wouldn't a timeout in milliseconds be a better solution?

Greetings,
Rick

 

[CIMTEET]

What does the timeout do? Will that wait at the mscomm1.input line or will it loop until the timer runs out? I have never heard of that but it is interesting. It also might sound impossible that the code is not capturing the string into a variable BUT, it is not. I placed a break point underneath the loop and then ran my mouse over both sides of the equal sign.

strSerial = mscomm1.input

99 times out of 100 mscomm1.input would have the proper string. strSerial would end up blank or not all the string that was in the input. There also were times when the variable would have last cycles data. I clear that out now but it wasn't getting refreshed every time the oncomm event fired. This is indrustrial application that will be used possibly 1000 times a day in the future and I need something reliable.

Thanks
Greg

 

[LazyMe]

>>I placed a break point underneath the loop and then ran my mouse over both sides of the equal sign.

Doing this will clear the input buffer; Once you got you intellisence show the contents of the mscomm.input, it's emptied....


The timeout itself will do nothing. It will just ensure that you will not end up in an endless loop if you don't get the correct information within the timeout specified. Mind you that you'll need to implement the timeout yourself (for instance by checking the timer() each time you run the loop.

Greetings,
Rick

 

[Diederik]

Greg,
Using

strSerial = mscomm1.input

will put the current received data stream into your variable. Next occurence will replace it by the next stream...
So something like:

strSerial = strSerail & MSMComm1.input

will give a better result.
Anyway, doing a keyword search on this forum on MSCOMM will give you most probably a solution or at least a good clue.
Also, check the help file (MSDN) on MSCOMM, it contains an example on receiving data...

Diederik