WO2003052530A2 - Procede et systeme de controle - Google Patents

Procede et systeme de controle Download PDF

Info

Publication number
WO2003052530A2
WO2003052530A2 PCT/GB2002/005787 GB0205787W WO03052530A2 WO 2003052530 A2 WO2003052530 A2 WO 2003052530A2 GB 0205787 W GB0205787 W GB 0205787W WO 03052530 A2 WO03052530 A2 WO 03052530A2
Authority
WO
WIPO (PCT)
Prior art keywords
program
network
network manager
control unit
procedure
Prior art date
Application number
PCT/GB2002/005787
Other languages
English (en)
Other versions
WO2003052530A3 (fr
Inventor
Ian Cartland
Original Assignee
Cambridge Cognition Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cambridge Cognition Limited filed Critical Cambridge Cognition Limited
Priority to AU2002352461A priority Critical patent/AU2002352461A1/en
Publication of WO2003052530A2 publication Critical patent/WO2003052530A2/fr
Publication of WO2003052530A3 publication Critical patent/WO2003052530A3/fr

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B15/00—Systems controlled by a computer
    • G05B15/02—Systems controlled by a computer electric
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0421—Multiprocessor system
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/22—Pc multi processor system
    • G05B2219/2241—Real time database, each processor stores in local memory used variables
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23304—Download program from host
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/25—Pc structure of the system
    • G05B2219/25022—LAN local area network for controllers

Definitions

  • the invention relates to a control system and method for controlling a plurality of devices, and to a corresponding programming language and method.
  • 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 .
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • control unit that are separate from the network manager PC advantageously makes the system extensible.
  • the user is advantageously offered from the network manager PC a single point of control and monitoring for all control units.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the designer and the settings editor incorporate a visual interface.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 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;
  • FIG. 4 illustrates a control unit embodying the invention.
  • 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.
  • CeNeS Control a product named CeNeS Control
  • 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.
  • 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.
  • VDU visual display unit
  • touch sensitive screen For more sophisticated cognitive testing, more complex components may be involved.
  • a visual display unit 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.
  • operation of the box entails controlling its inputs in a predetermined manner and monitoring its outputs.
  • 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.
  • a network 4 such as an ethernet, a local area network, a wide area network or the internet
  • the or each control unit can be interfaced to one or more boxes or other devices 8.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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) .
  • 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.
  • 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.
  • Results Manager 36 allows the production of reports and spreadsheets containing counts, rates, times and latencies of the measures on a per-block and per-program basis.
  • SQL standard query language
  • 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.
  • 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 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.
  • One run of a program may have many blocks, but the Turandot code for the program only specifies how to perform a single 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.
  • 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.
  • 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.
  • 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.
  • 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) .
  • 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) .
  • 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
  • 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) .
  • 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.
  • 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) .
  • 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) .
  • 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.
  • 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.
  • 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 .
  • 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.
  • Start 80 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.
  • 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.
  • the background behind its name becomes orange, and the links and watchers that it establishes become visible, all others being hidden.
  • a link 66 is represented by an arrow from one procedure to another, labelled with an event identifier 82.
  • 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.
  • Creating and Changing Links There are three icons to the left of the lower area on each procedure.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • this watcher-machine 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.
  • both links and watcher-enables and -disables can point to the same procedure that established them.
  • 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 .
  • buttons3Event are 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.
  • 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.
  • 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.
  • a library call is provided to programmatically cause definitions containing a particular event name to be evaluated.
  • 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.
  • brackets to override the operator precedence as follows: NOT (leverl AND lever2)
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • watcher-disables are represented as dotted red lines in the main Designer window.
  • 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 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.
  • Turandot 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 .
  • Set expressions are used to define, combine and manipulate sets. They always evaluate to another set.
  • Object names (and other 'sub-expressions') in expressions can be separated using the operators in the following table.
  • numeric constants (0, 54) and named constants (false, true) can be used between operators, as well as subset identifiers and function calls (explained later) .
  • 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:
  • 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:
  • 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.
  • 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 ⁇
  • Set expressions and set identifiers 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.
  • 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 .
  • lightSet [2..] is ⁇ light2, light3, light4 ⁇ and lightSet [ (3-1-1) ..3,1] is ⁇ lightl, light3 ⁇
  • 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.
  • 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 .
  • a subset is itself a set and can only be used in a set expression and assigned to another set.
  • 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.
  • 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.
  • 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 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.
  • 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 are described in the chapters Using Settings and The Network Manager respectively.
  • the 'View' menu has the option 'Code-only Mode' (see below) .
  • an asterisk appears after its name in the window's title bar.
  • 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.
  • the Designer 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • kills 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.
  • 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.
  • 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... ' .
  • 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 .
  • 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.
  • a latency can also be associated with a measure.
  • 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).
  • '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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the Network Manager 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.
  • 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.
  • 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.
  • 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 .
  • 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 .
  • 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.
  • 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.
  • the 'Remove latency' button may be used to stop monitoring a latency.
  • 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.
  • 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 ' .
  • latency columns 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 are saved into a results archive file.
  • the location of this file is specified in the Control Options Tab (see below box) .
  • 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.
  • 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.
  • 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.
  • 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 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 .
  • 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.
  • 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 ' .
  • 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.
  • Config files have a ⁇ .tntconfig' extension.
  • 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.
  • Line maps for boxes that are not running or paused 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.
  • each controller 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) .
  • 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) .
  • 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) .
  • 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.
  • 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.
  • 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) .
  • Tables can be deleted from the setup format by clicking
  • the Setting Wizard then appears offering a choice of type, value constraints, whether the setting is optional or compulsory, and various other details.
  • 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.
  • 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.
  • buttons in the file menu 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.
  • 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) .
  • 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 .
  • 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 .
  • a standard properties window will appear containing all the program-level settings. This function is also available on the toolbar.
  • This menu allows you to see what setups are open, switch between them, and arrange the setup windows within the main window.
  • 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.
  • 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.
  • 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.
  • an event defined as a digital input's name only fires when the input is turned on, not when it is turned off.
  • 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) .
  • 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) .
  • Speed of Simulation Simulation is performed in 'real-time'.
  • 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' .
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • General Engineering & Computer Science (AREA)
  • Stored Programmes (AREA)
  • Multi Processors (AREA)

