The present document gives a rought idea on how to
connect to an ArcVIEW system trhough a network socket.
Things that can be done through the socket:
- Complete handling on the system, including camera, TCS,
Filte or any other device conncted to ArcVIEW
- The protocol includes inmediate replies to commands,
as well as callbacks an asynchronous messages.
- Acces to the ArcVIEW internal database, for reading
all the variables, and writting some of them.
There is an special ArcVIEW module in charge of the socket
communication. This module gives access to the ArcVIEW system using
just plain sockets, with ascii commands.
The modes of operation of this module are two:
a) Normal Operation:
Two communication channels are used: The first for sending command and receiving inmediate replies. The second one for receiving callbacks (responses to long-to-complete- commands and asynchronous messages.
1) Command/Response channel:
All commands sent to ArcVIEW will receive a response.
For short commands, this response is the completion of the requested action.
For long commands, this response is an acknowledge to the command, which
will continue in execution. This long command, once it is completed, will
receive the response throug the second channel. Examples
--> DHE SET exposuretime=3.2 [s]
--> DONE
In this case "DONE" means: exposuretime was set. End of the command.
--> DHE EXPOSE
--> DONE (CB 82000)
In this case the response means: "Command was received, and the execution was started; the response will be sent through the second channel when completed. The estimated completion time should no exceed 82000 milliseconds (this is the timeout for the command)". All the commands which starts a long action will specify a CB timeout estimation. In this way the client knows both that the command is in execution (and not finished) and the aproximate maximum time for the command completion.
When an inmediate error ocurr, then no posterior action will follow. Example
--> DHE EXPOSE
--> ERROR starting exposure /*io error*/
err -5
Note that only 1 callback at a time is allowed for the same device: 1 for DHE, 1 for Filter, 1 for TCS, etc. If, for example a "DHE EXPOSE" is sent before a previously issued "EXPOSE" has completed, it will return an inmediate error:
--> DHE EXPOSE
--> DONE (CB 82000)
/*OK, command in execution*/
--> DHE EXPOSE
--> ERROR: Pending
/*a callback is already pending for that device; command will not
be executed*/
2) Callback/async. channel.
This channel will be used for returning responses to long
commands (callbacks) as well as asynchronous messages (not associated with
any previously issued command)
The asynchronous messages can be errors, warnings or
just general information.
A callback response will specify the device which is generating that
callback, so the caller can associate the response to a device (remember
that only 1 callback at a time is allowed for each device)
For the "EXPOSE" example listed above, we will receive:
--> Image_DONE (DHE)
This is saying that the long command that the DHE was executing finished with the described message.
When a message is asynchronous, then it will specify the device which generated the asynchronous message adding the extension _ASYNC to the device name. For example
--> Warning: Connection Down (TCS_ASYNC)
Is saying that the TCS device sent the message.
b) Blocking Mode:
This Mode of operation is for simple clients that cannot or (prefer
not to) handle more than 1 channel.
The blocking mode will use only 1 channel: the command/response one
described above. The system will block the channel untill a definitive
response has arrived for the issued command. This means that only b1 command
at a time will be allowed. For example:
--> DHE SET exposuretime 3200
--> DONE
/*return inmediatelly *
--> DHE SET EXPOSE
......
/*blocks -no response neither ack- untill image has completed*/
--> IMAGE_DONE (DHE)
/*now the channel can receive more commands*/
This mode of operation is usefull mainly for simple scripting languages,
wich normally can handle much more easily just one channel at a time, avoiding
the need of handling multiple threads.
TCP/IP Module Setting Commands
The ArcVIEW module which handles the tcp/ip communication is called COMSTCP. Any comand issued to the command channel which starts whith this prefix will be directed to the module itself. Available module commands are:
(all with the COMSTCP prefix):
BLOCKING <on | off> : tells if it should use the
blocking or normal mode of operation
ASYNC PORT <value>: tells the port to use for
sending callbacks and asynchronous messages. This command has meaning only
if the normal mode of operation is used.
Note here that IT IS POSSIBLE to specify the async. port to be the same
as the command/response port. In this case the callbacks and async.
messages will be returned through the same command/response channel (so
only 1 channel will be efectivelly used)
The default values (if no commands are sent) are read from a configuration
file. If no configuration file is found or specified, then the default
values are:
ports:
command/response: 1320, callback/async: 1325
blocking: off