Unexpected change in behaviour of ai/ao device support

["michael.abbott--- via Tech-talk" <tech-talk@aps.anl.gov>]

At Diamond we are a bit behind the times, so I am four years late in reporting the following problem.  In upgrading our EPICS base from 3.14.12.3 (honestly!) to 3.14.12.7 (keeping things up to date; we're nearly on RHEL7), we have discovered that the ai and ao record support for our Hytec cards is now broken.

The underlying problem is that the driver support relies on being able to set the ROFF field to a negative value.  Unfortunately this is no longer possible, and the result is that ao outputs drive into maximum negative output voltage (potentially very damaging), and the ai inputs can also produce nonsense values (haven't actually tried yet, but the driver code is also now clearly broken).


In release 3.14.12.5 the following change was noted in the release note:


aoRecord raw conversion overflows
---------------------------------

The ao record type now checks converted raw values and limits them to the 32-bit integer range before writing them to the RVAL field. Previously value overflows relied on Undefined Behaviour which could give different results on different platforms. The ROFF fields of the ao and ai record types are now DBF_ULONG to allow an ROFF setting of 0x80000000 to work properly.


The corresponding change can be seen as commit f498b36 here: 

	https://github.com/epics-base/epics-base/commit/f498b36438703eb941eaac15c87f94b8d679def6



Unfortunately, changing fields from signed to unsigned has serious side effects, and I find it very hard to understand how this change happened, particularly on a minor point release like this.


Going forward, I'm not sure what the correct solution is.  This change is now clearly embedded into all subsequent versions of EPICS, so I doubt that reverting it is a serious option.  However, any documentation I have been able to find still refers to the ROFF fields as LONG.  Clearly we'll have to fix our internally supported drivers, but I do wonder who else is affected.

Why has noone else noticed this issue before now?

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom