Ignition 7.6 / OPC-UA 1.6 Driver API Changes

Module Development
1

Those of you with driver implementations have some work ahead of you to make your driver compatible with the driver API changes that have occurred.

Here’s a brief summary:

[ul]DriverAPI.VERSION is now 4.

Driver#initialize() no longer has NodeManager and NodeBuilderFactory parameters; they can be obtained via the DriverContext.

Driver#getDriverState() has been removed.

Driver#getDriverSubState() has been renamed to Driver#getDriverStatus(). It is now the main mechanism for user-facing feedback of the driver’s status.

Driver#alterSubscriptions() has been removed. Subscription state is now managed by a DriverSubscriptionModel, obtainable via the DriverContext. See javadocs on DriverSubscriptionModel for more information.

AbstractDriver#notifyConnectDone() has been removed (previously deprecated). Use #notifyConnectSucceeded() and #notifyConnectFailed(Exception).

Drivers are no longer instanitated reflectively and setup with #initialize(). They are instantiated by an implementation of DriverType, which means implementations have control of how instantiation occurs.

Drivers no longer have their properties reflectively set on them. The DriverType implenentation will receive a driver’s PersistentRecord type when asked to instantiate a Driver, and properties can be retrieved from the record. These PersistentRecords must have a reference to a parent DeviceSettingsRecord. This all means that Drivers now use the extension point pattern prevalent everywhere else in the Ignition platform.

Custom UI/config pages are now just ConfigPanels. The LinkEntry sub-interfaces have moved and changed slightly. The ConfigUILink, in particular, has changed to allow the PersistentRecord to be edited.

Use LegacyDeviceConfigConverter to convert existing device configurations into new PersistentRecords for each DriverType. Override runLegacyConversions() in your AbstractDriverModuleHook subclass and do the work there.

AbstractNioDriver renamed to AbstractSocketDriver.[/ul]

I’ve highlighted some of the key changes.

The Modbus driver has been updated to accommodate these changes and will be a hugely helpful example for making the transition.

Of course, I’m available here in the forum as well as by email to answer any questions you have.

2

Trying to update my driver to match the new API. The programmer’s guide says to supply a list of metas, rather like in my old driver, however, I can’t find a method that in my module hook that takes the list of metas anymore. The old AbstractDriverModuleHook had getDriverMetas()…

On a different note, I was curious about runLegacyConversions. Do I use this only if I haven’t altered my driver class form the old API, or do I always run this, even if I completely rewrite my driver with the newer API?

3

The guide hasn’t been updated for 7.6, so don’t look there. Your best bet is to look at how the Modbus example in the SDK does everything now.

If there’s a chance someone will be upgrading from 7.5 to 7.6 you need to run the legacy conversions or their currently configured devices using your driver won’t work any more and they’ll have to add new instances of them.

4

I’ve been slowly converting my driver over to 7.6, using the Modbus driver as an example. I got the module to install without errors, but upon adding a device, my driver never appears as an option. I know I missed something, but I can’t figure out what. Can you tell me what interface and method are responsible for making that driver option appear? That would help a lot.

5

Registering your DriverType implementation with the DriverManager is what makes it appear in the list of available drivers when creating a new device.

6

Doesn’t that happen in the background if you’re using the AbstractDriverModuleHook?

7

Yeah, looks like it does, as long as you’re returning your DriverType in the #getDriverTypes() method you have to implement when extending AbstractDriverModuleHook.