Experimental Physics and
Industrial Control System

1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024	Index	1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024
<== Date ==>		<== Thread ==>

Subject:	Re: mbboDirect Bx fields don't update on alarm change
From:	"Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>
To:	Kay Kasemir <kasemirk at ornl.gov>
Cc:	EPICS tech-talk <tech-talk at aps.anl.gov>
Date:	Wed, 1 Sep 2021 18:28:16 +0000

Hello Kay,

On Aug 31, 2021, at 12:03 PM, Kasemir, Kay via Tech-talk <tech-talk at aps.anl.gov> wrote:

I have an mbboDirect that writes to hardware, with each B0, B1, .. bit shown on a display as a checkbox for users to set/clear.

At startup, the record is INVALID, VAL and all B0, B1, .. bit fields defaulting to 0, until device support can once communicate with the hardware and fetch the initial value, i.e., the record correctly initializes from the hardware for 'bumpless' startup.

On the GUI, however, this looks odd because the mbboDirect doesn't send out monitors for the alarm change if the bit field value is still zero. Only bit fields that changed to 1 as a result of the 'bumpless' initialization at startup get updates.

… snip …

I see that behavior with at least base 3.15.9, R7.0.4.1 and 7.0.6.

The mbb[io]Direct records have always been somewhat “unconventional.” Prior to 3.15.0.2 monitor events were only posted for the mbboDirect Bn fields at CA connection time and when they were written to from outside the record. That record never modified the Bn fields itself at all, so it had no reason to call db_post_events() for them — in closed-loop mode with DOL providing the value to be sent to the hardware the Bn fields were never updated to reflect the bit-pattern in VAL at all.

In 2012 (3.15.0.2) I fixed some unrelated issues in both records associated with the MASK field, and added the code to the mbboDirect that extracts the Bn field bits from VAL when in supervisory mode, although this currently only gets done in init_record() or in special() when the OMSL field is set to “supervisory” — getting VAL through DOL in closed-loop mode or writing to it directly in supervisory mode still doesn’t update the Bn fields.

I also added the call to db_post_events() in special() that posts any mbboDirect Bn fields that change when OMSL is set to “supervisory”. That was intended to ensure that when switching control from closed-loop to to manual mode the Bn bits would reflect the last bit-pattern that was sent out to the hardware. I can see now though that my implementation doesn't always pass the full state up to its clients because it doesn’t know what the Bn values were that were last posted.

On August 11th Dirk Zimoch reported an issue with mbboDirect not behaving as expected when writing directly to VAL in supervisory mode. He proposed a fix which I have been looking at but haven’t committed yet. Your message caused me to look at the two issues more closely, and I now don’t think either is completely correct.

One way to fix it is to update mbboDirectRecord.c monitor() as shown below, where the "if (events) .." block now sends out monitors on all bit fields. With that in place, the camonitor will see a time stamp and no alarm as soon as the record processes on all bit fields.

However as described above the actual values of the bit fields in those monitors won’t always match the bits which are being sent to the hardware.

Were these db_post_events simply missing?

I suspect the original idea may have been to not overload CA clients with Bn updates when the bit pattern going to the hardware was being generated elsewhere in the control system. In manual (supervisory) mode, puts to the Bn fields do get posted (automatically by the dbPut() routine in dbAccess.c) as well as being sent to the VAL field, but in closed-loop mode the record doesn’t bother extracting or posting the individual bits.

Nowadays we would probably choose different behavior. Before I work on the code any more I think we should decide in detail what we actually want the record to do.

- Andrew

Complexity comes for free, simplicity you have to work for.

References:: mbboDirect Bx fields don't update on alarm change Kasemir, Kay via Tech-talk

Navigate by Date:: Prev: Re: [EXTERNAL] caget freezes the bash script Vodopivec, Klemen via Tech-talk; Next: subArray behavior reading just 1 element Lucas Russo via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024
Navigate by Thread:: Prev: mbboDirect Bx fields don't update on alarm change Kasemir, Kay via Tech-talk; Next: subArray behavior reading just 1 element Lucas Russo via Tech-talk; Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 <2021> 2022 2023 2024

ANJ, 01 Sep 2021

· Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System