WO2003052530A2

WO2003052530A2 - Control system and method

Info

Publication number: WO2003052530A2
Application number: PCT/GB2002/005787
Authority: WO
Inventors: Ian Cartland
Original assignee: Cambridge Cognition Limited
Priority date: 2001-12-19
Filing date: 2002-12-19
Publication date: 2003-06-26
Also published as: WO2003052530A3; AU2002352461A8; GB2384866A; GB0130397D0; AU2002352461A1

Abstract

A network manager (20) is coupled to a network (4). A number of control units (6) is also coupled to the network, each having a plurality of inputs and outputs which can be coupled to one or more devices (8). The network manager transmits to the control units, over the network, programs for the control units to run on local processors to control the devices coupled to their inputs and outputs. Input signals received from the devices are temporarily stored as data by the control units, and then transmitted over the network to the network manager for storage (34). A results filter (32) is preferably associated with the network manager to filter the data after it has been transferred from the control unit or units and stored at the network manager.

Description

Control System and Method

The invention relates to a control system and method for controlling a plurality of devices, and to a corresponding programming language and method.

Background of the Invention

In many research and development applications it may be desirable to monitor and control a plurality of remote devices of similar type from a controlling PC. More specifically, it may be advantageous to be able to^' write algorithms in advance and to have these execute remotely from the controlling PC in order to interact with the remote devices. A simple example application in the field of cognitive testing is reaction time testing. A subject at a location remote from the controlling PC might be presented with an array of lights and an array of corresponding press-switches. An algorithm would be designed to switch on a light, either at random or according to a predetermined sequence, await a response on the corresponding press-switch and record a reaction time. Applications of such capabilities could be very diverse, ranging from cognitive testing to the prototyping of industrial control systems .

Summary of the Invention

The invention provides in its various aspects a control system and method, and a programming language and method, as defined in the appended independent claims. Preferred or advantageous features of the invention are defined in dependent subclaims .

In a first aspect the invention advantageously provides a control system and method in which a network manager runs on a computer (or PC) which interfaces through a network to one or more control units (or controllers) . Each control unit comprises a processor, a memory (which may comprise a buffer memory or persistent storage) , and a plurality of inputs and outputs which can be coupled to external devices which are to be controlled. The control units are advantageously dedicated units having no user interfaces, which communicate with the network manager using a predetermined protocol.

In a preferred embodiment the network manager determines the arrangement of the coupling of the inputs and outputs of each control unit to the external devices and downloads to the memory of each control unit one or more programs for controlling the external devices attached to each control unit. The processor in each control unit runs software which interprets and executes the commands required by the user's program or programs, which may cause output signals to be sent to each device and input signals to be recorded and optionally responded to via further output signals (that is, subsequent output signals may depend interactively on previously received input signals according to the program) .

This methodology may advantageously allow the user to define the interface between each control unit and the plurality of devices with which it may interface. Furthermore, the user can define and implement this interface remotely from the control unit, using the network manager. There are therefore two levels of remote interface: that between the network manager and the control unit, which is defined by the communications protocol between the network manager and the control units, and that between the control unit and the devices to which it interfaces, which is defined by the user using the network manager .

Input signals are preferably stored as data in the memory of the control unit, before being transmitted over the network to the network manager for storage and, optionally, later filtering and analysis. It is usually advantageous to store all of the input signals, or a selection of the input signals sufficient to avoid any need to rerun programs. It should preferably be possible to analyse stored data to recover desired results even if the need for those results had not been envisaged when the program was originally executed.

In a preferred embodiment, the invention may thus provide a system in which algorithms are easy and convenient to write. Further, the system may be able to execute algorithms, and store and retrieve collected data, in as automated a manner as possible. For example, the reaction time tester described above should advantageously be able to monitor the subject's responses remotely as they occur, and to record them accurately and securely for statistical analysis at a later time.

The use of networked control units that are separate from the network manager PC advantageously makes the system extensible. The combination of dedicated control units and programs that are interpreted by software on each control unit, rather than run directly on the control unit's physical processor, may advantageously allow optimisations of the control units for their dedicated tasks . These optimisations may improve performance and reliability and, in a preferred embodiment, permit very high accuracy of input processing.

Additionally, owing to the methodology of the invention, the user is advantageously offered from the network manager PC a single point of control and monitoring for all control units. In a further aspect of the invention, more than one network manager may operate on a single network, each controlling its own set of one or more control units, which are also coupled to the same network. In this case however, each network manager offers a single point of control for its independent set of control units.

In many circumstances it may be desired to rerun a program using a similar operating sequence but different starting parameters or other settings . In a preferred embodiment the network manager can send updated parameters and settings to a control unit to rerun a program, without retransmitting the entire program to the control unit. Similarly, a program may incorporate a number of similar, repeated program blocks which each require different settings. These settings can similarly be advantageously transmitted from the network manager while only transmitting the program block once.

In a further aspect the invention advantageously provides a programming language, or method, for allowing a user to control the target device or each of the target devices by means of the network manager.

The language advantageously comprises a designer through which a user can design programs for operating devices coupled to control units.

The language advantageously provides an event-driven programming system, preferably using a visual user interface. The user advantageously defines not only the responses of the system to events but also the events themselves. The programs are written in terms of procedures joined by links. Each procedure comprises a sequence of commands executed in order. The procedures are atomically executed, and each is entered through a link from a previous procedure as the result of the firing, or occurrence, of one or more events. Thus, each procedure is completed before a following procedure starts, and the following procedure may be entered or its parameters varied depending on events fired as a result of external actions, such as an input to a control unit, or as a result of the previous procedures.

Advantageously, an additional type of link can be set up which does not lead from a specific procedure but leads to a procedure which will be entered every time a predetermined event fires. These may be termed watchers. The designer is advantageously associated with a settings editor, which allows a user to set initial parameters, or settings, for a program, or to set a series of initial parameters or settings for each of a series of repeated runs of a program or program block.

In a preferred embodiment, the designer and the settings editor incorporate a visual interface.

Advantageously, a simulator may be provided to enable simulated operation of a program as an aid to debugging. The simulator preferably illustrates the program and the point of execution with the same visual representation as the designer.

It will be seen that the control system and the programming language provided by the invention therefore advantageously enable very flexible control of a plurality of devices by a single network manager over a network. In one aspect, programs or sequences of programs can be designed and run on a predetermined subset of the input and output lines of one or more control units so that programs can be allocated to particular devices and automatically repeated, using different program settings on repeated program runs if desired. In a second aspect, a single program or program block can be flexibly allocated to any number of the devices coupled to control units on the network and the devices controlled in parallel, using the same basic program or block to control each one. In a further aspect, the programming language or method incorporates a results filter for analysing and processing data stored on the basis of the input signals received from devices coupled to control units in previous program runs. The results filter may advantageously permit different analyses of the same raw data to be performed to extract different information. The results filter is preferably programmed with reference to the procedures in the original program which generated the data, by selecting desired paths through the program and filtering the raw data to extract instances when the selected paths were followed in practice.

Brief Description of the Drawings

Specific embodiments of the invention will now be described by way of example, with reference to the drawings, in which;

Figure 1 shows a block diagram of a control system embodying the invention;

Figure 2 shows a more detailed block diagram of the system of figure 1;

Figure 3 illustrates the display on the computer when a user is operating the designer of figure 2; and

Figure 4 illustrates a control unit embodying the invention.

Description of Specific Embodiment and Best Mode

CeNeS Control Introduction Overview

The invention is preferably embodied in a distributed digital input/output system (which is to form part of a product named CeNeS Control) in which a single PC may control a virtually unlimited number of digital inputs and outputs. The system finds particular application in cognitive testing, but may be applied to a wide variety of prototype, laboratory, manufacturing or other applications in which simultaneous control of one or more machines or devices is required. In this document, the term "boxes"

(referring to a set of devices, each typically being a box housing electronic equipment) is taken to cover any such application and not to be limited to any particular application.

Cognitive Testing

In the context of cognitive testing, each box may comprise components such as a lights, sound wave generators, press- buttons and switches . Inputs to the box can activate the components of the box and outputs from the box can carry signals indicating, for example, whether or not a press- button has been depressed.

For more sophisticated cognitive testing, more complex components may be involved. For example a visual display unit (VDU) such as a liquid crystal display, combined with a touch sensitive screen may be used. Inputs to the box then control the VDU and outputs from the box would be derived from the touch screen. In general terms, operation of the box entails controlling its inputs in a predetermined manner and monitoring its outputs.

Digital Control Structure

In the embodiment, as illustrated in overview in figure 1, the system comprises a personal computer (PC) 2 coupled, by means of a network 4 such as an ethernet, a local area network, a wide area network or the internet, to one or more control units (or controllers) 6. The or each control unit can be interfaced to one or more boxes or other devices 8.

The control system of the embodiment is shown in more detail in figure 2. A network manager 20 runs on the PC 2. It can access one or more programs 22 and enables the control of the boxes 8 coupled to the control units 6 using those programs .

Each control unit comprises a processor 23, a memory 25, and a plurality of inputs and outputs which can be—coupled to outputs and inputs respectively of one or more boxes. Advantageously, the network manager can control a plurality of control units via the network 4, and each control unit can be coupled to a plurality of boxes. Thus, the network manager can control a large number of boxes which may be at remote locations.

The physical digital inputs and outputs for the boxes are provided by the control units, and each control unit can control a number of boxes limited only by the number of input and output lines each box needs . The network manager can control a virtually unlimited number of control units, because direct control of the boxes uses local processing capability at the respective control unit.

In an initialisation procedure, the network manager allows a user to specify the number of boxes to be controlled and to allocate programs to boxes. Once it is established how many boxes are to be coupled to each control unit and which programs are to be run on each, the network manager calculates suitable digital input and output line allocations between each control unit and its boxes . Clearly, the allocation depends on the number of input and output lines required by each box for the program to be run, and the number of inputs and outputs of each control unit. The boxes can then be coupled to the control units according to the network manager' s instructions . In practice, control units may incorporate plug boards or other input and output ports to achieve coupling to boxes . Figure 4 shows an example of a control unit comprising a panel 100 of sockets 102 for connection to boxes. The sockets can each receive an input or output line.

If a series of programs is to be run on boxes coupled to a control unit, the network manager selects input and output allocations to remain unchanged between programs, where possible, to avoid changes in wiring.

The network manager then transmits to each control unit the program or programs required to control the boxes coupled to it. The program or programs are stored in the memory of each control unit and run on each control unit' s processor to generate the control unit outputs (forming control inputs to the boxes) , and to receive the control unit inputs (derived from outputs from the boxes) . The control unit inputs may be used by the control program to monitor the firing of events which interactively influence the subsequent operation of the program, and may be stored as data in the control unit memory.

Code Creation

The embodiment incorporates a programming language, named Turandot, 24 incorporating a designer 26 for writing the programs 22.

The language is designed to be event driven, to make responding to (for example) digital input changes ( such as the pressing of a switch) as simple as possible. The Designer is a graphical design environment built around this custom language which allows the flow of control through the program to be easily visualised, as illustrated in figure 3. The language allows for asynchronous response to multiple events, each of which may cause different paths through the program to be followed simultaneously.

The language provides in-built objects designed for digital control, such as timers 50, digital inputs 51 and outputs 52, counters 54 and flags 56, all capable of causing events. Events themselves can also be flexibly defined to be based on just a single object or on multiple objects (e.g. to fire only when a timer expires whilst a certain lever is depressed or a particular flag is set) .

Only a single block of a program need be created in the Designer. This same block can then be repeated with various different settings, defined in a Settings Editor 28. Groups of blocks, suitable for a long run of a program, can be named and stored for later use, to allow (for example) different schedules to be defined in advance for different days .

A simulator 38- is provided as part of the programming language to enable testing and debugging of programs using a graphical user interface similar to that used for program writing.

Results Management

Each program running on each box sends comprehensive data back to the PC running the Network Manager. Each change in a digital input or output is recorded by a results recordal system 30 coupled to the network manager, along with all events in the program that have fired and any other custom results the program elects to record. This information is, of course, often at too low a level to be directly useful, but it is important in many applications that all data is recorded when a program is run to avoid having to re-run the program to record different information. For this reason, CeNeS Control provides results filtering to extract meaningful measures from program data.

The measures a user wishes to extract are specified in the Designer to generate a results filter 32, and are based on paths through the visual representation of the program. The Network Manager then uses the results filter to allow flexible selection of which data (stored on the PC on which it is running) should be filtered. The filtered results are then stored in a database 34, either on the PC itself, or on a remote database server.

