Re: pyepics not updating pv.enum_strs after connection

[Matt Newville <newville@cars.uchicago.edu>]

Thanks Andrew, Kay, Dirk,

That's very helpful.  I'll update the connection callbacks for pyepics PVs to follow this approach of fetching CTRL variables and creating a separate monitor for DBE_PROPERTY events on the CTRL data type.

--Matt
 

On Thu, Mar 26, 2015 at 7:43 AM, Kasemir, Kay <kasemirk@ornl.gov> wrote:

Hi:

On Mar 26, 2015, at 4:47 AM, Dirk Zimoch <dirk.zimoch@psi.ch>
 wrote:
> In my opinion clients should work like this:
>
> Every monitoring client should have a connection callback.
>
> On connect it checks if the data type has changed (that may include changes in array length, keep in mind that dynamic array length is a relatively new thing and we cannot expect every server to support it). If yes, remove existing event subscriptions on this channel and start from scratch as if the channel was new. Most probably the client needs to clean up some if its internal data structures here.
>
> If no event subscription exists (new channel or changed data type), the client should get the DBR_CTRL data once, subscribe for VALUE (or LOG) plus ALARM changes on the DBR_STS data (as usual) and additionally subscribe for DBE_PROPERTY changes on the DBR_CTRL data (a second, independent monitor). It needs two different event callbacks because different things need to be updated. The callback for DBR_STS is the usual stuff, but the callback for DBR_CTRL needs to update enum strings, precision and such.

I agree with Dirk, and the details of changing the subscription are important.

For what it's worth, I started out like this:

1) Create channel
2) In connection callback, fetch DBR_CTRL_native_type
3) When received, establish monitor for DBR_TIME_native_type or DBR_STS, depending on your needs
.. keep receiving updates until
4) Channel disconnects for some reason: Clear monitor, start over at 2)

--> That doesn't work!
Clearing the monitor fails because the CA client lib tries to cancel the subscription on the CA server, which it can't reach since we're after all disconnected.
It's also possible that the IOC is still running, only the network between IOC and client had a problem. In that case, the IOC will keep the subscription info. On reconnect, client starting over at 2) now results in 2 entries in the CA server's client list.

What Dirk describes about comparing the type of existing subscriptions is correct:

1) Create channel
2) In connection callback, fetch DBR_CTRL_native_type
3) When received:
     if (monitor != null  &&  data type changed)
     {   clear monitor; monitor = null }
     if (monitor == null)
          monitor = ca_add_event(DBR_TIME_native_type);
.. keep receiving updates until
4) Channel disconnects for some reason: Start over at 2)

If you support DBE_PROPERTY, you actually have one more monitor for that, checked the same way on reconnects.

Thanks,
Kay