Developing the control system for the 40m OAN radiotelescope with ACS Observatorio Astronómico Nacional P. de VicenteOctober 2005

The OAN has 50 people in 4 different sites: 20 engineers and astronomers Developing the control system for the 40m OAN radiotelescope with ACS

Present status

Near term expectations Panel adjustment and subreflector alignment: End 2005 Mirrors and vertex: January-March 2006 Tests by MAN & BBH: April – May 2006 Delivery: Late spring First cooled receiver: Summer 2006 Commissioning by OAN: Summer >....

The Antenna Control Unit The ACU is composed of 2 CPU's: 1 Windows XP PC, 1 Motorola board on a VME crate. Windows XP + TwinCAT (real time extension) The ACU is commanded using TCP sockets. ACU interface almost finished. ACU simulator delivered recently. 80% functionality for the main axis

Why ACS? We need to manage a distributed system in almost real time. We want to work with free software CORBA has a steep learning curve. Software team for the 40m radiotelescope = 1.5 FTE.

Why ACS? ACS hides the CORBA complexity to the developer. ACS is used by other telescopes. Supports the languages we know: C++, Java, Python. Its lifetime matches that of the 40m OAN RT It is supported by an stable team of good developers.

Our experience with ACS First ACS installation in November ACS is installable in non-official Linux distributions (i.e. Debian) Self learning + unvaluable help from the users mailing list. Consequence of self learning: need to rewrite some components to include services provided by ACS not included in the first version of our code.

Our experience with ACS Component-Container paradigm implementation fits our needs. Good tools for debugging: logging system (?) Components already developed: ACU, Weather station, RF Synthesizer, Downconverter, Temperature probes, Optical focuser, Ephemeris Tipical development time for 1 simple component: 3 days.

Our experience with ACS Tipical development process: – write pure C++ class – write XML with error exceptions – create IDL (and include exceptions) – run the HPT code generator – Fill in the implementation – Compile and run

Our experience with ACS... – Test with the object explorer + jlog – commit the code to our CVS – create a client – test the client

What do we expect from ACS? We do not know if we are developing in the right way: We have many questions (logging system, archiving, error system...) We need to see more examples fully functional including clients in Java and Python. We would like more documentation and more complete.

What do we expect from ACS? We would like non-ALMA ACS users to commit their code to the CVS contrib area: the code can be reused. we can learn from the code even if we cannot reuse it.

What do we expect from ACS? Generation of code. (HPT code generator is really useful). Simulation of the behaviour of components. ACS takes too much disk space. Splitting of ACS into smaller packages. Installation of clients on DHCP hosts

Do we contribute? ACS installation in Debian and Ubuntu. We generated some feedback. Some components (5) haven already been uploaded to the CVS contrib area in ESO. We intend to commit more components in the future. We take part in the user's mailing list.

Final remarks ACS fits our needs. We have not learnt CORBA. It is well supported by a team of people and probably will have a long term life. Automatic generation of code is necessary: it reduces the coding time and error typing. We would like to see code from other people using the ACS.