The QLIB and the QLIB Server allows you to remote control QUANCOM hardware over a TCP/IP network connection. The QLIB Remote Server implementation is done by a server/client model. Every client and server that uses the remote functionality requires the QLIB Driver Library installed. On the machine that is remote controlled the QLIB Server Software has to be installed on. More details on installing the QLIB Server you will find in the SERVER.HLP file.
If you are completely new to QLIB programming, you should first learn more about the QLIB API and start to program the QLIB without remote functionality first.
Programming the QLIB (QUANCOM Library) with QLIB Server
The first step to create a remote application is to build an application that runs on your local system. After the program has been tested and verfied you can make the modifications to run it on a remote machine. After these modifications are made the program should run on a local and a remote machine ( see differences local vs. remote ).
There are two modes the QLIB (QUANCOM Library) can have. First mode is "Local" which is the default mode. In this mode all QAPIxxxx commands will route to the local hardware. Second mode is "Remote" which will route all QAPIxxxx functions, except QAPIConnect and QAPIDisconnect, to a remote QLIB Server. The QLIB Server will execute the requested QAPIxxxx functions on it's own local hardware.
First modification for a QLIB (QUANCOM Library) client program is to connect to the remote server with the QAPIConnect() function. This switches the client QLIB to the "Remote" mode. If QAPIConnect fails, the QLIB stays in "Local" mode. Which mode is currently active can be determined by the QAPIGetConnectionMode function.
If the QLIB (QUANCOM Library) has entered the "Remote" mode, the only reason why it switches back to "Local" mode is, that the QLIB Client program has called the QAPIDisconnect function. Network errors or terminations or other faults will not switch the QLIB back to "Local" mode. Despite of this, the function QAPIGetLastError will return the error "ERROR_QLIB_CONNECTION_DISCONNECTED". This behavior is to prevent QLIB from extecuting QAPIxxxx functions on the local machine in case of any error.
The second modification required is to test for network errors after every QAPIxxxx function call. You can do this by calling the QAPIGetLastError function.
call QAPIExtWriteDO32(...): If QAPIGetLastError() then goto err_network
I know that programmers dislike the "goto" and it is not a very good practice to use "goto". For every QAPIxxxx function you have to decide what happens if the function fails.
Putting the QAPIGetLastError behind the QAPIxxxx functions will make your program more readable then putting it below the function. But this is only tip from me.
With the exceptions of the QAPIConnect, QAPIDisconnect and the QAPIGetConnectionMode functions the QLIB in "Remote" mode is transparent to the client. The client program will not notice that it is executing on a remote machine.
The time between each QAPIxxxx function call must be less then the specified timeout intervall in the QLIB Server configuration. If the time is longer, the server will teminate the session and a call to QAPIGetLastError on the client side will return the error "ERROR_QLIB_CONNECTION_DISCONNECTED".
After the program has called it's QAPIxxxx functions it has to call QAPIDisconnect as third modification, which switches the mode to "Local" mode
and terminates the connection to the server.