EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <20222023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <20222023  2024 
<== Date ==> <== Thread ==>

Subject: Re: [Bug 1991765] Re: Problem with ROFF change in ai/ao
From: Simon Rose via Core-talk <core-talk at aps.anl.gov>
To: Bug 1991765 <1991765 at bugs.launchpad.net>, "core-talk at aps.anl.gov" <core-talk at aps.anl.gov>
Date: Fri, 7 Oct 2022 07:35:03 +0000
Hi all -

Is there some document with more information about this field and the motivation behind the conversion performed? I have to admit that it really isn't obvious to me why the field should not be allowed to be negative. It would also be nice to see what is a use-case that it is solving; the conversion

VAL = ((RVAL + ROFF) * ASLO + AOFF) * ESLO + EOFF)

seems pretty arbitrary.

I looked back at some of the older threads about this, and the history is also somewhat unclear to me, with it being deprecated, then undeprecated, etc; it would be nice to see some documentation as to _why_ it is the way it is at the moment.

Cheers,

Simon

On 2022-10-06, 19:20, "Core-talk on behalf of Andrew Johnson via Core-talk" <core-talk-bounces at aps.anl.gov on behalf of core-talk at aps.anl.gov> wrote:

    The original change (released 7½ years ago) was to properly support
    32-bit raw values as you requested in https://epics.anl.gov/tech-
    talk/2013/msg00684.php but without triggering UB, which modern compiler
    optimizers love to rely on to break previously-working-but-non-portable
    code.

    ROFF can't hold negative values, it was designed to support ADCs and
    DACs with an offset zero. If you have device support that was setting a
    negative ROFF it was depending on overflowing a uint32 calculation,
    which gcc allows with the -fwrapv flag but EPICS doesn't set that and it
    isn't portable.

    I don't think we can change this in the record types at all, the device
    support has to provide any fixes necessary IMHO.

    -- 
    You received this bug notification because you are a member of EPICS
    Core Developers, which is subscribed to EPICS Base.
    Matching subscriptions: epics-core-list-subscription
    https://bugs.launchpad.net/bugs/1991765

    Title:
      Problem with ROFF change in ai/ao

    Status in EPICS Base:
      New

    Bug description:
      In commit ffcbd4ca, ROFF of ai and ao have been changed from LONG to ULONG.
      This has caused problems when migrating from EPICS 3.14 to 7.0 in multiple cases where ROFF was negative and thus became a huge positive value.
      There seems to be no workaround for this regression.

    To manage notifications about this bug go to:
    https://bugs.launchpad.net/epics-base/+bug/1991765/+subscriptions



References:
[Bug 1991765] [NEW] Problem with ROFF change in ai/ao Dirk Zimoch via Core-talk
[Bug 1991765] Re: Problem with ROFF change in ai/ao Andrew Johnson via Core-talk

Navigate by Date:
Prev: [Bug 1991765] Re: Problem with ROFF change in ai/ao Dirk Zimoch via Core-talk
Next: epics-7.0 » mac - Build # 433 - Failure! APS Jenkins via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <20222023  2024 
Navigate by Thread:
Prev: [Bug 1991765] Re: Problem with ROFF change in ai/ao Andrew Johnson via Core-talk
Next: [Bug 1991765] Re: Problem with ROFF change in ai/ao Dirk Zimoch via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  <20222023  2024 
ANJ, 07 Oct 2022 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·