The measures in the filtered results can then be viewed in a Results Manager 36, which allows the production of reports and spreadsheets containing counts, rates, times and latencies of the measures on a per-block and per-program basis. Using standard SQL ( standard query language) queries, more complicated custom measures can be created by advanced users.

Because all the Results Manager's processing can be performed on any JDBC or ODBC-compliant database, a user can take advantage of conventional database servers, providing centralised administration and backup, giving potentially enhanced performance and allowing customised organisation of your results storage.

User Interface

All the parts of CeNeS control with which the user interacts are written in Java, so a Java virtual machine is installed on your computer to run them.

The CeNeS Control Designer

Overview

The CeNeS Control Designer allows the individual programs that control a group of digital inputs and outputs to be created. Programs are written in a language called Turandot, which has been designed for CeNeS Control and embodies an aspect of the invention. The language in use is represented visually in the main Designer window 60 on the PC screen. The language can also be edited textually if preferred. About Turandot

Turandot is a custom programming language in which execution is determined by the firing of events. Events cause procedures to be entered and executed, notionally 'automatically' (this is explained in more detail later; in short, the tasks that each procedure undertakes are executed as quickly as possible, without interruption) .

A Turandot program consists of initial declarations and procedures. The initial declarations specify the names and initial values of objects and events used in the program.

They are given in a left hand panel 62 in the main Designer window.

One run of a program may have many blocks, but the Turandot code for the program only specifies how to perform a single block. At the start of the program, and at the start of each new block, the declarations are executed in the order in which they appear in the initial declarations table. If the value assigned to one declaration depends on the value of a previous declaration, they must be in the appropriate order.

The remainder of a Turandot program consists of procedures. Each procedure 64 contains commands executed in order, just as in the initial declarations. However, as well as making further declarations, procedures may also contain commands to make assignments to objects, call library functions, freeze events and so on. Each procedure also sets up links 66 and watchers 68 which determine which procedures are entered when events fire. The procedures are represented in a right hand panel 70 in the main Designer window, with arrows between them to indicate links.

Turandot supports numerical expressions, and has 'variables' of various object types which can store values. As well as normal numeric constants, the values true and false can also be used. String types are not used.

Declarations

A palette of icons below an initial declarations table 72 is displayed on the left hand side of the window to represent all the types of identifiers which you can declare in your program. An identifier is simply the name of an instance of an object or event. The declaration table has three columns.

To declare an identifier, drag (using a mouse) the appropriate icon from the palette into the initial declarations table. A new row will be created at the bottom of the table, with the icon in the first column.

The second column of the table is where you type the name of the variable you are declaring. The name must be unique (not just for the current type, but throughout the program) . Reserved identifiers (such as "TIMER") cannot be used.

Once you have typed the name, press ENTER, or click elsewhere on the table. The remaining, third, column in the table is used to declare an initial value, which is assigned to the object or event at the start of the program and of each subsequent block. Click in the column to enter or edit the value which is assigned to it (the section to follow on Expressions gives more information about what can be entered in this column) .

For some types of object, it does not make sense to set an initial value, in which case that part of the table cannot be edited when you click on it. The initial value may be left blank; in this case, an initial value default value of 0, false (in the case of objects expecting a boolean value) or 'empty' in the case of sets, will be used at the start of the first block, and the object's value will not be reset at the start of subsequent blocks. Objects may therefore, if not given an initial value, persist from one block to the next. (Note that timers, described below, will not continue timing after the end of a block) .

The order of declarations is sometimes important: if you declare an integer a, whose value is 5, and an integer b, whose value is a + 10, it is clear that a must be declared before b can be.

Identifier Types The following types of object can be declared:

Digital Input: This is a digital input line used by the program, represented by a lever 51. It could be a pushbutton, that is only momentarily 'on', or a toggle switch, that alternates between on and off, but at any given time its value is either true (on, high) or false

(off, low) . Because its value is determined by the state of the input in question, it cannot have a value assigned to it.

The name you choose for it will be displayed in the Network Manager when it makes its line allocations . To avoid rewiring, it is sensible to use a consistent naming scheme for the facilities available in each box.

Digital Output: This is a digital output line used by the program, represented by an LED 52. It could be a light, that alternates between on and off, or a device that is normally off and only pulsed on momentarily, but at any given time its value is either true (on, high) or false (off, low) .

The name you choose for it will be displayed in the Network Manager when it makes its line allocations. To avoid rewiring, it is sensible to use a consistent naming scheme for the facilities available in each box.

Flag: A flag 56, like all the remaining objects, is purely internal to the program and has no corresponding physical entity. It is represented by a waving flag. It simply stores a boolean value - i.e. at any given time, its value is either true or false.

Timer: A timer 50 can be used to make events fire after a set number of milliseconds, and is represented by a sundial. When it is assigned a value, it immediately starts timing from that value. At the end of a block, it is reset to 0 (without firing any events) .

Repeat Timer: A repeat timer- 74 is exactly the same as a timer, except that whenever the time expires, it immediately begins timing the same duration again. It is also represented by a sundial, with faded sundials behind. At the end of a block, it is reset to 0 (without firing any events) .

Counter: A counter 54 is used to count the number of times something has occurred, and is represented by an abacus. It is initialised to a value, then later decremented, always having a value greater than or equal to zero. It can be used to make events fire when it reaches 0.

Setting: A setting is a value from a setup, and is represented by a spanner (wrench) 76. A setup is a collection of parameters that can be specified separately for each block of a program. Setups are created in the Settings Editor, and each program can have many setups, each with a different name.

When a setup identifier is referred to in a program, its value will depend on the block currently being run. It therefore cannot be assigned an initial value. Integer: The integer, represented by its mathematical set notation (a double-barred 'Z'), can store a positive or negative number. It is similar to a counter; the main differences are that counters can be used to fire events, and that integers can store negative numbers. Mathematical expressions based around integers and other object types are supported in Turando .

Set: A set serves two purposes: it introduces referentiality into the language (the ability to store references to objects themselves, rather than just their values), and it allows grouping of multiple objects. It is represented by a Venn Diagram.

A set is simply an (ordered) collection of object identifiers. Elements and sub-sets can be extracted from them, and set operations such as conjunction and disjunction are also provided. Finally, named events must also be declared:

Event: Events are represented by stylised yellow lightning strikes 78. An event is defined when it is declared, and its definition cannot be changed. Its definition consists of a boolean combination of object identifiers. For example, if we define an event as "timerl AND lever2" it will fire if timerl expires whilst lever2 is depressed (i.e. Iever2 has the value true). The meaning of each type of object identifier in an event definition is given in detail later.

Procedures and Linking

At the start of the program, and at the start of each subsequent block, a special procedure called Start 80 is entered. This procedure must establish the initial links and watchers that cause later procedures to activate when events fire. These later procedures may then establish further links and watchers, the block ending when no links or watchers remain. All links and watchers are cancelled at the end of each block, so must always be re-established for the next block by Start.

When a new program is created, the start procedure is automatically created for you, and has a green light icon by the name to denote it as such. Procedures are represented on the screen by procedure panels 64, which have an upper area that contains the name of the procedure, and a lower area that contains a miniature summary of the Turandot code executed when the procedure is entered.

Procedures can be moved simply by dragging them around; clicking on the lower area does not activate the procedure, but clicking on the upper area does. When a procedure is activated, the background behind its name becomes orange, and the links and watchers that it establishes become visible, all others being hidden.

To create additional procedures, click on 'New Procedure' at the top of the right-hand pane. A new procedure will appear at the bottom right hand corner of the window. To delete a procedure, click on 'delete' in the upper area of the procedure.

Links

A link 66 is represented by an arrow from one procedure to another, labelled with an event identifier 82. When a procedure is entered, any links from that procedure are established. If the event named on one of those links fires, the link is followed, the procedure that it leads to is entered, and all the links from the original procedure are cancelled. They are only re-established when the original procedure is entered again.

Once followed, therefore, a link is gone. If there is more than one link from a procedure, they represent a choice, and once one of them is chosen (by the firing of the event with which it is labelled) they all vanish until the procedure from which they lead is entered again. The Turandot code within procedures executes atomically, which means that even if an event fires half way through the execution of a procedure's code, any links on that event will only be followed after the remaining code has been executed.

If only links are used between procedures, and no two links from a procedure ever fire at the same time, then the program is like a simple flow chart (state machine) . That is to say, the 'point of execution' is always at a single, identifiable place in the program. It is normally at the end of the last procedure entered, waiting to follow one of the links from that procedure to another procedure.

However, is possible that the events on two (or more) links from the original procedure are followed at exactly the same time. In the event example above, an event was defined as "timerl AND lever2". If another event is defined as "timerl AND lever3", and both lever2 and lever3 are depressed when timerl expires, then both events fire at the same time. If there is one link from the original procedure on each of these events then both links are followed, and the procedures they lead to are entered, and execute notionally simultaneously. There is now no single place in the code that can be identified as the current point of execution - there are two such points . The note below on Multiple Threads and Inter-Dependencies expands on the possible repercussions of this.

Multiple Threads and Inter-Dependencies If two links are followed at the same time, the procedures they cause to be entered are notionally executed simultaneously. However, because procedures are executed atomically, in fact all the code in one procedure will be executed before any of the code in the other. For this reason, it is important that the procedures are not interdependent. If, for example, one procedure adds one to an integer, and the other procedure doubles the same integer, the procedures are inter-dependent, and the order of their execution does matter. It is therefore important that such procedures are not linked to by two links that could be followed simultaneously. Establishing a new point of execution is not quite the same as starting a new thread in multi-threaded programming languages . One of the two new ^paths' of execution that the points embark on will normally end suddenly when a procedure with no links is reached. However, if the second point of execution loops around in such a way that it meets the first point of execution, it merely re-establishes links that have already been established, and basically has no effect -(other than executing the code in that procedure again) . At any given moment, each link in a program can only be established and waiting for an event to happen once. If the procedure which established a link is entered again, the link is simply re- established, and not ^duplicated' . This avoids a potentially exponential increase in the number of paths of execution during some looping constructs.

Creating and Changing Links There are three icons to the left of the lower area on each procedure. The upper one - a solid orange bar 84 - is used to create new links. Bring the mouse pointer over this icon on the procedure at which you would like the link to start. The icon will highlight. Now hold the mouse button down and drag the mouse pointer away from the icon. A new, dashed link will follow the mouse pointer. Bring the mouse pointer over the procedure that you would like to be entered when the link is followed - its name will turn red. Then release the mouse to create the link.

To move a link from one destination procedure to another, move the mouse pointer over the link's arrow head. The arrow head will highlight to indicate that you may drag it. Once you begin to drag it, the link will become dashed and the same steps as during link creation should be followed. If the link is released when no procedure name is red, you will be prompted as to whether or not you would like to delete the link.

New links have "Change..." in place of their event name label, in orange. When you click on this label, a list of all declared event names will appear, from which you may choose an event. Click outside the list to avoid changing the event name.

After a separator, a list of objects is also presented. This is a list of all the objects declared based upon which you may define events. If you select one of these, an event will be created for you based on the object you chose, and with the word "Event" appended to the object name. (If the name already exists, it will not be created again) .

A further option on the list allows you to delete the link. The remaining option allows you to create an 'Always' link.

Always-Links

Links labelled with "[Always]" in place of an event name have a dotted appearance 86, and operate differently from normal links . They are always followed after procedures have finished execution, and are not dependent on any events. However, they do not cancel any other links from that procedure, hence their dotted appearance. If there are any other links from the procedure, then there become two points of execution, just as when two links are followed simultaneously - one point still at the tail of the always-link, and one at its head, in the new procedure it caused to be entered.

Multiple always-links may be used to create multiple different points of execution.

Watchers

A watcher 68 is established, just like a link, when a procedure is entered, and just like a link, it has an arrow that is followed whenever the event with which it is labelled fires. However, watchers are not cancelled when a link is followed from that procedure . Conceptually, watchers are like machines that a procedure can turn on. Once turned on, they continually look for their named event to fire, and each time it does, they cause the procedure at which they point to be entered. Once they are enabled, the event for which they are looking may fire any number of times, and each time it does, their target procedure is entered again.- Once enabled, they are entirely divorced from the procedure which enabled them.

Watchers are represented as little machines, with eyes looking up at their named event, and an orange arrow which they cause to be followed every time the event fires. A green dashed line leads from the procedure which establishes it to the watcher itself, to indicate the 'enabling' of the watcher.

More than one procedure may enable the same watcher. Just as each link is only 'active' once at a given time, so each watcher with a particular event label and target procedure only exists once, and may be enabled by more than one procedure. Each enabling procedure will have a green dashed line to the same watcher.

Creating and Changing Watchers.

