Topic: Setting DTREnable hangs for 1 second when using LavaLink KMDF ethernet-RS232 driver.
|By: RsGuest||Posted on: Sep 2 2014 at 04:51:29 AM|
|LavaLink (ethernet-RS232 converter) converted their drivers for Win 7 to KMDF and made then incompatible with Mscomm32 because it generates a RunTime Error 8020. LavaLink claims there is nothing they can do and claimed I would have to change to "Async Professional" if I wanted to stay with VB6. We have a huge VB6 codebase so I tried APAX but it required a lot of code changes and seemed a bit unstable. So I purchased Scomm32 ver 8.1.6. It required no changes and reads the LavaLink driver serial virtual comm port, but it hangs for 1 second whenever I change the DTREnable signal. This only happens with the LavaLink KMDF driver and none of the other 3 WDM drivers I have tried from other manufacturers.|
I checked with a scope and the DTEnable signal changes as soon I issue the command, but then the command does not return for 1 second. I do a lot of software signalling so this makes SComm32 unusable for us.
|By: RsGuest||Posted on: Sep 2 2014 at 04:07:11 PM|
|PS - It may be a driver issue but the APAX ocx control does not hang - it returns immediately when we set Comm.DTEEnable = True or False.|
|By: Support ||Posted on: Sep 2 2014 at 09:07:37 PM|
|Is it only DTR ? Or is it also RTS ?|
Either way, it sounds as if the status of dtr is being changed quite quickly but then, for some reason, the driver hangs around for a while waiting for confirmation from the remote rs232 device that the status was set.
If apax control is sending the command to the driver asynchronously (ie not waiting for the response) it could return immediately.
Our sComm32 ocx sets DtrEnable and then waits for the driver to confirm that the status has been set.
I never heard of a driver taking such a long time. Give me some time and I'll see if there's some way that we can issue the DtrEnable method asynchronously.
|By: RsGuest||Posted on: Sep 3 2014 at 06:13:52 PM|
Thank you so much for your quick response and insight.
Yes - you are correct - I just tried the RTSEnable and it hangs for 1 second also.
(Setting PortOpen = True takes 13 seconds to respond vs APAX 18 seconds. Setting PortOpen = False takes 4 seconds to respond vs APAX Close which takes 0 seconds but does not work since OnComm still receives events after that.)
Sorry to ask you to add the asynch calls due to this driver. I would greatly appreciate it, otherwise I will soon have to implement APAX to meet our shipping schedule.
|By: Guest ||Posted on: Sep 3 2014 at 06:45:26 PM|
|It takes 13 seconds to open the port? (18 seconds with apax)|
Are you serious?
You did say you're using an ethernet/rs232 device but those delays are not really acceptable. Have you tried other ethernet /rs232 devices?
What kind of network are you working with? Is the Ethermet/RS232 device on the same network as the computer where the application is running or is it miles away via slow internet.
|By: RsGuest||Posted on: Sep 4 2014 at 05:53:00 PM|
It seems to take 13 seconds for the LavaLink driver to negotiate with the Lava Ether-serial link dual port converter on a local ethernet network.
We started using Lava many years ago when it was the least expensive converter on the market, and we need to continue to support the existing units with their newer driver as our older customers are forced to migrate to Win 7. Lava's old XP driver ran fine with MScomm32.ocx but their new Win 7 kernal driver does not. The Lantronix virtual port drivers do not seem take as long to open and we may migrate to them in the future.
We can tolerate the 13 second connect time but not the 1 second DTEEnable time, so I am hoping that Support can solve our dilemma in the next few days since I really prefer the Scomm32 product over APAX.
|By: Support ||Posted on: Sep 4 2014 at 08:46:38 PM|
|RsGuest. Would you do a couple of tests for me please.|
If you toggle the .Break property on and back off again does that also take a long time ?
When you use the .Settings property does that take any time?
Another question - you said that when you set the DTREnable property the scope shows that the line state changes instantly and the delay occurs 'after the state change. You also said that RTSEnable also delays but does it behave exactly the same? or is there a slight delay 'Before' the scope shows the state change. If you see what I mean.
|By: RsGuest||Posted on: Sep 6 2014 at 02:31:07 AM|
No - toggling Break does not take any discernible time.
No - setting Settings property before the port is opened does not take any discernible time.
No - there is no discernible time between toggling the RTSEnable setting and seeing the signal change on the scope. It seems to be similar to the DTEEnable. It changes immediately and then the function call returns after 1 second.
|By: Support ||Posted on: Sep 6 2014 at 01:15:01 PM|
|We've made a change to the DTREnable and the RTSEnable code.|
If you download the trial again in should be version 8.0.7
Please try that one and let us know if it's any different.
|By: RsGuest||Posted on: Sep 9 2014 at 01:56:41 AM|
Sorry - no difference - the delay is still there.
I downloaded the free trial version.
I went to Control panel, Programs, Scomm32 uninstall.
I installed the new install_trial_scomm32.exe
I clicked on properties - and it said 18.104.22.168 9/5/2014 5:56PM
I unregisted it and made sure my code would not run.
I re-registered it (Regsvr32 c:windowssyswow64scomm32.ocx)
I restarted my app.
It still seems to have a one second delay returning after DTEEnable and RTSEnable.
Thank you for the rapid response.
Any other suggestions?
|By: Support||Posted on: Sep 10 2014 at 11:34:03 AM|
|RsGuest - would you send us an email.|
support at comm32 dot com
Reply - add a comment to this topic.
You may enter letters, numbers and standard punctuation only. HTML and other scripts/tags will be rejected.