1. Software v1.0
    1. Overview
    2. User Interface Panels and Controls
    3. Data Storage Structure
    4. Sending Data to Remote TCP/IP Clients
    5. Configuration Issues
    6. References

Software v1.0

 

 

 

 

 

 

 

 

 

 

 

ATLAS AMT 0.1 MiniDAQ software

 

 

 

Software v1.0

Documentation v1.1

 

 

University of Michigan

16 July, 1999

 

 

B. Ball, J. Kuah, J. Hollar, and E. Munson

 

 

 

 

 

 

 

 

 

 

Overview

 

The ATLAS MiniDAQ software is designed to program and acquire events from an AMT 0.1 mezzanine card setup. It uses user-level routines from the ATLAS interface library, which is implemented in LabWindows/CVI. The MiniDAQ program is operated through a set of user-defined CVI user interface panels. The function eventLoop in the ATLAS interface library is the core of the MiniDAQ system. It allows continuous polling for GUI or hardware events while the system is active. This function also allows counters to be updated and user “hook” functions to be called on each iteration of the loop.

  The MiniDAQ uses a user hook function to read data from the AMT 0.1. This is done through a VMIVME 2510B parallel IO module in a handshaking mode. The MiniDAQ stores the acquired data in a buffer, where it can be saved to a file or printed to standard IO. The ATLAS interface library also allows the data to be sent over TCP/IP to multiple remote clients as it is acquired.

 

User Interface Panels and Controls

 

  1. ATLAS Mini-DAQ Control

This is the main panel of the user interface. All other sub-panels are accessed from this panel. Resets of the AMT 0.1 are controlled by the AMT Reset, Event Reset, Bunch Reset, and Full Reset buttons. A Full Reset performs three consecutive VME writes in the order Reset -> Event Reset -> Bunch Reset. The Access AMT 0.1 JTAG button brings up sub-panels allowing JTAG programming of the AMT 0.1.

When a run is started, the user is prompted to select Disk or None (standard IO) as a storage preference. This choice is unrelated to sending the data over TCP. The packets are sorted and labeled as TDC header or trailer, group header or trailer, mask flags, single measurement, combined measurement, error, or debugging. If disk is chosen, the user is prompted to select an appropriate file in which to save the data as a text file. Time and date of the beginning and end of a run are recorded if data is saved to a file.

The GUI also includes buttons to pause a run, resume a paused run, or end a run.

Finally, a Help button and a Quit button are included. If the Help button is selected, the next control selected will display a help message.

 

  1. JTAG Control via 2510

This panel allows programming of the AMT 0.1 Setup and Control registers. This process uses the 2510B module to send the appropriate bit strings and clock controls to the AMT JTAG interface. The Cold Start AMT 0.1 button resets the DLL (Delay Locked Loop) and loads the control and setup registers. Change Control and Change Setup bring up sub-panels allowing bits in the control and setup registers to be toggled on or off. The Program AMT 0.1 button loads the control and setup registers with the values selected in Change Control and Change Setup . In addition, several status display buttons, a Reset TAP button, a Help button, and a Quit button are included.

 

  1. Control and Setup Registers of AMT 0.1

The Control Register panel and the five Setup Register panels allow the JTAG state bits of the AMT 0.1 to be toggled on and off. The panels can be cycled through with the Previous and Next buttons, and the Done button returns to the JTAG Control panel to apply the changes. Once the changes are applied, the Control and Setup panel states are saved and the panels are hidden. Hitting the Cancel button at any time exits the Control or Setup panels and returns everything to the previous state.

 

Data Storage Structure

 

During an acquisition run, the data words from the AMT 0.1 are stored in a one thousand-word array of 32-bit integers. This array is then formatted to include a six-word header before the actual data. In order to do this the MiniDAQ checks the packet type of each data word to see if it is an AMT 0.1 header. If it is an AMT 0.1 header, it checks the ID against the last ID received to avoid duplicate data. If the ID is different, it prepares the six-word header and reads in data until an AMT 0.1 trailer is received. The final structure of the buffer for each event is as follows:

 

    Header
1. Total length of this event, including this word
2. Run number
3. Event ID
4. Record Type
5. Reserved
6. Reserved

 

  Data
1. Total length of data record, including this word
2. First real data word
3. Second real data word
4. Third….

The first word of the data section immediately follows word six of the header section. All words are 32-bit integers.

 

 

Sending Data to Remote TCP/IP Clients

 

The ATLAS interface library includes functions for operating a DDE (Dynamic Data Exchange) server. The MiniDAQ is therefore automatically registered as a server when eventLoop is called. If there is a need to send data to remote clients, the MiniDAQ can be operated together with a CVI based “DDE client/ TCP server” program running on the same machine. This program receives data from the MiniDAQ over a single DDE connection, and then transmits it over TCP to multiple remote clients, which can be either CVI-based or UNIX-based. There should only be one MiniDAQ running at a time, as the ATLAS interface library will register each DDE server under the same name.

The DDE server is operated at the ATLAS interface level, and only the function SendData(*data, sizeof(data)), where data is a pointer to the new data buffer, needs to be called in the MiniDAQ. This is done in the function DDE_Send(void), which fills the buffer when a new event is detected. The entire one thousand-word buffer will be sent over DDE, with any unfilled elements of the array sent as zeroes. A one-second delay is introduced between sends to avoid overwriting DDE data.

The DDE -> TCP exchange is handled automatically by the Server/Client program once data is sent over DDE. If SendData is called without a DDE connection, the send request will be ignored. The DDE server will shut down on quitting the MiniDAQ. The purpose of this system is to avoid the overhead of running a TCP server handling multiple connections directly in the MiniDAQ program. For more information on the DDE/ TCP system, see [5].

 

 

Configuration Issues

 

The MiniDAQ program is written in C and compiled under LabWindows/CVI 4.0.1. Some or all of the visual interface routines may have to be altered to compile it under other graphical software packages. The code for the DDE server in the ATLAS interface library is written with CVI routines, so it should be compiled under CVI if data will be sent out over DDE. Since DDE operates only under MS Windows, the DDE server part of the program can not be run on other platforms.

  In addition, the appropriate VME and VXI controller and software must be installed correctly. These are described in [6].

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

References

 

[1] LabWindows/CVI Programmer Reference Manual. July 1996: National Instruments

 

[2] LabWindows/CVI Standard Libraries Reference Manual. July 1996: National Instruments

 

[3] LabWindows/CVI User Manual. July 1996: National Instruments

 

[4] ATLAS MiniDAQ Interface Library Software. June 1999: E. Munson and B. Ball

 

[5] DDE Client/ TCP Server System Software. June 1999: J. Kuah and J. Hollar

 

[6] ATLASinterface Library Configuration Issues. December 1998: E. Munson

 

Back to top


1