Experimental Physics and
Industrial Control System

Michael Abbott <[email protected]> · Thu, 11 Nov 2010 16:20:04 +0000 (GMT)

I'm writing to flag an unexpected incompatibility that may bite some other 
people, and perhaps flag up some related issues.

First the headline problem.  

After upgrading from the APS to the MRF timing EPICS support module and 
then restoring a previously saved timing configuration using BURT the 
result was that most of my triggers stopped working!  On closer inspection 
it turned out that all of the pulse widths (in my er records) had been 
reset to very small values, typically 1, 2 or 5, and only equipment 
capable of responding to such short (8 to 40ns) pulses was responding.

This turns out to be a very interesting combination of issues, including a 
couple of probable bugs.

First, the dbd file for the MRF er record has changed slightly: the pulse 
width fields (OT1W to OTDW) have changed from type DBF_ULONG to 
DBF_USHORT; this more correctly reflects the underlying hardware, but 
triggers the problem reported here.

Secondly, and this is unavoidable but a little excruciating, channel 
access promotes the pulse width field types for the APS er record to 
DBR_DOUBLE, but promotes the smaller MRF version of these fields to 
DBR_LONG.

Thirdly, BURT had saved the underlying data in a textual format reflecting 
the original underlying type, eg +2.56000000e+2.  

I'm sure you can see where this is going.  Now for the two underlying 
problems.

Fourthly, BURT relies on EPICS String to CA value conversion when 
restoring (even though it clearly didn't rely on CA value to string 
conversion when saving, as huge amounts of precision would have been 
lost); in the light of the final ... um ... feature, this is unwise.

Fifthly, EPICS String to Integer conversion (EPICS 3.14.11) is rather 
sloppy.  In particular, given the string +2.56000000e+2 this is silently
interpreted as 2.  I contend that the "correct" behaviour would be to 
raise an error, or perhaps with a bit more ambition this could have been 
converted to 256.

For me the solution is to rewrite or recapture the offending BURT files.

I wonder what the consequences would be of making EPICS string to number 
conversion strict, ie forcing caput failure if string to number conversion 
fails to convert the entire string.  I suggest it's worth considering, as 
it would make error detection easier and earlier.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System