Interfacing Programs to ALS Controls

There are several ways for programs to access the ALS control system to read (and in some cases write) information. This web is a collection of the documentation and code. This is a work in progress, so some parts are incomplete. Comments to akbiocca@lbl.gov

Accessing the Control System Efficiently

Minimizing network and data server loading requires efficient use of the protocols and data access libraries. The underlying Channel Access protocol has a set of optimized functions that determine where the data is served from (the discovery process), maintain a single TCP/IP connection to each data source, and efficiently transport blocks of data. It is inefficient to gather data in small increments - it is important to group the gathering of data together, and important to not re-discover channels each time they are frequently accessed. As an example of the efficiency of this system, the Archiver gathers 7,000 channels of new data in the control system periodically (every few minutes). Of these, 5,000 are control and boolean type values that do not often change and 2,000 are analog input values that change frequently. The control values are 'monitored' which means that the data is only transmitted over the network when changes occur. Monitoring techniques are advanced and beyond the scope of this document. The analog input values are read in a 'group', and this read process takes xx milliseconds. A 'get group' of a few channels typically requires 2-6 milliseconds, and this time is of course somewhat more for larger data sets.

Most of the data in the control system originates in the Intelligent Local Controllers (ILCs) that exist out in proximity to the devices such as magnet power supplies, beam position monitors, etc. Each of these devices reads data at hundreds to thousands of times per second. This data is stored in a local memory that is periodically polled via the serial link from the CMM, at about 10-20hz. This is in turn scanned by the CRIOC (Control Room Input Output Controller) at about 12 hz. Thus new data is available on the order of every 100 milliseconds. Attempting to read data faster than 10hz is not useful. Programs should perform 'get group' methods at less than 10 hz, and only as often as they actually require data. Multiple groups can be created so that if only a few channels are required part of the time, and a larger set at other times, a separate group for each set increases performance and efficiency.

The paradigm we have evolved to for reading data is to create a 'data set' or 'group' that is transferred at once. This is efficient for the network and the data servers such as the CRIOC. The programmatic interface for this is to build a group by repeatedly calling 'add channel to group'. Once the whole group is constructed a call to 'get group' will gather all the data and bring it into the local memory of the program, in data structures that were created as the group was built. Finally 'read from group' accesses from the data retrieved during the 'get' phase, a local memory access.

The data includes not only the value, but also the status of that value. Possible status' include errors (not connected, stale data), or that a new value has been read. It is important to check the status of the data. A special value is sometimes used to indicate invalid data. This value was chosen to be unlikely to occur in normal operation (1.2345e-30?), but the status contains more info, and is a better way to handle the data.

Access Methods

Language Specific Methods

Legacy Methods

Note that some portions of this site are restricted to LBNL or ALS access. Contact AKBiocca@LBL.gov for access issues.