 |
|
|
Topic: Is Scomm32 slower to output than mscomm?
|
By: Richard | Posted on: Dec 16 2015 at 05:31:54 PM | Because of Windows 10 I have to find an alternative to MSCOMM32.
Scomm32 looks good so I tried it as replacement in an exiting app without any code changes.
Found that after .Output the out buffer did not get processed unless a doevents loop was placed immediately after .output.
Also noted that for MSCOMM32 checking OutBufferCount immediately after .output is always 0 for small messages, so the buffer is transmitted quickly without any doevents. But Scomm32 seems much slower, the doevents loop mentioned above can take approx. 0.03 secs before OutBufferCount is zero.
This slight difference in timing could lead to many problems in our app which communicates with equipment from many manufacturers and its not possible to test them all again. Any comment would be much appreciated. | |
By: Guest | Posted on: Dec 16 2015 at 05:46:32 PM | SComm32 has a property called .OverlappedIO
Try setting that to false before opening the port. | |
By: Guest | Posted on: Dec 16 2015 at 06:34:16 PM | Thanks, that seems to make the output behave much like MSCOMM32. Does OverlappedIO have any effect on the receive buffer processing please? | |
By: Guest | Posted on: Dec 16 2015 at 07:16:48 PM | In your first post you mentioned that you needed to call DoEvents directly after doing .Output
That would only be necessary if your program was designed to sit in a loop and not release the processor.
If you're just sat in a loop outputting data and waiting for data by reading inbuffercount in a loop then OverlappedIO won't make any difference. | |
By: Richard | Posted on: Dec 16 2015 at 11:23:57 PM | The program is not designed to sit in a loop and not release processor, so I'm so sure why the DoEvents loop was necessary. In any case the program is only required to send short messages so having OverlappedIO turned off is fine for our requirements.
But still wondering if what are implications for the receive buffer?
I see that you can switch off OverLappedIO in Custom property page, that's great idea thanks. | |
By: Guest | Posted on: Dec 17 2015 at 04:30:48 PM | OverlappedIO only really affects the transmit side of things.
| |
By: Guest | Posted on: Mar 26 2023 at 08:57:44 AM | I just experienced this issue in VB6 when using a USB to Serial adapter with the CH340G chip set. Using a simple polling routine (rather than OnCommEvent) everything was fine with FTDI or Prolific 2303 HXD chip sets using MSComm32, but using Scomm32 with the CH340G it took an additional 60ms to 80ms (just using GetTickCount) for the output buffer to empty and transmit the 117 character non-overlapped test string at 9600, N, 8, 1. It seems that testing for the output buffer to reach 0 with a DoEvents loop appeared to be trustworthy, but I decided to use a DoEvents millisecond timer instead. | |
|