> .. Given the lengths both sides of the connection go to in order to support dynamic limits over CA, it seems natural that they would be supported when using PVA.
Yes, PV Access is better prepared for this. We no longer have predefined data types in the protocol. The CSS client simply subscribes to a channel to get “everything”. The client receives the complete data structure in the first
update, and from then on, the client receives whatever changes. Usually that’s the value and timestamp, maybe also severity/status. But could include the units, limits etc. So, on the client side we’re prepared to handle changing units, limits, precision,
…
Of course, there’s some more detail there as well. The client cannot decipher any random data structure. We expect to see “Normative types” with “value” for the value and “display/limitLow”, “display/limitHigh” for the display
range etc., see
https://docs.epics-controls.org/en/latest/specs/Normative-Types-Specification.html How well the server side supports this depends on what’s in the IOC, currently called “QSRV”. Looks like it right now it certainly sends normative types, but it always sends
updates for the alarm status/severity even at times where they don’t change, which is strictly speaking wrong but acceptable. Last time I tried I think changes to the units were correctly transmitted, but in the end you’ll have to give it a try yourself with
the current EPICS base version to see if changes to what you’re interested in are sent out or not.
-Kay