Page History

...

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 each otherone another.

 Image Modified

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 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

Image RemovedImage Added

 Path: /u2/dcs/source_linux/3_hell/TCP_DCS_sendPacket.vi (reentrant)

...

The .vit (VI Template) files are useful when an application requires multiple identical instances of the same routine. Each instance gets a separate memory space. To have a true parallelism all the inner VIs have to be set as reentrant.

Image Modified 

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

Image Modified

Path: /u2/dcs/source_solaris/common/ethernet/TCP_DCS_query.vi
(reentrant)

First level VIs

TCP_DCS_testConn.vi

Image Modified

Path: /u2/dcs/source_solaris/common/ethernet/TCP_DCS_testConn.vi( WARNING: think if this VI must be reentrant or not!!!  ) 

GConnList1_eth.vi

Image Modified

Path: /u2/dcs/source_solaris/globals/GConnList1_eth.vi

...

connectionManager_eth_2.0.vi

Image Modified 

/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 identifies wich which elements require a VME-to-VME connection , and which one require an ethernet connection and returns this information into an array of booleans 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.

...

 Looking at the above example, we see that the first element QUATM004 is controlled by a DEVIL with ethernet connection (VME/ETH = T). For this element, the two corresponding components of the RTDBStaAdd and RTDBDynAdd arrays are equal each other and contain the same TCP_DCS connection ID.

The second element QUATM005 is controlled by a DEVIL with VME-to-VME connection (VME/ETH = F) so that the two corresponding components of the RTDBStaAdd and RTDBDynAdd arrays contain the actual VME addresses that we have to use for the dynamic and static fetch routines.

The connectionManager_eth also returns also — for each element — the class ID (21=MG1, 15=CHN).