...
| Code Block | ||
|---|---|---|
| ||
Bytes Name ----- ---- 4 opcode n data (alias command arguments) |
- opcode: a unique number associated to the specific service.
- arguments: any data (string or binary stream) needed for the execution of the command (e.g. element name, set value, etc...) The arguments size can Arguments size can be calculated from the packet length as: arguments size = (packet length) - 4
Opcode | Name | Associated function and parameters | |
0x00000000 | DO_NOT_USE | 0x00000000 must NOT be used | |
0x00000001 | FETCH | fetch the STA or DYN fork: <elementName>,STA|DYN | |
0x00000002 | SEND CMD 1 TO 3 | send a command from the console to the DEVIL: <command_string> | |
0x00000003 | FETCH_BUFFER | fetch n bytes from a buffer global variable: <#OfBytes> | |
0x00000004 | ECHO | send n bytes ang get the same n byte back: <byte_string> | |
0x00000005 | FETCH_BLOCK | fetch STA or DYN fork (full array): <elementName>,STA|DYN (the elementName is used by the servlet just to recognize the proper class and can be any elementName belonging to that class in that DEVIL) | |
0x00000006 | GET_ALIVE_COUNT | read the DEVIL alive counter: no arguments | |
0x000000xx | to be defined | not implemented | must NOT be usedto be defined |
0x000000ff | DO_NOT_USE | 0x000000ff must NOT be used |
| Code Block | ||
|---|---|---|
| ||
Bytes Name ----- ---- 4 packet code, always = 0x00000000 |
...
packet code: the Server returns in this field the command number (as from the Client request).
raw data: any data (string or binary stream) as requested by the command (e.g. element dynamic record, data buffer, etc...)
The raw data size can be calculated from the packet length as: arguments size = packet length - 4
LabVIEW VIs
The TCP_DCS application protocol is implemented as by a set of LabVIEW VIs. There are VIs to be used at level 3 by the DEVILs and other VIs to be used at level 1 by the control windows.
Third level VIs
TCP_DCS_readPacket.vi
This VI has been set as reentrant. A reentrant VI is a program that has a separate space of memory allocated data for each instance. More instances of reentrant VIs can execute in parallel without interfering with one another.Reads the packet coming from level 1 (e.g. from a user window).
Path: /u2/dcs/source_linux/3_hell/TCP_DCS_readPacket.vi (reentrant)
The task performed by the VI is to read the packet through two separate TCP Read.
The VI executes two TCP reads: the first one gets the 12 byte of the header, whilst the second one gets the 4 bytes of the command that has to be executed and the parameters (if any).
The first TCP Read timeout is set to -1 in order to allow infinite waiting for the header arrival.
The second TCP Read timeout is set to 3000 ms, because it would make no sense to wait for an indefinite time after the reception of the header.
TCP_DCS_sendPacket.vi
Sends a TCP_DCS answer packet to level 1 (e.g. to a user window).
Path: /u2/dcs/source_linux/3_hell/TCP_DCS_sendPacket.vi (reentrant)
The VI reconstructs Reconstructs the packet to be sent through a single TCP Write, appending to the header the requested information. The byteNumber is calculated including the header length.
servlet_eth_x.x.vit
...
Path: /u2/dcs/source_linux/devils/DEVIL_eth/servlet_eth_3.x.vit
(reentrant, called by reference as a VIT instance)
The VI operates in three modes managed by the DEVIL process:
mode = 0 the Servlet recovers the references associated to the typeDef which the DEVIL has to deal with.
mode = 1 the Servlet receives, interpretes and executes the commands, accordingly to the TCP_DCS protocol.
command —interpreted by the sub-VI
TCP_DCS_query.vi
Path: /u2/dcs/source_solaris/common/ethernet/TCP_DCS_query.vi
(reentrant)
First level VIs
...
connectionManager_eth_2.0.vi
Manages the connection with DEVILs in charge of the control of elements that are in "elementList".
/u2/dcs/source_solaris/1_paradise/util/connectionManager_eth_2.0.vi
As said above, this VI performs a complete management of the connection with the DEVILs involved in the control of a given set of elements.
At first it At first the VI identifies which elements require a VME-to-VME connection and which an ethernet connection and returns this information into the boolean array VME/ETH (FALSE=VME, TRUE=ETH).
Then it opens the required TCP connections (if any). In case of window reconfiguration — as for the MagTerminal when a new operating area is selected — it closes the TCP connection no longer needed.
The connectionManager_eth takes care of updating the global VI GConnList1_eth.
...