Host Engineering Forum
General Category => DirectSOFT => Topic started by: johnr on December 26, 2014, 02:21:49 PM
-
I noticed a subtle change in the comm server that comes with the new DirectSoft 6. I know it's intended as an improvement but it is going to be a significant nuisance to many of us, and I hope something can be done to address it.
In previous versions of DS, if the existing commserv.rst user definitions file contained serial comm links that referenced non-enabled COM port numbers (that is, COM port numbers that did not have corresponding COMXEnabled=1 statements in the DS500.INI file), these comm links would be unconditionally dumped from the file by the comm server. On the flip side of that statement, as long as a given COM port# was enabled in the file, it didn't matter whether that logical COM port was actually available at the present time, the link would be preserved.
With DS6, it seems that this behavior has been changed. Now, regardless of a particular COM port number being enabled in the DS600.INI file, if that COM port does not happen to be available to the program at the moment that the comm server is launched, all comm links that reference that COM port will be dumped, without warning and with no way to cancel out. A COM port may not be available because a COM port adapter is not plugged in at the moment, or it is in use by another program. It does not matter, the link definitions are gone.
Speaking at least for myself, this is a very undesirable behavior. I would estimate that 95% of the time that I am launching DirectSoft, my COM ports are not available, because I am off line or ethernet-connected only to my test PLCs, and my USB-Com port adapter is not plugged in. Just the same, my COM port links are very important to how I used DirectSoft. Different PLCs, baud rate settings, etc. I don't want to have to re-create them every time when I do use serial access!
I understand the reason for this change. For users who don't wish to concern themselves with the vagaries of logical COM port assignments when connecting through whatever USB-COM port adapter they happened to pick up, limiting the comm server's COM port# choices to those ports that are immediately available is a big help. Those are your "auto-sense" users. The rest of us, who define and manage our links and connections on our own, won't need or want this for the most part.
So here is my suggestion: how about backing off on this new behavior if autosense is disabled? That seems not to be the case at present. In other words, if autosense is disabled, revert to DS5 behavior, where the link will be preserved as long as it is enabled in DS600.INI. If autosense is enabled, then the new behavior would be in effect. That type of overall program behavior would be consistent with the meaning of autosense in my thinking. Or if there is another way around this that I'm not aware of, please let me know.
By the way, I really like the new sorting by link name. If only a bunch of my links hadn't been deleted....
-
Boy do I agree!!!
The autodetect "feature" makes boot up a crap shoot at best. I have spent the past week trying to get past the error flags and app hangs that accompany the inability of the software to cope with the off line start. To date -- I consider D6 pretty much useless as I can't get the program to even start, let alone use it. Went to the ini file and all of the com ports are there -- marked with their little "1s" -- but not there in the editor box. Please, please, please -- go back tot he D5 comms set up. We do this for a living and can't spend all of our time trying to get the software to work.
Doug
-
We're looking into this. We'll have an answer soon.
The current thinking is to use a combination of old way and new way. Ports explicitly listed will be added unconditionally, and then add any we find in the scan. It won't be hard, and we should be able to get a maintenance release out pretty quickly.
This one came as a complete surprise to us, due to the fact that Do-more Designer does it the same way...and yet...we haven't heard a single peep from Do-more users in the two years it's been shipping. Then we figured it out: very few people use RS232 to program Do-more.
We really were trying to make things easier... ::)
-
With DS6, it seems that this behavior has been changed. Now, regardless of a particular COM port number being enabled in the DS600.INI file, if that COM port does not happen to be available to the program at the moment that the comm server is launched, all comm links that reference that COM port will be dumped, without warning and with no way to cancel out. A COM port may not be available because a COM port adapter is not plugged in at the moment, or it is in use by another program. It does not matter, the link definitions are gone.
Wow, I wouldn't like that at all. I actually create links and name them after specific customer PLC's if the config is other than generic. It's not like they're hard to delete once you don't need them any more.
This one came as a complete surprise to us, due to the fact that Do-more Designer does it the same way...and yet...we haven't heard a single peep from Do-more users in the two years it's been shipping. Then we figured it out: very few people use RS232 to program Do-more.
Yup. For me, it's been about 99% Ethernet, and 1% USB, and I'm not entirely sure I've EVER connected to a Do-More via serial even once (for programming).
-
Wow, pleasant surprise! It had been quite a while after I posted and there hadn't been a response, so I stopped checking. Then, I get notified of the first maintenance release for DS6, and guess what's included in the list of updates! Thanks a bunch guys, for understanding and addressing this. ;D
You bring up the point of this change being made in Do-more but nobody said anything - actually, I noticed this during the DoMore beta program and I was going to bring it up in subsequent discussion, but I never bothered. I think the answer to your puzzlement about this not being an issue in DoMore is that serial COM port connectivity is 3rd tier (behind USB and Ethernet) and is probably not used a lot. With Direct Logic, COM port access is 1st tier default, the only access that is guaranteed to be available. While ECOMs may get designed into every DL project I ever do, I rarely encounter them in the field when working with a pre-existing installation that wasn't my design. Don't go on site without your DL port 1 cable, though I use it less and less these days.
It seems to me that now DS6 comm server behaves pretty much the same either with autosense on or off, which is fine, as long as it preserves the pre-existing links. I didn't do a lot of testing with Autosense, which brings up another issue:
I have about 50 Ethernet comm links in my DS rst file, because I manage some larger networks. Again, as with serial comm ports, 95+ percent of the time most PLCs are unavailable when I start DS, but with autosense, DS goes out and tries to poll every one. I lived with this for years (not knowing about the autosense INI setting) until I upgraded to a SurfacePro and Windows 8.1. Now commserver on Win8 spends 5-10x longer than it does on WinXP waiting for each unavailable link (3-5 seconds each, is my rough guess), and the resulting startup time forced me to look for a workaround, and turning autosense off does just fine.
I think that you still want to look at this further, though, and here's why. During the long slow autosense process, when the DS application window and initial dialog finally come up, they present themselves to the user a good 15-30 seconds before comm server is finished polling. This is especially not good, because the user will almost always not realize this - main DS6 program window obscures the little commserver link progress window, and DS6 is fully enabled for user input. If the user tries to go on line before commserver is finished starting up (DS6 lets you) a full DS/comm server hang is the result.
Anyway I thought you should know. There are some other Win8 oddities that I've noticed, I'll provide feedback on them when I get a chance.
Thanks,
John Raynes
Raynes Engineering, Inc.
-
CommServer startup timeout is 60 seconds...completely arbitrary and very easy to change. Thanks for the heads up.
Not sure why Win8 would be so ponderous, but some of these networking calls are completely outside our control. There are no OS version specifics in the CommServer that I am aware of.
-
One possible hint:
Link checks seem to return faster if the connecting PC has no active adapter on that particular subnet, I think. In other words, if I have a PC adapter enabled on 192.168.2.xxx, the non-existent devices matching that subnet mask will take much longer to return in the case of no reply.
I say "I think" because the whole notion of multiple adapters active at the same time (usually wireless and wired) adds to a lot of uncertainty in how Windows networking services respond, it always has (sigh). I spend a lot of time enabling/disabling adapters when connected simultaneously to a company wireless network and also (my) isolated wired machine network, I don't think it has anything to do with DS or commserver. Sometimes everything runs fine, other times Windows seems to get a bee in its bonnet as to where to look for a network connection, and disabling one or the other is the only way to get it to look in the right place.
John Raynes