1 / 10

EpicsOra and I/O Hardware Parameters RDB

This meeting at APS discusses the goals of the hardware RDB, the IO_NAME identifier, the hardware device schema, prototypes 1 and 2, and further work to be done.

rosariomartin
Download Presentation

EpicsOra and I/O Hardware Parameters RDB

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. EpicsOra and I/O Hardware Parameters RDB DESY, MKS2 group RDBCore meeting at APS

  2. EPICS link with hardware • e.g. INP • Device-specific formatted string, e.g. @CAN1:N36[4] ‘L=6553’ • Parameters in string are device attributes, node, channel, limits…etc RDBCore meeting at APS

  3. Goals of hardware RDB • Keep device data in RDB separate from EpicsOra data • Link EPICS PVs to hardware device data in a flexible way • Pull EPICS address string parameters and values from device data: automatically generate formatted address string RDBCore meeting at APS

  4. IO_NAME • Unique identifier associated with a hardware channel (measurement/control point) and its parameters. • Used by EpicsOra as the link to device data. • IO string generated from parameters for channel corresponding to the IO_NAME. • To change channel for a record: change the IO_NAME. RDBCore meeting at APS

  5. Hardware device schema • Each channel/measurement/control point has a unique IO_NAME. • DB contains device properties and values to construct IO string (and eventually more) • DB has links to assets data. • DB reflects structure of device: • “Composed of” relationships (module/channel) • “Linked to” relationships (channel/sensor) • Device structure not “hard coded” in database structure: can add devices, properties, and relationships effortlessly! RDBCore meeting at APS

  6. Prototype #1 • Simple schema with a few example devices (CAN) • Stored procedure for assembling IO string from parameter names and values • Extensible parameter list • MS Excel + VB prototype user interface RDBCore meeting at APS

  7. Data model Accommodate “composed of” and “linked to” plus parameter lists. Use Oracle hierarchical structure or object types??? Extend existing DESY prototype schema and UI (Matthias) Modify Prototype #1 IO string stored procedure to query this schema. Will use Java servlet UI. Module 1 Common module properties Specific module properties AI Channel Common channel properties Specific AI properties AO Channel Common channel properties Specific AO properties Module 2 Common module properties … Prototype #2 RDBCore meeting at APS

  8. Additional requirements • Computed parameters should be generated by database or UI software e.g. device ranges and limits  HI and LO • Supporting metadata and maintenance: • Device definitions and default parameters. • Tables to specify the IO String (list of parameters required and their positions and labels) • Etc. RDBCore meeting at APS

  9. Further work… • Develop Prototype #2 further: • Schema • UI Servlets (or other?) • IO String assembly stored procedure • Examples • Import flat EPICS .db files into EpicsOra RDBCore meeting at APS

  10. “Dynamic Table” structure and UI RDBCore meeting at APS

More Related