Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 25 Nov 2013 15:33:37 -0600

Hi Emmanuel,

On 11/25/2013 01:05 PM, Emmanuel Mayssat wrote:

Breakpoint tables should be considered a basic feature of any control
system, including EPICS.
I would like to make a petition to have the breakpoint table
implementation reviewed.

I think you're conflating two issues which are related but not

identical. I'm not rejecting your concerns, but the solutions are not

necessarily what you suggest they should be...

My suggestions:
1/ RVAL in should be double (at least for ai/ao and maybe for all records)

The ai & ao records were designed for interfacing to individual ADC and

DAC devices, which even nowadays still present/accept data as some kind

of an integer, hence the choice of a DBF_ULONG for RVAL still makes the

most sense. Changing the type of the RVAL fields might require changing

and would certainly need testing of a large number of device support

routines at almost every EPICS site; I can't imagine fixing all the

issues that would probably arise even just here at the APS, let alone at

all the other sites.

Individual ai & ao device support may choose to provide or consume a

double value (when interfacing to devices over GPIB say) in which case I

believe the original design assumption was that some of the features

such as engineering units conversion will have been taken care of by the

remote device; the device support therefore must provide any missing

record features that need to be supported.

The breakpoint table code in Base is actually a standard API and not

built into the ao/ao records. This library code does not require that

the raw value be an integer. Stephanie showed how it can be called from

a subroutine record, and presumably the only reason why nobody has

created a separate breakpoint table record is because it's not

particularly hard to interface to it that way. If someone wanted to

contribute such a record type to Base I would be happy to review and

hopefully accept the result.

2/ no check on monotonicity in X and Y.
     * Just properly document side effects in manual.  (Happy to take
care of that!)
     * Whoever create the table and associated records should know what
she/he is doing

The monotonicity check is not implemented in the dbdExpand program that

comes with 3.15, although the IOC still does the check (which can be

disabled before loading the table as previously explained). I added this

check back in 2006 (Base 3.14.9) while cleaning up the breakpoint

library code, which was somewhat buggy at the time. I will admit that I

probably should have added the -b flag to dbExpand at the same time,

although it's easy enough to load a table into an IOC from its own DBD

file which avoids having to use add that flag.

I will remove the monotonic checks if there is enough demand for them to

go, but I do think that requiring engineers to explicitly disable them

is safer and not that inconvenient.

PS: Bob, I wouldn't mind contributing to the documentation.
Except most of the documentation is formatted as PDF documents or
read-only html pages.

Bob is not in charge of that, I am, and there are ways you can

contribute to the documentation:

* The Record Reference Manuel and various HowTo documents are currently

on a Wiki at http://wiki-ext.aps.anl.gov/epics/index.php/Main_Page for

which I will be happy to create you an account on request.

* Thanks to the late James Rowland, the Application Developers Guide is

a multi-file LaTeX document, the source code for which has its own

Bazaar project at https://launchpad.net/epics-appdev

- Andrew
--
Advertising may be described as the science of arresting the human
intelligence long enough to get money from it. -- Stephen Leacock

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System