Abstract

La présente invention concerne un système comportant un gestionnaire de réseau (20) relié à un réseau (4). Un certain nombre d'unités de contrôle (6) est également relié au réseau, chacun comportant une pluralité d'entrées et de sorties pouvant être reliées à un ou des dispositifs (8). Selon le procédé de l'invention, le gestionnaire de réseau transmet aux unités de contrôle, à travers le réseau, des programmes permettant aux unités de contrôle de fonctionner sur des processeurs locaux pour contrôler les dispositifs reliés à leurs entrées et sorties. Des signaux d'entrée reçues en provenance des dispositifs sont temporairement mémorisés en tant que données par les unités de contrôle, et ensuite transmis sur le réseau au gestionnaire de réseau pour mémorisation (34). Un filtre de résultats (32) est, de préférence, associé au gestionnaire de réseau pour le filtrage des données après leur transfert de l'unité ou des unités de contrôle et leur mémorisation au niveau du gestionnaire de réseau.
PCT/GB2002/005787 2001-12-19 2002-12-19 Procede et systeme de controle WO2003052530A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2002352461A AU2002352461A1 (en) 2001-12-19 2002-12-19 Control system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB0130397A GB2384866A (en) 2001-12-19 2001-12-19 Control system using a network
GB0130397.3 2001-12-19

Publications (2)

Publication Number Publication Date
WO2003052530A2 true WO2003052530A2 (fr) 2003-06-26
WO2003052530A3 WO2003052530A3 (fr) 2003-10-02

Family

ID=9927961

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2002/005787 WO2003052530A2 (fr) 2001-12-19 2002-12-19 Procede et systeme de controle

Country Status (3)

