![]() |
![]() ![]()
Experimental Physics and
| ||||||||||||||||
|
Hi Emanuele, On Sun, Jun 2, 2019 at 4:25 PM Emanuele Laface <[email protected]> wrote:
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.
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.
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.
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. --Matt
| ||||||||||||||||
ANJ, 03 Jun 2019 |
![]() · Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing · |