NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC82003 > GrailStatus

Changes | Index | Contents | Search | Statistics | Go

Grail Status Notes

NOTE: All items marked 'Done' are completed, but have not been signed off by sponsor. I intend to do this as soon as convenient.

SOAP 1: Interface to Samplers

Done. Samplers can be started and stopped. Once started, samplers can be polled for values. If the sampler is polled having not been started, the client is informed of the error. Paul has written a client in Java that is callable from Matlab and successfully retrieved sampler values with it.

SOAP 2: Serialize Parameters

Done. I have set up a hierarchy of gSOAP classes that can represent any Ygor parameter. The Ygor parameter is encoded by a recursive algorithm that is part of a ParameterToSoapVisitor class based on the Grail Parameter::Visitor class. This way, Parameter has no need to know about SOAP serializing. Currently the visitor can encode:

• Simple types
• Structures
• Enumerations
• Strings
• Static Arrays (of both simple types and structures)
• Dynamic Arrays (of both simple types and structures)

On the Python end, SOAPpy decodes it into SOAPpy structure and array types. It is not too difficult to figure out their structure. A simple example is the 'state' parameter of a manager. This is the familiar 'Ready', 'Off', 'Standby' etc.

>>> p = cl.get_parameter(dcr, 'state')
>>> for i in p:
...     print i
...
state
current operational state of Manager
<SOAPpy.Types.typedArrayType field at 17206464>
872415243

>>> for i in p[2]:
...     print i
...
{u'units': 'None', u'type': 'enum', u'name': 'state', u'value': 'Running', u'description': 'current operational state of manager'}

Both parameter fields and parameter array elements are encoded as array elements in the SOAPpy types. Each parameter has at least one top level field. If the field is a Plain Old Type (POD), the 'value' element will be in there, with the actual value encoded as a string. If the field is itself a structure, then the 'field' element will be there instead, and there will be a SOAPpy.Types.structType object associated with it. It (the field structure) may contain more fields or array elements, which can be PODs or structures, and so on.

SOAP 3: Connection Reliability

Done. When a manager goes down, Grail knows to reconnect. However, there are actually two aspects of the connection: Controlling and receiving. The control side was reconnecting, but not the recipient. This led to many of the problems being seen where the configuration tool does not reconfigure some manager. The sequence of events went as follows:

1. The manager goes down or is reset.
2. Grail loses connection
3. Grail's copies of the manager's parameters are all in the last state the manager was in before it went down.
4. The manager comes back up and Grail's PanelRemote reconnects, but does not register the recipient.
5. New manager no longer has RPC program number to Grail's recipient server, and does not have any parameters registered. Thus it is incapable of updating Grail, and manager's state no longer matches what Grail thinks it is.
6. Same config as before gets sent. Grail compares new parameter values to its (now outdated) copies and thinks parameters are already set, so doesn't set them. Config tool thinks configuration was sent, but manager never gets it.

I solved this by using the PanelRemote::setRecoveryMethod(), whose purpose it is to do handle just this sort of problem. setRecoveryMethod() sets up a callback function that gets called when connection is re-established. This callback function then can set about to reregister the recipient, register parameters, and get fresh copies of all registered parameters. I have tested this with the ToyTelescope Undulator manager. I could reproduce the problem before the fix, and I verified that the system works properly after the fix.

SOAP 4: Callbacks

In progress, just started this one.

SOAP 5: Parameter Details

Done. See SOAP 2 for details; SOAP 2 and SOAP 5 are all one.

SOAP 6: Mgr Commands

Done. All manager commands supported by PanelRemote can be called directly or indirectly through Grail.

SOAP 8: New Name and CVS

Done. ScanExecutor is now Grail. The CVS path is ygor/user/Grail. Grail needs libraries from Ygor to compile, so the rest of the Ygor tree should be up to date, particularly the ygor/libraries/Util directory, where I have added some general purpose classes that I use in Grail.

NOTE: Grail has been set up to be compiled with the cross-compiler. However, a strange situation occurs when this is done: Some static string arrays in the Ygor DataType class, while there (the linker does not complain of their absence), appear to be inaccessible. On accessin an element one gets a null pointer, not a string. Compiling on a Solaris machine with the default g++ for Solaris results in correct behaviour. Until Grail is ported to Linux, or the cross-compiler is fixed, we will have to manually compile and install Grail at each release. This problem possibly is caused by the cross-compiler being set up for Solaris 2.6.

SOAP 9: Fix consecutive configuration fault

Done (for now). When Grail received configurations while the Spectrometer was still 'Activating', some part of Grail threw a std::exception, causing the program to terminate. I still don't fully understand this problem; however, ensuring that a device is in 'Ready' before sending the configuration to it avoids the problem. I have adopted this temporary solution until I can understand the real problem.

SOAP 10: Add security

Not started yet. Grail currently can fully control every M&C manager, but has no security mechanism in place to prevent misuse. A short term solution is to add the current Gateway capability to Grail, while a more comprehensive and trully secure solution is studied. This may not occur this cycle.

-- RamonCreager - 03 Nov 2003