Country Link
AU (1) AU2002352461A1 (fr)
GB (1) GB2384866A (fr)
WO (1) WO2003052530A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1733288A2 (fr) * 2004-04-08 2006-12-20 Kohler Co. Systeme de commande distribue d'une baignoire d'hydromassage

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5162986A (en) * 1990-10-19 1992-11-10 Allen-Bradley Company, Inc. Remote downloading and uploading of motion control program information to and from a motion control I/O module in a programmable controller
US5850523A (en) * 1996-06-21 1998-12-15 National Instruments Corporation Method and system for monitoring fieldbus network with multiple packet filters
DE19750365A1 (de) * 1997-11-14 1999-05-20 Bosch Gmbh Robert Verfahren zum Laden eines Programms und Datenverarbeitungsgerät
US5963444A (en) * 1996-09-18 1999-10-05 Mitsubishi Denki Kabushiki Kaisha Control apparatus having remote PLC device and control method for same
US5978578A (en) * 1997-01-30 1999-11-02 Azarya; Arnon Openbus system for control automation networks
US6098117A (en) * 1998-04-20 2000-08-01 National Instruments Corporation System and method for controlling access to memory configured within an I/O module in a distributed I/O system
EP1091522A2 (fr) * 1999-10-06 2001-04-11 Hewlett-Packard Company, A Delaware Corporation Copier des paramètres de configuration entre des équipements électriques
GB2358559A (en) * 1999-10-04 2001-07-25 Fisher Rosemount Systems Inc Process control configuration system for use with a Profibus system

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2286903B (en) * 1994-02-28 1998-07-29 Sanyo Electric Co Remote management system
JPH10118297A (ja) * 1996-10-17 1998-05-12 Omron Corp ネットワークシステム
WO2000043870A2 (fr) * 1999-01-22 2000-07-27 Pointset Corporation Procede et appareil permettant de definir des caracteristiques programmables d'un appareil electromenager
DE10084648T1 (de) * 1999-05-27 2002-05-16 Invensys Plc Foxboro Über Feldbus upgradebare Vorrichtung und Verfahren hierfür
WO2001027753A2 (fr) * 1999-10-12 2001-04-19 Scientific-Atlanta, Inc. Procede et appareil destines au chargement d'un logiciel dans plusieurs processeurs
JP2001268668A (ja) * 2000-03-21 2001-09-28 Seiko Epson Corp リモートコントロールシステムとその設定方法

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5162986A (en) * 1990-10-19 1992-11-10 Allen-Bradley Company, Inc. Remote downloading and uploading of motion control program information to and from a motion control I/O module in a programmable controller
US5850523A (en) * 1996-06-21 1998-12-15 National Instruments Corporation Method and system for monitoring fieldbus network with multiple packet filters
US5963444A (en) * 1996-09-18 1999-10-05 Mitsubishi Denki Kabushiki Kaisha Control apparatus having remote PLC device and control method for same
US5978578A (en) * 1997-01-30 1999-11-02 Azarya; Arnon Openbus system for control automation networks
DE19750365A1 (de) * 1997-11-14 1999-05-20 Bosch Gmbh Robert Verfahren zum Laden eines Programms und Datenverarbeitungsgerät
US6098117A (en) * 1998-04-20 2000-08-01 National Instruments Corporation System and method for controlling access to memory configured within an I/O module in a distributed I/O system
GB2358559A (en) * 1999-10-04 2001-07-25 Fisher Rosemount Systems Inc Process control configuration system for use with a Profibus system
EP1091522A2 (fr) * 1999-10-06 2001-04-11 Hewlett-Packard Company, A Delaware Corporation Copier des paramètres de configuration entre des équipements électriques

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1733288A2 (fr) * 2004-04-08 2006-12-20 Kohler Co. Systeme de commande distribue d'une baignoire d'hydromassage
EP1733288A4 (fr) * 2004-04-08 2011-05-04 Kohler Co Systeme de commande distribue d'une baignoire d'hydromassage

Also Published As

Publication number Publication date
AU2002352461A1 (en) 2003-06-30
WO2003052530A3 (fr) 2003-10-02
GB2384866A (en) 2003-08-06
AU2002352461A8 (en) 2003-06-30
GB0130397D0 (en) 2002-02-06

Similar Documents

Publication Publication Date Title
US7367017B2 (en) Method and apparatus for analyzing machine control sequences
US7827532B2 (en) Finite state model-based testing user interface
JP4347371B2 (ja) 階層ファイル構造の構成要素の選択システムおよび方法
US7343587B2 (en) System for creating, managing and executing computer testing and task management applications
US8261240B2 (en) Debugging lazily evaluated program components
US6121968A (en) Adaptive menus
EP2508996B1 (fr) Visualisation de relations entre un graphique de traces de transactions et une carte de sous-systèmes logiques
KR101837109B1 (ko) 트랜잭션을 논리적 서브시스템들의 맵을 통하는 흐름들로서 시각화하는 방법
US8291261B2 (en) Lightweight application-level runtime state save-and-restore utility
US20030081003A1 (en) System and method to facilitate analysis and removal of errors from an application
KR20040089518A (ko) 객체 계층구조 내에서 객채의 생성을 위한 시스템 및 방법
JPH0581082A (ja) 同期ジヤーナリングシステム
US7987446B2 (en) Method for automating variables in end-user programming system
US5404440A (en) Metaphor environment control system
US20190250968A1 (en) Smart Multiple Display Calculator with Input Output Data Matrix
KR20040028475A (ko) 액세스가능 시스템 이벤트 메커니즘 및 방법
EP1186998A2 (fr) Raccourci dynamique pour l'inversion des actions de logiciels autonomiques
TW200406692A (en) Semiconductor test data analysis system
US20070043547A1 (en) Integrated debugging environment for a network simulation
Rose et al. Modechart toolset user’s guide
WO2003052530A2 (fr) Procede et systeme de controle
Daboczi et al. Automatic testing of graphical user interfaces
US8516384B1 (en) Method and apparatus for performing viewmarking
EP0524103B1 (fr) Système de commande pour environnement métaphorique
KR100936670B1 (ko) 도형화된 시스템 요구사항 처리 장치

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR IE IT LU MC NL PT SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP