Multi threaded c++ with gclib

Hello Toney,


In one word, gcaps.


With the gcaps server, when you issue the GOpen() function in your gclib application, you are actually opening a connection to the gcaps server and not the controller. The gcaps server then establishes the necessary handles/protocols for communication with the controller.


"Why the middle man?" you ask? Previous Galil APIs (like the GalilTools COM Library for example) opened an additional connection to the the controller each time the GOpen() equivalent was called. The number of available handles can vary from controller to controller, the DMC-40x0 has 8 handles while the RIO-47120 has 3 and these are often required for external peripherals. The gcaps server limits all communication with a host PC in the system to at most two handles, leaving the remaining handles open. In addition, this capability is not limited to Ethernet connections. Multiple applications or threads can connect communicate via the gcaps server over PCI and Serial/USB Buses as well. The routing and handling of both solicited and unsolicited traffic to separate threads and/or separate applications is handled entirely within the server.


When multithreading with gclib, it is crucial that each thread interact exclusively with it's own GCon Object to avoid inadvertently stepping on memory during program execution. In your case I would advise the following connection strings:


GCon galilCtrlCon=0;

GOpen("", &galilCtrlCon);

GCon galilUnSolCon = 0;

GOpen(" -s MG", &galilUnSolCon);


The only difference between the two GOpen calls is that the unsolicited connection 'subscribes' to unsolicited messages. Specifying which ports to connect to with the --p1 and --p2 switches is not necessary. This means that any messages coming from the controller to the gcaps server will be routed to this thread and any other thread and/or application that subscribes similarly.


Lastly, I would suggest changing the #JS statement in your dmc code to #JP. Each time #JS is called, the subroutine stack is added to. This stack is 16 deep, so your current code will throw an error after 16 runs (with a WT 2000, this is ~32 seconds).