Experimental Physics and
Industrial Control System

Hi Hinko,

On Sun, Jun 2, 2019 at 12:53 PM Hinko Kocevar via Tech-talk <[email protected]> wrote:

Thank you all for the input.

I understand that adding new records to the IOC database is the "EPICS" way of doing it, and I've done it so far for IOCs under my control, with success. The thing is that there are not enough bodies, with EPICS knowledge and free time, for this to happen on all IOCs at ESS, leading such low priority requirements being forgotten.

I've never used the base filters before - this looks like a good opportunity to look into that!
The PVs that need throttling are mainly scalars, but in some cases, even more critical PVs as waveforms. I would imagine that "deadband" filter might not play well with those. In any case, deadband filter looks promising, but at the end of the day, I'm after simple decimation of PV update rate, not depending on the value change itself.
(How) can filters be used with python client (pyepics3)?

The periodic polling, sounds like to most straightforward approach, for sure.
In python, there might be unwanted delays introduced to the "caget" if the PV is not accessible/reachable at the time of the poll. And then the rest of the PV updates (in a single thread) suffer from not being updated in timely fashion. Someone will say, use threads; but I can have +50 PVs to look at on this slow monitoring client hence each PV would need to get its own thread? Or would the use of PV instead of caget in pyepics3 lead to better experience?

If I understand correctly, you want to report or act on PV changes at a fixed rate that is slower than you expect the real rate of change for the PVs.   I would probably start with something like this (for brevity it uses 8 PVs, but I think this should scale to 100s of PVs without change and to 1000s PVs without change except to worry about the i/o rates of the print() calls (and you probably wouldn't really be printing anyway):

####

import epics
import time
pvnames = ['S:SRcurrentAI',
          'S:SRlifeTimeHrsCC',
          '13IDA:DMM1Ch11_calc.VAL',
          '13IDA:DMM1Ch12_calc.VAL',
          '13IDE:userTran1.A',
          '13IDE:userTran1.B',
          '13IDE:userTran1.C',
          '13IDE:userTran1.D']

pvs = [epics.PV(name) for name in pvnames]

MESSAGE_DELAY = 2.0  # delay time in seconds

while True:
    try:
        time.sleep(MESSAGE_DELAY)
        print("# Time : %s" % (time.ctime()))
        for pv in pvs:
            print("  %s %s" % (pv.pvname, pv.char_value))
    except KeyboardInterrupt:
        break

####

Here, the PV objects are internally monitored, automatically updating their values on each real change event. We ignore the events and only use the fact that the values will be up-to-date after we've slept for a short, fixed time.   That will act on (here 'print()') every PV at a fixed interval.  FWIW,  pyepics 'caget()' and 'caput()' are built upon PV objects (so that connections are not re-established), so that the most naive script of 

###

import epics
import time
pvnames = ['S:SRcurrentAI',
          'S:SRlifeTimeHrsCC',
          '13IDA:DMM1Ch11_calc.VAL',
          '13IDA:DMM1Ch12_calc.VAL',
          '13IDE:userTran1.A',
          '13IDE:userTran1.B',
          '13IDE:userTran1.C',
          '13IDE:userTran1.D']

MESSAGE_DELAY = 2.0  # delay time in seconds
while True:
    try:
        time.sleep(MESSAGE_DELAY)
        print("# Time : %s" % (time.ctime()))
        for name in pvnames:
            print("  %s %s" % (name, epics.caget(name, as_string=True)))

    except KeyboardInterrupt:
        break

####

would give the same output, and not be very different in performance.

If you want to act only when the PV actually changes but not necessarily on *every* change, I would suggest testing the timestamp in the event handler, and ignore events that are too soon after the last change, perhaps something like this:

####

import epics
import time

pvnames = ['S:SRcurrentAI',
          'S:SRlifeTimeHrsCC',
          '13IDA:DMM1Ch11_calc.VAL',
          '13IDA:DMM1Ch12_calc.VAL',
          '13IDE:userTran1.A',
          '13IDE:userTran1.B',
          '13IDE:userTran1.C',
          '13IDE:userTran1.D']

MESSAGE_DELAY = 2.0
last_update = {}

def onchange(pvname, value=None, char_value=None, timestamp=0, **kws):
    if timestamp < (last_update.get(pvname, 0) + MESSAGE_DELAY):

        # un-comment this next line to see what you are missing!  
        # print("     <ignored event for %s>" % (pvname)) 

        return
    else:
        print("%s, value=%s at %s" % (pvname, char_value, time.ctime()))
        last_update[pvname] = timestamp

pvs = [epics.PV(name, callback=onchange) for name in pvnames]

# run, wait for changes (or run the rest of your app)

while True:
    try:
        time.sleep(0.05)
    except KeyboardInterrupt:
        break

####

In this version, we look at the timestamp each change event (by default, the TIME_* DBR type for a PV so that those timestamps are from the record) and ignore events that are too recent.

All of these rely on the default behavior for pyepics PVs that they are monitored internally and updated asynchronously by threads in the CA library, but you should not need to worry about this threading on the client end - it all happens in the background.   The  use of a rich PV (with internal monitor and connection callbacks and using the TIME_* DBR variant by default)  does use a few more resources than a bare channel access connection.  The expectation is that if you're using Python, programmer time is more valuable than counting bytes on the IOC.  But, if you're close to saturating an IOC or your network, you may want to be more careful. 

Hope that helps.  If I missed some important point, let me know,

--Matt