• David Bowie And Tin Machine*
• Coda 2021 Trailer Sundance
• Coda 21

Historical context

Site-Wide Autocomplete. Coda will now index your Local Root and autocomplete your own functions, classes, and variables. Plug-in Manager. Enable, disable, and update your plug-ins via Preferences. Securely sync your sites, keys, passwords, and more, with other copies of Coda 2.5, Diet Coda 1.6, and Transmit iOS. Indentation Guidelines. August 4, 2017 Revised Standards 2-14 and 3-7 Adopted and Implemented February 2, 2018 Revised Definitions of Terms Adopted and Implemented August 3, 2018 Revised Standards 2-1 and 2-24 Adopted January 1, 2019 Revised Standards 2-1 and 2-24 Implemented August 2, 2019 Definition of Terms (Patients with special needs) and Standard 2-12. Coda comes with building blocks—like tables and buttons—and time-saving templates, so your doc can grow and evolve with the needs of your team. Everyone gets their way. With customizable views, your Trello-loving designer and Gantt-head PM can work off the same data, in their own preferred way.

The 1.x versions of CODA were based on code originally written on ULTRIX workstations starting in 1990 with the first useable version released within the lab in 1992. Many lessons were learned during the use of the early CODA versions and were included in revisions and updates. The original plan was that version of CODA after 1.2 would be version 2.0. (A decision made during the last months of Chip Watson's tenure as head of the data acquisition group at CEBAF). At about the same time the laboratory was in the throes of introducing the HP-UX operating system to run along side ULTRIX. Version 1.3 of CODA was introduced in 1993 to provide cross platform support for ULTRIX, VxWorks and HP-UX from common sources. This has since been a great time saver as, at the end of 1995, the decision was made by the laboratory to phase out ULTRIX and introduce AIX and SOLARIS.

note CODA was never ported to AIX, by the end of the port to Solaris AIX had fallen out of favor as a recommended operating system.

Versions 1.4 and 1.4.1 of CODA were a response to the use of CODA in hall C and contained updates to facilitate the running of 'real experiments'. During late 1993 and through 1994 the focus of the group was to prepare and support the first physics experiments in Hall C and the work then being undertaken by the hall A and B collaborations to prepare for data taking. Version 1.4.1 proved to be so stable that no further major modifications were made and CODA development effort after 1994 focussed on the CODA version 2 required to bring the CLAS detector online.

From the predicted high data rates (>10 Mbytes/Sec) and complexity of the CLAS spectrometer in Hall B it was clear that a major rewrite of large sections of code was advisable to take advantage of lessons learned from halls A and C, and advances in programming techniques and operating system features since the project started. The name CODA 2.0 was reserved for this new, mostly re-written version of CODA. The 1.X numbering system was continued for bug fixes (versions 1.3a, 1.3b, 1.3c) and for the release of CODA2.0 features on top of an essentially CODA 1.3 core (versions 1.4, 1.4a and 1.5).

This numbering scheme has caused some confusion in the past since in early talks time scales for the release of CODA 2.0 were discussed when that version of CODA was actually released as version 1.4.

Lessons learned from halls A and C

Several lessons were learned from the early versions of CODA. The first is of a political rather than technological nature: For CODA to be widely accepted by off-site users it should contain as little commercial software as possible and be able to run on as wide a range of hardware as possible. Many times low budget off-site users attempting to test hardware for use in experiments at this laboratory wished to use CODA for data acquisition only to discover that the only brand of UNIX system on hand was not supported by CODA (we only supported ULTRIX and HP-UX at the time, late 1993) so users were required to buy a supported system and additional commercial software. This was often an unacceptable strain on the budget. A related lesson came from an original assumption that workstations were cheap enough that one could be dedicated to data acquisition and two users would not attempt to run DAQ systems at the same time from the same machine. In the 1.x Versions of CODA technical limitations imposed by the RPC communications software required that only one copy of CODA could be running on a given machine at any instant. This problem was hit almost as soon as the first users touched CODA and everyone wanted a test drive at the same time!

Commercial software

The most noticeable commercial items of software in the early CODA versions were Eiffel, Dataviews, VxWorks and RPC.

Eiffel is an object oriented language which was used to write the RunControl program which controls data taking in CODA. As a language Eiffel has many features which made it superior to C++. Unfortunately the Eiffel compiler is a commercial product and tying RunControl to Eiffel meant firstly that it could not be run on a platform for which there was no Eiffel compiler and secondly that building CODA from sources required the purchase of an Eiffel compiler.

The Dataviews package was our original response to the need to display and monitor parameters from CODA and from a 'slow control' system (high voltages etc.). Once again Dataviews is a reasonably expensive commercial package and off-site users were often complain about the additional cost.

The CODA system relies on having embedded intelligence in the front-end Fastbus, CAMAC or VME systems, the embedded controllers require a real-time operating system and VxWorks was our choice. VxWorks is a commercial product and the licensing structure is complex and expensive. At the moment we have not addressed the problem of the high cost of VxWorks. VxWorks is a good match to the needs of Jefferson lab since it is stable, fast and a market leader. Unfortunately the cost of a code development license for VxWorks is prohibitively high for most off-site users. Work is in progress to port CODA to LINUX but at the moment this is not seen as a replacement for VxWorks.

Author's note early 1999, the Linux port is complete and we are looking ay LynxOS and real-timeLinux as replacements for the increasingly expensive VxWorks operating system.

Finally the RPC package comes 'for free' with most UNIX operating systems and was chosen for use in CODA, unfortunately all versions of RPC were not created equal and the use of RPC actually caused us many problems.

Configuration.

Further lessons came from configuration of CODA for use in an on-line environment. Since the RunControl GUI was written in Eiffel modifications could only be made by the Jefferson lab. data acquisition group and by the nature of Eiffel the code turnaround time was long. Often additions to the GUI would be requested by users leading to a large workload for our group. This problem was partly solved by allowing the user to specify shell scripts to be executed by the RunControl program on state transitions. These shell scripts could then be used to execute small user interface programs written by the CODA user.

The final configuration problem stems from the use of RPC for inter-process communication. RPC uses a program numbering scheme to determine the destination for an RPC message, CODA uses named processes. A name server would be required if more than one CODA component was to be run on a particular host. In the early CODA versions this problem was ignored by 'hard-wiring' the program number into the code and simply stating that there can't be two CODA programs of the same type running on the same machine at the same time.

Author's note early 1999, the name server problem has been attacked by many groups larger than the Jefferson lab DAQ group. For CODA 2.x we decided to write our own name server. In later versions of CODA we will probably use a third party naming service such as CORBA.

CODA 2.0 features (not exhaustive)

Reduced reliance on commercial software

CODA 2.0 uses the minimum of commercial software but does make extensive use of third party packages. The embedded controllers still require VxWorks but the reliance on Eiffel, Dataviews and RPC has been removed. CODA is now extremely portable since it is now written entirely in C, C++ and the Tcl scripting language which are available on all UNIX platforms. We have used the GNU configure tools to allow automatic generation of Makefiles so that porting to new platforms should be very simple and can in many cases be done by users without our intervention.

All of the third party packages, mostly extensions to the Tcl language but also the MSQL database, are either 'freeware', GNU, or free to non-commercial organizations. We do take great care that third party packages are extensively tested. Unfortunately in some cases we were forced to modify third party software such as itcl to add functionality which was useful in our application but were not adopted by the software's original authors. For these reasons many packages are at versions which are not the latest available on the network. In particular we froze Tcl at tcl7.4 but added packages which gave us most of the functionality of tcl8 without having to wait several years for tcl8 to stabilize.

Configuration

Configuration parameters for versions 1.x of CODA were stored in text files. CODA 2.0 replaces this with a relational database, MSQL. This has several advantages, access is rapid and robust, all machines need not share a common file system, the database has access control features. Finally and most importantly the database is dynamic and leads to reconfiguration of the system rather than having to hand edit text files.

One feature of the use of the configuration database is that CODA 2.0 programs can enter information about themselves, such as which TCP port and host they are listening for control messages on. Any other process can query the database to retrieve this information. The need for a separate server to translate program names into program configuration information disappears since the database takes over this function.

A problem with CODA version 1.x which is touched on above is the need for the Jefferson lab. data acquisition group to constantly modify vast libraries of code to configure them for the specific needs for an experiment only to find that the next experiment down the line has entirely different requirements. One way out of this problem is to make the software extremely modular and use a scripting language to glue libraries together into programs. A scripting language has the advantage that, since it is interpreted rather than compiled, very rapid code changes can be made. We chose Tcl as the language for CODA, other languages were considered but Tcl seemed the most stable and best suited to our needs at the time that the choice was made.

The advantages that Tcl gives us are many. The most important is obviously rapid prototyping. Another lest obvious advantage is that since each program is a Tcl interpreter we can easily give any program a command line interface. This is particularly usefull when a system is being debugged since commands normally issued by remote calls over a network can be entered manually.

The Tk extension to Tcl allows rapid development of graphical tools for debugging, monitoring and other tasks removing the need to modify the main RunControl GUI. Suplementary graphical interfaces written in Tcl may be started by RunControl.

To aid in configuration two editors have been written. The first is a general editor which can be used to create and modify tables in the MSQL database. The second editor allows the user to draw a pictorial representation of the dataflow in the experiment. The picture is stored as database entries which are used by CODA to configure the system for a particular data taking run type.

David Bowie And Tin Machine*

Speed

CODA 2.0 has many features designed to improve performance. The readout controllers now contain a buffer manages so that multiple events may be buffered untill enough data has been accumulated that the overhead involved in setting up a network transfer is much less than the time taken to perform the transfer. The buffer manager also reduces the deadtime since filling and emptying buffers can occur in parallel.

The use of Tcl ,suprisingly enough,also leeds to a speed increase. Network links are now monitored by Tk file handlers which reduces the number of points in the code where network socket status must be checked (calls to select). Also low priority periodic tasks can be handled by Tk timer handlers so that they do not conflict with the main data flow.

Robustness

CODA 2.0 is more robust than earlier versions of CODA and this feature will be improved as we gain experience in working with the new software. The use of asynchronous file handlers for the monitoring of communication links means that any problems are noticed immediately and action can be taken to correct the problem. The distributed programming system used by CODA has several fallback positions before a network link is declared to be unrecoverably 'down'. These features are documented in the user's guide sections on control and networking.

All CODA 2.0 processes contain signal handlers and 'atexit' handlers to trap standard problems , such as the use of '^C'. When a fatal problem is detected the last hing that a process does, if possible, is to communicate with the MSQL database and change it's state to 'down'. In the event that a process hangs or crashes in such a way that it cannot communicate with the database each process also emits a periodic 'heartbeat' signal. This signal can be monitored to provide a warning of a potential problem. If the problem persists a recovery mechanism can be automated.

Control

The RunControl program which provides centeral control of the data acquisition system has been re-written in C++. The new RunControl is actually two programs, a GUI called runcontrol, and a server called rcServer. Multiple copies of 'runcontrol' can be executes and connected to a single server. Mastership can be transferred between GUIs.

The run control server is part of the 'session management' system of CODA 2.0. One problem with CODA 1.x was it's inability to have multiple copies of the data acquisition system (sessions) sharing the same set of configuration files. In CODA 2.0 each instance of rcServer is defined to be a 'CODA session' and an entry is placed in the database describing the session. The CODA software keeps track of which configurations of hardware and software are being used by each session and attempts to ensure that two people do not try to control the same device or process at the same time. This concept was designed for use in the early stages of data taking when 'experts' on different aspects of the detector need to run independent data acquisition on their own part of the detector.

The rcServer program has an interface to the CDEV system. CDEV is a common API for control systems. The concept is that a user should be able to send simple 'plain English' commands to a control system without having to much of an in depth knowledge of the internal workings of the system. The EPICS control system used for accelerator control and detector 'slow controls' also has a CDEV interface. The use of CDEV allows information and control to pass between EPICS and CODA without the user needing to understand both systems thoroughly.

UNIX Buffer manager

CODA 2.0 incorporates a shared memory buffer manager. This is the DD (Data Distribution) system written by Chris Witzig of Brookhaven National Laboratory. The Jefferson lab. group worked with Chris on development of a common version of the DD system for the two laboratories. The resulting system is faster and more robust than the original with many new features.

Monitoring

In a distributed system like CODA monitoring of data flow and process health is important. Several tools have been developed to assist the end user. These are described in detail in the user guide.

Coda 2021 Trailer Sundance

Coda 21