Release Notes for P04-05-00 (last updated 11/03/2004):

The latest revision of this document is located here. The notes for the previous release are located here.

Installing LATTE

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

  1. LATTE installation requires administrative privileges. Please make sure you are logged in with administrative privileges.
  2. Make sure Python 2.3 or later is installed. If not, download it from:
  3. After the Python installation add the Python 2.3 installation directory to your PATH.
  4. Download and install Win32 Extensions for Python here:
  5. Download LATTE_Pxx-xx-xx_py2.3.exe from Start the installer and follow the onscreen instructions.
  6. Verifying LATTE installation:

  7. Make sure VxWorks network parameters are set properly. If not, enter "bootChange" and enter the correct values.
  8. 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.
  9. Open up a Command Prompt and change the directory to "%ONLINE_ROOT%\LATTE\tests".
  10. Type "..\start\setupLATTE.bat
  11. For GASU-based teststands, type:
        "python -i --server gitot --schema %ONLINE_ROOT%\LATTE\repos\simpleGasuSchema.xml"
  12. For CAL teststands, type:
        "python -i --server gitot --schema %ONLINE_ROOT%\LATTE\repos\simpleTemSchema.xml"
  13. For TKR teststands, type:
        "python -i --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.

  14. 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:

  15. 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.
  16. 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.
  17. Modify runId.cfg and change the machineId to a value that is unique within your site.
  18. In order to start Run Control with the modified configuration use the --config configName.cfg command line option.
  19. 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).

    Running Run Control:

  20. Run Control needs to be started from the LATTE\start directory as follows:
        runcontrolmain  --server servername --config configFilename --schema schemaFileName
    runcontrolmain  --server gitot --config runControl.cfg --schema %ONLINE_ROOT%\repos\simpleTemSchema.xml
    If you need to change the schema without exiting Run Control you can use the “Select Schema” File menu option.

Upgrading LATTE:


Dependencies, Bug Fixes, and New Features:


Flight Software Release:

Qt and PyQt Related:


Functional blocks and registers:

Run Control:

Client & Servers:

Housekeeping Client & Server:

Schema and Configuration:

Message Logger:

Trigger Interface:


Test Suite:


Event handlers:

In past LATTE releases there has been only one event handler. It is called rcTransitions.__eventHandler(). This handler uses the evtCli class to fetch the event data from a socket and initialize the evtCli data parsers. If no other work is done by the system (the application process() method is empty and the data is not archived), we see the system handle about 3 KHz of LAT generated triggers (i.e., not solicited triggers) on the 2.5 GHz PCs used by LAT I&T. This drops to about 2.5 KHz with archiving turned on.

A new event Handler has been added with this release. It is called rcTransitions.__datagramHandler(). In addition, the ability to use a custom event handler has also been added. The method to select the event handler is called rcTranstions.selectEventHandler(). It takes an argument from the list rcTransitions.EVENT_HANDLER_STANDARD, rcTransitions.EVENT_HANDLER_LEAN_AND_MEAN, rcTransitions.EVENT_HANDLER_CUSTOM, and may be expanded in the future. If selectEventHandler is not called, the event handler of previous releases is used.

The new __datagramHandler() method is selected with the LEAN_AND_MEAN option. The intention of this handler is that it does the minimum amount necessary to get the data off the socket, delivered to the process() method, archived and multicasted. With archiving turned off, we now see ~5 KHz on these same PCs. It drops to ~4.5 KHz with archiving turned on. Multicasting has negligible effect on the rate. It is recommended that if the infrastructure of evtCli isn't needed for a particular test application, then the LEAN_AND_MEAN event handler should be selected. If the events need to be parsed in this case, use the LDF package.

Note that these rates are very sensitive to the PC's capabilities and the amount of work LATTE and the running test application has to do for every event. The rate values shown above may well be different in your particular situation and may well change in either direction in the future.

Application Defined Datagrams and LATcontributions:

