1 / 9

EPICS Limitations

EPICS Limitations. Bob Dalesio Marty Kraimer. Limited view point. These slides are written from a limited perspective Many people could and should add the limitations that they encounter to this.

saule
Download Presentation

EPICS Limitations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.

More Related