Driver Subscription Logic

I know that the abstract driver handles subscriptions for you, but I really want to use the Driver interface instead, which doesn’t have that. As such, if I want subscriptions, I believe that I have to do the following:

–Extend from the DriverSubscriptionModel.ModelChangeListener interface to get the items added and items removed method, to know what tags need to be subscribed to.

–Add my driver as a listener to the DriverContext.DriverSubscriptionModel.

–Do a little math to find the greatest common factor among the various sampling times.

–Create a set of lists of tags that will be read at different times.

–Schedule a task to run during the GCF time, using the ExecutionManager grabbed from the GatewayContext…

–Cycle through my sets of tags to be read during my scheduled tags, reading the appropriate set.

–Repeat and update if necessary.

Am I way off base, or am I close?

–L. Wasserman

That sounds about right.

We don’t do the GCF math, instead grouping items by the rate the need to be sampled at and then doing best effort to update those groups of items at their requested rates.

Cool. The task was kind of daunting, so I wasn’t sure where to start. This whole task of writing this driver over the past year and a half has been my intro to non-trivial Java, so I definitely appreciate the info.

–L. Wasserman

Managing the subscriptions is definitely the most complicated piece of implementing a driver, assuming you’ve got the actual protocol for whatever device you’re talking to taken care of.

Yep. Everything else is working. I can do asynchronous reads without a problem.

Do the itemsAdded and itemsRemoved methods get called when an existing tag’s scan class changes, or do I need a different method for that?

A change in scan class rate should eventually make its way to the driver as a remove followed by an add.