Writing to mbboDirect.VAL does not work any more in EPICS >= 3.15

[Dirk Zimoch]

In EPICS 3.14, it was possible to write to mbboDirect.VAL. This does not work any longer with EPICS 3.15 or higher.
However, writing to .VAL was always buggy anyway (did not update the.Bx fields).

[mdavidsaver (mdavidsaver)]

Dirk, Have you investigated what changed, and when? Maybe some special() logic?

[Dirk Zimoch (dirk.zimoch)]

Not yet, I am current checking, what actually worked in 3.14.
For example the first write after ioc start did not work and splitting the values into the .Bx fields did not work either.

[Dirk Zimoch (dirk.zimoch)]

The change is in commit 04ff9eb "rec: mbbiDirect and mbboDirect refactoring" from 2012-12-12.
The documentation says:
 * After the device support's init_record() routine returns during record
   initialization, if OMSL is supervisory and UDF is clear the fields
   B0-BF will be set from the current VAL field.
 * When a put to the OMSL field sets it to supervisory, the fields
   B0-BF will be set from the current VAL field. This did not used to happen,
   the individual bit fields were previously never modified by the record.
   Note that this change may require some databases to be modified, if they
   were designed to take advantage of the previous behavior.

This is exactly what happens. Thus this is no "bug". Also the behavior is the same as before as long as OMSL is closed_loop, but that is not the default.

What I would expect (but what is neither documented nor implemented) is that while OMSL is supervisory, one can write to the VAL field (which is the "normal" behavior for output records) and that the record would update the .Bx fields, This has never happened before but now only happens when switching to supervisory but not while OMLS is supervisory.

I will try to implement it...

[Dirk Zimoch (dirk.zimoch)]

Setting VAL to special(SPC_RESET) already does the trick.
All tests succeed.

[Andrew Johnson (anj)]

The Record Reference for the mbboDirect record is a bit contradictory about what the record should do, and the code doesn't do everything you might want either.

In the intro at the top it says "The mbboDirect record performs the opposite function to that of the mbbiDirect record. It accumulates bits (in the fields B0 - BF) as unsigned characters, and converts them to a word which is then written out to hardware." That description isn't really correct because in closed-loop mode the Bn fields are neither read from nor written to by process(), so they don't reflect the bits in the VAL field at all.

However the "Desired Output Parameters" section says: "The desired output can be written into the VAL field via dpPuts at run-time when the record is in supervisory mode." This describes the result of the change that Dirk is proposing. It's not particularly efficient since when dbPut() writes to VAL the new value gets round-tripped into the Bn fields by special() and back to VAL by process(), but doing anything else would probably get complicated.

Currently writing "supervisory" to OMSL sets the Bn fields from VAL and (since my 2012 changes) posts monitors on those Bn fields that change, but any timestamps that accompany those monitors will be from when the record last processed. Dirk's change extends that behavior to any writes to the VAL field while OMSL is supervisory; the Bn timestamps will still be from the last time the record processed, while the monitor which process() posts on the VAL field will have the new timestamp.

Do we want to make any other changes while we're fixing this record? I'm collecting edits in my base-3.15 tree and will merge that up to the 7.0 branch when we're done.

[Dirk Zimoch (dirk.zimoch)]

The special() function could update the time stamp before posting the monitors.

[Dirk Zimoch (dirk.zimoch)]

A bit of background why people are not simply using longout instead: They want to use the MASK and SHFT features provided by some drivers, in particular read-modify-write when updating some bits in a longer hardware register.

[Andrew Johnson (anj)]

> The special() function could update the time stamp before posting the monitors.

True, but then a record's timestamp no longer tells you if/when it was last processed. We used to tell people to check UDF for that, currently we say to check the timestamp.

A few other record-types also call db_post_events() from their special() routines without getting a new timestamp: calcout, mbbi, mbbo

The mbboDirect::special() doesn't call db_post_events() when it updates VAL. That would raise questions about updating MLST as well, and what to do about alarms – calling monitor() isn't right either...

I suspect this discussion is just widening the cracks in our abstraction that is the IOC's record model. Unless somebody else has any other bright ideas I'll just add the special(SPC_RESET) as proposed and stop there.

[Ralph Lange (ralph-lange)]

I remember my (failed) fight for having a timestamp in the event update that shows when the value changed - instead of or in addition to the timestamp that shows when the record processed...

[Andrew Johnson (anj)]

See https://epics.anl.gov/tech-talk/2021/msg01619.php

[mdavidsaver (mdavidsaver)]

A potential solution, based on my (likely incomplete) understanding.

https://github.com/epics-base/epics-base/pull/199