Developing the control system for the 40m

OAN radiotelescope with ACS

Observatorio Astronómico Nacional

P. de Vicente October 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 2006.

First cooled receiver: Summer 2006

Commissioning by OAN: Summer 2006 -> ....

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 2003.

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.