All of these approaches do not solve my issue.
I have this scenario: N PVs of waveforms (arrays) of 10^5 data in each PV.
The IOc runs at 14 Hz, it means that if I subscribe in monitor mode I will be updated 14 times per second with N x 10^5 numbers.
I'm not sure I understand what "The IOC runs at 14Hz" means. Does that mean the device producing the waveforms updates them at 14 Hz?
I hadn't appreciated that the question was regarding many arrays. You are right that *if* you monitor these, you will get N*14 events per second, one for each of the waveform PVs. Whether that is a problem probably depends on N.
Now I have an interface that I want to update just once per second with the content of these waveforms.
If I am in monitor, I can easily get the value once per second but my python script will anyway use the bandwidth and the cpu to process at 14 Hz because the threads of the monitoring will be updated at that frequency.
You can create the pyepics PV object with `automonitor=False` to prevent it from automatically subscribing to all monitor events and then use `PV.get()` to actually do an explicit without relying on internally cached values.
In fact, by default, `automonitor` is False for arrays with counts > 65536 to avoid the kinds of problems you describe. So, if you really have arrays of 10^5 elements, they would *not* be auto-monitored, and `PV.get()` would really fetch the latest value.
If I use caget once per second I need to deal with all the timeouts that can occur if some pv is down, disconnected, unreachable etc.
In pyepics, `caget()` and `caput()` actually use cached PV objects, creating them if needed. This avoids making new connections for each call. `caget()` uses the defaults for `automonitor`. That means the simplest way to write what you want to do:
while True:
time.sleep(1.0)
for name in pvnames:
print(" %s %s" % (name, epics.caget(name, as_string=True)))
might be *exactly* what you want. If your arrays have > 65536 elements, PV objects will be created and reused and connections maintained (you could establish connection callbacks if desired), but they will not be monitored and generate network traffic for every change in value.
Depending on your value of N, it might take some noticeable time to fetch all the waveforms. That seems sort of inevitable to me: you are saying that you want to *not* get the waveforms asynchronously, but on demand. That sort of implies having to wait for the response.
I haven’t find a reliable way to get the data once per second in a full asynchronous mode but without rejecting the data that anyway occupy bandwidth and cpu.
If your device is creating arrays at 14 Hz and you only want to use them at 1 Hz, what you are asking to do is to reject data. If you want to dictate the rate and time of the data arrival, that really is not asynchronous.
If that isn't what you're looking for, it might be that what you really want to do is slow down the device generating the events and arrays on the server end.