Watchers are not strictly created (they may already have been established by another procedure) but enabled, as implied above. A 'watcher-enable' is created in just the same way as a link (see above) , except that the icon with the dashed green line is used instead of the icon with the solid orange line. The event for which the watcher looks is changed by clicking on the label in exactly the same way. (Of course, 'Always' is no longer an option in the list) . It should be noted that if two procedures establish a watcher, and you wish to change the event for which it is watching, then the event name on both watcher-enables must be changed. This is because when one watcher-enable is visible and being changed, the other is normally invisible until its establishing procedure is selected, and is not changed behind-the-scenes to avoid potential mistakes.

Watchers can be moved by dragging the arrow head, in exactly the same way as for links.

Disabling Watchers

Just as a watcher can be enabled by a procedure, it can also be disabled by a later procedure. However many times a watcher on a particular event and target procedure has been enabled, if a single procedure is entered which disables that watcher, then it will be cancelled and cease to watch for its named event until one of the procedures which establishes it is re-entered. If a machine (a watcher) has already been disabled or has not yet been established, disabling it has no effect.

For convenience, a watcher-disable can be created by clicking on any procedure that established the watcher (to^' make it visible) and clicking-and-dragging from the third icon (the dotted red line) on the procedure that you wish to disable the watcher. As you drag the mouse, a red cross will follow the mouse pointer, and when the mouse pointer is over an existing watcher, that watcher will be highlighted in red. If you release the mouse button, a watcher-disable will be created for the watcher with that event name and target procedure.

The watcher-disable is represented by the watcher with the red cross superimposed on it, and a red dotted line in place of the green dotted line to indicate that the watcher is being 'turned off rather than on.

Note that as with watcher-enables, if you change the event on a watcher-enable, you must also change the event on any watcher-disable that you wish to continue to correspond, and visa-versa. This is because if you have two watcher-enables and change the event name on one, the program does not know which of the two resultant watcher-enables (the one with the new event name or the one with the original event name) you wish the watcher-disable to act upon. It therefore does not change the event name on the watcher-disable.

View All Mode If 'Show faint links' or 'Show all links' has been used, as well as all links being visible, all watcher-enables and watcher-disables will be visible at once. To avoid confusion, if more than one procedure enables a watcher and at least one procedure disables the same watcher (i.e. a watcher with the same event name and target procedure) , then all the watcher-enables and disables will appear at the same point. A single watcher machine will, for example, have two green dotted lines and one red dotted line leading to it, indicating two watcher-enables and a watcher-disable.

If you change the event name above this watcher-machine, it will only be changed on the watcher-enable or -disable from the procedure most recently clicked on. (When you click on a procedure, all the links and watchers that is establishes. become uppermost on the screen) . A second watcher machine will therefore seem to appear on the screen, watching for the new event. Only when all three event labels have been changed will the three be consolidated again. Likewise, when a watcher-enable or -disable is moved, only the uppermost one will follow the mouse. The remaining ones must be moved separately. If you wish to access lower ones, release the upper one on the same procedure and try again. The system will cycle through them for you.

If two or more links go to the same procedure, their arrow heads will also lie on top of each other. If when you try to move one, the wrong link is 'picked up' by mistake, simply release it and try again, and the system will cycle through them.

Links to self

Note that both links and watcher-enables and -disables can point to the same procedure that established them. In the case of watchers, the (short) dotted line will be drawn from the procedure to the watcher just adjacent to it, and in the case of links, a small 'loop' will appear below the procedure .

Event Definitions

To make use of links and watchers, events have to be declared and defined in your program. A simple example of an event definition was given above; an even simpler example appears when, on changing the event upon which a link is defined, you select the name of an object from the list instead. If, for example, you select "button3" from the list, then button3Event is declared for you, simply with the definition button3. Normally, button3 either has the value true or false. However, when button3 is held down, its value is continually true. Does this mean that the event fires continuously after the button is pressed on, and if so, how frequently? Naturally, it does not. An event fires when one of the objects in its definition causes it to be evaluated and it evaluates to true. A digital input causes events defined on it to be evaluated whenever it changes value. So button3Event only fires once, since the button3 causes the expression to be evaluated when its value changes - when the button is depressed, and when it is depressed its value is true, so the event fires. When it is released, the event definition is re-evaluated, but is false, so the event does not fire. If we are interested in the button's being released, we must define an event as NOT button3. When the button is release, button3's value is FALSE, so NOT button3 has the value TRUE and the event fires.

Evaluation of Objects in Event Definitions

With a digital signal, it is clear what value the identifier should have in an event definition - it evaluates to true when the line is 'on¹, or high, and. false otherwise.- However, when a counter is evaluated normally, its value is a number. When is a number true or false?

Clearly, different objects must evaluate in different ways in event definitions. In the case of a counter, it is only true at the instant that it is decremented from one to zero, and false otherwise. Likewise, a timer is only true at the instant it expires.

Both of these need to cause event definitions to be re-evaluated at (only) the respective instants mentioned.

The following table indicates how each type of object is evaluated in event definitions, and when each one causes the definition to be evaluated.

Digital Input: This evaluates in the same way as in a normal expression, and causes definitions to be evaluated whenever its value changes .

Digital Output: This evaluates in the same way as in a normal expression, and causes definitions to be evaluated whenever its value changes .

Flag: This evaluates in the same way as in a normal expression, and causes definitions to be evaluated whenever its value changes.

Timer: This only evaluates to true at the moment when it expires, and only causes definitions to be evaluated then. It evaluates to false at all other times, including when manually set to 0.

Repeat Timer: This only evaluates to true at the moment when it expires, and only causes definitions to be evaluated then. It evaluates to false at all other times, including when manually set to 0. Counter: This only evaluates to true at the moment when its value changes from a positive integer to 0, and only causes definitions to be evaluated then. It evaluates to false at all other times. Setting: Settings have no effect in event definitions. They must be assigned into, for instance, a flag first.

Integer: Integers have no effect in event definitions, and should not be used. Set: Sets evaluate to the logical OR of their elements' evaluations. For instance, if setl contains leverl, lever2 and flag3, using setl in an event definition is equivalent to typing (leverl OR lever2 OR flag3) . They cause definitions to be evaluated whenever any of their members cause definitions to be evaluated.

N.B. A library call is provided to programmatically cause definitions containing a particular event name to be evaluated.

Event Definition Operators

Object names in event definitions can be separated using the keywords NOT, AND, OR, and XOR. They can also come between other 'sub-definitions', brackets ( ) being used to determine order of evaluation. Definitions inside the brackets are evaluated first. Where brackets are not used, the operators are evaluated with the following precedence (the topmost being evaluated first) : NOT This precedes a single operand, and inverts its value (changing false to true and true to false) . AND This goes between two operands and evaluates to true only if both operands evaluate to true. It evaluates to false otherwise.

XOR Exclusive-or . This goes between two operands, and evaluates to true if one or other of the operands evaluate to true, but not if both do. If they both evaluate to true (or both to false), it evaluates to false. OR This goes between two operands, and evaluates to false only if both operands evaluate to false. It evaluates to true otherwise.

Examples of Event Definitions

To clarify the above points, here are a few examples of event definitions:

NOT leverl AND lever2 : This fires at the moment when leverl is released, so long as lever2 is held down at that moment. It also fires at the moment that lever2 is depressed, if leverl is not held down at that moment.

If we intended to define an event that fires when either lever releases and the other is already released, we can use brackets to override the operator precedence as follows: NOT (leverl AND lever2)

The following example is a little less practically useful: NOT timerl OR leverl. This is evaluated when the timer expires and when the lever is pressed or released. It therefore fires whenever the lever is pressed, when the lever is released, and also if the timer expires whilst the lever is held down.

NOT timerl AND leverl: This is evaluated when the timer expires and when the lever is pressed or released. It only fires whenever the lever is pressed. It is checked when the timer expires, but because the NOT is applied to the timer, the expression evaluates to false whether or not the lever is pressed.

Procedure Code Every time a procedure is entered, as well as [re-] establishing any links and watchers, the Turandot code in the procedure is executed. In the visual designer, the code is represented as a table of icons in just the same way as the initial declarations were, the rows being executed in the order in which they appear.

The code in procedures is executed atomically, after any links and watchers that the procedure establishes have been set up. This has certain repercussions, which are explained in more detail under the heading "Atomic Execution and Link Establishment".

The code in a procedure is summarised in the lower area of the procedure panel on the screen. The summary is a miniature panel of textual Turandot code. The textual code for Turandot is defined in more detail later, but is so similar to the code in the tables that is should be self-explanatory.

The area is initially blank when a procedure is created, since it contains no code to execute. To create or edit the code in a procedure, click on 'modify' in the upper area, or simply double-click on the procedure panel.

Atomic Execution and Link Establishment

Procedures execute atomically, which means that no rows from other procedures will be executed until all the rows from the currently executing procedure are completed. The order of execution is unimportant except where values are assigned to objects based on objects previously assigned to, as with the initial declarations. Links and watchers are established before the rows of code in the procedure are executed, so if any events are fired as a result of executing the procedure, links and watchers set up on that event will respond to them. However, because the code is executed atomically, they will only respond after all the remaining rows in the procedure have been executed.

Moreover, if any other procedures nominally execute at the same time as the this first procedure (as in the example in the "Links" section above) , these simultaneous procedures will also be entered before any links or watchers from the first procedure respond.

^'Because these ^Λsimultaneously executed' procedures were not entered until after entering and executing the first procedure, any links and watchers that they set up will not yet have been established, and will therefore not respond to events fired during the execution of the first procedure.

Editing Procedures After double-clicking or clicking 'modify', a floating procedure editor will appear over the procedure panel on the screen, containing the name of the procedure, an area for typing comments and a table in which the rows of Turandot code are presented. The editor extends below and to the right of the procedure panel to the bottom-right of the window.

To rename the procedure, simple click on the existing name and type a new name .

Procedures code is edited in exactly the same way as the initial declarations are - by dragging icons representing commands into the table. Rows can be reordered and deleted by clicking on their icons and using the buttons to, the top right of the table, just as before. The columns in the table have a similar function - the first column contains the icon that represents the command, the second column contains the name of the object or event (where applicable) and the third column contains an expression (where applicable) . The main difference is that when you click in the second column, as well as being able to type a name, you will also be presented with a button with a downward arrow. When you click on this, a list of all declared identifiers of the appropriate type will appear, so that you can conveniently choose one, and be sure you have chosen an identifier of the correct type.

When you have finished editing the procedure, click outside the procedure editor and it will disappear.

Commands to Use

The following icons are available in the palette of the procedure editor:

Switch On: This command is used to turn a single digital output on, and is represented by a socket with a plug and the power on. The second column should be used to select the name of a digital output. The third column reads "=TRUE" to reflect the fact that the value TRUE is being assigned to the digital output chosen. Decrement: This decrements a counter, and is represented by a fading abacus with a green arrow overlayed. It reduces the value by of the counter by 1, causing events defined on that counter to be evaluated if the counter reaches 0. The second column should be used to select the name of a counter. Switch Off: This command is used to turn a single digital output off, and is represented by an empty socket with the power off. The second column should be used to select the name of a digital output. The third column reads "=FALSE" to reflect the fact that the value FALSE is being assigned to the digital output chosen. Assignment: This is the general form of assignment, of which the above three commands are special cases, and is represented with an 'equals' symbol. It changes the current value of the object identified in the second column to the value of the expression in the third column. This may cause events to be fired. If assigning to a timer, it causes that timers to start (timing from the value that is assigned to it in milliseconds) .

Expressions are explained in more detail later, with an indication of which types of expression can be assigned to which type of object. The expression in an assignment is the same as the expression in a declaration, except that 1) in an assignment, the expression is, of course, compulsory, and 2)- the expression is • re-evaluated and assigned to the object every time the assignment is executed, (i.e. every time the procedure containing the assignment is entered) . Expressions in initial declarations are only evaluated and assigned at the start of each block.

As an example of the equivalence mentioned, a decrement command applied to counterl could be replaced by the assignment to counterl of the expression ( counterl - 1 ) . If the counter is set to 7, the expression ( counterl - 1 ) is evaluated, and the result (6) is assigned to counterl.

Library: This allows a library function to be called, and is represented by a library book. A library function typically performs some frequently-used task for you automatically, to avoid your having to use the Designer to create code to perform it.

The second column is not used. The third column is an expression, which should be a call to a library function. Expressions are explained in more detail later, but a simple example would be cenes .util.pulse (lightl, 100), which pulses lightl on for 100 milliseconds then turns it off again .

If the library call returns a value that you want to use, you should use an assignment instead, specifying an integer (for example) to store the return value in the second column, and putting the function call expression in the third column again.

