In some areas the number of needed magnets may exceed the number of currently installed power supplies in order to run a complex experiment. Because of budgetary restrictions and space problems on some supply galleries no additional power supplies are easily available. But it is usually possible to borrow some 3 to 5 fix-installed power supplies temporarily from a neighboring area by connecting the additional magnets via DC power cables laid over the shielding walls, and leaving the computer control still hooked to the area's default server PC. But in order to access all magnets from a single area host PC, TCP/IP connections to up to 4 area server PCs have to be established by the controlling programs on the host computer. The following PC host programs have been modified to maintain a TCP/IP dialog with up to 4 area server PCs:
Note: Of course not all devices of the second server should be visible
and accessible from your host PC. In order to hide all but the borrowed
devices, the Device.Dum file on the working directory (e.g. c:\optima) of your
host PC has to be modified with a text editor. This file serves as a
template when the programs on the host PC download the Device.Lis from the
server PC(s). If the nth DUM is altered to DUMx then the information of the nth
device contained in the Device.Lis of the corresponding server is blanked out
on your host.
If more than one server is used, then the downloaded lists of the other servers are appended
to the downloaded list of the first server. Thus, if the first list contains 30
devices and the first 20 devices of the second list should be made invisible,
then the DUM entries number 31 to 50 should be modified to DUMx. (Lines in the
Device.Lis files starting with '*', '-' or 'RESUNI' or alias definitions {A=B}
are not counted as device definition lines. But blank lines are counted as
such ones.) Of course, the Device.Dum list in the working directory of the
host PC of the area which borrowed you some power supplies should also
be modified in order to make devices belonging now temporarily to your area
invisible for the users of the other area.
Hint: Instead of connecting to a 2nd area server it is also possible to connect to a second server in the same experimental area. For example this feature is used in order to tune a µSR-apparatus via some PSI-SMK Camac motor drives connected to an own transportable PC (to be used either as a host for local tests or as a server of the corresponding area PC for remote tuning of the apparatus while the muon-beam is on).
Second, more elegant method: Instead of connecting to the same Server32.exe program via the same
TCP-IP port nnn as the main user, a second instance of the Server32.exe program must be run with a different
TCP-IP port mmm on the server PCxyz to which the borrowed devices are attached. But in order to have a
separate device.lis (containing only the borrowed devices) being used by the parasitic user, it has to be in
a subdirectory of C:\optima on the server PCxyz (e.g. C:\optima\PiE5). Important: This directory has to be declared
as the startup directory in the second instance's shortcut of Server32.exe (via properties -> Shortcut -> Start in:).
On the client PC of the parasitic user, in addition to the 1st command line parameter Server1+Server2+..
the second command line parameter for the 4 programs mentioned above has to be port1+port2+.. (instead of only 'port').
(The device.dum files on both machines [server and client] do not have to be edited anymore). The version
numbers of the 4 programs mentioned above have to be 2.06 or higher. In order to have the second Server32.exe
instance restarted automatically for the case the server PCxyz is rebooted, a shortcut with the correct
parameters mentioned above has to be created in the server PCxyz's startup directory (get a hint from the
corresponding shortcut of the main user's Server32.exe).
|