News:

  • March 27, 2025, 08:18:30 PM

Login with username, password and session length

Author Topic: DirectSoft 6 Comm Server  (Read 3455 times)

Kieutrang

  • Newbie
  • *
  • Posts: 3
DirectSoft 6 Comm Server
« on: August 28, 2019, 10:09:21 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....

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3731
    • Host Engineering
Re: DirectSoft 6 Comm Server
« Reply #1 on: August 29, 2019, 09:36:08 AM »
I was not able to duplicate this issue.  I had a link on COM1, then changed the COM port setting on my PC from COM1 to COM9, and the link still showed up as COM1 after re-running DSLaunch.  You may try re-booting in case something is "hanging".

Fist thing, whenever you do change the INI file, you must shut down DSLaunch and all instances of DirectSOFT, then rerstart them for those COMxEnable settings to "take".  The CommServer must shut down then re-start.  It stays opened as long as one of its clients is still running (i.e. DSLaunch or DirectSOFT exe).

Another possibility, the INI file that is being edited in the Windows folder vs. the one in the Virtual Store.  The best way to edit the proper INI file is via DSLaunch.  Run DSLaunch and  look for the DS600.ini entry below the Utilities tree node.

Look for the [devasync.dll] section, then make sure you have that specific COM port number enabled that does NOT exist on your PC (e.g. COM9):
[devasync.dll]
COM9Enable=1

Shut down DSLaunch, all DirectSOFT sessions, etc.
Re-run DSLaunch or DirectSOFT.  You should be able to manually create a link on COM9 using the Link Editor.  If COM9 does not show up in your Port list, then something strange is going on.  If it's listed, go ahead and create a new link on COM9.  Again, shut down all instances of DirectSOFT and DSLaunch.

Re-run again DSLaunch, your COM9 link should be listed in the Comm Links tree node.  You should also be still able to create new links on this non-existent COM9 port.  Let us know if this is not true.

Oh, and undo all the INI file tweaks (unless those were "valid" non-existent COM ports).