MOOC Wish List
Use standard technologies - C++
Front-ends subscribe to dbnews to automate the downloading of
persistent data from database
Eliminate proprietary protocols, ACNET, RETDAT, et. al. Have front-ends
service RETDAT, FTPMAN, et. al. interfaces using CORBA. The principle
benfit here is this provides a migration path from RETDAT, et. al., to
Use new cross-platform ACNET API currently being developed
Improve code quality - eliminate compiler warnings, eliminate accessing
of out-of-bound array elements, reduce use of casting
Make object instantiation simpler - allow subclasses to initialize inherited
class instance variables by calling the inherited classes initialization
Make accessing inherited instance variables simpler - subclass must currently
now how an object is laid out in memory, so that they can do the required
pointer arithmetic to locate inherited instance variables
Use more efficient algorithms and data structures
Allow an interrupt-driven vs. polled alarm scan.
Allow the polling rate of a polled alarm scan to be configured on a per
object or per class basis.
Good documentation - both a User's Manual and a Design Manual. The
Design Manual would explain design decisions and MOOC internals.
It would be intended for maintainers of MOOC. This documentation
should be on the WWW.
Linking with mooc should be easy - just include a single header file, say
mooc.h, and link with the appropriate mooc library, e.g., libmooc68k.a
or libmoocppc.a. MOOC should be under the CVS revision control system and
should exist outside of individual users home directories.
Allow more than 256 channels
Mixed data types in classes for alarm handling
Allow end-users, e.g., operators and techs, to add hardware to crates
without front-end programmer involvement. (This is possible with
the current MOOC.)
Allow front-ends to have knowledge of when an acnet setdat/retdat request
list is being processed, so that a front-end can "lock" a hardware resource
while the list is being serviced. This would allow a front-end
to insure that the requests in a list are not interleaved with other requests,
assuming there is some means to lock the hardware in question. This
is intended to meet the beamline swics need to "lock the branch", where
multiple front-ends can service a single item of hardware.
Insure that entries in a retdat/setdat request list are processed in sequence
and without other requests (to the same front-end) being interleaved.
This is also intended to meet the beamline swics need to lock the branch.
Identify objects by a device index instead of an oid encoded in the SSDN.
Since a device index (di) is an arbitrary integer that does not supply
any information, the front-end will need a mechanism to determine details
about a device, e.g., device type, device address, and channel, given a
device index. Currently, this is done by encoding such details into the
SSDN which is sent to the front-end along with the (ignored) device index.
The device details must be decoded from the SSDN and checked for errors
for each method invocation. Since the SSDN is fixed for a given property
and device, this decoding and error checking of the SSDN does not need
to be done for each method invocation. The SSDNs for each property could
be decode and error checked just once when the device/object is constructed.
The information obtained from the SSDNs at instantiation would be used
to initialize the object's instance variables. Eliminating the SSDN decode
would speed up method invocation. Ideally the front-end would obtain the
SSDNs for each device it services directly from the database when it boots
or when a device it services is added, deleted, or modified. In addition,
if the device/object need more device details than could be fit into an
SSDN such details could also be obtained from the database and passed to
the constructor. Additional database tables might need to be created to
hold these constructor arguments and DABBEL would also need modified. Allowing
more device details than can be fit into an SSDN makes it easy to deal
with devices that have more than 256 channels or say digital I/O devices
that need large bit masks and shifts that can not fit into an SSDN. MOOC
would need a means of locating an object in memory based on its device
index, presumably a hash table. Perhaps the SSDN could be eliminated altogether.
Using the device index with a hash table instead of an oid with a static
array in kernel.c eliminates the oid range limitation. It may
be that the correspondence between oids and device index is not 1 to 1.
Every device/device index will be associated with a single object /oid.
But a single object /oid may be associated with several devices/device
indices. The many devices to one object case would be used for hardware
objects. Two devices with same hardware address would reference
the same object. The single object to single device case could be
used for software objects.
Allow a class to have a class method which would do an alarm scan of all
of its instances. This could improve performance when "economies of scale"
can be realized by alarm scanning a class at a time rather than an object
at a time. For example suppose one has a 32 input digital input card in
which the input statues are read as a single 32-bit integer and that one
creates a device for each bit. The reading methods for the devices would
each read the input status and pick out the appropriate bit. Therefore
an alarm scan cycle on an object basis would access the hardware 32 times.
But if an alarm scan cycle was done on a class basis one could read the
input status just once and then check all bits in the status. Thus the
alarm scan cycle on a class basis eliminates 31 reads of the hardware.
Utility or something that generates DABBEL templates from C++ class declarations.
Or even something that actually adds devices to the database. Is there
enough information in the source code to do this? More generally make adding
Some mechanism to gather a consistent collection of "aggregate" or "correlated"
data. Want to avoid situation where data is collected during a discontinuity
in the machines operational condition, e.g., with and without beam.
If two consoles request device property data for the same device on the
same event would like them to receive the same value. Apparently this is
not the case now, since the front-end will get two separate RETDAT requests
and MOOC will call the objects reading method twice, once for each each
console, instead of calling the method once and returning the single value
to both consoles.
Create or allow one to create classes which use different access methods
depending on channel. For example, if a front-end has two different
analog input cards - one with 4 and the other with 8 channels - the programmer
may want to present them as if they were a single object with 12 channels,
instead of as two distinct objects. Since the hardware is different
the programmer, may want to write two different access methods, one for
each card. The appropriate method is chosen based on the channel
number. (This is Charlie's "general purpose class" concept.)
If can/do not support database based instantiation, have startup-script based instantiation.
Support for multiple alarm blocks. Some means to select current alarm block.
A method for changing alarm blocks should be provided. The front
end code could select different alarm blocks as its state changes. How could
something outside the front end select the current alarm block?
Hide network representation from MOOC users. Allow users to specify the
structure of their property data, and MOOC will perform the required
manipulations to convert between native and network
representation. For example, for basic control the user could specify that
the data size was 4 then MOOC would swap even and odd (2-byte) words with
each other on a big-endian machine, if the user specified a data size of 2,
MOOC would leave the data alone on a big-endian machine. This method will
have some run-time overhead. Another possiblity is to present data to user
in network representation but provide inline functions to convert between
network and native representations. This method is more subject to error
since a user must remember to use the functions for all accesses rather than
just specifing the properties structure once in the constuctor, but it
elimates runtime overhead. Since one only converts what is actualy used.
Also in the case of the basic control attributes one is converting the constant
attribute to network representation at compile-time rather than converting the
non-constant SETDAT data to native represenation at run-time.
FE-to-FE communications.(IRMs do this)
Mechanism for allowing contributed code, like IRM's local and page applications.
15Hz corrolated data, for IRMs.
Front Ends in General
Allow front-end programmers more control over front-end configuration and
architecture - priority of supporting tasks, e.g., ACNET and MOOC tasks,
startup sequence. Allow the programmer to opt out of support for FTP, alarms,
etc. Inient() would have configuration information passed to it. Such information
would include what hardware is being used to decode TCLK and what protocols
are to be supported. To reduce the memory footprint inient() would load
code dynamically on an as required basis, using VxWorks loadLib. Dynamically
loaded support modules would use the GNU C++ compiler's attribute keyword
to have their initialization and deinitialization routines executed when
they are loaded. Dynamically loaded modules could reference symbols in
previously loaded modules with correct link options. Dynamically loaded
modules would need to register with previously loaded modules, if the modules
need to interact in some way.
Improve how informational and error messages are indicated - synchronize
messages, allow user to select what type of things are logged, allow messages
to be redirected over the network
Handle RETDAT and SETDAT requests in order received on network. Use
a single queue, instead of two queues. This would require modification
of ACNET on front-ends, and perhaps a change to the ACNET API.
Control System in General
Streamline alarm block download - direct access to database from front-ends
(java applet? onc-rpc?)
Change length and offset to 4-bytes from 2-bytes
Eliminate FTPs dependency on the TCLK 02 event. Need a timestamp which
specifies the time since some t=0 event, instead of the time since the
last TCLK 02 event.
Implement FTD plus delay and/or custom software event data collection.
Could extend RETDAT or use additional bits of event FTDs.
Handle odd-byte lengths better. Currently, MOOC rounds odd-byte requests to
the next byte. This means a request may be given to the user-supplied methods
which would fail a bounds-check although the actual request on the wire would
extends beyond the
Security, Privacy, Legal