Release Notes for P04-03-01 (last updated 08/30/2004):
The latest revision of this document is located
here. The notes
for the previous release are located
here.
These procedures cover a Windows installation. If you wish to install LATTE under Unix/Linux, refer to the separate procedure.
Installing Truegrid Pro NFS Server for Windows NT/2000/XP
Please refer to the instructions
here to install the NFS server.
Installing LATTE
- LATTE installation requires administrative privileges. Please make sure
you are logged in with administrative privileges.
- Make sure Python 2.3 or later is installed. If not, download it from:
http://www.python.org
- After the Python installation add the Python 2.3 installation directory to
your PATH.
- Download and install Win32 Extensions for Python here:
http://sourceforge.net/project/showfiles.php?group_id=78018
- Download LATTE_Pxx-xx-xx_py2.3.exe from
http://www-glast.slac.stanford.edu/IntegrationTest/ONLINE/updates/default.htm. Start the installer and follow the onscreen instructions.
Verifying LATTE installation:
- Make sure VxWorks network parameters are set properly. If not, enter
"bootChange" and enter the correct values.
- On VxWorks, enter "< startup-ACD-P.vx" or "< startup-ACD-R.vx" for GASU
and "< startup-ltem.vx" for an LCB based non-GASU system. If only
one of these startup scripts is ever used with a given test stand, you can use
the "bootChange" VxWorks command to launch the startup script at boot time.
- Open up a Command Prompt and change the directory to "%ONLINE_ROOT%\LATTE\tests".
- Type "..\start\setupLATTE.bat
- For GASU-based teststands, type:
"python -i test_evt_aem.py --server gitot --schema
%ONLINE_ROOT%\LATTE\repos\simpleGasuSchema.xml" - For CAL teststands,
type:
"python -i test_evt_cal.py --server gitot --schema
%ONLINE_ROOT%\LATTE\repos\simpleTemSchema.xml"
- For TKR teststands, type:
"python -i test_evt_tkr.py --server gitot --schema
%ONLINE_ROOT%\LATTE\repos\simpleTemSchema.xml"
Press Enter.
At the ">>>" prompt, type "test()" and press Enter. You should see the event data
or a running counter being displayed.
Displaying software and hardware versions:
In order to run the "versions" utility, at the command prompt change the directory to "%ONLINE_ROOT%\LATTE" and type "versions.bat
--server servername --schema schemaName". This should output version info for all modules (VxWorks and python) loaded,
and all hardware defined in the given schema that is connected.
To begin writing LATTE scripts, refer to the test scripts in the
%ONLINE_ROOT%\tests\apps directory for orientation.
Setting up the cfg
files:
- For Run Control to operate properly runControl.cfg.sample and
runId.cfg.sample should be copied as configName.cfg and runId.cfg
respectively and modified based on subsystem requirements.
- Modify configName.cfg and add any additional instrument types,
particle types, orientation and phase values. All the other settings can be
changed within the Run Control preferences dialog.
- Modify runId.cfg and change the machineId to a value that is unique within
your site.
- In order to start Run Control with the modified configuration use the
--config configName.cfg command line option.
- If you have copied runId.cfg to a location other than the LATTE\start
directory specify its location in the runId.cfg directory entry in preferences
(Don't forget to click on the SAVE button after making the changes).
- Prior to installation, the old LATTE directories should be renamed
to Online_Pxx-xx-xx and VxWorks_Pxx-xx-xx, where xx-xx-xx is the previous
release number. This allows the user to go back to an earlier release if there
is a problem with the latest one.
- After installation, runControl.cfg file needs to be carried over to the new
installation. If you have created a runControl.cfg in the start directory,
this needs to be copied to the new LATTE\start directory. If
runControl.cfg exists in another directory and you are using the
"runcontrolmain --config" option to specify a configuration file location, then
there is no need to move the file.
- Also the LATTE\start\runId.cfg file from earlier releases needs to be copied
over to the new installation directory. The machine ids needs to be updated to
ensure uniqueness. runId.cfg.sample file contains comments indicating machine
id assignments for each subsystem. This scheme allows for 100 teststands per
subsystem and 999999 runs per teststand. If Run Control fails to access the
runId.cfg after loading the application script, it will throw an exception. In
addition, if you created a brand new runId.cfg by copying from runId.cfg.sample
and fail to change the machine id from its current value of 0, Run Control will
throw an exception as well.
- If you create additional batch files to provide a customized
runControl.cfg to Run Control, please do not create it under the LATTE
installation directory. Instead use your subsystem root directory (ie.
ACD_ROOT, CAL_ROOT, etc.). This way, when you install a new LATTE release, you
won't have to carry over your batch files to the new directory.
- If you have any of the following environment variables defined:
ACD_ROOT, CAL_ROOT, ELX_ROOT, INT_ROOT, TKR_ROOT
you may get an error stating that the digestData file does not exist. This is
due to the fact that Run Control now validates subsystem scripts as well as
core LATTE scripts. When the subsystem installation packages are ready this
won't be a problem; however, until then you need to do the following after your
LATTE installation completes:
- Open up a Command Prompt.
- Type "cd %ONLINE_ROOT%\LATTE\setup".
- Type "createDigestData %XXX_ROOT% c:\Python23 XXX_01-00-00" where XXX is
your subsystem prefix. The third parameter is not important right
now but it should have your subsystem release tag in the future.
- If you get an error such as "bad marshal data" you may have the digestData
but it may have been created with an old Python release. In that case,
follow the instructions above again to recreate the file.
- If you get an error similar to the following:
ERROR:root:ImportError: Bad magic number in
c:\LAT\CAL\Scripts\calu_init.pyo
that means your byte codes were generated with a different Python version. To
fix this just delete all *.pyo and *.pyc files from your script directories.
- If you get an error saying:
'python' is not recognized as an internal or
external command, operable program or batch file.
then your python installation directory may not be in your search path. Edit
your PATH environment variable and add C:\Python23 to it.
- EGU classes should always return an integer from their raw() method.
- GPDU node is now called GXBRD.
- GPDUC node is now called GPDU.
- GGLT node now needs to be specified under the GXBRD node.
- readSchema, applyConfig and readConfig methods are now members of the root
node of a schema, namely GLAT and GXBRD nodes.
- Windows local mode binaries cmdSvr.exe and evtSvr.exe are now phased out
and replaced by OcsManager.exe.
- The schema is now either passed to Run Control from the --schema command
line option or selected from the File menu. Prior to the test script execution
the schema should have been loaded.
- reuseSchema is now obsolete.
- All gutil methods are now distributed amongst gLog, gBits and gException
modules in the LATTE.client package. gutil is still supported but will give a
deprecation warning if used.
- node.getStatus() syntax is no longer supported. You can retrieve the
status of a register access by accessing the exception object in your
try/except block.
- cmdCli.setIgnoreErrors and cmdCli.ignoreErrors are no longer supported. So
all register accesses will now raise an exception if an error occurs.
- In Run Control preferences, there is an additional button "Save".
Previously the preferences changes would persist in runControl.cfg whenever
the "OK" button was clicked. With LATTE 4, "OK" button changes only persist
during the current session where as the "Save" button changes will persist
across Run Control sessions (ie. saved to runControl.cfg).
- COMM card and AEM G2 based teststands are no longer supported.
- Some of the methods available in the event client have now been moved to
the GOCS node. The following table describes the how the old methods map to
new methods:
LATTE 3 |
LATTE 4 |
evtCli.setEventMode(evtCli.SEND_EVENTS) |
GOCS.evtHandlerSendAll() |
evtCli.setEventMode(evtCli.DONOT_SEND_EVENTS) |
GOCS.evtHandlerSendNothing() |
evtCli.setEventMode(evtCli.SEND_ONLY_ERROR_EVENTS) |
GOCS.evtHandlerSendErrorsOnly() |
evtCli.setEventMode(evtCli.ACD_SW_SCALERS) |
GOCS.evtHandlerSendAcdScalers(marker) |
evtCli.setEventMode(evtCli.PRESCALE_EVENTS) |
GOCS.evtHandlerSendPrescaled(prescale) |
evtCli.sendTimeStamp() |
GOCS.synchronize() |
Since in evtHandlerSendAcdScalers and evtHandlerSendPrescaled it is
possible to pass an argument, the method setUserParm method is phased out. In
addition a new method GOCS.evtHandlerSetVerbosity(verbosity) allows the script
to set the verbosity level of the event handler. Scripts can access the
methods mentioned above by using the following statement:
self.rc.common().getOCS().evtHandler...
- childrenXXX dictionary member for nodes is no longer supported. Scripts
can instead use a combination of public children node dictionaries (e.g..
self.lat.TEM) and allXXX() broadcast node methods to have the same
functionality.
- The method for importing LATTE and LDF modules has changed. Now one uses
syntax like 'import LATTE.<module>'. Modules affected are:
- ArgumentImpl: Use LATTE.runcontrol.ArgumentImpl instead. Although scripts
can still import ArgumentImpl as before, a deprecation warning will be
displayed.
- rcTestReport: Use LATTE.runcontrol.rcTestReport instead. Although scripts
can still import rcTestReport as before, a deprecation warning will be
displayed.
- rcTransitions: Use LATTE.runcontrol.rcTransitions instead. Although
scripts can still import rcTransitions as before, a deprecation warning will
be displayed.
- trigger: Use LATTE.trigger instead. Although scripts can still import from
trigger as before, a deprecation warning will be displayed.
- In the past all classes from the trigger package were automatically
imported. With LATTE 4, the scripts need to specify which classes to import
explicitly.
- Gversions: 'from versions import Gversions' is now 'from
LATTE.database.gVersions import Gversions'. Also getModuleVersions() now
expects an GOCS instance as parameter. In addition getHardwareVersions()
expects only a GLAT instance. See above on how to access a GOCS instance.
- gSchemaConfig: 'import gSchemaConfig' is now 'from LATTE.database import
gSchemaConfig'.
- gEGU: 'from gEGU import *' is now 'from LATTE.database.gEGU import *'
- gConstraint: 'from gConstraint import *' is now 'from
LATTE.database.gConstraint import *'.
- rcComplStatus: 'import rcComplStatus' is now 'from LATTE.runcontrol import
rcComplStatus'.
- LDF is now contained in its own package therefore "import LDF" needs to be
changed to "import LDF.LDF" and "import LDFdumper" needs to be changed to
"import LDF.LDFdumper".
- Saturation counter control methods have been renamed and moved from GLAT
node to the GTIC node. They are:
satCtrEnable(self, reg):
satCtrDisable(self, reg):
satCtrLoopEnable(self):
satCtrLoopDisable(self):
satCtrSetLoopDelay(self, delay)
The signature for satCtrEnable and
satCtrDisable is a little different.
Previously the scripts used to pass constants defined in CmdCli to these
methods. Now they actually need to pass the register id that corresponds to
the saturation counter. So an example would be:
tic = self.lat.TEM[0].TIC
tic.satCtrEnable(tic.regs['sat_deadtime_lrs_ctr'].id())
By default none of the saturation counters are enabled. So the script
needs to enable it if reporting on these counters are required.
satCtrLoopEnable()/Disable() enables/disables the update loop that updates all
saturation counter pseudoregisters.
- self.cmdCli is no longer available to user scripts. While discouraged, you
can access the command client through self.rc.common().getCmdCli() or
self.lat.client().
- If any of the schemas reference EGU,
constraint and/or rule classes defined in LATTE, they need to specify the full
package specification of the class. So as an example, if the schema declares:
<class>gEGU.GEGU_linear</class>
it now becomes:
<class>LATTE.database.gEGU.GEGU_linear</class>
Installation:
- Added icon for local mode OCSmanager.exe
- All python code is now compiled to .pyc and .pyo during the installation.
- The python code for the Qt designer .ui files is now generated during the
installation.
- In addition to "C:\LAT\Data", "C:\LAT\Exports" directory is created during
installation if it doesn't already exists.
Flight Software Release:
Qt and PyQt Related:
- This release requires and uses Qt 3.3.1 and PyQt 3.11. All the required
libraries can be found in the LATTE\ext directory.
- pyuic.exe is also provided in the same directory and should be used to
generate python code from the .ui files. The best way of doing this is to run
setupLATTE.bat from the LATTE\start directory before running pyuic. This
way an older version of pyuic won't be used by mistake. Also, please make sure
you own a valid PyQt license if you are going to use pyuic.
- If sub-systems are doing any GUI development using the Qt Designer, it is
recommended that they
download and compile Qt 3.3.x on their systems.
Hippodraw:
- Hippodraw 1.10.3 is included with this release.
Functional blocks and registers:
- GPDU node is now called GXBRD.
- GPDUC node is now called GPDU.
- GGLT node now needs to be specified under the GXBRD node.
- childrenXXX dictionary member for nodes is no longer supported. Scripts
can instead use a combination of public children node dictionaries (e.g..
self.lat.TEM) and allXXX() broadcast node methods to have the same
functionality.
- Added GLCB node which now contains setEvtEnable(), set/getLCBCSR()
methods.
Run Control:
- Fixed the problem of last user always resetting to the first in the
list.
- Added an optional message parameter to logException.
- LATTE 4 port of the code.
- rcTransitions.COMPL_STATUS_PASSED like syntax can now be used again in
addition to self.COMPL_STATUS_PASSED.
- The status monitor no longer updates while a snapshot is being taken.
- Run Control will now produce INFO logs indicating the beginning and end
of a run which contains the test name, operator name, run id, time stamp,
completion status and completion time.
- To run Run Control in local mode use "localhost" for the --server option
when running runControlMain.bat
Example: runControlMain --server localhost --config runControl.cfg --schema
..\repos\simpleTemSchema.xml
- Exception handling was added or improved in the FSM transition handling,
the GUI bridge, event handling and commandSynch threads to make Run Control
more robust.
- The state machine now transitions or remains in the state closer to RESET
when an exception occurs in a state transition. Thus, in SETUP fails to
RESET, TEARDOWN fails to RESET, STARTRUN fails to STOPPED, STOPRUN fails to
STOPPED, PAUSE fails to PAUSED, RESUME fails to PAUSED and STOP fails to
STOPPED.
- If an exception occurs in a state transition that tries to shut down
commandSynch (typically STOPRUN) and therefore doesn't succeed in shutting
it down, the system will hang since there is no way for the system to force
commandSynch to exit. There doesn't appear to be a way to overcome this
limitation at this time.
- If the event handling or commandSynch jobs throw an exception that is not
caught by the application, the system now forces the application into the
RESET state, marking the applications status as FAILED.
There should be far less need to restart Run Control between application
runs now.
- applyConfig now accepts an additional XBRD node instance as parameter.
Run Control Command Line Options:
Mandatory options:
--server to specify the hostname or the IP address of the
teststand crate to connect to.
--config to specify the run control configuration file to use
Optional options:
--schema to specify the schema file to load.
--evtdebug to specify event client debug mode (defaults to 0)
The following debug modes are available and can be added
together for combinations:
0: No Debug
1: Debug All
2: Event Dump
4: Warnings
8: Parser Output
16: Error Output
--cmddebug to specify command client debug mode (defaults to
0).
If this option is specified then all
register accesses from the command client is logged to the logger.
--playback to indicate that Run Control should command the
event server to play back the next event from its file. Since this is done
using the GLT's self trigger command, the state of the internal trigger enable
bit deterimines whether the application or Run Control will issue the self
trigger command. No events will be delivered if the application has the
internal trigger enabled, but doesn't issue CMD_SELF_TRIGGERs.
--noreload to specify a file that contains prefixes of
modules which should not be reloaded when a user script is selected.This list
gets appended to the default list which currently contains the following
prefixes 'scipy', 'weave', 'qwt', 'xml', 'pyexpat', 'win32'. The file should
contain one prefix per line.
--securedir The full path to the secure directory where the
password file ("passwords") and the user permissions file ("security.cfg") is
stored.If this switch is specified then Run Control is started in secure mode.
Servers:
Schema and Configuration:
- The memory requirements and speed in loading a schema has been
significantly improved.
- GTWR and GXBRD nodes now reside outside the GLAT hierarchy (see
simpleTemSchema.xml in the repos directory).
Trigger Interface:
- Modified logic for sweeps slightly for safety. During a sweep, the
application is
locked out of the trigger system.
Housekeeping System:
- There are two components of the housekeeping system, the server:
HskSvr, and the client: HskGuiReceiver (HskReceiver). All programs live in the
monitoring package of LATTE.
- HskSvr reads register values from a teststand directly, parses them, converts
to engineering units (if a conversion is available) and applies thresholds and
asserts alarms (if available). Data is then written out to a "database",
currently implemented as a flat file. HskSvr requires access to the teststand,
and takes the following inputs:
- latSchema: a LAT detector schema
- hskSchema: A housekeeping schema. Example: repos/hskTestSchema.xml
- cmdSchema: A LAT detector schema with ability to command the
detector (must be able to turn power on/off)
- HskGuiReceiver reads values placed in the above database and displays them in
graphical form. HskReceiver is a subset of HskGuiReceiver which simply prints
out the data. Both can run simultaneously with HskSvr.
- HskGuiReceiver does *not* require access to the teststand but takes the
following inputs:
- dataFile: A flat file generated by HskSvr.
- keyFile: Optional (but useful) set of data values to plot.
Contains a set of Key:PlotTitle pairs which set up the plotting mechanisms.
The file monitoring/keyList_full.dat contains the keys currently supported,
but is *not* a valid keyFile. Key names come from the Housekeeping system of
Flight Software and are the unique names used when dealing with ITOS. If a
keyFile is not provided, an example set of values from ARC 11 will be shown.
For the time being, avoid putting large numbers of plots in keyFile (>20), as
all plots are displayed in one window simultaneously.
- HskSvr Usage:
Mandatory options:
- --server specify the hostname or the IP address of the teststand crate to
connect to.
- --latSchema specify the LAT schema file that defines the detector.
- --hskSchema specify the Housekeeping schema file to load.
- --dataFile define the flat file that receives housekeeping data.
Optional options:
- --cmdSchema specify the LAT schema file to be used for commanding. default is
to use --latSchema
Example: $ HskSvr --server lat-elf1 --dataFile c:\TEMP\lat-elf1.dat --latSchema LAT.xml
--hskSchema HSK.xml --cmdSchema LAT.xml
- HskGuiReceiver Usage:
Mandatory options:
- --dataFile define the flat file that contains housekeeping data.
Optional options:
- --timeDepth define the time depth of the housekeeping plots. Default is 2
hours. Units are in seconds
- --keyFile define the file of variables to plot Note: keyFile format is "KEY :
Plot title"
Example: $ HskGuiReceiver --dataFile c:\TEMP\lat-elf11.dat --timeDepth 3600 --keyFile
plots.dat
Miscellaneous:
- setup directory now contains a genUI.bat batch file which automatically
calls pyuic to generate .py files from all .ui files in a given directory
and its subdirectories.
- Created a trigger package in t he ext directory to as a wrapper for the
LATTE.trigger package for backward compatibility.
- Added "Charge Injection" to the particle type section in
runControl.cfg.sample.
- Option names in runControl.cfg can now have non-numeric values. This was
mainly introduced to be able to assign short names for instrument types.
- Added the --noerrfile debug switch to prevent creation of bad and error
event files during testing.
(Retrieved by running versions.bat --server servername --schema
schemaName while in %ONLINE_ROOT%\LATTE directory)
Module |
Version |
LATTE.client.gBits |
2.2 |
LATTE.client.gCmdCli |
2.5 |
LATTE.client.gCommand |
2.2 |
LATTE.client.gEvtCli |
2.9 |
LATTE.client.gException |
2.8 |
LATTE.client.gLog |
2.6 |
LATTE.client.gLoopback |
2.2 |
LATTE.client.gNode |
2.2 |
LATTE.client.gOptions |
2.3 |
LATTE.client.gRegister |
2.3 |
LATTE.client.gResponse |
2.5 |
LATTE.client.gSocket |
2.5 |
LATTE.database.gAEM |
2.9 |
LATTE.database.gAttr |
2.13 |
LATTE.database.gCRU |
2.4 |
LATTE.database.gConstraint |
2.1 |
LATTE.database.gDb |
2.12 |
LATTE.database.gEBM |
2.5 |
LATTE.database.gEGU |
2.2 |
LATTE.database.gGEM |
2.7 |
LATTE.database.gGLT |
2.5 |
LATTE.database.gGroup |
2.1 |
LATTE.database.gHSK |
1.7 |
LATTE.database.gHdb |
1.6 |
LATTE.database.gLAT |
2.7 |
LATTE.database.gLCB |
2.1 |
LATTE.database.gMem |
1.2 |
LATTE.database.gNAT |
2.4 |
LATTE.database.gOCS |
2.9 |
LATTE.database.gPDU |
2.5 |
LATTE.database.gRule |
2.1 |
LATTE.database.gSchemaConfig |
2.22 |
LATTE.database.gTEM |
2.18 |
LATTE.database.gVersions |
2.8 |
LATTE.database.gXBR |
2.12 |
LDF.LDF |
5.1.1 |
OCS (server) |
1.0 |
PyQt |
3.11 |
Python |
0x20304f0 |
Qt |
3.3.1 |
cfitsio |
2.470 |
logging |
0.4.9.2 |
sihippo |
1.10.3 |
xml |
0.8.3 |
Component |
Version |
TEM |
|
GCRC |
|
GTRC |
|
AEM |
|
GARC |
|
GAFE |
|
Please contact Selim Tuvi, Ric Claus, Lester Miller or Jim
Panetta if you have problems or any questions (Contacts
Page)
Back