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:
Typing 'tservers' at the command line will produce the following output:
Retrieves a list of registered servers for the given context and subsystem Usage : tservers <context> [<subsystem>] e.g. tservers HERA or tservers HERA MAG See also: 'tproplist', 'tdevlist' for retrieving information
So we immediately see that it takes the targetted 'Context' as an argument, and, optionally, an input subsystem. Resubmitting the command with for instance context 'DORIS' and subsystem 'RF' will produce the following output (at least at DESY):
Servers in context DORIS subsystem RF: DORCAV DORQ1 DORQ4 DORFB DOTRCRF 5 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.
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 /HERA/HEPKOLLI/WR094.AUSSEN
which specifically identifies the device name as belonging to context 'HERA' and device server 'HEPKOLLI' and referring to the instance 'WR094.AUSSEN'. The call could as well be made by typing:
tdevs HEPKOLLI
which omits the context and the device instance. This will be resolved by the ENS by ignoring the CONTEXT entirely and looking for the first match as to the device server name of 'HEPKOLLI'. If there is no other 'HEPKOLLI' registered (for instance in a 'TEST' context) then there is no ambiguity. The device instance can be ignored entirely. In our case, the output for either of the above queries looks like:
DEVICE_NAME,DEVICE_NUMBER GENERAL,0 WR094.AUSSEN,1 WR094.INNEN,2 WR094.OBEN,3 WR094.UNTEN,4 WR094.MAX,5 WR094.MEAN,6 WL105.AUSSEN,7 WL105.INNEN,8 WL105.OBEN,9 WL105.UNTEN,10 WL105.MAX,11 WL105.MEAN,12 WL150.AUSSEN,13 WL150.INNEN,14 WL150.OBEN,15 WL150.UNTEN,16 WL150.MAX,17 WL150.MEAN,18 WR033.AUSSEN,19 WR033.INNEN,20 WR033.OBEN,21 WR033.UNTEN,22 WR033.MAX,23 WR033.MEAN,24 WL019.AUSSEN,25 WL019.INNEN,26 WL019.OBEN,27 WL019.UNTEN,28 WL019.MAX,29 WL019.MEAN,30
Typing 'tproplist' at the command line will produce the following output:
Retrieves a list of registered properties for the given device server Usage : tproplist <device server> or tproplist <device server>/<device name> 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" 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 /HERA/HEPKOLLI/WR094.AUSSEN
which specifically identifies the device name as belonging to context 'HERA' and device server 'HEPKOLLI' and referring to the instance 'WR094.AUSSEN'. The call could as well be made by typing:
tproplist HEPKOLLI
which omits the context and the device instance. This will be resolved by the ENS by ignoring the CONTEXT entirely and looking for the first match as to the device server name of 'HEPKOLLI'. If there is no other 'HEPKOLLI' registered (for instance in a 'TEST' context) then there is no ambiguity. Furthermore, the device instance will not be passed to the server in question, so a generic response to the query will be returned. If all devices support the same property list then, once again there is no ambiguity. In our case, the output for either of the above queries looks like:
Property List for HEPKOLLI (75 properties)
DIODES
SET:DON
SelectedFile
POSITIONS.SOLL
POSITIONS.IST
XRATES
STATUS.USER
BKGLIMIT
RD:PARAM
JawMove
POSITIONS.NAM
POSITIONS.SOLL.NAM
FILE820GEV
RATES
JAWSIN
JAWSDISPLACED
JawPosition
RD:STD
POSITIONS
POSITIONS.IST.NAM
ST:COPY
SET:PARAM
SUMRATE
TARGETS
STATUS.ERROR
STOP:ALL
FILE15MM
SCANFILES
BACKGROUND
RATES.NAM
SCANDATES
STOP:FST
BKGOPTSET
INTRPT
STATUS.ERROR.NAM
STATUS.USER.NAM
ST:FST
SET:D1933
STATUS
RESET
BKGFLAG
TARGETS.NAM
RATEMODE
ST:AUTO
DISABLED
JAWSOUT
SET:DOFF
BKGOPT
KOLLIFILE:******
KOLLIFILE:*****
KOLLIFILE:****
ST:FST:**
ST:RES:**
ST:COPY:**
ST:AUTO:**
ST:SLW:**
ST:IN:**
ST:OUT:**
R:GRV:**
R:RPOS:**
R:POS:**
S:RPOS:**
S:POS:**
S:ACC:**
S:VEL:**
C:RUSR:**
C:MOVE:**
C:EICH:**
C:RAUS:**
C:RDRE:**
C:RMIC:**
C:PON:**
C:POFF:**
C:STOP:**
C:RALL:**
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
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>] 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
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 ...
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. A string data array will be sent as either NAME64, 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 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.
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.
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.
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. A string data array will be sent as NAME64, 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 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).
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
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:
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 ...
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/* [alarm 0] { server : Mag.Main device : DI_DC alarmTag : PS AUS alarmCode : 521 timestamp : 1320825611.576 starttime : 1320822005.264 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : } [alarm 1] { server : Mag.Main device : DI_AC alarmTag : PS AUS alarmCode : 521 timestamp : 1320825774.787 starttime : 1320819765.958 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : } [alarm 2] { server : Mag.Main device : QD alarmTag : PS AUS alarmCode : 521 timestamp : 1320825773.783 starttime : 1320819764.946 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : } [alarm 3] { server : Mag.Main device : QF alarmTag : PS AUS alarmCode : 521 timestamp : 1320825773.783 starttime : 1320819764.947 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : } [alarm 4] { server : Mag.Main device : SD alarmTag : PS AUS alarmCode : 521 timestamp : 1320825774.787 starttime : 1320819765.958 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : } [alarm 5] { server : Mag.Main device : SF alarmTag : PS AUS alarmCode : 521 timestamp : 1320825774.787 starttime : 1320819765.958 alarmMask : 0x0 severity : 13 descriptor : 6 alarmSystem: 100 alarmData : }
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' 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).
1.5.8