Experimental Physics and
Industrial Control System

"Johnson, Andrew N. via Tech-talk" <[email protected]> · Wed, 30 Jan 2019 19:33:19 +0000

On Jan 30, 2019, at 2:20 AM, Ralph Lange via Tech-talk <[email protected]> wrote:
> 
> On Tue, 29 Jan 2019 at 18:00, Johnson, Andrew N. via Tech-talk <[email protected]> wrote:
>> 
>> On 1/29/19 10:09 AM, Bruno Martins via Tech-talk wrote:
>> > CALC's value is initially 1, as expected. However, if I do "caput CALC
>> > 0", a monitor event is never issued again when CALC.VAL goes back to
>> > being 1. Shouldn't a monitor event be issued in this case?
>> Your "caput CALC 0" is pointed at the VAL field, which has some special
>> handling.
>> [...]
> 
> One could say that the VAL field of a CALC record is not intended to be written to, as its value will always be updated by the result of the calculation.
> 
> The same effect (with the same possible surprise about unexpected behavior) applies to all output record types that don't consider VAL as the original source of the value to write, but calculate VAL using some algorithm, e.g. from base:
> 	• the calcout record as it does the same as the calc,
> 	• the mbboDirect record that overwrites VAL with the or'ed up Bn fields,
> 	• the sel record that overwrites VAL with the result of the selection algorithm.

Record types do have some control over the behavior. The db_post_events() call in dbPut() is only skipped for the VAL field if it's marked pp(TRUE) in the Record.dbd file.

Hmm, the CALC record does *not* have pp(TRUE), and when trying Bruno’s database I see that the IOC *does* send out a monitor when I do caput CALC 0, but it never posts the update when the value subsequently goes back to 1. My original analysis of the report was thus wrong.

The problem is that dbPut() doesn’t update the CALC.MLST field when it generates that monitor, so the record doesn’t know anything about it having been sent. When CALC next processes it sets VAL back to 1, which equals the MLST field so the monitor() routine skips sending out an update for that value. Using MDEL=-1 will enforce the monitor updates, but it isn’t the ideal solution since it wastes bandwidth by sending out an update even when the value hasn’t changed.

There is an easy change that might resolve this particular problem, but I don’t think it’s actually the right fix: Set MLST to VAL at the top of the process() routine. It seems wrong because it's ignoring MDEL, but the dbPut() monitors ignore MDEL too...

> Would making the VAL field SPC_NOMOD make the behavior more clear by rejecting writes? Feels like it could have side effects that break existing databases, though…

That does seem like it should be a better fix, but I think it would break too many existing applications. For example another record in the same IOC that writes to the VAL field through a DB link with the PP flag set just to trigger record processing. If VAL were marked SPC_NOMOD that would cause dbPut() to return S_db_noMod which would prevent processTarget() from being called by dbDbPutValue(). The correct database should be writing to the PROC field (or forward-linking). Another problem would be any time the CALC expression uses VAL, which would see the last value which was put.

Other ideas welcome here…

- Andrew

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System