1 / 12

ALMA Control SW & ACS

This document presents an overview of the physical layout of the Monitoring and Control (M&C) network for the ALMA project, including its characteristics such as a 1 Mbit/sec data rate and a maximum cable length of 35m. It discusses the architecture used in the ACS course held from June 22 to July 3, 2003, in Garching, Germany. Key topics include the "bag of properties" paradigm, Interface Control Document (ICD) definitions, monitor/control point implementation, and the usage of specialized device I/O classes for deterministic communication and automatic device discovery.

amato
Download Presentation

ALMA Control SW & 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. ALMA Control SW & ACS Ralph Marson (NRAO)

  2. Physical Layout of the M&C network ACS Course, June 22 – July 3 2003, Garching, Germany

  3. AMB Characteristics • 1Mbit/sec data rate • Leads to a theoretical maximum cable length of 35m • 29-bit addressing • Split into 11-bit (2048) node address and 18-bit (256k) monitor/control point address • Broadcast mechanism and serial numbers allow automatic device discovery and identification. • All hardware devices are passive and only speak when requested (response in 150 micro-seconds) • This leads to deterministic communications. ACS Course, June 22 – July 3 2003, Garching, Germany

  4. Control SW use of ACS • Uses the “bag of properties” paradigm. • Begins with an Interface Control document (ICD), which is a binding agreement describing the M&C interface of the hardware (next two slides). • Assign one or more properties for each monitor or control point (show slide) • Implement each property, perhaps using a customized device IO classes. (show C++ implementation). ACS Course, June 22 – July 3 2003, Garching, Germany

  5. Name Relative CAN Address (hex) Data Size (bytes) Sugested Interval (secs) Timing Event related? GET_COMP_STATE 0x0 00 06 1 300 No GET_CONTROL_BOX_TEMP 0x0 00 13 2 300 No GET_CROSSHEAD_CURRENT 0x0 00 08 2 300 No GET_ELEC_CAGE_TEMP 0x0 00 12 2 300 No GET_FAN_AIR_TEMP 0x0 00 10 2 300 No GET_FAN_MOTOR_TEMP 0x0 00 11 2 300 No GET_FRIDGE_DRIVE_STATE 0x0 00 07 1 300 No Table 1: Summary of Monitor Points Monitor Point description (summary) ACS Course, June 22 – July 3 2003, Garching, Germany

  6. Monitor Point description (details) 4.6.1.1 GET_COMP_STATE Relative CAN Address0x0 00 06 DescriptionGet current state of the helium compressor system. On power up or when power is cycled, the helium compressors will be in a state determined by a front-panel switch. This monitor point returns that state, independent of the SET command of the same name. Suggested Interval300 secs TE RelatedNo Data1 byte: (ubyte) bit 0: 0 -> The compressor is off 1 -> The compressor is running bits 1 – 7: Unused and always set to zero ACS Course, June 22 – July 3 2003, Garching, Germany

  7. IDL file #include "enumpropMACRO.idl"#pragma prefix "ALMA"module ticsFECOMP { // A baci enum for compressor and fridge drive states enum DriveState { DISABLED, ENABLED }; ENUM(DriveState); interface Fecomp : AMBSI::AmbsiNode { // hecomp-specific monitor points readonly attribute RODriveState get_comp_state; readonly attribute RODriveState get_fridge_state; readonly attribute ACS::ROpattern get_status; readonly attribute ACS::ROdouble get_gm_return_pressure; ACS Course, June 22 – July 3 2003, Garching, Germany

  8. Constructor Example1::Example1(PortableServer::POA_ptr poa, const ACE_CString& name) :TICS_Device_i(poa, name) { // getExampleStatus property getExampleStatus_mp = new ROpattern(name+":getExampleStatus", getCOB()); ACSDO_PROPERTY(getExampleStatus, getExampleStatus_mp); // getPowerState property Member function ACS::ROpattern_ptr Example1::getExampleStatus(CORBA::Environment& ACE_TRY_ENV = TAO_default_environment ()) ACE_THROW_SPEC ((CORBA::SystemException)) { if (getExampleStatus_mp == 0) return ACS::ROpattern::_nil(); ACS::ROpattern_var prop = ACS::ROpattern::_narrow(getExampleStatus_mp->getCORBAReference(), ACE_TRY_ENV); return prop._retn();} ACS Course, June 22 – July 3 2003, Garching, Germany

  9. Include class fecompState: public devIOCAN{public: fecompState(const ACE_CString & name, ambSimpleCANNode *Node) : devIOCAN(name, Node) {}; virtual void writePattern(long value, int &errcode, unsigned long long &timestamp); virtual long readPattern(int &errcode, unsigned long long &timestamp);}; ACS Course, June 22 – July 3 2003, Garching, Germany

  10. Implementation long fecompState::readPattern(int &errcode, unsigned long long &timestamp){ unsigned char uch[8]; int data_len; errcode = m_Node->Read(m_RCA, data_len, uch, timestamp); if (uch[0] == 0) { return ticsFECOMP::DISABLED; } else { return ticsFECOMP::ENABLED; }} ACS Course, June 22 – July 3 2003, Garching, Germany

  11. Device communication • Uses a specialized Device IO class (devIOCAN) • Derive a specific class containing custom conversions or status bit interpretation. This leads to many small classes and a lot of code duplication. ACS Course, June 22 – July 3 2003, Garching, Germany

  12. Demo of objexp & antMount GUI ACS Course, June 22 – July 3 2003, Garching, Germany

More Related