Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Wed, 16 Dec 2020 19:04:45 -0000

This could be tagged Codeathon if we can agree what the behaviors should
be.

-- 
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/1908433

Title:
  Some bi and bo record issues for discussion

Status in EPICS Base:
  Confirmed

Bug description:
  1. Should bo.VAL and bi.VAL always be forced to 0 or 1 only?

  The code in bo::process() that reads DOL can result in VAL being set
  to something other than 0 or 1. Almost everywhere else the code that
  sets VAL prevents that; the only other place I can see is that IVOV
  isn't limited to 0/1 and gets copied to VAL if IVOA triggers it; or a
  put from elsewhere could also set it to a non-boolean value. This can
  also result in RVAL being set to something other than 0, 1 or MASK.

  The bi::readValue() routine copies SVAL to VAL in simulation mode
  without checking it for 0/1, and any bi device support could also set
  VAL to some other value and return 2.

  Both get_enum_str() routines handle the invalid case by returning
  "Illegal_Value".

  2. Both get_enum_strs() routines currently return 1 string if ZNAM is set but not ONAM, or 2 strings in all other circumstances (neither ZNAM nor ONAM set; ONAM set but not ZNAM; or neither ZNAM nor ONAM set). There is a comment in that bo code saying that returning 0 strings breaks CA clients, but the mbbi and mbbo records both do that if no strings are defined, so that comment might be out of date now. Should bi/bo behave like an mbbi/mbbo with NOBT=1?

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System