Freeze: This command freezes an event, and is represented by a frozen, blue event icon. Its effect is to stop the event from firing from the moment the freeze command is issued. The second column should be used to select the name of the event. Any watchers and links defined on that event will do nothing while the event is frozen, even if it would have fired many times normally.

Thaw: The thaw command is used to unfreeze an event, and is represented by a glowing event icon with flames. The second column being used to specify the name of the event. Once thawed, the event is returned to normal and will fire the next time it occurs. (None of the missing fires from when the event was frozen will occur) .

Disable Watchers: This command disables all watchers on a particular event, and is represented by two watchers overlayed with a cross.

Normally, watcher-disables are represented as dotted red lines in the main Designer window. However, this command allows all watchers defined on a particular event to be disabled, without your having to specify them explicitly. Any new watcher-enables defined on the same event, created in the Designer long after dragging this icon into a procedure's code, will still be affected by it when the program is run.

The second column is used to specify the name of the event upon which all watchers will be disabled. Unlike a freeze command, the watchers are permanently disabled, and cannot be 'unfrozen' (they must be individually re-enabled) , and links are unaffected.

End Block: This command can be used to explicitly end the current block of the program and re-start with the next one. It will cancel ail remaining links and watchers. (If you are not using settings in the current program, or you are on the last block, this command will end the program) . It is represented by block sawn from the end of a beam.

The end block command is only provided as a convenience, since blocks also end when there are no links or watchers established.

Declarations in Procedures

In addition to these commands, declarations can also be made in procedures. This is useful if the objects declared only apply to the current procedure and links directly from it, for instance. Declaring an object in a procedure is the same as declaring it in the initial declarations, except that if you give a value expression in the third column of the declaration, that value will be assigned to it whenever the declaration is executed, instead of at the start of each block. It is therefore equivalent to declaring the object in the initial declarations with no value, then assigning to it in the procedure.

It is recommended that normally only flags, sets, integers and events be declared in procedures, and even these only when they are use just in the procedure itself and links leading directly from it. For this reason, only these icons are provided, although other declarations could be made by editing the textual Turandot code directly. Expressions

The key to most operations in Turandot is in assignments - they are used for everything from starting timers to manipulating the elements in sets, and the key to assignments is expressions, since it is these that are evaluated and assigned to objects. Expressions are also used in function calls, to set initial values in declarations, and even to specify which member of a set to access .

The most clear cut division between types of expression is between ordinary (numeric) expressions and set expressions. (Leaving aside the already-mentioned expressions used as event definitions, which are only used where events are declared and never in assignments) .

Ordinary expressions are used to perform mathematical calculations to provide numbers, including calls to library functions which return numbers, and to create and manipulate true and false values by using comparison operators (e.g. a <= b) and the boolean operators we have seen in event definitions (e.g. NOT, AND) . They may also access the objects in sets and use their values. They may finally evaluate to a numeric or a boolean (true/false) value (see inset box, Boolean Representation) . Set expressions are used to define, combine and manipulate sets. They always evaluate to another set.

Ordinary Expressions

Object names (and other 'sub-expressions') in expressions can be separated using the operators in the following table. In addition, numeric constants (0, 54) and named constants (false, true) can be used between operators, as well as subset identifiers and function calls (explained later) . It is not recommended that timer or repeat timer identifiers are used in expressions, and of course set identifiers cannot be (but see below) , but other objects can be, including counters, which assume the value to which they have counted down.

Brackets ( ) can be used to determine order of evaluation, expressions inside the brackets being evaluated first. Where brackets are not used, operators of the same precedence are evaluated from right to left. This means that, for example, a - b - c is equivalent to a - (b - c) , not (a - b) - c, which may have a different value. However, the designer will insert brackets automatically for you to confirm evaluation order. The operators in the following table are given in order of precedence, the topmost being evaluated first. Operators at the same level in the table have the same precedence.

The first three operators are prefix operators with one operand - that is, they precede the expression to which they apply:

+, -, NOT: These first two operators set the sign of their operand - positive or negative respectively.

The third operator inverts the boolean value of its operand. It returns true if its operand evaluates to false, and false if its operand evaluates to true. All the remaining operators are infix operators with two operands - that is, they have one expression before them and one expression after them, and act on the evaluation of those two expressions:

*, /, \ _r % ' These operators perform multiplication, integer division, division with probabilistic rounding and modulus (remainder) respectively. Integer division rounds to the largest integral value not greater than the result (i.e. 6.7 becomes 6, and -5.2 becomes -6).

Division with probabilistic rounding performs rounding with a probability determined by the size of the fractional part. For example, 6.8 would become 7 on 80% of occasions and 6 on 20% of occasions. Likewise, -6.8 would become -7 with an 80% probability and -6 with a 20% probability. +, -: These operators perform addition and subtraction respectively. : This raises its left operand to the power of its right operand. For example, to evaluate b squared, use the expression b ^Λ 2.

< <= >= >: These operators compare the values of their operands and return true or false depending on whether the comparison is correct for the value of their operands. The comparisons they perform are, respectively, less-than, less-than-or-equal-to, more-than-or-equal-to and more-than. For example, 5 < 2 evaluates to false, and -4 >= -4 evaluates to true. = !=: These operators compare the values of their operands and return true or false depending on whether the comparison is correct for the value of their operands . The comparisons they perform are, respectively, equal-to and not-equal-to. For example, 3 = 4 evaluates to false, and -3 != -4 evaluates to true.

AND: This evaluates to true only if both operands evaluate to true. It evaluates to false otherwise. XOR: Exclusive-or. This evaluates to true if one or other of the operands evaluate to true, but not if both do. If they both evaluate to true (or both to false) , it evaluates to false.

OR: - This evaluates to false only if both operands evaluate to false. It evaluates to true otherwise.

Here is an example of an expression which evaluates to true:

5 - 3 - 3 >= 5 AND 5 ^Λ 2 = 5 * 5 XOR FALSE

It is equivalent to:

(((5 - (3 - 3)) >= 5) AND ( (5 ^Λ 2) = (5 * 5))) XOR FALSE Sets and Set Expressions

A set is an ordered collection of object identifiers. Sets are defined by surrounding event identifiers with curly braces. The following set expression defines a set which contains two digital outputs and one digital input: { lightl, light2, lever3 }

It is not possible to have the same identifier in a set twice (duplicates are removed) .

Set expressions and set identifiers (the names of objects declared as sets) can be combined using the operators in the following table. As with ordinary expressions, evaluation is from right to left, brackets can be used to set evaluation order, -and the operators have the following ■ precedence, first to be evaluated topmost: INTERSECTION: This returns a set containing only elements present in both its operand sets. The intersection of {a,b,c} and {c,d,e} is {c} . The empty set ({}) may be returned. DISJUNCTION: This operator returns a set containing the elements present in one operand set or the other but not in both. The disjunction of {a,b,c} and {c,d,e} is {a,b,d,e}. UNION: This returns a set containing the elements present in both its operand sets. Elements present in both operand sets are only present once in the result set. The intersection of {a,b,c} and {c,d,e} is {a,b,c,d,e}.

Subset expressions

