 |
|
|
|
Topic: scomm32.ocx and VB6 Sample
|
| By: Steve V. | Posted on: Jun 30 2016 at 07:04:19 PM | I have a windows 7 PC with a Toledo Scale attached to Com2 at 9600,E,7,1
and no handshaking. I am trying out Scomm32 to see if it resolves all the parity, framing errors, and lockup I am experiencing using MSComm32 before I make the purchase.
The scale is set to output a continuous stream of weight details.
Using Hyperterminal to view incoming data it runs fine and forever without
any problems.
When running the VB6 Sample (not simple) application included with the Scomm32
downloaded package I find the following.
1. No parity or Framing errors - Good!
2. Runs for 2 minutes 20 seconds and hangs requiring killing the VB program. :(
Here are the steps.
Detect ports
Select Com2
Open Port
Data comes in, shown in "Text in", RxD indicator flashing at a steady rate,
After 2 minutes and about 20 seconds The RxD indicator either remains off or stays solid on and the received test display shows data still coming in but at a much slower rate. Close port button does not work. Program is not responding.
Need to kill it.
I would have expected this VB6 sample program to continue to run forever.
I have found that if the close port button is used to close the port, then port open shortly after the close, the data continues to come in normally. However again after 2 minutes and 20 seconds it locks up again.
Is this a limit built into the demo download or do you have some sort of problem
that needs to be resolved or is it caused by the input text box filling up?
Another problem i am having is getting too many bytes on a .Input
SComm1.InBufferSize = 256 'properties of control also set to 256
SComm1.OutBufferSize =256
SComm1.SThreshold =1
SComm1.RThreshold = 1
SComm1.InputLen = 0 'to read all bytes in receive buffer
SComm1.PortOpen = True
strInBuf = SComm1.Input
SComm1.PortOpen = False
strInBuf has 3718 bytes received. I was expecting not much more than 256
Could you explain to me why I am getting so many bytes more than what I expected?
Any help here is appreciated.
| |
| By: Guest | Posted on: Jul 1 2016 at 04:59:03 PM | Yes. I'd say it's the text box filling up.
I'm not looking at the source code so can't be 100% sure but you have the source to the sample project. Look in the sample project source code. If the data is appended to the textbox simply with:
Textbox.Text = Textbox.Text & NewText
Then you will find that it gets very processor intensive as the box fills up because each time data is appended VB has to keep copying the whole string from the textbox and as the string gets bigger it takes longer.
If ever you need to keep appending data to a textbox then appending like that is not good. Personally, if ever I need to append text I use the .SelectionStart propery. like this:
.SelectionStart = 99999999 '// Some big number way beyond the end of the current text
.SelectedText = NewText '// That places the new text instantly at the end of the text
'// bit of a hack but it work. Fast.
Your question about inbuffer size. I think there is a minimum. Any attempt to set below minimum is overridden. Read back the InbufferSize. I think it'll show the actual inbuffer size ignoring what you asked for. 256 byte buffer at 9600 without flow control really is not enough anyway. | |
| By: Mike Janus | Posted on: Jul 1 2016 at 05:08:33 PM | Minimum size is 4096
Reading back InbufferSize will still show the size you asked for but functionally it's going to ignore anything below 4096 | |
| By: Steve V. | Posted on: Jul 5 2016 at 07:54:05 PM | got it working thank you.
| |
|
