Re: mbboDirect Bx fields don't update on alarm change

["Johnson, Andrew N. via Tech-talk" <tech-talk at aps.anl.gov>]

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.