MOOC Wish List

 MOOC

  • Multi-threaded
  • 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 CORBA.
  • 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 method
  • 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 devices easier.
  • 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 not.
    • extends beyond the

    Security, Privacy, Legal