Previous: Hardware
Up: Control hierarchy
Previous Page: Hardware
Next Page: State of the Union

Software

The top levels of the software run on the observer VAXstation, as tasks started up under the ADAM real time monitor (which is programmed in FORTRAN, has FORTH-like structures incorporated and runs under VMS/Windows).

The high level ICL commands (or sequences of ICL commands executed as ICL command files) are passed to the ADAM Cd and D tasks (one Cd task for the complete facility, plus one D task for each local processor involved). These ADAM tasks, after checking the formal existence of the command, its syntax and the parameter range, translate it into the string required by the destination microprocessor. The D task adds Ethernet code for source and destination, and passes it to the NIU for transmission. After Ethernet transmission, the destination NIU extracts the bare message and passes it to the required local controller (4MS or such). After more syntax and parameter checking, the local controller activates the mechanism hardware in one way or another, and monitors for completion. During all this time, the VAXstation, through its MIMIC task, shows the component status as `undefined' (i.e. in white, at the old or an intermediate position) on the MIMIC screen (any explicit `immediate status request' at this stage will also return `undefined' status and have the same effect on the MIMIC screen).

The usual practice is for the D task to issue a `delayed status request' for the component with every `move' or `initialise' command. This causes the local controller to return an Ethernet status message, but not until after the component has arrived at its target. The NIU and D task pick up this status return, the Cd task updates the component status in its table and the MIMIC task detects this status change, causing it to show the component in green on the MIMIC screen, at its new position.

All of this is in asynchronous operation, the process will take as long as is necessary for the mechanism concerned (plus an overhead of seconds for all the message-passing). All mechanisms or functions in all local controllers are accessible simultaneously, subject to traffic density on Ethernet. Any errors detected (such as timeout or communication error or parameter out of range) are reported all the way up, ending with the component shown in red on the MIMIC screen; an `immediate status request' at that point will usually inform the observer about the nature of the error (though not always about its cause).

Where speed is critical, there are special solutions, in hardware or in software. However, the above is the basic principle and it works, for those who are prepared to wait. The price of flexibility is sluggishness, but much of the `lost' time is recovered by the observer-proofness of the whole arrangement.

Most of the local controllers work in one FORTH dialect or another; this makes them powerful and fast, but the programmes are difficult to read and service. One hopes never to have to reprogramme 4MS, SMDM, Autoguider VME, CCD controller and such; this would require inhuman foresight on the part of their designers and in fact modifications are needed every few years as new applications emerge from development. For ease of adaptations, the software in most of these systems is based on a table of permitted functions and parameters, and a status array which faithfully reflects the real-life equipment. An excellent description of this RGO FORTH kernel is to be found in the ISIS 4MS manual ER 422.



Previous: Hardware
Up: Control hierarchy
Previous Page: Hardware
Next Page: State of the Union


Mon Mar 14 16:50:31 GMT 1994