Subset expressions define sets that contain selected members of a set. hey may be used in set expressions like any other set identifier or expression. In addition, they may assigned to and, if they select a single set member, used to represent that set member in ordinary expressions. Subset expressions are created by following a set identifier (but not a set expression) with an open square bracket ([), ranges to identify the set members to access, and a close square bracket. The first member in a set is numbered 1, so, for example, if the set lightSet has just been assigned the value {lightl, light2, light3, light4} then lightSet[2] is {light2}.

Ranges are specified with an optional start index (taken to be 1 if omitted) , two dots ( .. ) and an optional end index (taken to be the index of the last item in the set of omitted) . The indices can be expressions, and multiple ranges and single indices can be specified, separated by commas .

Continuing the example above, lightSet [2..] is {light2, light3, light4} and lightSet [ (3-1-1) ..3,1] is {lightl, light3}

Sets and Assignments

If a set is assigned to (i.e. a set identifier is chosen in the second column of an assignment) , the expression that is assigned to it (in the third column) must be a set expression. Indeed, when a set identifier is chosen, any existing ordinary expression is removed, and visa versa. However, it is possible to assign the value of an ordinary expression to the objects referred to by a set. This is achieved by assigning to a subset, and causes every object in the subset to be assigned the value of the expression. For example, to turn on all the lights in lightSet, enter true in the third column - the expression being assigned to the subset. In the second column, select the name of the set from the drop-down list, the before clicking elsewhere or pressing ENTER, type [..]. The second column should then read lightSet [ .. ] , and whenever the procedure containing that assignment was entered, lights 1 to 4 would turn on.

Assigning an expression to, for instance, lightSet [3] is semantically exactly the same as assigning that expression to light3 .

Subsets in Ordinary Expressions

Normally, a subset is itself a set and can only be used in a set expression and assigned to another set. However, if a set expression is followed by a single bracketed number (or expression) , in the context of an ordinary expression, it references the set member and evaluates it. For example, if all the lights in lightSet have just been turned on, the expression a > b OR lightSet [4] evaluates to true.

However, subsets generally cannot be used in expressions, since it is not know which member of the set to find the value of. The expression a > b OR lightSet [3..4] is not valid.

Functions and Function Calls Library functions contain code that is frequently used, to avoid its repetition in every program that uses it, or that is written in a native language such as C for speed or flexibility.

CeNeS Control comprises a range of useful library functions . They contain utilities such as cenes .util.eventif, which allows events to be declared with blank definitions and fired at will, and functions that interact with setups, such as cenes .settings . fillset, which fills a set with the contents of a list of settings from the current block in the setup.

It also includes functions to pulse digital outputs on and off conveniently, produce random numbers and shuffle the contents of sets for pseudo-randomisation, record the values of objects into the results, change the block to be executed from the setup to allow adaptive programs, and even just to make boolean selections between expressions (in the manner of C's ?: expressions) . Function calls are written as a function name, followed by an open parenthesis, a comma-delimited list of arguments, and a close parenthesis: company.group. functio (argl, arg2, arg3 ... ) They return values, so can be used in expressions just like any other object identifier or sub-expression. For example, to produce a random number from 50 to 59 inclusive, use the expression: 49 + cenes .util .random (10)

Some functions take no arguments, and simply return a value: cenes .util . getblockssofar () Note that the parentheses are still required. Other functions perform actions (such as pulsing a light on and off) but return no value of interest - if you do not want to store the return value from a function, or it has none, use the library call (book) icon instead of the assignment or declaration icon.

Arguments to a function can be identifiers or full expressions. See the heading "By Value or By Reference?" for more information about how objects, sets and expressions are passed to functions.

The Designer Itself

Once a program has been chosen, the main designer window is split into two parts, the left hand panel with the initial declarations and the right hand panel with the procedures . Comments for the program as a whole may be added in the text area just above the main declarations panel.

Most functions are accessible directly in the main window. Procedures can be modified and deleted by clicking on 'modify' or 'delete' on the procedure itself, and links created by using the icons also on the procedures themselves. Other frequently-used actions are presented at the top of the designer window, such as 'show faint links' and 'new procedure', which have already been described. Further options are available on the pull-down menus. The 'File' menu has an option 'New Window', which opens a complete new Designer window in which a new program can be created, or a different existing program opened. The 'File' menu has no options for "Open Program" or "New Program", since these can all be achieved by creating a new window and closing the existing one.

The 'File' menu also has options for saving programs (see below) and the 'Exit' option which closes the current Designer window. The two remaining options ('Copy Settings From...' and 'Create Test Program...') are described in the chapters Using Settings and The Network Manager respectively. The former copies setups from another program, and the latter creates a program to allow you to perform line allocations and test your digital inputs and outputs .

The 'View' menu has the option 'Code-only Mode' (see below) .

'Design Results Filter...' allows a results filter based on the current program to be created, and is described in more detail in the Results Filtering chapter. Finally, Options...' gives access to the Control Options Tab (see @) •

Saving programs . Changes you make in the Designer are not saved to disk until you choose to, and when you do, your program will be checked for obvious mistakes, and only saved if none are present. If you do not want to keep changes you have made to a program since you last opened it, you can simply close the main Designer window - you will be prompted as to whether you want to lose changes if any have been made. To revert back to the last version saved whilst editing, rather than closing the Designer, select 'Revert to Last Saved' from the 'File' menu.

As soon as a change is made to the current program, an asterisk (*) appears after its name in the window's title bar. To save the program, click on 'save' at the top of the right-hand pane or select 'Save' from the 'File' menu. If there are any errors, you will be given a message and prompted to change them (see Program Errors, below) . Otherwise, the asterisk will disappear and the changes you have made will be saved to disk.

Renaming Programs

Programs should not be renamed lightly, since their name is stored in results files and used for filtering - the originally named program must still be present on the disk for filtering to be performed. The name is also stored in setups, and both the program file and the folder it resides in use the name. However, it is possible to create a new program that is identical to a previous program, and the previous program's folder could then be deleted if desired to perform a 'renaming' operation.

Program Errors

When you are typing values into the tables in the Designer and make an error, when you click elsewhere or press ENTER, the Designer will show an error message, then highlight the error, surrounding the box containing the error with a red line. Some errors, such as the use of an undeclared identifier, are permitted on the basis that you might, in this example, define the identifier later. However, such errors are checked for when you try to save the program, and are highlighted in just the same way. Note that the program will not have been saved, so you must correct the error and try to save it again.

Alternatively, switch to code-only mode and save the program from there (but be warned, you may not be able to open the program in the Designer again without correcting the error in the text first) .

Code-only Mode

The Designer visually represents textual Turandot code. It is possible to switch at will between either designer or code-only mode, with any changes made in one mode being seamlessly integrated into the other. This is achieved using the first item on the 'View' menu.

Code with some of the errors that the Designer checks for can be saved in code-only mode, although basic parse errors are still not permitted. When code with errors is opened in the Designer, it will automatically switch to code-only mode and attempt to highlight the error.

Only when an error in the text is corrected will the 'View' menu item permit a change into Designer mode.

Designing a Results Filter

Raw results are filtered (by the Network Manager) to record occurrence counts, times and latencies of various measures that you can define with respect to the program. A measure is simply an incident in a program that has an associated time of occurrence and (optionally) an associated latency. Because the incident that the measure refers to may happen more than once during the course of a program's running, counts, rates and mean latencies of measures can then usefully be calculated from the filtered results. A filter is a collection of named measures defined that apply to a given program.

Whilst the raw results are stored in a results archive file on the PC running the Network Manager, the filtered results are stored in a database (see the Network Manager network for more information) . Paths

In more detail, a measure is defined as one or more paths through the program. If any one of these paths is followed during the course of the execution of the program, an incidence of the measure is deemed to have occurred. For example, if one path through the program identifies a correct action, and another identifies an incorrect action, a measure (called "Action", say) could be defined to include both these paths . Then, whenever a correct or incorrect action happened, an incidence of the Action measure would be deemed to have occurred. If the latency on each path was the time taken for the (correct or incorrect) action to occur then the mean latency of all incidences of the measure would give the mean time taken for the action, regardless of whether it was correct or incorrect. Two- further measures, each containing just one path, could be used to count and time just correct or incorrect actions.

The filtering process works by simulating the program using the raw data, at all times watching for (and timing) occurrences of all paths in all measures in the filter. If a path is partially followed and then a point not on the path occurs, the path is deemed to have been cancelled, and the remainder of the path is not searched for (but the start of the path is searched for again) .

A path is a list of points in the program. Each point has a single time associated with it (the time at which the point is reached in the program) , and the points must occur in the order in which they appear in the path for the path to have been followed. A path can also contain gaps, during with other points in the program can occur without cancelling the path.

Path Points

A point on a path can be one of the following: A link - for a link, the filter stores the start procedure, the end procedure, and the event name. Only the specific link to which these apply may form the point on the path. If the procedure names or event name change then the path becomes invalid. The time associated with the link is the moment at which the event occurs.

A watcher - for a watcher, the filter stores the target procedure and the event name. Only the specific watcher to which these apply may form the point on the path. If the procedure name or event name changes then the path becomes invalid. The time associated with the watcher is the moment at which the event occurs .

A procedure - for a procedure, the filter simply stores the procedure name. If the procedure name changes then the path becomes invalid. The time associated with the procedure is the time at which it is entered, which is exactly the same time as the event which caused it to be entered occurred.

If the next occurrence on a path is a link from a certain procedure, the path can only be cancelled by the following of a different link from that same procedure. The path can also be (cancelled-but-) restarted by the re-occurrence of the first point in the path.

Whilst this works for links, it does not work for watchers or procedure entries. If, in the example on the left, we define a path consisting of the links "Pathl, Path2" then if the events during the program occur in the order "Pathl,

OtherEvent, Path2" the path is still deemed to have been followed. However, we cannot reasonably define a path "Pathl, Path2, Path3, Path4" since events could occur in the order "Pathl, Path2, OtherEvent, Path3, Path4" in which case is in not possible to determine whether OtherEvent should cancel the path. It could be an event in a completely unrelated, asynchronous part of the program, in which case it should surely not cancel the path. Where a procedure entry or watcher are used, there is implicitly a gap before them, and the path should be defined as "Pathl, Path2, <gap>, Path3, Path4".

Gaps can also be added manually to paths to occur between links. During a gap, no points in the program will cancel the path except for the first point in the path, which will (cancel-but-) restart it.

You may wish to forbid certain points from occurring during a gap. (That is, to permit the path through the program to follow any route from the point before the gap to the point after the gap excluding routes that go via certain point (s) . These points are called kills, and if a kill point is met during a gap, the path is immediately cancelled. Note that kill points could be points that occur earlier or later in the path itself - it is only during gaps that they cause the path to be cancelled.

During filtering, the search for each path in the filter can only be at one point on that path at a given time. If the first point in the path occurs half way through the path, the search for that path is reset to the start.

For the last path defined in the above example, "Pathl, Path2, Pathl, Path3, Path4", would not be deemed as an occurrence of the path.

Filter Definition

To define a filter for a program, select 'Design Results Filter' on the 'View' menu. This will allow the standard filter for the program to be edited (see "filter files") . All links and watchers in^' the program will become visible on the right hand side of the window.

The filter designer is wizard-based, and should be fairly self explanatory. Measures are created by clicking 'New Measure...'; this creates an empty measure for you (called "New Measure") and moves to the measure editing pane automatically. The measure may then be given a more meaningful name, by typing over "New Measure" at the top of the screen, and paths may be added to it by clicking 'New ^' Path... ' .

After you have clicked there, the procedure names and event names on the right hand side of the window will highlight when you pass the mouse over them. Simply click on the highlighted event names (on links or watchers) and procedure names in the order in which you would like them to appear in the path. The path you are creating will appear in the left hand side of the window,- with_. the points you click on being added in turn as numbered rows .

If you add a watcher or procedure to the path, a gap will automatically be added for you. To manually add a gap as the next item in the path, click 'Add Gap'. To add a kill, click 'Add Kill' then click on the point that you would like to act as a kill in the right hand side of the window. (After you have added one kill, the next point you click on will be added to the path as before) .

Filter Files Filters are stored as files with a ".cnsfilter" extension. They store the names of procedures and events, so if the program structure is changed or events and procedures are renamed then the filter could change its meaning or even become invalid. The standard filter for a program is stored in the same folder as the program, with the same filename as the program (but a different extension, of course) . When you have a stable version of a program and filter (s) that apply to it, they should be copied into another folder for future re-use. Multiple filters can also be defined by renaming the standard filter and using the filter editor to create a new standard filter. To use the renamed filter when performing the filtering, specify its full path and filename in the alternative filter box provided.

Latencies

As well as the time at which an incidence of a measure occurs, a latency can also be associated with a measure. By default, the latency is the time between the occurrence of the first point in the path and the last point in the path (the time of occurrence of the measure's instance being the time of the last point in the path). However, 'Move Start' and 'Move End' can be clicked on to cyclically move the start and end of the path to other points. The latency is then the time between the point labelled "START" and the point labelled "END". This is useful if, for instance, the timing you are interested in only applies if certain events (about whose timing you have no interest) have already occurred.

In fact, four times are associated with each path, and therefore with each incidence of a measure: the start of the path, the start of the latency, the end of the latency, and the end of the path. They will always occur in that order (some perhaps simultaneously) .

Completing the Filter If you make a mistake in defining the path, click 'Cancel' and begin again; otherwise, click 'Done' when the path is completed. (Do not just click 'Back' or the path will be lost) . An entry will be added to the list of paths above the path definition. To view a path's definition, simply click on it in the list; to remove it from the measure, click on ' (delete) ' adjacent to it. Note that the paths are not stored in any particular order, so always click on a path to check its definition before deleting it. Once all the paths are completed, click 'Back', then add any further measures- required in the same way. To change an existing measure, just click on its name in the list, or to delete it, use the adjacent 'Delete' button. Finally, click 'Finish' to save the filter. Alternatively, click 'Cancel' to abandon all changes to the filter. Do not close the Designer window without clicking 'Finish', or your changes will not be saved.

The Network Manager Overview

The Network Manager allows boxes on multiple control units to be defined, and programs to be assigned to them. It therefore controls the allocation of the digital input and output lines on each control unit, making line assignment automatically which can be overridden by advanced users if required.

It allows ^' programs to be started, paused and stopped on each box, and listens on the network for results coming back from the boxes, recording them in a results archive on the PC on which it is running.

It has a separate section which allows results that have already been recorded to be filtered into a database according to criteria specified in the Filter Designer.

Basic Operation If the control units are set up properly and attached correctly to the network then the Network Manager should automatically detect them within a short while of being started, and present their names (initially just their IP addresses) in a drop-down box at the top right-hand corner of the main window. Click on the downwards arrow to see a list of all control units available, along with the 'Entire Network' option which allows all connected controllers' boxes to be viewed.

Each control unit has a fixed number of input and output lines, subsets of which can be assigned for running programs. Each such subset is referred to as a 'box' (since the lines in the subset are typically all routed to one physical box of electronics) , and the number of boxes on each control unit is specified by explicitly adding and removing boxes using options on the 'File' menu. The allocation of which lines are used for each box, and which of those physical lines corresponds to which digital input or output in the program running on that box, is performed automatically by the Network Manager and presented in a table to make wiring as simple as possible.

If a different program is later run on the same box, new lines will only be allocated if the program contains new identifiers for digital inputs and outputs. Otherwise, the old allocations will be re-used.

The Main Window This window appears over a 'Network Manager Log' window when the Network Manager is started, and is divided into a Configuration pane and a Summary data pane .

The Configuration pane has a controller selector at the top right-hand corner, after the 'Controller:' label. The boxes that have been added to the controller selected here are displayed in the table below, with one row for each box (and a row above them labelled ' [All Boxes] ' if there is more than one) . If 'Entire Network' is selected, the boxes from all the controllers will appear in the table, in contiguous blocks for each controller.

The first column in the table is the name of the box; this can be changed as desired by double-clicking on the name, typing a new one, then pressing ENTER. The next column is the name of the last program that the Network Manager attempted to send to the box, followed similarly in a third column by the name of the last setup sent that pertained to that program.

The fourth column, 'Experiment', is for a user-defined name that will be saved with results coming back from programs running on that box. This can be changed to any text that you desire before running each program, and should be used to help you keep track of your data. By default it is left blank.

The next column gives the approximate time (to the nearest ten seconds) for which the program has been running.

The final column is a panel of three buttons; they are respectively a play button, used to start the program, a pause button, used to temporarily suspend execution of the program and ignore digital inputs, and a stop button, used to forcibly terminate execution of the program. The buttons are greyed until they can be pressed - if, for instance, a program is selected but either requires a setup or is not received correctly by the control unit, the program name will be displayed in the second column of the table, but the play button will remain greyed. After the play or pause buttons have been pressed, they will light up to indicate that the box is in 'play' or 'pause' mode.

The summary data panel similarly contains a row for each box, and has a column for each event in each program. It allows the progress of programs to be monitored as they run, keeping counts and rates for each event declared in the program. Columns can also be added to display latencies between events . Adding Boxes

Initially, a controller has no boxes defined. Use the 'Add boxes' option on the 'File' menu to add boxes to the control unit currently selected in the controller selector. Before adding boxes, you should have given the controller a name; it you have not already done so, click '(properties...)' at the top-right hand corner of the configuration window and rename it there.

When you add boxes, a window will appear allowing the number of boxes to be added to be specified, and a 'name prefix' which will precede each of the numbered boxes. If, for instance, you already have a single box called "Eunice 1", and add two boxes with the name prefix "Eunice", they will be named "Eunice 2" and "Eunice 3". If you specify the name prefix "Fred", they will instead be named "Fred 1" and "Fred 2". The names can be individually edited later.

The two remaining options are the number of input and output lines you wish to reserve for this box. If you do not reserve any lines for a box, when a program is assigned to multiple boxes, they will use the first free lines available to them. (e.g. Box 1 might use lines 1-6, and Box 2 lines 7-12) . If a program using more digital inputs or outputs is then assigned to Box 1, more lines will have been allocated (for instance, lines 13-15 for Box 1 and lines 16-18 for Box 2) . Box 1 now has a non-contiguous set of lines, namely 1-6 and 13-16. If we had reserved 10 lines for each of the boxes, Box 1 would instead use lines 1-9 (with line 10 still reserved), and Box 2 lines 11-19.

Lines reserved for one box can later be 'stolen' by another if necessary. Input lines and output lines are handled completely separately, so a separate reservation may be made for each. Assigning and Running Programs

To assign a program to a box, click in the second column. A downwards arrow will then appear; click on this to be presented with a list of programs that you can run. (Only valid programs in folders under the folder specified in the Control Options Tab will be displayed) .

If the program you have selected causes a change in line allocations, a window will appear to inform you of this (see Line Allocation, below) .

If the program you have selected uses settings, you should then select the name of the setup from the third column in a similar fashion. Once the program (and setup if applicable) have downloaded to the control unit, the play button will turn green and may be clicked to begin the program. However, it is normal to specify an experiment name of your choice in the fourth column before starting the program.

It is possible to assign the program, setup and experiment name to more than one box, and to start/pause/stop the programs for multiple boxes, by using the top row of the table. It is normally headed '[All Boxes]', and selections made in the top row will apply to every box in the table (i.e. every box on the currently selected controller, or all boxes on all control units if 'Entire Network' is visible in the controller selector. As soon as you click in the top row, all the remaining rows will highlight to reflect this.

If you would only like to affect some of the boxes in the table, highlight their rows either by clicking and dragging, or by holding the CONTROL button and clicking on individual rows to select/unselect them. The 'Time Remaining' column is the most suitable one to click in, since it is uneditable so the there will be no accidental side-effects . Once more than one row is selected, the top row will be headed '[Selected Boxes]', and only those rows selected will have their value changed when settings are made in the top row. Even the play, pause and stop buttons will affect multiple rows, although a warning message will appear lest you accidentally pause or stop programs on all boxes.

You can also blank the program name, setup name and experiment on selected rows by using the DELETE key.

Line Allocation

When a program is selected on a box, the Network Manager will look at the names of all the digital inputs and outputs it uses . Where inputs or outputs with those names are already allocated to line numbers on that box, the same line numbers will be allocated to them. If a name that does not currently have a line allocated against it is met, the Network Manager will look for unused lines that have been reserved for that box, and if there are any available, allocate them. If there are still insufficient lines, the Allocation Choice Window will appear. If, once the allocation is complete, any line mappings have changed, the Properties Window will appear to allow you to look at the line maps for all attached control units.

Allocation Choice Window This window gives the name of the box, and (in brackets) the name of the identifier for which the Network Manager is trying to allocate a line. The window allows you to choose which of the following method (s) will be used to allocate a line number for this identifier and any future new identifiers met in the program. Any combination of the three options may be ticked, and the ones ticked will be attempted in the order in which they are presented.

Reallocate lines from previous programs - this will cause the Network Manager to use lines on the current box that have previously been allocated to identifiers that are not used by the current program.

Allocate free lines - this will cause lines that have not been used before to be allocated to the current box and used for the new identifiers.

Defer the choice - if the other options ticked (if any) fail because there are no suitable lines to use, this allows the identifier to remain unallocated, so that you can manually edit the Line Map Table later.

After you have clicked OK', the method(s) you have selected will be tried for all remaining new identifiers in the program.

Do the same for all boxes - if you have used the top row of the configuration table to select the program for multiple boxes, this option will cause the choice you have made above to be repeated for all the boxes to which you are trying to allocate the program. It will not cause the options to be repeated when you later select a program from the table.

Properties Window

This window appears when line allocations change, or when ' (properties) ' at the top-right of the configuration window is clicked. It has three tabs for each control unit. The first of these tabs, with the controller's (control unit's) name, contains information about the configuration of the control unit, and also allows its name to be changed. The remaining two tabs contain the input and output line mappings, respectively, for that controller.

The line mapping tables (both for inputs and outputs) have one column for each box, and one row for each identifier used in a currently selected program. If an identifier is not used on a given box, the corresponding cell in the table cannot be edited, and contains a dash. All other cells should contain line numbers, but if lines are still unallocated then they will appear blank.

Note that lines that are reserved for a box, or that have previously been allocated to an identifier that is not used in the currently selected program, do not appear in the table. To see these allocations, and to see the allocations presented in line number order rather than in identifier order, generate a Line Map Report by clicking on 'Line Map Report...' below the table.

Line Map Reports A line map report is a list of the line numbers (input or output, depending on whether the report was generated from a table of input or output allocations) available on the controller. For each line, the box to which it has been allocated (if any) is given, and the identifier with which it is associated (or '<reserved>' if the line is reserved for a box but not yet allocated. Free lines can be identified by looking for rows which contain nothing but the line number itself.

Once generated, the report is not updated, so close its window after you have finished looking at it. The report does include any changes you have made to the table; note that these changes will not be kept if you click the 'Cancel' button in the properties window.

The report can be saved by clicking on 'Save As...' below the report, and opened in a spreadsheet package (or just a text editor) and printed if desired. Editing the Table

The line numbers in the table can be edited simply by clicking in the cells, typing the new line numbers and pressing ENTER. You will be warned if the numbers you enter are invalid, or if they involve stealing a line that has been allocated to another box. When replace one line number with another, the original line will remain reserved for the box to which it was allocated. To free a line completely, you must blank the cell in the table and press ENTER. A message will appear to ask you whether or not you want the line to remain reserved for the box.

Lines are allocated in alphabetical order; if this is not convenient for wiring, you may swap the line allocations in any two rows in the table, simply by selecting the two rows (by holding CTRL and clicking if necessary) and clicking on ' Swap Rows ' below the table .

Naming Schemes

If you wish to wire all the facilities that the various boxes attached to a controller have at once, and want to avoid subsequent rewiring, it is advisable to decide on a naming scheme for all the facilities in advance, and write a program in the designer that simply declares the names of all the digital inputs and outputs you would like to use. (The program could also be used to test all the inputs and outputs) . Then add and name the boxes, reserving more lines than you will need if you want to leave room for future expansion, and run the program on each box that will use the naming scheme. (You may have to write multiple programs if different boxes have different facilities) . The network properties window will appear to give you details of the line mappings allocated, which you can modify i^*£ you wish before clicking 'OK' .

Finally, select all boxes and press DELETE, answering 'Yes' to the question presented in order to blank the program's name from all the boxes . You may now exit the Network Manager, and next time you start it the line mapping scheme will be remembered. It is recommended that before exiting you store a lab save, so that you can always revert back to this 'blank' initial scheme later.

Naturally, once a naming scheme has been established, all programs run under that lab save must conform to the same naming scheme (of course, the ability to store multiple lab-saves permits multiple such naming schemes) . If the naming scheme uses the terms "Switchl" and "Switch2", programs cannot use the terms "leftSwitch" and "rightSwitch" to have the same meaning. Fortunately, the process of converting a program from one naming scheme to another is trivial, since when you change the name of a digital input or output in the declarations panel, it is automatically renamed throughout the program for you.

Results Handling

The results sent back from the control units are a per-box record of program and block starts and finishes, all changes in digital inputs (and outputs) , and all events fired. Pauses, restarts and custom data saved by library calls are also recorded.

The results are stored in the computer's memory by the Network Manager, and saved to disk when the program finishes or is stopped. These raw results can be viewed, saved as a spreadsheet, and (most importantly) filtered into a database of more meaningful measures . Live monitoring of results can be provided by the summary data table .

Summary Data Table

This table gives the block of the program that each block is executing, and the counts and the rates (per-block or per program) of all events. The units in which the rates are measured, the number of significant figures shown and whether analysis is per-block or per program can all be set by clicking on 'Options' beneath the table. Changes are reflected by the second row of the table headers, which give the units for the rates .

In addition, custom latencies between events can be added to the table. The mean value of the latency, as well as its value at the last occurrence, will as a result be displayed in a new column.

To add a latency, click 'Add latency' , and select the events between which the latency is to be measured. You may also give the latency a name to use in the column header. The value recorded will be the time from the most recent occurrence of the first event to the occurrence of the second event. (For example, if the first event fires three times before the second event fires, it will be the time from its third occurrence that is measured) . Latencies are of course only monitored after the column has been defined, so you will normally want to add all the latencies you wish to monitor before starting the program.

The 'Remove latency' button may be used to stop monitoring a latency.

Table Layout and Row Selection

The columns in the table can be moved by dragging on their headers, and resized (as for all tables in CeNeS Control) by dragging the vertical part of the header's border, between the columns (the part circled in the inset picture) . The currently selected column (or columns - hold CTRL and click in the columns you wish to select) can be hidden and shown using the icons at the top-right of the table. Note tha't if the columns in the table change (for example, if you monitor boxes which are running a different program) the table will be reconstructed with new columns and changes such as these will be lost.

Normally, the summary table displays the same boxes as the configuration table. However, you can 'lock' it to monitoring boxes of your choice, meaning that changes to the upper table need not cause the aforementioned table reconstructions. This is achieved by selecting the rows that you are interested in from the configuration table (from more than one controller if you would like) and clicking on 'Monitor boxes selected above'. Even if the selection subsequently changes, the summary table will remain locked to these boxes (to update it to the new selection, simply click again) . To return to monitoring the boxes selected in the upper table, click on 'Monitor all boxes ' .

Once latency columns have been added, they (like event columns) will still be updated with respect to boxes that are not visible in the summary table. Likewise, if you hide a latency column, it will still be updating ready in case you elect to show it again later. If you want to stop the computer from monitoring a latency altogether, you must instead select 'Remove latency' . Once removed, a latency will not be saved in the config, unlike when it is simply hidden.

Raw Results

Raw results are saved into a results archive file. The location of this file is specified in the Control Options Tab (see below box) . To see the program-runs stored in the archive, click on 'Filter Results...' or select 'Filter results' from the 'Tools' menu. (A program-run is a single run of a program on a single box, from the time at which play was pressed to the time at which the program finished or was stopped) . The Filter Manager allows program-runs to be listed by their experiment name, controller, program name and date. Simply click on the entries of interest in the four left hand lists, and the relevant program-runs will appear in the main, right hand list. You may select multiple entries in the left hand lists by holding CTRL and clicking on them; having all items in a list selected and having none selected are equivalent.

You may then select the program-runs of interest in the right-hand list, in exactly the same way. To view the logs of results for the selected program-runs, click on 'Show logs ' . A window will appear for each program-run selected, with a list of the results that occurred. The first column is the time of occurrence, in milliseconds, the second column is the type of result, the third and fourth (where present) columns storing data about the result.

The entries are all fairly obvious; types such as TEST (program) and BLOCK have values such as START and END in the third column, which refer (respectively) to the program's and block's starting and ending. The type

PROGRAMMATIC refers to events which have fired, the third column giving the event name. DIGITAL_IN and DIGITAL_OUT record changes on the digital lines, the third column giving the relevant identifier and the fourth column giving the its new value.

The log can be saved as a file by clicking 'Save As...' at the bottom of the window. The log is saved as a CSV file, which can be imported into any spreadsheet.

File Locations and the Control Options Tab The Control Options Tab is used to set options that pertain to CeNeS Control as a whole. As well as the two important options detailed below, it also has settings to change user interface aspects such as the look-and-feel, which determines the appearance of button, menus and such like, and which should normally be set to the Vava look and feel' unless it causes you particular offense. Program Folders Under - Each program has its own folder inside the folder specified here. Inside each program's own folder, the program is stored in a file with the same name as the program and the extension ".tnt". Other backups of the program are also normally stored here, along with the program's setup format and setup files, and the program's filter file.

Programs (and setups and other files) can be saved in other locations on the disk if you prefer, but will be less convenient to access. However, if you use ^ΛSave Copy As...' to save to a different location, the program can be retrieved when next opening the Designer by selecting ^λOther...' from the drop-down list and browsing for the file.

Results Archive - This is the full path and filename of a results archive file, in which all raw results from programs running are recorded by the Network Manager. You should not normally change this option if programs are running. It also specifies the archive from which results are filtered when you perform filtering in the Network Manager .

Managing Results

To avoid the results archive's becoming too large, the archive file to which results are saved should sometimes be changed. A new filename in the folder in which you store the results archives may be specified in the Control Options Tab, the file being created when -the results from a program-run are first stored there.

To view and filter results from an archive other than the one to which results are currently being saved, simply change the setting in the Control Options Tab to the old archive (remembering to set it back to the new archive before running any more programs) .

Filtering Results After selecting the program-runs that you would like to filter, click 'Start filtering' at the bottom of the screen. At this point you will be invited to give a connect string to the database in which you would like the filtered results to be stored. If you then 'Click here to connect', filtering will begin, each program being filtered with its own filter. Details about how to specify the measures that you want in a filter are given above .

N.B.. It is important -to filter results before changes have- been made to the program, because the program is used during the filtering process. Likewise, the filter stores the names of procedures and events, and becomes meaningless if the program is restructured or has its identifiers renamed. Once programs have been used to gather useful results, modifications should be made by creating a new program with a different name ( 'MyProgram2 ' rather than

'MyProgram') and reverting from the original. If you must change the program before filtering, save a copy of the original. When you want to filter results created by runs of the original program, revert back to your saved copy before doing the filtering.

Other Features

Configuration Features Network Manager Options

The options window can be opened by selecting 'Options' from the 'Tools' menu. It allows access to the Control Options Tab (described above) , and also to a tab which allows logging details to be set for technical support purposes, and should not normally be modified. The remaining tab contains network port settings which you should not normally have to alter (again for technical support purposes) , and one useful setting, 'Automatic config load', which is described under the heading 'Network Manager Configs ' .

Network Manager Configs

A config is a disk file which stores everything you have set up in the Network Manager - the controllers and their names, the boxes on each of the controllers, the line mappings and reservations for each box, and even which program and which setup has been allocated to each box. It also stores preferences and latencies from the summary data table.

A config is automatically saved for you whenever you exit, and automatically opened again when you start the Network Manager. If you do not want it to be automatically opened, and would rather start with a ''clean slate' , untick the ^Automatic config load' checkbox in the options window (select 0ptions' from the ^λTools' menu) . You can also manually save and load configs. This can be used to back-up line allocations that you have set up, and could also be used to save schedules for different days, including experiment names and details of which programs and setups to use. Use ^λLoad config' and ^ΛStore config' on the ^vFile' menu to load and store configs in a location of your choice, or ^λRevert to autosaved' to revert to the state when the Network Manager was last exited. Config files have a ^Λ.tntconfig' extension.

Configs for the Current Controller Only

Configs may contain information about several controllers, but you can elect to load information about only the currently selected controller. This will leave other controllers unaffected, will not change options in the summary table, and will add to (rather than replace) any latencies you have defined. A config may also be saved that contains information about only the current controller. ^λLoad current from config' and ^ΛStore current controller only' on the ^ΛFile' menu perform these respective actions.

Controller Properties Windows

Line maps for boxes that are not running or paused (but have programs assigned to them) can be viewed or edited at any time by selecting the control unit from the controller selector, and clicking on '(properties...)' immediately to its right. This opens the window that otherwise appears when the line mapping has changed. A line map report can be generated from here if desired.

Other -Menu Options Reinitialise All Controllers This command, located on the 'File' menu, causes box and program information to be re-sent to all controllers. It can only be used when no programs are running. (This should happen automatically if a control unit is ever turned off then on again.)

If a control unit fails to appear in the controller selector, try selecting this item - it will cause a broadcast message to be sent over the network instructing all attached controllers to identify themselves.

Current Controller Interface This command, located on the 'Tools' menu, opens a web (internet) interface for the control unit currently selected in the controller selector. In this embodiment, each controller (control unit) acts as a web server, and has a webpage which you can browse here. It gives information about the status of the controller, and allows its static IP address to be changed (and for automatic configuration via DHCP to be specified instead) . Exit

Selecting this option from the 'File' menu, or closing the main window, causes the Network Manager to exit. This should not be done while programs are running, since if it is they will be stopped. (The Network Manager has to be open while programs are running in order to receive their results) .

When you exit, your current settings are automatically saved. If you only want the boxes and line maps to be re-sent to the controller the next time you open the

Network Manager, and not the actual programs and setups chosen, select all boxes (usually just click on the top row of the configuration table) and press DELETE before exiting; (Alternatively, to avoid the boxes' being recreated altogether, untick the 'Automatic config load' setting in the Network Manager options) .

Using Settings

Overview

A program specifies how to run a single block, and the settings infrastructure executes this code (i.e. processes the initial declarations and enters the Start procedure) repeatedly for all the blocks in a program-run. It is ^'possible to create a program that uses no settings at all and effectively consists of a single block, but if more than one block is to be executed then a setup format must be designed for the program, and one or more setups created in the Settings Editor.

A setup specifies the number of blocks to execute, and (optionally) the values of various settings. It is the setup format that defines what settings can be used with a given program, and in what range those settings' values may be.

The settings may apply to all the blocks in the program, or may be specified on a per-block basis. In addition, lists of settings may be specified on a per-block basis. These lists can then be accessed using library calls or even imported into sets in the program. The Settings Designer is used to name the settings available and the range of their values, and to determine whether they apply to the entire program or to a single block.

The settings are read in the program simply by declaring a setting object (the spanner/wrench icon) with the name of the setting, then using it in expressions just as with an integer or a flag. Settings may themselves be booleans (true/false) or integers, and in the latter case they may be limited to a range or specified as a choice from a list.

Designing a Setup Format The Settings Designer is wizard based, and should therefore be mostly self-explanatory. It begins by offering a choice of program. The program must first have been created in the Designer, and should be selected from the list before clicking 'Next'. A choice is then offered between creating settings that are specified for the whole program or for each block. If you elect to create a setting that is specified for each block, you must additionally specify whether it is an individual setting (that is one whose value is specified only once per block) or a list setting. A list setting is one that can have multiple values (that is, for which a list of values exists for each block) .

List Settings and Tables

These lists of settings appear as columns in tables. You may, for example, have 'sub-blocks' within the blocks of your program, whose execution is handled by your Turandot code, and you may wish to have various settings for each sub-block. To achieve this, you would create a table called "subblocks" and add each of the settings as list settings - that is, columns - in the subblocks table. This would ensure that any list settings that are part of the subblocks table are specified an equal number of times in any given block, because each column in a rectangular table must have the same number of rows .

If all the list settings you wish to use can have different list lengths in a single block then they must each be the sole column in their own table.

To create a table, click 'New... ' . You must give the table name ("subblocks" above) , a singular form for the row heading ("Sub-Block") and a plural form ("Sub-Blocks") . To add columns to it, select it from the drop-down list and click 'Next', then specify the columns in just the same way as you would specify the per-program and per-block settings (described below) .

Tables can be deleted from the setup format by clicking

'Delete', and the singular and plural forms can be renamed by clicking 'Rename...'. The table name itself is never visible to users of the Settings Editor, and is never used in programs. It exists solely to group columns of list settings together.

Specifying Settings

After you have selected the type of settings you wish to create and clicked 'Next', a list of currently defined settings of that type (initially blank) will appear. Click 'New... ' to create a new setting. You will be asked for the setting's name. This must be exactly the same name as you declare the Setting object with in the program, and should contain no spaces. The name will not be visible in the Settings Editor, because a more aesthetically pleasing caption is specified later. Although the caption can later be modified, the name cannot.

The Setting Wizard then appears offering a choice of type, value constraints, whether the setting is optional or compulsory, and various other details.

Notable options are that to make a setting optional - this is not normally recommended - and a 'show column' option. The latter allows settings to be hidden in the tables in the Settings Editor, and only accessed in properties windows (described later in this chapter) . The final pane of the wizard allows you to specify help text to explain the function of the setting to users of the Settings Editor.

Once a setting has been defined, it can later be modified or deleted by selecting it in the list and pressing the appropriate button in the main wizard window.

When all the settings of the type being edited are satisfactory, click 'Next'. Your changes will be saved and you will be returned to the second pane of the wizard, so that you can edit another type of settings or click 'Finish' to save the setup format. If you do not want to keep the changes you have made to the current type of settings, click 'Back' and you will be returned directly to the second pane of the wizard. If you want to lose all changes made to the setup format, simply click the 'Cancel' button at the bottom of the main wizard window.

Creating and Modifying Setups Setups are stored as files on the disk, and the Settings Editor is a standard multi-document program which allows them to be opened and saved with familiar 'Open', 'Save', 'Save as...' (etc.) options on the 'File' menu. To create a new, blank setup, select 'New' from the 'File' menu. The 'New from template' option requires a setup on which the new setup is to be based to exist already, so cannot be used at this stage. A setup window will be opened for the new setup inside the main window, containing a table of blocks.

Setup Windows The table in the setup window has one row for each block, so the number of blocks in the setup is implicitly defined by the length of the table. Each per-block setting is represented by a column in the table, and excepting list settings, these can all be edited directly by clicking in the table.

Rows can be added and removed from the table using the buttons on the toolbar - the actions of these buttons apply to the currently selected setup window, since you can have multiple setups for multiple programs open in the Settings Editor at the same time. The buttons act on the rows which - are currently selected. Multiple rows can be selected (and unselected) by holding down CTRL whilst clicking on the row headers in the table.

The first five buttons duplicate items on the file menu. The remaining buttons, respectively, cut and copy the selected rows, and paste them at the current selection point into any matching table. (This means that you can cut blocks from one setup and paste them into another) . The selected rows can be reordered using the up and down arrow buttons . The next button creates a new, blank row, and the button with the cross deletes the currently selected rows. All these functions can also be accessed by right-clicking on the rows in the table . Columns in the table can be hidden either by clicking in them and using the next toolbar button, or more easily by right-clicking on them and selecting the appropriate option. Columns hidden (either by you or in the setup format) can be shown by using the next button and selecting them from the list which appears . The penultimate button brings up a window containing help on the current item; the help is also normally present at the bottom of the table for the current column.

Editing values in the table directly only allows settings to be modified for one block at a time. However, the properties of multiple blocks can be set at once by selecting the rows to modify and then using the final button (or right-clicking) . This opens a properties window. Properties windows can also be used to modify the values of list settings.

Properties Windows

A properties window allows the values of settings in one or in multiple blocks to be set. The settings are grouped into tabs; one tab exists for each table of list settings, and other settings are grouped in tabs according to function. To find the function of any setting, right-click on it and select 'What's This?'. The blocks to which a properties window applies are given in its title bar, and unless, when a properties window is opened, the values of a given setting are the same for all these blocks, the setting will be blank (or greyed in the case of checkboxes) .

If settings are left blank then, when 'OK' is pressed, the original values of the settings in the blocks will be unaffected. However, if a value is entered for a particular setting, that setting will be set to the value entered in all the blocks to which the properties window applies .

List Settings

List settings are handled in just the same way as the blocks in the main table - they too appear as rows in tables, with one column for each list setting. Rows can be added, copied and deleted in just the same way, by using the toolbar above the table itself or by right-clicking, if you are editing the list setting in respect of a single block then you can even open 'sub' properties windows on the list settings' table rows themselves, to set multiple values .

As with ordinary settings, list settings appear blank unless the value of the item in the list is the same for all the blocks to which the properties window applies .

Other Menu Items Program Properties

If settings exist which apply to the program as a whole, rather than being specified on a per-block basis, then these can be edited using this option. A standard properties window will appear containing all the program-level settings. This function is also available on the toolbar.

Revert functions

As with the Designer, you can save copies and revert to them later. This is useful for taking backups. The function to revert to the last saved version is available on the toolbar.

Window Menu

This menu allows you to see what setups are open, switch between them, and arrange the setup windows within the main window.

Using Settings in Programs When searching for a setting, the system will attempt to find a program-wide setting with the name, then (failing this) a per-block setting with the name, then (failing that) a list setting with the name. All settings can be referred to in a program simply by using the setting object with that corresponding name. However, this only allows the value of the setting in the current block to be accessed, and is of little use for list settings (where it just returns the first setting in the list) . Pseudo-Randomisation

Although cenes .util. random is available to provide random numbers, it may be required that these numbers are distributed in a more controlled way. For example, you might have five lights, and want a random one to turn on, but want to be sure that in total each light will come on a fixed number of times. This is clearly not the behaviour that calling cenes .util .random(5) will guarantee.

One way to achieve such pseudo-randomisation is to fill a set with the light numbers (e.g.

1,1,1,2,2,2,3,3,3,4,4,4,5,5,5), perhaps by using cenes .setting. fillset, and then shuffle the set with cenes .util. shuffleset.

Adaptive Behaviour

It is possible to make programs exhibit adaptive behaviour (that is, change their subsequent behaviour depending on earlier performance) in a number of ^'ways. Naturally, all adaptive behaviour could be included in the Turandot code itself. However, it may be more convenient to define a large number of blocks in the setup, then skip a certain number of the blocks each time depending on performance. This is facilitated by library calls such as cenes . setting. setnextblock, cenes . setting. getblockssofar and cenes . setting. getcurrentblocksofar as well as those already mentioned.

The Simulator

Overview

The Simulator is entirely wizard based, and should therefore be mostly self-explanatory. It exists to allow programs to be run and tested on the PC, without the need for a control unit or any hardware to be connected. The programs can be run in 'real time', or in a debugging 'Managed' mode in which you choose which event fires at any given time.

Visual Representation

The objects in the program are all represented visually with their names and icons (as when they are declared in the designer), and where applicable, their values. The value of timers is displayed approximately as a progress bar. The values of integers, settings and counters are displayed as numbers below the icons. The names of the objects contained in sets (or just the values in sets whose members are not objects in the program) are displayed in a scrollable list below sets.

The image or animation may also be used to determine the state of an object - the sun arcs over the sundial as the timer runs, the abacus shuffles its beads until the counter reaches 0, and the flag flies at full mast only when its flag object is set to true. Digital outputs are on only when the LED is glowing red, and digital inputs are off and on when the switch is up and down respectively (as with a light switch) .

The objects can be arranged in any way you like, be it to represent their physical layout or their logical role in the program. You can also interact with digital inputs to turn them on and off; click the switches with the left mouse button (being very careful not to move the mouse, or you will drag them instead) to flick them between on and off, or right-click on them to push them to the opposite state then back again. The latter option is useful for input devices such as pushbuttons, which are only momentarily on; start with them turned off and click the right button. This will briefly turn the digital input off then turn it on again, as if pushing again the spring of a doorbell. Remember that an event defined as a digital input's name only fires when the input is turned on, not when it is turned off.

Use for Debugging

If you click 'show program design' in the main window, the main pane will split to show the objects at the top and the program at the bottom, with procedures that have been executed and still have active links highlighted in orange. This is useful to trace the flow through the program, and pick up any unintentional branches (since two procedures will become highlighted) .

Remember that a procedure's being highlighted means that a) it has finished executing and b) it has active links waiting for a corresponding event.

Technicalities

Some behaviour in Turandot is undefined. For instance, if two watchers are watching for the same event (with different target procedures) , which procedure will be entered and executed first is undefined. If the procedures reference the same variable the order of their execution may make a difference (e.g. if one has the statement n=n+l and the other has the statement n=n*2) . In this case, the program is clearly in error, but it may happen that they are always executed in the desired order in the Simulator but not in the real interpreter on the control unit. Because the two interpreters are implemented separately, it may therefore appear that they are behaving differently even when they are both actually meeting the specification of the Turandot language. Of course, real-life examples will tend to be far more subtle and complex than the one given above .

Java also executes considerably more slowly than the code on the control unit, has to take care of its graphical user interface, and is less robust (it may pause at certain points to perform administrative tasks such as "garbage collection") . It cannot be guaranteed that the Simulator will operate properly with very fast timers, in particular, and the screen is unlikely to redraw itself quickly enough. (But see Speed of Simulation, below) .

Finally, not all library functions are necessarily implemented in the Simulator. If a library call is met but not simulated, the fact will be recorded in the simulator log, along with the arguments passed to the function. If it is not recorded in the log, you can safely assume that is has been executed.

No results are recorded by the simulator. To test results filters, you must run the program on the control unit.

Speed of Simulation Simulation is performed in 'real-time'. However, you may globally modify the value of assignments to timers by using the options on the 'Timer Assignments' menu. Because these settings do not affect timers that are already running, you will only normally want to change them when no timers are running. The settings are largely irrelevant in managed mode, where timers' expiring does not cause any events to be fired.

Simulation may be accelerated or decelerated by two or ten times by selecting the corresponding option from the menu before clicking 'Continuous' or 'Blockwise' to begin the simulation. Alternatively, enter a multiplier of your choice after selecting 'Other' .

Further Alternative Embodiments

In alternative embodiments of the invention, the following features or modifications of features may be implemented. Improved robustness of Network Protocol and Control Units If a large number of control units operate a large number of external devices, it may be possible to overload the network if all results are downloaded to the network manager in real time. For example, with five controllers each with 10 boxes, the network and Network Manager would be responsible for monitoring and recording-to-disk the data from 50 running programs. All input changes and events are recorded, and each input change might cause an event, so with inputs at up to 20Hz and level changes at up to

40Hz, this could overload the system. In this embodiment, therefore, results are no longer sent live to the Network Manager for all connected controllers. Instead, results on the control unit are downloaded automatically after each program run finishes or is terminated. This option can be turned off by unticking ^automatic results retrieval' in the options dialogue, in which case the Results Manager may be used to retrieve the results at a later date.

In this embodiment, results are persistently stored in each control unit, to avoid overloading the network and network manager with data from ast-rate input changes . The dedicated control units run a real-time operating system with software designed to permit fast input rates to be monitored and recorded efficiently to a local disk. Rather than attempt to additionally send results over the network, the control units maintain summary data - that is, counts and rates of events, and values of digital inputs, digital outputs and recorded program variables - and update this summary data to the network manager approximately once per second. The user can define which events and values he wishes to monitor in advance through the network manager, which communicates this information to the control unit. The control unit need only monitor and send summary data for the requested items. Significantly, the user need not be aware that the system is operating any differently than with the embodiments described above, in which all results were sent over the network in real time. In this embodiment the monitored data is updated as before, and as soon as a program run completes, the network manager automatically downloads the persistently stored results from the control unit, at the same time as it previously would have committed them to disk from its own memory. The user simply sees the program run complete and finds the data ready on the local network manager disk just as before. This is not equivalent to running programs on separate computers, which each store data locally, and then manually collating that data.

A further advantage of this embodiment is that if data is lost for any reason on the network manager PC, it is possible to download data stored on the control unit at a later date. A user interface at the PC end offers a list of all program runs available on each control unit, which may be filtered by attributes such as date, time or program. Once the results to download are chosen, they are retrieved automatically by the software.

Results on the control units are organised into ^pages' on each control unit, to keep the number of results manageable and the storage efficient. Changes of page may be automatic or manual. Free hard disk space for each controller can be viewed in the controller options dialogue.

A further advantage arising from this embodiment is that control units may be able to operate without the Network Manager. Previously, if the Network Manager was closed, all running programs were stopped, and if the machine hosting the Network Manager crashed or was turned off, results from all running programs would be lost. Now it is advantageously possible to exit the Network Manager (after a warning) when boxes on connected control units are powered-on and even running. In the latter case, they will continue to run and record results. PC crashes are also recoverable .

In a further embodiment, it may even be possible to close or disconnect the Network Manager and start it again, even on a different computer, and continue to monitor running programs on a control unit.

This feature is implemented using network manager configs. Each network manager config comprises a control-unit config containing configuration information for each connected control unit, as well as various global data items. The Network Manager transmits each control unit config to its respective control unit, where it is stored. The control unit does not process the config file, it merely stores it. It may not even have software capable of processing the config file.

After the network manager controlling a control box is switched off, crashes, or is disconnected from the network, a new network manager connecting to the network polls all control units on the network and each control unit transmits the IP (internet protocol) address of the network manager currently controlling it. If the IP address differs from that of the new network manager, the user is offered the opportunity to take control. If they elect to, the control unit sends various properties to the new network manager, including the config file, and a list of box statuses (playing, paused etc.). The new network manager then reinstates its config in the same way that it would if the user opened it normally, and sets the states of the boxes appropriately. The config sent by the control box to the network manager includes full information about monitoring data, and the control unit has continued to update all its results counts and rates in the absence of the original network manager, so the new network manager is able to immediately display accurate and up-to-date monitoring data.

A practical example of this embodiment is as follows. Suppose that a PC with two control units connected uses the Network Manager to run some programs, and suppose that a fault develops with the power supply to the PC, which it turns itself off. As described above, the control units would continue to run, storing results locally. It would also be possible to take a laptop computer, with no previous connection to the corporate Ethernet network (which perhaps hosts the program files and even Network Manager configs) and directly connect it to the running control units' Ethernet hub. On running. the Network Manager software on the laptop, the two control units will be identified (after a prompt to confirm that the laptop should take about taking over control from the previous Network Manager) with their list of boxes and operating parameters, including the prepared/playing/paused modes of the boxes, updated running time, and all counts, rates and values in the monitoring tables up to date, no events having been missed during the unconnected period. The network manager on the laptop can then take over control of the control units with no interruption to experiments running on boxes interfaced to the control units.

In a further embodiment, multiple Network Managers can advantageously operate on the same network. This is achieved as follows .

Controllers can be removed from configs temporarily (for example, while they are rebooted) or permanently. By removing some controllers permanently from one network manager config and some from another, two network managers running on two PCs could operate different sets of controllers on the same network. Controllers can be unbarred from configs (and barred controllers can be viewed) by selecting unbar controllers' from the controller menu.

If one Network Manager is using a given control unit, the user is prompted before another Network Manager is permitted to take over control .

More specifically, each Network Manager automatically opens a config when it is started, and as noted above this config may contain a list of 'permanently removed' control units. These control units will be completely ignored bu the network controller. If, for example, there are two network managers (1 and 2) and five control units (A - E) on the same network, the user may wish for network manager 1 to control control units A and B, and for network manager 2 to control control units C, D and E. To achieve this, the user permanently removes control units C, D and E from the automatically opened config on network manager 1, and permanently removes control units A and B from the automatically opened config on network manager 2.

- 81 - unbarred from configs (and barred controllers can be viewed) by selecting ^Λunbar controllers' from the controller menu.

If one Network Manager is using a given control unit, the user is prompted before another Network Manager is permitted to take over control.

Claims

- 82 - Claims

1. A control system for controlling a device over a network, comprising;

a network manager coupled to the network; and

a dedicated control unit coupled to the network and comprising a processor, a memory, and a plurality of inputs and outputs, at least one of the inputs or at least one of the outputs being couplable to the device,

in which a program and program settings are transmitted from the network manager over the network to the memory according to a predetermined protocol, and the processor executes the program to control the device by means of the coupled input (s) or output (s).

2. A control system according to claim 1, in which more than one device is couplable to groups of the inputs and outputs of the control unit, and the processor executes programs to control each device.

3. A control system according to claim 1, in which input signals received on the input (s) from the device are stored as data in the memory, the memory optionally comprising a buffer or persistent storage.

4. A control system according to claim 3, in which the data are transferred over the network to the network manager.

5. A control system according to any preceding claim, in which the network manager provides new settings to the control unit to enable the program to be repeated using the new settings. - 83 -

6. A control system according to any preceding claim, in which the network manager assigns inputs and outputs for coupling to the or each device.

. A control system according to any preceding claim, further comprising a plurality of control units coupled to the network and controlled by the network manager.

8. A control system according to any preceding claim, comprising a results filter for filtering data stored by the network manager after being received over the network from the or each control unit.

9. A network manager as defined in any preceding claim.

10. A control unit as defined in any preceding claim, optionally having no user interface.

11. A results filter as defined in claim 8.

12. A method for controlling a device over a network, comprising the steps of;

transmitting a program and initial program settings over the network according to a predetermined protocol from a network manager to a dedicated control unit having input (s) and output (s) couplable to the device; and

operating the program at the control unit to control the device by sending output signals from the control unit output (s) to the device and receiving input signals on the control unit input (s) from the device.

13. A method according to claim 12, comprising the steps of storing the input signals as data at the control unit.

14. A method according to claim 13, comprising the step of transmitting the data stored at the control unit over the network to the network"manager.

15. A method according to any of claims 12 to 14 comprising the step of transmitting new settings from the network manager over the network to the control unit to enable the program to be rerun using the new settings.

16. A method according to any of claims 12 to 15, for controlling a plurality of devices, in which a plurality of devices is couplable to the control unit.

17. A method according to any of claims 12 to 16, for controlling a plurality of devices, in which a plurality of control units is coupled to the network for receiving transmissions from the network manager.

18. A programming language, in which procedures are joined by links to be followed in response to respective predetermined events, such that when a procedure is left on one or more links leading to one or more new procedures, all links leading from that procedure are cancelled, the one or more new procedures is or are entered, and all links leaving the one or more new procedures are established.

19. A programming language according to claim 18, in which two or more links can be followed simultaneously, preferably permitting concurrent points of execution.

20. A programming language according to claim 18 or 19, comprising a link which does not lead from a specific procedure but leads to a procedure which is entered when the event to which that link is responsive fires.

21. A programming language according to any of claims 18 to 20, which is a textual language enabling graphical representation of programs. - 85 -

22. A method of operating a control system, using a programming language as defined in any of claims 18 to 21.

23. An operant box control programming language as defined in any of claims 18 to 21.

24. An operant box control system which uses a programming language as defined in any of claims 18 to 22.