Front End Glossary¶
(Accelerator Controls NETwork) Technically, ACNET refers to the home-grown, network transport layer of the Fermilab Accelerator Control System. The ACNET transport routes packets between ACNET nodes for all protocols used at the lab. The term "ACNET", however, is also informally used to refer to various layer of the control system.
An attempt at rebranding the Fermilab control system. It's a clever abbreviation of Accelerator Control System and pronounced "access", which is what the Controls Department wishes to provide. It was coined by Charlie Briegel to wash away negative associations other labs may have built up with the ACNET name. By using a more general name -- without a hint of ACNET in it -- we want to appear to be more receptive to integrating alternate technologies (although ACNET will still be a large part of the system for years to come.)
The ACNET Control System uses a central database for all its configuration information. The Device Database, in particular, holds all information pertaining to the devices that interface with the accelerator. You can interact with the database using this
D80 console application. The command line utility,
dabbel, is useful to make many, many mechanized changes to the database.
Acnet Control Language ???
A device can either refer to a piece of hardware, e.g. magnet power supply, that is out in the field or an ACNET device which is a variable associated with the hardware.
Any machine providing devices to the control system. Most front-ends at Fermilab use protocols over ACNET to deliver device data. However, Fermilab has mimimal support for EPICS front-end (IOCs) as well. Front-ends use a framework that translates network protocol requests into hardware accesses (via drivers). Due to historical reasons and budget constraints, we have many front-end architectures: MOOC, IRMs, SRFs, ACSys, LabView, and OACs are all active front-end platforms that provide data to operate the accelerator. MOOC-based front-ends are used by VME processors running VxWorks. ACSys front-ends run on Linux machines. OACs are software-only front-ends written in Java.
Software written for a front-end framework that interfaces with hardware.
The Data Pool Manager provides a consistent interface to the lower levels of the control system. It helps clients from having to worry about what protocols are supported by front-ends, in which front-ends devices reside, and how to scale data from the front-end. It also consolidates similar requests to front-ends to minimize network traffic and front-end load.
Typically used to refer to an ACNET node. An ACNET node is a system that participates in ACNET communications. In order to participate, a machine needs to be registered as an ACNET node (which means its IP address has been added to the ACNET node table.)
Refers to any of the Linux machines that run ACNET console applications ("CLX" was probably distilled from "Consoles" and "Linux".) These machines are ACNET nodes and their node names start with "CLX". More recently, the CLX nodes have also been used to host ACSys front-ends.
Is an abbreviation for "sub-system device number"; it is an 8-byte word of driver specific information. SSDNs are sent as part of the payload for a device reading (or setting) request. Although each front-end architecture defines the layout for its SSDN, the information obatined is pretty much the same: the driver identifier, channel number, scaling or masking information for the device, etc.
Is an abbreviation for "Object ID" and is used to uniquely refer to a driver resource in a front-end. Both the MOOC and ACSys front-end frameworks use the term "OID" to refer to an instance of a driver. The term "Object" was coined because MOOC uses an object model for drivers so each instance of a driver that is running is an object instance. The frameworks reserve a position in a device's SSDN to specify the OID that supports the device.