Feedback Measurement API Discussion

The Feedback Measurement Application is a new software application that will run in each Measurement IOC. It is responsible for collecting the measurement data from the 120Hz measurement devices controlled by the IOC, and providing it to the Fast Feedback network layer, to be sent out on the FF network.
It is a design goal that this Measurement application encapsulates knowledge of the Feedback System, so that the network layer does not.
It is a design goal that adding or removing a device to the fast feedback system will not require that ALL feedback IOCs to be rebuilt/rebooted. It is ok to require rebooting the IOC whose total number of devices has changed.
We have a basic design where the Measurement App collects measurement data from the device pulse processing, and provides that data to the network layer, likely via some shared memory area. The network layer sends that buffer of data out within a timeout period.
The following ideas were proposed:We need an initialization routine that creates a static 'hash map' in shared memory area, mapping device name to data location, including space for all 120Hz devices under its control, and possibly including extra space for future additional devices. The list of devices is a configuration item that can be changed whenever a measurement IOC is rebuilt/rebooted.
the Measurement App initializes a timeout value for the network layer to use. The network layer will send the current pulse measurements out by the end of this timeout period. If a device has not measured before the timeout is complete, that device data will be missing.
It is proposed that the measurement IOC outputs data from all 120Hz devices it controls, whether or not the device is currently used by a feedback
Still to be discussed:measurements are output on every pulse with LCLS timeslot? only pulse with beam?
when beam is deflected should devices downstream still send measurements, with quality adjusted?
when a device ACCESS is not 'running' should it still send measurements? with quality adjusted?
NEW: it is a design goal that the measurements can go out on Channel Access and/or the fast feedback network, depending on the needs of the feedback (the slower Launch Feedbacks may work fine with Channel Access only) Can this be implemented in this middleware layer?
So far we have a Measurement App basic logic flow:

  1. initialize data area, timeout period
  2. on each pulse
    1. for each device get measurement, timestamp, and quality (callback from monitored PVs?)
      adjust quality if necessary (see above)
      calls Network.putData(measDevice, data) //information in data includes value, quality, timestamp/timeslot
      Alternatively,
  3. initialize data area, timeout period NEW CA or FF choice?
  4. on each pulse
    1. for each device

get measurement, timestamp, and quality (callback from monitored PVs?)

adjust quality if necessary

place data in array # calls Network.putData(measDevices, dataArray) //array of data, one call

The network layer will send this data out when data area is filled or at timeout
so far we have a proposed Feedback Measurement IOC <-> FF Network Interface APIinitialization - Measurement app calls Network.createDataArea(devices)
initialization - Measurement app. calls Network.setTimeout(timeoutValue)
Measurement app. calls Network.putData(measDevice,data) once for each measurement device, on each pulse
OR, measurement app. calls Network.putData(measDevices, data) array of devices and assoc. data
information contained in data includes measurement value, quality, timeslot/timestamp

  • No labels