[Gb-ccb] suggested changes to ccb library

[Brian Mason]

Martin Shepherd writes:
 > 
 > 
 > On Mon, 11 Aug 2003, Brian Mason wrote:
 > >  a) reordered error messages: not a *requirement*, just something
 > >  that would be really nice. This will help us "throw out" (actually,
 > >  send to a log file, rather than our message system) messages of the
 > >  sort that we don't normally have in the message system.
 > 
 > An alternative that I would prefer would be to include another
 > enumerated argument with the log messages, specifying their type. I
 > would imagine that this would be easier at your end too. Would this be
 > acceptible?

Melinda can comment here...

 > 
 > >  b) a simulation mode of the actual ccb server; the goal here is
 > >  to have as much of the code as reasonably feasible be identical
 > >  between the simulation and the real thing. Again not an absolute
 > >  requirement, but something which we believe will pay off.
 > 
 > Agreed.

Great

 > 
 > >  c) possibly, we would like to use the "scan control bit" which is
 > >  in the device interface, to control scans. We currently have
 > >  proposed a somewhat awkward mechanism in which the manager secretly
 > >  starts a scan just before a real scan (outlined in draft form in
 > >  the use cases Melinda and I wrote some time ago). Currently i believe this
 > >  bit is not accessible via the server, ie, the server interface hides
 > >  this bit and manipulates it itself (possibly for very good reasons:
 > >  we don't know, and would like to discuss it).
 > 
 > This bit needs to be toggled at precise instants that can only be
 > achieved by real-time interrupt handlers, so it would make no sense
 > for the server to have access to it. This is also only one of many
 > control bits, all of which need to be toggled with real-time
 > precision.

I see...

 > 
 > Could you tell me what the problem is that you are trying to work
 > around? Since new configuration information doesn't have any effect
 > until a new scan is started, I can't imagine a situation where one
 > might need a dummy intra-scan.

The issue is that a new scan can't start until the current integration
is done. Potentially this is a longer delay than we want.  I believe
we determined this by working through one of your (or Yamasaki's?) old
state machine diagrams and are not sure if it's still true given
revisions to the design.

In any case we *do* have a work around and it sounds like we should
let this one lie.

 > 
 > Beware that the internals of the device driver are liable to change
 > significantly, now that I am doing the hardware. The server interface
 > that I have provided to you is supposed to insulate you from those
 > changes, so if something in the server interface can't accomodate your
 > requirements, then I need to fix it at that level, without explicit
 > reference to the specific device-driver/hardware implementation.
 > Thinking about, and specifying server changes in terms of
 > hardware-level implementation details, such as the start-scan bit,
 > isn't a good idea.

Ok.

One thing which would be useful is to check my old draft "use case"
document against the current server interface. I'm not sure how much
the interface has changed.

 Brian

 > 
 > Martin

-- 
--------------------------------------------------------------------
Brian Mason                           | office: +1(304)456-2338
Assistant Scientist                   | fax:    +1(304)456-2229
National Radio Astronomy Observatory  | mail:   PO Box 2
bmason at gb.nrao.edu                    |         Green Bank, WV 24944
http://www.gb.nrao.edu/~bmason/       |
--------------------------------------------------------------------