Topic: A difference COMM32 and MSCOMM32
|By: mjohnm||Posted on: Oct 24 2017 at 02:42:01 PM|
|A very handy difference between COMM32 and MSCOMM32 is the fix for the error 8020 bug. However, when I switched my VB6 code to COMM32 my code failed. I have a tight loop in which I send out a command then receive a reply from the COM port. With COMM32 the code stalls trying to get the input because .Input remains empty until I put a DoEvents() in the loop. Unfortunately that breaks my code because this causes the order of task execution changes in my rather large complex code. Does stuffing the input buffer with incoming data have a lower priority in SCOMM than it does in MSCOMM32? |
I'm trying to fix the issue using "in use" semaphores but run into even bigger problems. I realize there is unlikely to be a work around for COMM32, but thought people might like to know of this incompatibility.
|By: Guest||Posted on: Oct 24 2017 at 07:25:09 PM|
|Try setting the .OverlappedIO property to false.|
|By: Support||Posted on: Oct 24 2017 at 07:28:07 PM|
|mjohnm, please email us. We'd like to send you an update to try.|
|By: mjohnm||Posted on: Oct 25 2017 at 12:02:12 PM|
|Guest: The documentation only discusses .OverlappedIO in terms of sending data, not receiving it. Do you think changing it to False would help?|
Support: Thanks for the offer - I have just sent email to you.
|By: Guest||Posted on: Oct 26 2017 at 12:15:50 PM|
|I think your problem is related to sending.|
From your post it sounds like you put data into the transmit buffer. OverlappedIO means that the .Output method returns immediately and the data is sent in the background. But in your case you've immediately gone into your closed loop basically preventing anything from happening. So, I reckon, your TX data hasn't actually been sent, it's still somewhere in the buffers and you're in a loop waiting for a reply that will never come.
The reason your call to DoEvent works is because that actually allows the TX process to complete.
My suggestion to disable the OverlappedIO property simply tells SComm, when sending, to make sure all of the data has actually been sent before returning control to the application. You can then go into your closed loop and should get your reply.
|By: mjohnm||Posted on: Oct 31 2017 at 01:02:49 PM|
|Guest: Thank you very much for your suggestion - disabling OverlappedIO fixed the issue. Also a special thanks to Iam in support who came straight to my aid to offer the update. Simply put, SCOMM32 solved all my problems so I give it my strongest endorsement.|
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.