The current release contains features that help with generating and archiving LATdatagrams and LATcontributions to the science data stream. An example of two different methods for doing this is given in tests/apps/ The variable OneDgContrib in that program switches between the two methods.

The first example method creates a standard datagram containing an application defined LATcontribution. This method would be used when it is desired to record the application defined datagram only once, versus for every event.

An identifier for the the contribution must be chosen. See the LDF doxygen for LATprimaryId and LATsecondaryId and pick an unused offset from one of the choices. From the primary and secondary IDs, build the LATtypeId as shown in the example.

A LATcontribution is a LATtypeId and a length followed by an arbitrary payload. The length includes the LATtypeId and length fields in addition to the length of the payload. It is in units of bytes, but must be divisible by four to keep longword alignment.

Prior to writing the application defined datagram out to the science data stream, it may need to be byteswapped so that the recorded data ends up in Big Endian order. Some of the LDF package functions can help with this.

The second example is aimed at adding custom LATcontributions to every event or to some subset there of. Thus if one were ramping a charge injection DAC, or something like that, once could add a LATcontribution on the first event of a new setting that records the setting. One could also use the first method above to record a separate datagram between events containing the value of the new setting.

Adding an application defined contribution to an event consists of creating the LATcontribution somewhere, either prebuilding it in one of the state transitions, or somewhere in the commandSynch() method. Use the same ideas as above to create it. When the contribution is to be added to the event, return a tuple from the process() method containing the LATcontributions you want to record, in the order you want to record them. When this method is used, the application is also responsible for providing the LATcontribution containing the event data. The rcTransitions base class will construct a LATdatagram consisting of the the LATcontributions specified by the process() method. The event data LATcontribution can be retrieved from the LATdatagram _string_ passed to the process() method by shaving off the first eight bytes, e.g., latDatagram[8:].

Again the rule applies that all LATcontributions in the returned tuple must be in longword Big Endian format. Thus, if the event data LATcontribution has been processed by the LDF package on a little endian machine, its contents will have been byte swapped. It must be swapped back to longword big endian before being returned by process(). This can be done using the LATcontribution.string() method.

If process returns None (or, equivalently, returns nothing), the rcTransitions base class takes care of writing the event datagram.

Version Information:

(Retrieved by running versions.bat --server servername --schema schemaName while in %ONLINE_ROOT%\LATTE directory)



LATTE.client.gBits 2.2
LATTE.client.gCmdCli 2.3
LATTE.client.gCommand 2.3
LATTE.client.gEvtCli 2.28
LATTE.client.gException 2.12
LATTE.client.gLog 2.7
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.8
LATTE.database.gAEM 2.9
LATTE.database.gAttr 2.14
LATTE.database.gCRU 2.4
LATTE.database.gConstraint 2.1
LATTE.database.gDb 2.13
LATTE.database.gEBM 2.6
LATTE.database.gEGU 2.2
LATTE.database.gGEM 2.9
LATTE.database.gGLT 2.5
LATTE.database.gGroup 2.1
LATTE.database.gHSK 1.8
LATTE.database.gHdb 1.7
LATTE.database.gLAT 2.11
LATTE.database.gLCB 2.4
LATTE.database.gMem 1.5
LATTE.database.gNAT 2.4
LATTE.database.gOCS 2.11
LATTE.database.gPDU 2.7
LATTE.database.gRule 2.2
LATTE.database.gSchemaConfig 2.41
LATTE.database.gTEM 2.20
LATTE.database.gVersions 2.14
LATTE.database.gXBR 2.15
LDF.LDF 5.2.0
OCS (server) 1.1
PyQt 3.13
Python 0x20304f0
Qt 3.3.3
cfitsio 2.470
sihippo 1.12.3p1
xml 0.8.3



Please contact Selim Tuvi, Ric Claus, Lester Miller or Jim Panetta if you have problems or any questions (Contacts Page)