Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flexible handler for NTScalar standard optional fields #149

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Monarda
Copy link

@Monarda Monarda commented Aug 4, 2024

The file nthandlers.py implements the logic required for NTScalar control, valueAlarm, and timeStamp fields. A put or post will be evaluated against those structures if present, e.g. if control.limitHigh is set then the value of the PV will not be allowed to exceed that value, or if a value below valueAlarm.lowAlarmLimit is set then alarm.severity will be set to valueAlarm.lowAlarmSeverity.

The included example code shows this in practice:

pv = SharedPV(nt=NTScalar('d', control=True, valueAlarm=True),
              handler=NTScalarRulesHandler(),
              initial=12.0)
pv.post({'control.limitHigh': 6,
         'valueAlarm.active': True, 'valueAlarm.lowAlarmLimit': 1, 'valueAlarm.lowAlarmSeverity':2})

Server.forever(providers=[{
    'demo:pv:name':pv,
}])

and using pvput we see the expected results:

> ./pvput demo:pv:name 12
Old : 2024-08-04 18:44:07.781  4
New : 2024-08-04 18:44:12.279  6
> ./pvput demo:pv:name 0
Old : 2024-08-04 18:44:12.279  6
New : 2024-08-04 18:44:14.502  0 MAJOR lowAlarm

The code uses two orderedDicts to construct a list of rules. One set of rules are applied to onFirstConnect and are used to ensure the PVs are immediately in the correct state, e.g. control limits applied before first connection is evaluated. The second set of rules are applied to each post (these have the prior and ServerOperation state to consider). In practice the two sets of rules share a considerable amount of code. A developer may interact with the orderedDicts to override default behaviour or add additional user-specified behaviour.

Does this seem useful? If so, in generalt terms, is this implementation a sensible way of supplying this functionality?

I thought it made sense to check if was desired before extending to other Normative Types or implementing tests.

@Monarda
Copy link
Author

Monarda commented Aug 4, 2024

I forgot to add this has only been lightly tested with Python 3.8 and Python 3.11.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant