Applications that offer a user interface are best written as GUI applications, either using the Windows GUI API plus Visual Basic, Visual C++, LabView, etc. or using the Java API. On the other hand, there are occasions where client access to a server (or servers) is desireable from the command line. For instance in calling a property from a server and piping the output to a file, or for usage within scripts. To this end there are a number of command line interface tools which offer contact with the control system.
These are:
- tservers (queries the Equipment Name Server ENS for registered servers)
- tdevlist (queries a server for its devices)
- tproplist (queries a server for its properties)
- tinfo (queries a server for property information)
- talarms (queries a server for its current alarm list)
- tget (synchronous read-only call to server)
- tmonitor (asynchronous read-only poll to server)
- tsend (synchronous write call to server)
- tputget (synchronous atomic write/read for attibute style properties)
- tsendrecv (synchronous atomic write/read for call style properties)
- twait4target (monitor readback from a server until a requested target is met)
- thistory (queries the archive server)
- tglobals (monitors the set of global keywords from the tageted context)
- teventdata (queries the event archive server)
- mkhstfiles (utility for making the 'standard' set of local history files)
Note that certain synchronous script calls such as 'tget' or 'tputget' will ordinarily access the ENS to resolve the target address and then synchronously access the target for the desired data and then 'disappear'. That is, the process is finished and any address caching is then lost. Thus repeating the same call will once again access the ENS to resolve the address and so on. To combat this inefficiency, various command line calls will attempt to start a local 'repeater' process in the background and make requests through this background process (which does not 'disappear' once started). In this way the already cached address can be used when the call is repeated, avoiding extra stress on the ENS. Furthermore the repeater uses the asynchronous listener mechanism to 'reflect' the targeted data locally, avoiding unnecessary pummelling of the target server with synchronous data requests. The background repeater can, however, be 'circumvented' if for some exotic reason it is desired to do so. Setting the environment variable TINE_USE_REPEATER to either 'NO' or 'FALSE' will serve this purpose.
tservers
Typing 'tservers' at the command line will produce the following output:
Retrieves a list of registered servers for the given context and filter criteria
Usage : tservers <context> [/sub=<subsystem> /os=<OS> /eqm=<equipment module> /ip=<ip address> /resp=<responsible> /imp=<importance> /v=<TRUE for vervose output>]
search string can be abbreviated and occur multiple times
e.g. tservers PETRA
tservers PETRA /s=RF /s=VAC /o=UNIX
tservers PETRA /eqm=CDI /ip=192.168.
See also: 'tproplist', 'tdevlist' for retrieving information
So we immediately see that it takes the targetted 'Context' as an argument, and, optionally, an set of filter criteria so that the output list can be further focused. Resubmitting the command with for instance context 'DESY2' and subsystem filter '/sub=RF' (i.e. tservers DESY2 /sub=RF) will produce the following output (at least at DESY):
Servers in context DESY2 (filter: /sub=RF ):
RFSetValueCavity
RFStorage
RFSetValueRegulation
USpannung-VI
DE_DN_Mod
DE_HF_History
DE_DN_Cy30
DE_DN_Cy32
DE_DN_Cy34
DE_DN_TRANSMITTR
DE_DS_Cy06
DE_DS_Cy10
DE_DN_Kly
MHFTrcTranslator
DE_DS_Control
DE_DN_Control
DE_DS_Cy08
DE_DS_TRANSMITTR
DE_DS_Mod
DE_DS_Kly
RFAlarm
DE_DN_Cy28
DE_SER_HFPhase
DE_DS_Cy04
MHFeRefPegel
DE_DN_ERTemp
DE_DS_ERTemp
27 servers found
Note that 'tservers' queries the equipment name server (ENS) only and does not attempt to verify whether a server is online or not. Hence the output is simply a list of all registered servers under the context given.
More detailed server information can be obtained by provide the verbose switch.
For instance, tservers DESY2 /sub=RF /v=TRUE will produce the following:
Servers in context DESY2 (filter: /sub=RF ):
Server FEC IP Address Port OS Importance
RFSetValueCavity D2R3D.2 131.169.154.219 2 JAVA Necessary
RFStorage D2R3D.2 131.169.154.219 2 JAVA Necessary
RFSetValueRegulation D2R3D.2 131.169.154.219 2 JAVA Necessary
USpannung-VI D2UCIST.FEC 131.169.128.60 10 WIN32 Necessary
DE_DN_Mod DE_DN_Mod 192.168.33.115 0 WIN32 Necessary
DE_HF_History PEHFDATA.4 192.168.33.69 4 WIN32 Necessary
DE_DN_Cy30 DE_DN_Cy30 192.168.33.130 0 WIN32 Necessary
DE_DN_Cy32 DE_DN_Cy32 192.168.33.160 0 WIN32 Necessary
DE_DN_Cy34 DE_DN_Cy34 192.168.33.106 0 WIN32 Necessary
DE_DN_TRANSMITTR DE_DN_TRANSMITTR 192.168.33.132 0 WIN32 Necessary
DE_DS_Cy06 DE_DS_Cy06 192.168.33.125 0 WIN32 Necessary
DE_DS_Cy10 DE_DS_Cy10 192.168.33.146 0 WIN32 Necessary
DE_DN_Kly DE_DN_Kly 192.168.33.111 0 WIN32 Necessary
MHFTrcTranslator MHFTrcTransFEC.3 131.169.151.47 3 WIN32 Essential
DE_DS_Control DE_DS_Control 192.168.33.104 0 WIN32 Necessary
DE_DN_Control DE_DN_Control 192.168.33.103 0 WIN32 Necessary
DE_DS_Cy08 DE_DS_Cy08 192.168.33.154 0 WIN32 Necessary
DE_DS_TRANSMITTR DE_DS_TRANSMITTR 192.168.33.113 0 WIN32 Necessary
DE_DS_Mod DE_DS_Mod 192.168.33.118 0 WIN32 Necessary
DE_DS_Kly DE_DS_Kly 192.168.33.117 0 WIN32 Necessary
RFAlarm D2R3D.4 131.169.154.219 4 JAVA -unassigned-
DE_DN_Cy28 DE_DN_Cy28 192.168.33.121 0 WIN32 Necessary
DE_SER_HFPhase DEDESERHFPhase 192.168.33.40 3 UNIX -unassigned-
DE_DS_Cy04 DE_DS_Cy04 192.168.33.124 0 WIN32 Necessary
MHFeRefPegel DEMHFeRefPegel 192.168.33.41 4 UNIX -unassigned-
DE_DN_ERTemp DEDEDNERTemp 192.168.33.38 5 UNIX -unassigned-
DE_DS_ERTemp DEDEDSERTemp 192.168.33.39 5 UNIX -unassigned-
27 servers found
tdevlist
Typing 'tdevlist' at the command line will produce the following output:
Retrieves a list of registered devices for the given device server
Usage : tdevlist <device server>
e.g. tdevlist /HERA/HEPBLM
See also: 'tservers', 'tproplist' for retrieving information
We see that it takes the targetted 'device name' as an argument.
The device name submitted must be understood by the ENS. Namely, it can be fully specified as in
tdevlist /PETRA/BLM
which specifically identifies the device name as belonging to context 'PETRA' and device server 'BLM'. This call yields the following device list :
DEVICE_NAME,DEVICE_NUMBER
PU01I,0
PU01O,1
PU02I,2
PU02I_I,3
PU03O,4
PU03O_I,5
PU04I,6
PU04O,7
PU05I,8
PU06O,9
PU07I,10
PU07O,11
PU08I,12
PU09O,13
PU10I,14
PU10O,15
PU11I,16
PU12O,17
PU13I,18
PU14O,19
ColSWL015_O,20
ColSWL015_U,21
ColSWR015_O,22
ColSWR015_U,23
ScrSWR020_O,24
ScrSWR020_U,25
ScrSWR020_L,26
ScrSWR020_R,27
ColNOL015_O,28
ColNOL015_U,29
ColNOR04_O,30
ColNOR04_U,31
tproplist
Typing 'tproplist' at the command line will produce the following output:
Retrieves a list of registered properties for the given device server
Usage : tproplist /<context/<server>[/<device>] [/e=<TRUE,FALSE> /d=<debug level>]
e.g. tproplist /HERA/HEPBLM
or tproplist /HERA/HEPBLM/WL105K1
If you specify a specific device name and it contains blanks use ""
e.g. tproplist "/HERA/HEPBPM/WL197 MX"
Use /e=TRUE or FALSE to display error messages when the call is not successfull (default=TRUE)
See also: 'tservers', 'tdevlist' for retrieving information
We see that it takes the targetted 'device name' as an argument.
The device name submitted must be understood by the ENS. Namely, it can be fully specified as in
tproplist /PETRA/Cms.MagnetPs/PCH_OL_7
which specifically identifies the device name as belonging to context 'PETRA' and device server 'Cms.MagnetPs' and referring to the device instance 'PCH_OL_7'. The call yields the following output
Property List for /PETRA/Cms.MagnetPs/PCH_OL_7 (174 properties)
PS.MassWait
Strom.NegMin
Quench.IstCurrent
Psc.TestAlarm
Strom.Bits
SENDINCR
BusID
Psc.AutoOp
Quench.EstimatedLoadHeatRise
HARDWREGS
pscExtendedValue
PS.Massage
Strom.ReStore
CrateVolts
PS.Reserve
PROXY.INFO
Mux.Magnet
Psc.Reset
ImsGetReset
TrMan.listSize
Dio.Status
TrMan.done
PS.RampTrigger
Psc.Halt
PSNAME
RANGE
(...)
tinfo
Typing 'tinfo' at the command line will produce the following output:
Retreives information about the specified device server and property.
Usage : tinfo <device name> <property>
e.g. tinfo /HERA/HEPBPM ORBIT.X
See also: 'tservers', 'tproplist', 'tdevlist' for retrieving information
We see that it takes the targetted 'device name' and the targetted 'property' as arguments. As in the above cases, the device name submitted must be understood by the ENS. Namely, it can be fully or partially specified. Note here that as 'tinfo' takes two arguments, if spaces appear in a device name then you need to surround the entire name in quotes, as in:
tinfo "/HERA/HEPBPM/WL197 MX" ORBIT.X
An alternative on Unix machines is to use '\ ' where blanks occur. This call obtains information about the property in question, such as engineering units, set points, etc. The above call produces the following output:
Device : /HERA/HEPBPM/WL197 MX
Property : ORBIT.X
Description : X Position data
Size : 141
Format float
Maximum : -20.000000
Minimum : 20.000000
Units : mm
tget
Typing 'tget' at the command line will produce the following output:
Synchronous call: gets the specified TINE device server property
Usage : tget <device name> <property> [/s=<size> /f=<format> /t=<timeout> /b=<TRUE/FALSE> /c=<separator character> /e=<TRUE/FALSE> /d=<debug level>]
use option /b to surround complex data types with brackets (default TRUE)
use option /c to provide a separator character for array output (default = <single space>)
use option /e to display error messages when the call is not successful (default = TRUE)
e.g. tget /HERA/HEPBLM/WL105K1 AVELOSS
or tget /HERA/HEPBLM/WL105K1 AVELOSS /s=300 /f=float
Use quotes "" around device names with spaces
e.g. tget "/HERA/HEPBPM/WL197 MX" ORBIT.X
If you regularly call 'tget' inside a script,
please make use of a 'trepeater' daemon!
A timeout other than the default 1000 msec can be specified via the /t option switch
See also: 'tmonitor', 'tsend' for sending and receiving data
We see that it takes the targetted 'device name' and the targetted 'property' as required arguments. As in the above cases, the device name submitted must be understood by the ENS. Namely, it can be fully or partially specified.
Optionally, you can supply a requested data type and data length in the call. If you omit either or both of these items, then the call will resort to the the default registered property information.
So, calling
tget "/HERA/HEPBPM/WL197 MX" ORBIT.X
will produce the following output (a series of numbers defining the instantaneous orbit, which can be matched against the device list returned by 'tdevs').
0.69 2.1 -0.27 0.7 0.22 -4.27 0.07 0.9 -3.02 -4.06 1.07 2.19 0.25 1.22 2.29 1.14 -1.15 1.8 2.82 -1.1
5 -2.65 2.01 0.3 -2.51 -1.68 2.34 3.25 -0.92 4.76 5.28 0 0 0 1.99 -23.19 -6.33 -1.42 2.71 -0.03 -3.2
4 4.78 1.65 1.57 0.28 -0.81 1.28 1.62 -0.35 -0.07 -0.01 1.76 0.26 -1.84 0.42 -0.98 -1.37 -1.08 0.49
-0.33 0.02 1.35 2.4 -0.11 -0.52 4.74 -1.79 1.95 0.2 -2.98 -0.3 0.87 0.57 -1.42 -0.58 2.37 0.03 -1.84
0.5 3.06 -0.96 -2.07 1.37 2.36 0.38 -0.53 2.19 1.34 0.42 -0.16 2.95 0.3 -5.61 0.7 2.35 0.27 -1.15 4
.49 -6.86 6.37 0 0 0 3.28 6.14 1.3 0.45 -1.82 -1.35 2.55 1.22 -0.49 -1.27 2.02 1.18 -2.62 0.73 1.47
0.65 17.55 1.19 2.52 -0.83 -2.02 1.45 -0.08 -2.14 -3.09 1.96 1.11 -1.1 -1.41 3.74 -3.01 -2.06 -3.91
-3.95 -1.25 27.04 3.26 -1.82 -33.86
However calling
tget "/HERA/HEPBPM/WL197 MX" ORBIT.X /s=10 /f=float
will obtain only the 10 values beginning at position 'WL 197 MX':
0.63 2.1 -0.27 0.78 0.12 -4.27 0.16 0.9 -3.02 -3.96
tmonitor
Typing 'tmonitor' at the command line will produce the following output:
Asynchronous call : Monitors the specified TINE device server property
Usage : tmonitor <device name> <property> [/s=<size> /f=<format> /t=<timer>]
e.g. tmonitor /HERA/HEPBLM/WL105K1 AVELOSS
or tmonitor /HERA/HEPBLM/WL105K1 AVELOSS /s=300 /f=float
Use quotes "" around device names with spaces
e.g. tmonitor "/HERA/HEPBPM/WL197 MX" ORBIT.X
A polling interval other than the default 1000 msec can be specified via the /t option switch
See also: 'tget', 'tsend' for sending and receiving data
We see that it takes the targetted 'device name' and the targetted 'property' as required arguments. As in the above cases, the device name submitted must be understood by the ENS. Namely, it can be fully or partially specified.
Optionally, you can supply a requested data type and data length in the call. If you omit either or both of these items, then the call will resort to the the default registered property information. The calling conventions for 'tmonitor' are entirely analogous to those for 'tget'. 'tmonitor' will continue to append the standard output with the most recent value returned from the targetted server.
So, calling
tmonitor /HERA/HEPIDC/GEAR0 Current /s=1 /f=float
will produce the following output in this case, namely a single float showing the instantaneous beam current which repeats until the call is terminated with cntl-C:
12.0147402
12.0166578
12.0175386
12.0165626
12.0156748
12.0164026
12.0171064
12.0169017
12.0155421
...
tsend
Sending data (i.e. issuing a 'set' command) to a server can be accomplished by using 'tsend'. Typing 'tsend' at the commond line will produce the following output:
Synchronous call: sends the input data to the specified TINE device
server and property. Sets the WRITE access bit by default.
A single string can be sent by enclosing the data in quotes "".
A data array can be separated by blanks, commas, or semi-colons.
Do not enclose string arrays with quotes!
You can specify a format by using the /f option switch and you can
specify an explicit size by using the /s option switch (cannot exceed the number of elements!)
A timeout other than the default 1000 msec can be specified via the /t option switch
Usage : tsend <device name> <property> [/f=format /s=size /t=timeout] <data1> [<data2> <data3> ...]
e.g. tsend /HERA/HEPBLM/WL105K1 MODE 1
or tsend /HERA/HEPBPM/WL105K1 MESSAGE "hello"
Use quotes "" around device names with spaces
e.g. tsend "/HERA/HEPBPM/WL197 MX" MODE 1
or tsend "/HERA/HEPBPM/WL197 MX" MESSAGE "hello"
See also: 'tmonitor', 'tget' for receiving data
Without specifying a data type or number of elements, 'tsend' will attempt to do something 'reasonable', by scanning the input to see if the data looks like integer numbers (format CF_INT32) or float numbers (format CF_DOUBLE) or strings (format CF_NAME64, etc.). Otherwise the caller can signal that a specific format type and array size be used. Note however that only simple format types will be parsed by this utility (e.g. compound types such as CF_FLTINT are not allowed).
In analogy with 'tsend', atomic write/read command can be issued at the command line by making use of 'tputget' which will assume that the input (write) data is of the same type and length as the output (read) data, or by making use of 'tsendrecv' which will use the given (or deduced) data type and size for the input data but allow the server to return whatever data type and size it wishes.
tputget
Sending data (i.e. issuing a 'set' command) to a server and receiving returned data of the same data type atomically can be accomplished by using 'tputget'. Typing 'tputget' at the commond line will produce the following output:
Synchronous call: sends the input data to the specified TINE device
server and property, and acquires the output. Sets the WRITE access bit by default.
This call should be used for attribute style properties where the format and size are
the same for both input and output data
A single string can be sent by enclosing the data in quotes "".
A data array can be separated by blanks, commas, or semi-colons.
A
string data array will be sent as either
NAME32 or
NAME16 elements.
Do not enclose string arrays with quotes!
You can specify a format by using the /f option switch and you can
specify a specific access (default= READ|WRITE) by using the /a option switch and you can
specify an explicit size by using the /s option switch (cannot exceed the number
of elements!)
A timeout other than the default 1000 msec can be specified via the /t option switch
Usage : tputget <device name> <property> [/f=format /s=size /t=timeout] <data1>
[<data2> <data3> ...]
e.g. tputget /HERA/HEPBLM/WL105K1 MODE 1
or tputget /HERA/HEPBPM/WL105K1 MESSAGE "hello"
Use quotes "" around device names with spaces
e.g. tputget "/HERA/HEPBPM/WL197 MX" MODE 1
or tputget "/HERA/HEPBPM/WL197 MX" MESSAGE "hello"
See also: 'tmonitor', 'tget' for receiving data, 'tsend' for sending data.
and 'tsendrecv' for sending and receiving data with different data types and sizes
Use 'tgputget' for 'attribute' style properties.
tsendrecv
Sending data (i.e. issuing a 'set' command) to a server and receiving returned data atomically can be accomplished by using 'tsendrecv'. Typing 'tsendrecv' at the commond line will produce the following output:
Synchronous call: sends the input data to the specified TINE device
server and property, and acquires the default output. Sets the WRITE access bit
by default.
A single string can be sent by enclosing the data in quotes "".
A data array can be separated by blanks, commas, or semi-colons.
A
string data array will be sent as either
NAME32 or
NAME16 elements.
Do not enclose string arrays with quotes!
You can specify a format by using the /f option switch and you can
specify a specific access (default= READ|WRITE) by using the /a option switch and you can
specify an explicit size by using the /s option switch (cannot exceed the number
of elements!)
A timeout other than the default 1000 msec can be specified via the /t option switch
Usage : tsendrecv <device name> <property> [/f=format /s=size /t=timeout /a=access] <data1> [<data2> <data3> ...]
e.g. tsendrecv /HERA/HEPBLM/WL105K1 MODE 1
or tsendrecv /HERA/HEPBPM/WL105K1 MESSAGE "hello"
Use quotes "" around device names with spaces
e.g. tsendrecv "/HERA/HEPBPM/WL197 MX" MODE 1
or tsendrecv "/HERA/HEPBPM/WL197 MX" MESSAGE /a=READ "hello"
See also: 'tmonitor', 'tget' for receiving data, 'tsend' for sending data.
twait4target
Some activites managed by a server consitute a form of process control. These would be actions such as moving a motor to a target position, which do not complete in a short time, and consequently make synchronous command and control awkward and inefficient. Generally such processes offer a 'START' property, e.g. "Move.START", which launches the 'move' process and returns immediately. A script would then need to 'know' when the process has completed in order to 'continue' with the next step. This usually involves monitoring a 'STATUS' property, e.g. "Move.STATUS" whose return value gives the progress of the the 'move' process. This is most easily scripted by making use of the twait4target command line tool, which will monitor the designated server until a target value is reached and then exit. This will effectively 'block' the sequence of the script until the process has completed (or an error occurs).
If you type 'twait4target' at the command line you will see the following output:
Asynchronous call : Monitors the specified TINE device server property for
the given target values and stops when the target is met or an error
condition arises
Usage : twait4target <device name> <property> [/s=<size> /f=<format> /t=<timout> <target1> [<target2> <target3> ...]
A single string can be sent by enclosing the data in quotes "".
A target array can be separated by blanks, commas, or semi-colons.
Do not enclose string arrays with quotes!
You can specify a format by using the /f option switch and you can
specify an explicit size of the monitored data (default = 1) by using
the /s option switch (cannot exceed the number of elements!)
A maximum wait timeout can be specified via the /t option switch
(default : does not timeout)
twait4target /PETRA/MotorSteering/Motor1 Move.STATUS 0
twait4target /PETRA/MotorSteering/Motor1 Move.STATUS /s=1 /f=int32 0
Use quotes "" around device names with spaces
twait4target "/PETRA/Collimator/Outer Jaw 300M" Position 300
If the target value(s) is(are) omitted, a default target with the
single value of '0' is assumed. Multiple targets can also be supplied.
If thedata size is '1' then any supplied target will cause the monitor
to stop in which case the exit code will specify which target caused
the monitor to halt. If the target array size is '1' (a single target)
and the data size is > '1' then all elements of the output data array
must match the target in order to stop the monitor. If both the target
array and data size array are > '1', then the monitor will halt
immediately if they do not have the same dimension, otherwise each
element is compared element by element to determine if the targets are
met.
calling something along the lines of
twait4target /PETRA/MotorSteering/Motor1 Move.STATUS 0
will by default not produce any output to the screen (you can however apply the switch "/o" to generate some diagnostic output if desired). The call will not return until either 1) the primary target (exit code 0) 2) one of the secondary targets (if given) has been met (exit code = the ordinal number of the target which was met), 3) an error condition has arrisen on the monitor (exit code will be the negative of a TINE return code) or 4) the alotted maximum wait time has been exceeded (error code = -operation_timeout).
tglobals
Typing 'tglobals' at the command line without input will automatically begin monitoring the SITE globals (if available).
Otherwise supply the targeted context as input at the command line
e.g. tgobals PETRA
Z:\>tglobals PETRA
>monitor BeamPermText : Nicht vorhanden @09.11.11 08:38:56.000 CET
>monitor MachineStateText : Keine Strahlfreigabe @09.11.11 08:38:56.000 CET
>monitor MachineTypeText : PETRA @09.11.11 08:38:56.000 CET
>monitor ParticleTypeText : Positronen @09.11.11 08:38:56.000 CET
>monitor MessageText : Service day @09.11.11 08:38:56.000 CET
>monitor BeamPerm : 2 @09.11.11 08:38:56.000 CET
>monitor MachineState : 403 @09.11.11 08:38:56.000 CET
>monitor MachineType : 3 @09.11.11 08:38:56.000 CET
>monitor ParticleType : 2 @09.11.11 08:38:56.000 CET
>monitor Energy : 0 @09.11.11 08:38:56.000 CET
>monitor BeamCurrent : -0.046129 @09.11.11 08:38:56.000 CET
>monitor DeclaredState : Technical Problems @09.11.11 08:38:56.000 CET
>monitor MagCurrPermText : Nicht vorhanden @09.11.11 08:38:56.000 CET
>monitor MagCurrPerm : 2 @09.11.11 08:38:56.000 CET
>monitor MachineFile : Positronen-Aus.Wartung_2009-06-10T07:54 @09.11.11 08:38:56.000 CET
>monitor StateReadiness : 2 @09.11.11 08:38:56.000 CET
>monitor StateReadinessText : Bereit @09.11.11 08:38:56.000 CET
>monitor Optic : none @09.11.11 08:38:56.000 CET
>monitor BeamLifetime : 0 @09.11.11 08:38:56.000 CET
>monitor FastOrbitFBStatus : 2 @09.11.11 08:38:56.000 CET
>monitor FastOrbitFBStatusText : Aus @09.11.11 08:38:56.000 CET
>monitor NumberOfBunches : 0 @09.11.11 08:38:56.000 CET
>monitor OrbitRMSX : 639.37 @09.11.11 08:38:56.000 CET
>monitor OrbitRMSY : 526.333 @09.11.11 08:38:56.000 CET
>monitor SlowOrbitFBStatus : 2 @09.11.11 08:38:56.000 CET
>monitor SlowOrbitFBStatusText : Aus @09.11.11 08:38:56.000 CET
>monitor TopUpStatus : 2 @09.11.11 08:38:56.000 CET
>monitor TopUpStatusText : Ohne Top-Up @09.11.11 08:38:56.000 CET
thistory
Typing 'thistory' at the command line will produce the following output:
Retrieves a stored archive data for the keyword and device specfied
Data can be obtained from a central archive server or from a local history,
depending on how the context and keyword are specified.
A simple keyword along with a context will contact the central archive
server for the context.
e.g. thistory thistory HERA HPDCCur now 1hour
The history depth can be specified in hours, days, weeks, or months and
is parsed as
<number><time unit>
The history target time can be 'now', a valid unix timestamp, or a date
and time string in the form
<day>.<month>.<year>_<hour>.<minute>.<second>
where all entries execpt <day> are optional from right to left.
e.g. thistory HERA HPDCCur 31.05.2006 1day
or thistory HERA HPDCCur 31.05.2006_12:00:00 1hour
A local history can be obtained by specifying the target device server
along with the context (with a leading "/")
e.g. thistory /HERA/HEEKOLLI SOLLWERT HESL66i 31.05.2006 1day
A history snapshot of an array record at a specific time can be obtained
by specifying 'snapshot' as the depth parameter.
e.g. thistory /HERA/HEPBPM ORBIT.X #1 7.06.2006_12:00:00 snapshot
returns the array data record stored at or after noon on June 7th 2006.
The timestamp of the record found is always displayed along with the data.
Usage : thistory <context> <keyword> <device name> <stop time> <depth>
Here <keyword> will be the archived keyword, may or may not be identical to a live property offered from a server, and is the only parameter which is not optional. The order of importance, if you omit anything is as follows:
- keyword : required
- depth : <number><unit> e.g. "8hours" or "1day" default is "1day". The unit can be "minutes", "hours", "days", "weeks".
If omitted it will be intpreted as seconds.
- stoptime : <day>.<month>.<year> as in "28.11.2002". If omitted it is interpretted as now.
- context : Is the designated context. If omitted, the default archive server is queried.
- device : either a number as an index in an array or a matched device name.
For example, to get Getter Pump "WL:2HP171" from "HEVACN" you would type
thistory HERA HEVACN WL:2HP171 28.11.2002 1day
This would produce the following output:
HEVACN/WL:2HP171, Timestamp
3.211e-09, Wed Nov 27 00:03:21 2002
3.211e-09, Wed Nov 27 00:07:24 2002
3.311e-09, Wed Nov 27 00:15:59 2002
3.211e-09, Wed Nov 27 00:46:01 2002
3.211e-09, Wed Nov 27 00:48:38 2002
3.162e-09, Wed Nov 27 01:04:45 2002
3.211e-09, Wed Nov 27 01:06:21 2002
3.211e-09, Wed Nov 27 01:11:08 2002
3.162e-09, Wed Nov 27 01:12:25 2002
3.162e-09, Wed Nov 27 01:42:27 2002
3.162e-09, Wed Nov 27 01:43:32 2002
3.162e-09, Wed Nov 27 01:48:57 2002
3.211e-09, Wed Nov 27 01:53:18 2002
3.162e-09, Wed Nov 27 01:56:24 2002
3.162e-09, Wed Nov 27 01:57:54 2002
...
talarms
TYping 'talarms' as the command line will produce the following output:
Retrieves the current list of alarms for the given device server and device
Usage : talarms <device server> <device>
e.g. talarms /HERA/PBLM
or
talarms /HERA/PBLM/WL167
See also: 'tservers', 'tdevlist' for retrieving information
For example, typing
talarms /DESY2/Mag.Main *
produces the following output:
talarms /DESY2/Mag.Main *
Found 6 alarms for /DESY2/Mag.Main
teventdata
TYping 'teventdata' as the command line will produce the following output:
Z:\>teventdata
Synchronous call: gets the specified stored event data
Usage : teventdata <event trigger> <device name> <property> <event no.> [/c=<event server context> /i=<index> /s=<size> /f=<format> /t=<timeout>]
The required parameters 'event trigger', 'device name', 'property', 'event no.' must be supplied in the call otherwise an error is returned. By default the event server context will be taken to be that supplied in the targeted device name, the index will be taken to be '0', the data size and format will be that registered for the property in question, and timeout will be 1000 msec.
mkhstfiles
'mkhstfiles' is a command line utility for producing a set of local history files to be used for the local history subsystem. These are produced in a highly defragmented manner in order to speed up (dramatically on Windows NTFS) data acquistion of local history data. A best effort is made to produce unfragmented files. However it is also advisable to run the 'contig' utility afterwords in order to guarantee the contiguousness of the file set.
TYping 'mkhstfiles' as the command line will produce the following output:
Configures 'standard' local history random access files according to contents of history.csv
Usage : mkhstfiles [/m=<eqm name> /s=<server name> /p=<history home> /l=<legacy
home> /b=<spillover buffer size>] /t=<monthly> /x=<true>
e.g. mkhstfiles /m=BPMEQM /l=x:\histories\BPM
-will look for history.csv in the BPMEQM subdirectory
of the FEC_HOME area
-will assume that HISTORY_HOME is given by an environment
variable or is a HISTORY directory adjacent to FEC_HOME
-will search for legacy history files in x:\histories\BPM
and convert the contents of any files found
e.g. mkhstfiles /s=BPM
-will look for history.csv in the FEC_HOME area and attempt to
match the contents of the EXPORT_NAME column with the server 'BPM'
-will assume that HISTORY_HOME is given by an environment variable
or is a HISTORY directory adjacent to FEC_HOME
-will assume that any legacy files are located in the same directory
or in a 'SAVED' subdirectory of HISTORY_HOME
use the '-x' switch to examine the activity of mkhstfiles without
actually creating the standard file set
e.g. mkhstfiles /m=BPMEQM /l=x:\histories\BPM /x=true
The history manifest file 'hstmf.csv' will be scanned in lieu of a 'history.csv' file (for those cases, where the local history information is given via API call or .xml file).
