EPICS Limitations

1
EPICS Limitations

• Bob Dalesio
• Marty Kraimer

2
Limited view point

• These slides are written from a limited
  perspective
• Many people could and should add the limitations
  that they encounter to this.
• It is a collaboration and that is an invitation
  to voice what is wrong (and volunteer to fix some
  of it)

3
There is no device abstraction in the database

• What are devices?
• Power Supplies w Magnets
• Scope
• What are the properties
• multiple inputs and commands
• states taking data, ramping, turning off
• multiple status bits over temp, on/off etc.
• Does each command and status become a channel
• Does the value / status fit the command / state
  model
• Does a device use channels for interfaces to hw
• Does a device disallow control of output channels
  it use
• Marty is working on a new database to overcome
  this.

4
System Limitations

• The database can process as many as 100K records
  per second in the new power PCs faster
  processors.
• But, the fastest response time to an interrupt is
  on the order of 30 usecs for interrupt latency
  and record processing
• Distributed IOCs can run loops over Channel
  Access at about 20 Hz, care must be taken to
  handle loss of communication.
• Faster applications must be done in dedicated
  hardware (interface it to EPICS for integration
  and expose all variables and configuration
  parameters)
• There is no way to add channels to a running IOC
  without restarting it (redundant IOCs may limit
  the impact)

5
Channel Access Limitations

• There are currently 2 versions of the Server
• There is no built in name introspection
• What to do about an interface to devices? a thin
  interface supports general purpose / reusable
  clients
• Currently we can only monitor on value dead band,
  alarm dead band, or change of alarm status. It
  would be nice if we could monitor on
• Frequency or dead band per client
• Monitor device when a certain state is true (BPMs
  used for different virtual beam lines)
• No support for synchronous gets from variety of
  IOCs (there are at least two instances of data
  silo for getting synch data but not in the
  release of EPICS)
• The support for arrays is weak
• The time base and offset are not in the array
  data
• There is no direct support for multi dimensional
  arrays.
• No support for subarrays in the protocol
• Arrays are not buffered only pointers to the
  arrays are buffered
• There is no support to direct the record to
  process for a get or put this is decided
  statically in the field description in the .dbd
  file.

6
Database Limitations

• Only time stamp, display limits and control
  limits meta data can be obtained. It would be
  nice if some new metadata or data structures were
  available
• Statistical information
• Data from the past? Statistical data from the
  past?
• Message / State Data?
• Data to support device implementation
• There is weak support for process control
  algorithms for PID and lead/lag control and no
  control loop cascading support
• The record set and record reference manual needs
  to be updated.
• Redundancy is supported in a limited way but
  there is no fielded device support that takes
  advantage of this capability.

7
Configuration tools are limited

• Reusable relational database tools for
  configuration are nearly non-existent.
• All configuration tools are done in stand alone
  tools not in an integrated environment.

8
Clients

• Adherence to industrial standards for tools like
  a state-transition tool
• Integrated develop environment would be nice is
  CSS becoming this?
• Physics applications are not tightly integrated
  with the control system and frequently these
  tools recreate functionality that is ready in
  other client tools.
• Web based technology is not available in a
  uniform way.

9
Conclusions

• Our community has successfully delivered control
  systems for a number of applications.
• The ability to share software and hardware
  solutions is enhanced by working on the same base
  even though it is flawed.
• The architecture supports the ability to create
  work-arounds.
• There is always work that can be done to improve
  productivity and reliability while reducing
  costs.
• The community should actively inform us when
  things are not working or if you have a better
  solution that we could use.