1 / 16

Developing the control system for the 40m OAN radiotelescope with ACS

Observatorio Astronómico Nacional P. de Vicente October 2005. Developing the control system for the 40m OAN radiotelescope with ACS. Developing the control system for the 40m OAN radiotelescope with ACS. The OAN has 50 people in 4 different sites: 20 engineers and astronomers. Present status.

phoebe-sykes
Télécharger la présentation

Developing the control system for the 40m OAN radiotelescope with ACS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Present status

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related