Hello,

You are right, GalilTools does not close UDP handles which it opens. This is an odd thing, but the reasoning is here:

1.) UDP is technically "connectionless". Unlike TCP, there is no protocol for opening and closing a connection. http://en.wikipedia.org/wiki/SYN_(TCP)#Connection_establishment

2.) GalilTools will use the same UDP port for scope on each connection. This means that the handle resource on the controller is reused.

Try this form power cycle:
Connect to controller, Type TH. Note Handle A is used, TCP
Start Scope, Type TH. Note A TCP, B UDP
Close GalilTools
Connect to controller, Type TH. Note A TCP, B UDP
Start Scope, Type TH. Note A TCP, B UDP

So the B handle is reused. Here's a terminal trace:

192.168.1.11, DMC4020 Rev 1.0a1, 457, IHA
TH
CONTROLLER IP ADDRESS 192,168,1,11 ETHERNET ADDRESS 00-50-4C-20-01-C9
IHA TCP PORT 23 TO IP ADDRESS 192,168,1,10 PORT 4198
IHB AVAILABLE
IHC AVAILABLE
IHD AVAILABLE
IHE AVAILABLE
IHF AVAILABLE
IHG AVAILABLE
IHH AVAILABLE
:TH
CONTROLLER IP ADDRESS 192,168,1,11 ETHERNET ADDRESS 00-50-4C-20-01-C9
IHA TCP PORT 23 TO IP ADDRESS 192,168,1,10 PORT 4198
IHB UDP PORT 60000 TO IP ADDRESS 192,168,1,10 PORT 4199 ***SCOPE ON UDP PORT 60000***
IHC AVAILABLE
IHD AVAILABLE
IHE AVAILABLE
IHF AVAILABLE
IHG AVAILABLE
IHH AVAILABLE
:192.168.1.100, RIO47100 Rev 1.0b, 279, IHC ***CONNECT TO SOMETHING ELSE, OR DISCONNECT ***
192.168.1.11, DMC4020 Rev 1.0a1, 457, IHA
TH
CONTROLLER IP ADDRESS 192,168,1,11 ETHERNET ADDRESS 00-50-4C-20-01-C9
IHA TCP PORT 23 TO IP ADDRESS 192,168,1,10 PORT 4203
IHB UDP PORT 60000 TO IP ADDRESS 192,168,1,10 PORT 4199 ***B IS STILL TAKEN ALTHOUGH NOT BEING USED***
IHC AVAILABLE
IHD AVAILABLE
IHE AVAILABLE
IHF AVAILABLE
IHG AVAILABLE
IHH AVAILABLE
:TH
CONTROLLER IP ADDRESS 192,168,1,11 ETHERNET ADDRESS 00-50-4C-20-01-C9
IHA TCP PORT 23 TO IP ADDRESS 192,168,1,10 PORT 4203
IHB UDP PORT 60000 TO IP ADDRESS 192,168,1,10 PORT 4204 ***SCOPE NOW BEING USED, SAME PORT, SAME HANDLE***
IHC AVAILABLE
IHD AVAILABLE
IHE AVAILABLE
IHF AVAILABLE
IHG AVAILABLE
IHH AVAILABLE
:

We have done extensive testing with GalilTools and have not run into full handles issues. Perhaps SmartTerminal, ActiveX, AND GalilTools in concert could have some issues, though I can't think of a scenario offhand.

If you can reproduce the issue, please share the procedure. We can actively close the UDP handle by Galil proprietary measures (IH command), but the UDP standard should not require this.

Yes, the issue is ActiveX and Galil Tools. When ActiveX connects to a controller using DMCShell1.DMCController = does it use a UDP handle? Since I'm debugging a VB.NET app that still uses ActiveX (for odd, old reasons), there are times when I simply terminate the debugging session rather than using DMCShell1.DMCConnect = False. Would that cause this problem? If so, then it's my own fault.

BTW: I'm not using the .NET API's because I could not find a way to programmatically connect to a controller with a specific IP address. With ActiveX I programmatically find the controller by searching DMCRegister1.IPAddress = . Then I know the controller number to use with the DMCSHell. This is done because only the IP address is unique. The controller number in the registry and even the controller name (using registry or Galil Tools) are not guaranteed to be the same for all PC's that might run the application. If ther is a way to do it with .NET API's that would help in the future.

Thanks

I just did a test by issuing the command IHT=>-1 to close UDP handles. It worked, but I had to use Galil Tools because Smart Terminal would not connect (full handles). This is rather odd because TH (Galil Tools) showed B handle wasn't being used. Maybe Smart Terminal needs several handles?

Unfortunately, I forgot to capture the Galil Tools log. When this happens again I'll do that and send it to you

Check you Ethernet Parameters setup in the Controller Registry.

In SmartTerminal
Tools/Controller Registration/Edit Controller Properties (button)/Ethernet Parameters (tab)

Under the Unsolicited Messages drop-down, you probably have "Open 2nd Handle". If this is the case, Smart Terminal (as well as Active X, .Net, WSDK etc) will open a second handle for unsolicited messages, and therefore requires 2 handles to connect.

Also, the older drivers require a
DMCShell1.DMCConnect = False
on exit.
Otherwise the handles will fill. This is probably the source of your full handles.

All of the older stuff (non-GalilTools) uses the windows registry to get connection info. There is no simple way to connect to a generic IP address, in general.

You can set up a "controller 1" with the desired IP address and always connect to that. This would not span various PCs, however, as the windows registry entry would have to be present on all PCs. You can also edit the registry programatically, adding the registry when needed.

With the GalilTools api, of course, this is trivial.

Galil g("192.168.1.1");
g.command("XQ");
//...

Based on your last response, it looks like there are three ways for a program to interact:

1. ActiveX API's
2. .NET API's
3. GalilTools API

They are not the same (at the program level at least)

Is that correct?

To add one to your list:
1. ActiveX API's
2. .NET API's
3. GalilTools API
4. DMCwin32.dll (native C library)

1 and 2 are built atop 4. 3 is a brand new API written in C++ using Qt crossplatform libraries. All 4 interfaces have varying syntax.

3 is recommended for all new applications.

Thanks. I surmised the relationship too. I'll look into the GalilTools API's.

[quote=DJ]To add one to your list:
1. ActiveX API's
2. .NET API's
3. GalilTools API
4. DMCwin32.dll (native C library)

1 and 2 are built atop 4. 3 is a brand new API written in C++ using Qt crossplatform libraries. All 4 interfaces have varying syntax.

3 is recommended for all new applications.[/quote]

This should be posted front-and-centre on any web pages pertaining to development on the PC for your products - I know it would've saved me a lot of confusion six months ago!

Hi Erik,

Our new website does make it a bit clearer:
http://www.galilmc.com/support/software-downloads.php

The older software is still perfectly valid, and required for some applications (e.g. the DMC-1700).

Note:
"Current Software Package for New Applications"
and
"Other Software Utilities For Windows 98SE / ME / 2000 / XP / Vista"