NODAL(ID:2285/nod001)High level declarative language for physics researchfor NOrsk Data Accelerator Language (though also possibly from being fundemantally aware of nodes, or possibly from base-9 (nodal) as an advancement on base-8 systems) Interpreted language implemented on Norsk Data's NORD-10 computers. Created by a mixture of FOCAL and SNOBOL Used by CERN, KEK and DESY high energy physics labs to control their accelerator hardware, PADAC and SEDAC. Included trackball input, graphics. Shering (2000) says "Nodal was developed from Focal, a DEC language for the PDP 8 (now we are on a history lesson!). It was necessary to ADD so many features that we gave it a new name which reflected its network capability." According to Shearing 2000, Nobel Prize winner Simon van der Meer was "an expert Nodal programmer" Anticipated the JAVA code applet downloading feature by extensions to FOCAL, as can be seen in the example from Yamamoto and Takagi 2000 of which they say "One of its unique features is a remote execution of Nodal program within a program" Places Related languages
Samples: References: Contents of CERN 78-07 The NODAL system for the SPS 1. Introduction 2. Commands and Variables 2.1 Simple Commands TYPE and SET 2.2 NODAL Names and Variables 2.3 Numbers 2.4 Expressions 2.5 Strings 2.6 Arrays 2.7 Lines with Multiple Commands 2.8 Abbreviation of Commands 3. Programs in NODAL 3.1 Line Numbers 3.2 The LIST Command 3.3 Error Reporting 3.4 The DO Command and Error Handling 3.5 The RETURN Command 3.6 The GOTO Command 3.7 The END Command 3.8 The % Command 3.9 ESCAPE and the QUIT Commands 4. Decisions and Loops 4.1 The IF Command 4.2 The $IF Command 4.3 The FOR Command 4.4 The WHILE Command 5. Editing and Debugging 5.1 Line Editing 5.2 The EDIT Command 5.3 The ERASE Command 5.4 Debugging 6. System Variables 6.1 Read and Write Functions 6.2 Mathematical Functions 6.3 Call Functions 6.4 Function Parameters 6.5 Data Modules 6.6 Equipment Functions 6.7 Data Module Support Functions 6.8 Data Tables 6.9 Data Module Protection 7. Multi-computer Programs 7.1 The IMEX Command 7.2 The EXECUTE Command 7.3 The REMIT Command 7.4 The WAIT Command 7.5 An Example 7.6 Parallel Processing 8. User of Files 8.1 The Working Area 8.2 The RUN and OLD Commands 8.3 Saving Programs and Data 8.4 The LOAD Command 8.5 Task Common, the ARGs, and STRARG 8.6 The OVERLAY Command 9. More About Input and Output 9.1 The TYPE Command 9.2 The ASK Command 9.3 The $ASK Command 9.4 The IDEV and ODEV Streams 9.5 Alternative Input and Output Streams 10. More About Strings 10.1 Name Indirection 10.2 String Functions 10.3 Concatenations 10.4 The $DO Command 10.5 The $MATCH and $PATTERN Commands 10.6 Patterns 10.7 Pattern Functions 10.8 Self Modifying Programs 11. Defined Functions 11.1 The DEFINE Command 11.2 The OPEN Command 11.3 The VALUE and $VALUE Commands, ERROR Function 11.4 The Defined Function Area 11.5 Utility Commands 11.6 Recursion 11.7 Other Uses of the Defined Function Area 12. Real Time Facilities 12.1 Synchronising Interactive Programs 12.2 Scheduling Independent Programs 12.3 Some Implementation Details 13. Writing Machine Code Modules for NODAL 13.1 The Header 13.2 Parameters and Data Modules 13.3 Parameters for General Purpose Functions 13.4 String Descriptors 13.5 Working Space 13.6 Support Macros 13.7 Other Types of Module 14. NODAL Element Lists 14.1 Element Types APPENDICES 1. Line Edit Commands 2. Error Definitions 3. Example of Machine Code Module 4. NODAL Element Types 5. Function Documentation 6. Command Summary The use of function minimisation techniques for optimum design according to given performance criteria is well-known. Given a well-defined criterion and a means of evaluating it precisely, the problem reduces to choosing the best optimisation procedure to suit the problem. Direct search techniques which do not generally rely on the computation of derivatives of the error function are ideal for on-line improvement of the global accelerator performance since the error function is not known analytically, e.g. the number of antiprotons stored in the antiproton accumulator ring on a pulse-to-pulse basis as a function of all the antiproton production and stochastic cooling system parameters. The user-friendliness of the NODAL interpreter at the man-machine interaction level, its capability to easily control and manipulate equipment as well as its capability to synchronise with respect to time events on a cycle-to-cycle basis makes it suitable for an on-line accelerator performance optimisation type of application. A modular procedure, based on the Simplex technique [1] has been implemented recently which allows function minimisation depending on the error function definition module. This enables an easy manipulation of variables and synchronization with machine events. For the antiproton accumulator (AA), while the circulating beam current transformer lacks the resolution to measure the exact number of antiprotons stored on a pulse-to-pulse basis, there are a large number of electrons produced in the production process [2] and a signal emanating from these can be adapted to provide the performance criterion and appropriate parameters used as function variables in the optimisation process. First trials based on optimisation of injection of antiprotons in the AA look promising, but further work is necessary in the direct definition of the error functions. in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details Tasks that overload the minicomputers are processed on the KEK central computers. One minicomputer in the network serves as a gateway to KEKNET, which connects the minicomputer network and the central computers. The communication with the central computers is managed within the framework of the KEK NODAL system. NODAL programs communicate with the central computers calling NODAL functions; functions for exchanging data between a data set on the central computers and a NODAL variable, submitting a batch job to the central computers, checking the status of the submitted job, etc. are prepared. External link: Online copy in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details History NODAL was designed in the beginning 70's at CERN in Geneva as a flexible and easy to handle tool for controlling the SPS accelerator. In NODAL features of FOCAL and SNOBOL-4 (with some influence of BASIC) are combined. The first implementation was written in assembler for the NORD-10 minicomputer, now an assembler version for the NORD-100 exists too. Many of these computers are interconnected in a homogeneous network. Each of these nodes may be used to execute NODAL programs whereby exchange of NODAL statements and NODAL data between the different computers is possible. In the control of the new accelerator LEP other processors than for the SPS are used for which the existing assembler implementations of NODAL cannot be adapted easily. Since NODAL was found to be very useful at testing, during running-in and in all situations where flexible response was required, it was desirable to have NODAL also available for LEP. To overcome the limitations of assembler programs when adapting them to different processors it was decided to create a new version, written in a portable language. The choice was MODULA-2, since for this language compilers are available for all computers used. When designing the control system for the new GSI accelerators, the Prozessrechnergruppe was looking for an interpreter for accelerator control. Because of the portability of the new NODAL version it was decided to cooperate with CERN and use NODAL also at GSI. Extract: Characteristics of NODAL Characteristics of NODAL Contrary to other interpreters NODAL is emphasized by the following characteristics: integrated elements for access to equipment, called data-modules. parts of programs can be exported to run on another computer and results of calculations can be received (not implemented in GSI-version). output of programs and data to files (and also to other computers) is formatted uniformly. Thus it is possible to store programs and data in one file. Special features of the MODULA-2 version of NODAL are: The separation into kernel modules (processor independent) and target modules (processor dependent) eases the adaptation to different types of processors. When transferring NODAL to another processor, only the target modules like file input/output, error handling, operating system access etc. have to be modified. Actually modules exist (or are under work) for MC68000, VAX/VMS, VAX/UNIX, NORD-100, LILITH, TMS9900, IBM-PC. Execution is faster than in the previous assembler versions. This is achieved by generating an intermediate code which is used after first execution of a program. Thus lexical and syntax analysis has to be done only once which speeds up repitative parts of NODAL programs. To calculate arithmetic expressions it is planned to install a 'throw-away' compiler. pdf in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details Introduction Nodal was developed as an accelerator control language for the CERN SPS project Since then it became a very popular tool for control, at CERN but also at other large laboratories like DESY or KEK. Within the project of rejuvenation of the PS and SF'S control systems, it was decided to develop a portable version of the Nodal interpreter, written in C, which can be used on various platforms his portable version must be able to reuse program and data files of the Norsk Data version. It also must handle the remote execution between old and new versions, and between the various platforms running under different operating systems. This project was done in a large international collaboration involving CERN. Sincroton Trieste (Italy), and IHEP Protvino (Russia). Some other laboratories took an important pan in porting Nodal to various platforms. This paper will give a short overview of this portable' version. and some results and experiences gained with this product. Extract: Features of the kernel Features of the kernel The kernel uses the double precision (8 bytes) floating point type for scalar variables. and all the basic numeric scalar C data types for arrays: byte. short (2 bytes). long (4 bytes), float (4 bytes floating point) and double float (8 bytes). Strings use the C style strings (NULL ended array of characters). Global data and shared Nodal functions are available on systems which offer a shared memory service. Extra relational operators have been added to provide numerical value comparison without approximation. Asynchronous event processing capability is included in the system which provides multiplexing of input events. It can be used for dedicated services by a Nodal call back feature. This is a way to connect a Nodal block to events. This piece of code is executed asynchronously to the main flow of the program on arrival of an event This feature is used to allow Nodal to do exception processing on system interrupt signals and on normal or abnormal program endings. A minimum editing facility is provided according to the connected terminal capability. Full page editing facility is offered by an embedded call to the favorite editor of the user. A history list with navigation, save and restore capabilities. and a self learning and replay facility is available. The command parser includes processing to easily build Nodal functions with variable parameter lists. (e. g. missing parameters replaced by defaults. variable number of parameters and variable parameter types: suing, value or numerical expression). This facility is useful to build a convenient and uniform user interface to he equipment access package. A pre-parsing feature was lint introduced but then abandoned because the gain in performance was too marginal in comparison with what was gained with the hash coding technique. The various flavors of the process (interactive. network servers, file driven. OS9 file server) arc defined by option parameters in the stan command. This command can also include a Nodal command which is executed a the end of the customization. intensive facilities to view the slate of the various subsystems and internal conditions are provided for active use. Extract: ConclusionsConclusions Conclusions Nodal is still a very useful tool for accelerator control, specially for testing and protoyping. Its easy integration into various control envimnments makes it attractive to preserve knowledge and skills of people who are not professional sofware developers in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details The software system is based on the NODAL language devised at the CERN SPS. The KEK NODAL system retains main features of the original NODAL: the interpretive scheme, the multi-computer programming facility, and the data-module concept. In addition, it has the following features: (1) fast execution due to the compiler-interpreter method, (2) a multi-computer file system (3), a full-screen editing facility, and (4) a dynamic linkage scheme for data modules and NODAL functions. The accelerators are operated through five operator consoles, each of which is managed by one minicomputer in the network. An operator console contains two 20-inch high-resolution color graphic displays, a pair of touch-panels, and ten small TV monitors. One touch-panel is used to select a program and a piece of equipment to be controlled; the other is used mainly to perform the console actions. DOI in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details In this paper we present an overview of the project and the employed methods. The choice of the database management system, the implementation of the Beam Instrumentation (BI) database and its use in controls as well as the benefits of the approach will be discussed in some detail. pdf Extract: History of NODAL The original control system of the Experimental Areas dates from 1976, and it was based on NODAL programs running on NORD computers with CAMAC for equipment interface. In 1994/95 the control system was upgraded and a new system architecture, similar to the one used in LEP was introduced [1]. This architecture is often referred to as the ? standard model?. NORD machines were replaced by HP-UX workstations at the control room layer and by PCs running the LynxOS operating system on the front-end layer, leaving the equipment control layer unchanged. The large investment in hardware at the level of CAMAC and below makes the replacement costs prohibitive so that new low-level equipment control is introduced on case-by-case basis. To avoid rewriting the large suite of application programs written in NODAL over the preceding 20 years the NODAL programming environment was recreated for the HP-UX operating system. This approach has helped to replace the obsolete NORD computers, but the many, often little understood NODAL programs were left in place and this constitutes now the biggest problem for the Experimental Areas controls. The software interconnections of this system are represented at the left-hand side of Figure 1. The right-hand side represents the new software connectivity and will be discussed later. Extract: Evolution of the EA controls Evolution of the EA controls The large number of programs written in an obsolete language, the little knowledge we have about them and the limited manpower make it impossible to replace all the EA controls in one big project. Since the NODAL programs use their own data structure to store data and interact between themselves heavily, it is also difficult to replace them in an incremental way. Fortunately the project to replace the Beam Instrumentation (BI) database of connections and addresses has offered us the opportunity to slowly migrate the control system to a new environment. OO techniques employed in this project provide a infrastructure on which the new controls software can be built. Extract: The Beam Instrumentation database The Beam Instrumentation database The database of the electronics modules and their connections has been one of the most complicated pieces of software ever written in NODAL, and it represented an effort of several man-years. This database fulfils several functions in the current system. The obvious one is to keep track of used racks, crates and modules and their interconnections. There are about 5000 physical items in the database. It is also used for creating new equipment according to equipment templates. The system scans the database searching for free channels and allocates them to the new equipment. Calculating addresses of equipment is another capability of this system. Every equipment type has its own addressing program. Modules can be wired together to create a common facility, called system and system channels can be used in equipment and other systems. With about 60 equipment and 30 system types (and almost as many addressing variants) the complexity of this database was obvious. With maintenance becoming more and more difficult, the replacement of this database, responsible for the equipment address generation, became an absolute necessity but it has also been taken as a challenge and opportunity to introduce new techniques. in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details Operational aspects and control software Like all beams in the SPS experimental areas, the West Area beams are operated by a control tree program written in the Nodal language[14]. Nodal is a program language written originally for Norsk Data computers. Recently it has been emulated in C on Unix systems [15]. The control programme allows to select and monitor magnet currents, collimator positions, to move targets, absorbers, converters and dumps and to operate the beam instrumentation. It allows the creation, loading and manipulation of beam files (lists of magnet currents and collimator positions), changes of beam momentum and particle type. Many actions are available to the users, but certain actions (e.g. modification of layout descriptions, definition of beam control privileges) are restricted to the experimental area operators and/or EA physicists. The control of the X5 and X7 beams is normally restricted to the main user teams as defined in the SPS Fixed Target Programme. The H3 beam is strictly under control of the EA physicists and the experimental area operators. This is imposed by password protection on the magnet power supplies and dump and collimator motors. The only exception relates to those collimators in the H3 beam, which allow to reduce the flux on the individual secondary target of the main user in question. This facility is vitally important during changes from tertiary mode to secondary mode and vice versa. In case of tertiary mode, the H3 acceptance collimators can be left open, whereas for secondary mode, they have to be closed until the intensity has decreased to below 106 particles per SPS cycle. A special programme has been written to guide the users in this task. Whenever a user wants to take access to his experimental area, he can prepare safe conditions from his beam terminal. Once the conditions are safe, access can be granted and safety is guaranteed by the normal access interlock hardware. Every person entering the area has to take a key and keep this until he or she leaves the area. As soon as the access is terminated and all keys are back, the user can switch on the beam. Only when an area has been put in free access (i.e. access is possible without taking a key), the experimental area operators have to be involved for enabling beam conditions again after a search of the area. in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details Introduction In the 1970?s the computer control of accelerators was a very hot topic. Accelerators had progressed beyond the capability of manual and hardwired control systems, the computer was there and full of promise, but experience and software for accelerator control had not yet become available. The SPS control system was a high water mark of this period. It brought together concepts such as the touch panel from SLAC, interpretive language ideas from Rutherford, powerful (for the time) minicomputers from Norsk Data, and welded them together into a network based control system which became an example for many other control systems, notably at DESY and KEK. The problem with the SPS control system was that everything was home designed and custom built. The next generation of developers did not like this (not unreasonably) and an attempt was made to replace the custom designed elements with ?commercial solutions?. The Norsk Data consoles programmed in Nodal were replaced by workstations programmed in C. The network facilities of Nodal were replaced by Remote Procedure Calls and Equipment Databases. The Norsk Data minicomputers with CAMAC and custom Multiplex I/O were replaced by VME computers. Although each of these steps sounded good on its own, taken together the simplicity of the SPS system was lost and the 1980s? control systems were no better, and were more manpower consuming, than the 1970s? ones, despite enormously increased computer power and memory. Extract: NODAL anticipating the network computer model A Network Computer has only one piece of software on board, a Java enabled browser. This can be downloaded from the network at power-on or built-in on ROM. The SPS Control System of the 1970s used the same approach. The console software consisted of a Nodal Interpreter with built in facilities for the man-machine interaction. All other functionality, in particular all the accelerator control functionality, came down over the network in the form of Nodal interpretable code and objects. In the SPS the computer software image was loaded through the network, and for the first ISOLDE control system which was modeled on the SPS one, all the system software was in ROM (EPROM) in the CAMAC based ICC. This was similar to the first personal micro-computers where the system software and BASIC was in ROM. This has the advantage of faster response at power on with no need to load the system image through the network, and so useful network interaction can begin at once. Extract: Applications Programming and NODAL Applications Programming. In the late 1960s the first attempts to harness the potential of computers for accelerator control foundered on the so-called ?Software Barrier?. In the 1970s people became very aware of this problem and for the SPS the solution was Nodal, an easy to use interpretive language. This was successful and a wide range of accelerator personnel were able to program their knowledge into the control system. In the 1980s a new generation of control personnel appeared who had not lived through the experience of the ?60s and were entranced by the power of the workstation. They therefore launched into applications programming in C as the latest in software technology. This resulted in many problems and large teams of programmers had to be employed to produce the code, which was often not what the accelerator specialists would have produced, especially experts such as Nobel Prize winner Simon van der Meer who was also an expert Nodal programmer. Extract: Demise of NODAL The final nail in Nodal?s coffin was our inability to keep up with user expectations concerning such support facilities, on-line help etc. That is why it is so important to latch-on to a successful standard such as the Web. Extract: NODAL and JAVA Java and the Interpretive approach The above approach is very powerful and Microsoft is promoting it strongly as ?ActiveX?. There are some problems, however, including the need to register the OCX control, the security problem of loading a binary into your computer, and the size of the binary. An interpretive approach to network computing was used in the SPS control system to surmount these and other problems, and the result was the Nodal system for the SPS (reference 4). The interpretive approach has now been re-discovered, and the hottest item in computing today is ?Java and the Web?. The interpretive approach has advantages for the user and for the system. For the user the advantages are an easy interactive approach to program development and a simpler language. For the system the advantages are the security offered by the interpretation, sometimes called running in a ?virtual machine?, and the network transferability of the code. The requirements for an interpretive language do not exclude compilation. In fact ?Just In Time? compilers for Java are already available whereas it took us from the SPS to the AA, five or six years, to get the ?Nodiler? for Nodal into operation. The important thing is that an applet running over the network must be self contained, must need no parts pre-loaded into the target computer and must leave no parts behind. The network transferability of code can be illustrated by the following example from the Nodal Manual. 1.1 WAIT-CYCLE 6 1.2 FOR I=1,6; EXECUTE (I) 2 1.3 DIMENSION A(108) 1.4 FOR I=1,6; WAIT (I); FOR J=1,18; SET A(18*(I 1)+J)=B(J) 1.5 EXECUTE(DISP) 3 A 1.6 GOTO 1.1 2.1 DIM B(18) 2.1 FOR I=1,18; SET B(I)=HPOS(I) 2.3 REMIT B 3.1 SET ODEV=15; CLEAR; HISTO(A) Line 1.2 shows how group 2, an interpretive applet is sent to each of computers 1 to 6, the so-called General Purpose computers at each of the SPS?s six access points. In the remote computer the code is interpreted and the work done. Line 2.3 shows how the data is sent back. B is an object, in this case an 18 element array, but it is self-contained. It consists of a set of bytes containing its size, type, number of elements and then the data, so that it can be interpreted in the client computer on arrival. This example also shows parallel execution of the remote code, also a feature of Java. Why develop a new language? Of all the myriad languages that have been devised to program computers relatively few survive, and popular wisdom holds that we need a new programming language like a hole in the head! The same was said in 1972 when we started with Nodal, although there were many fewer languages then. Nodal was developed from Focal, a DEC language for the PDP 8 (now we are on a history lesson!). It was necessary to ADD so many features that we gave it a new name which reflected its network capability. In the case of Java the opposite was the case! It started with C++ with its good things such as objects, but they had to SUBTRACT the things which could not be interpreted (and which made it bug-prone), such as pointers. Interpretive languages tend to be simpler as the interpreter must be resident and ready to handle any language construct, whereas compiled languages can be more complicated as no code will be generated if a language construct is not used. The result is that Java is simple and compact, yet powerful and object oriented. In my opinion, as a neophyte in the matter, it well justifies the hype it is experiencing at present. A language can fail, despite its beauty, if there is not enough effort put into its support environment. This was the final end of Nodal and the PS developed language P+ at CERN. Even Pascal and Modula 2, also invented in Switzerland though not at CERN, are suffering from this problem. There are alternative approaches to bringing life to Web pages, for example Netscape's plug-in technology, Microsoft's ActiveX which is based on downloading OCX?s, and Oracle?s network loadable objects for database access. None of these use the interpretive approach, however, with the possible exception of Oracle?s PL/SQL, nor do they enjoy the simplicity and power of the Java object oriented language. I would say that Java will make it. The biggest assurance for me with Java is that Microsoft have produced Visual Java ++ with all the goodies of Visual Basic and Visual C++. Microsoft?s Internet Explorer 3.0 is fully Java enabled, and all the signs are that Microsoft will absorb it rather than fight it. It is interesting to note that Java, like Nodal, started life as an equipment control language and system. It was originally intended, by its development team at Sun Microsystems, to allow a large, distributed and heterogeneous network of consumer electronic devices to talk to each other and coordinate activity. Ideally every device in the network could communicate with every other, for example the television could turn the kettle on when the favorite program is near to the end. There was no intention to release the language for general use. When the Internet ?exploded? with the World Wide Web the Java team realized their product was ideally suited to the new environment as it would allow executable content to be distributed over the Internet. Java has become so successful that Sun hope to move it back into its original on-line use. Sun is predicting that their software sales of on-line control type Java based software will contribute more to their turnover than server'sales by the end of the century. If this happens then maybe in accelerator controls we will see Network Computing spreading even below the control system into the equipment itself. in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details pdf Extract: Use of NODAL in TRISTAN Use of the interpreted language in an accelerator control system is not a new idea. TRISTAN, predecessor of KEKB, control system used NODAL language developed at CERN for its control system. Nodal language is a BASIC like interpreted language designed for a control system. One of its unique features is a remote execution of Nodal program within a program. As shown in a sample program, Figure1, a NODAL program can send a part of itself to the other computer and can get a result of execution in the remote computer.This function can be used to access resources only available at the specific computer. It can be also used to reduce data transfer overhead in some cases. This ability should be compared with the today?s network agent technologies. in Nuclear Instruments and Methods in Physics Research Section A: Accelerators, Spectrometers, Detectors and Associated Equipment Volume 247, Issue 1 , 1 June 1986 view details Resources
|