Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Change in terminology: "Alerting" -> "Alarming"

To align better with industrial standards, the term "alarming" is now preferred for the core features in this version of Ignition. "Alerting" generally refers to alarming that is specific to a particular operator's preferences and settings. Therefore, the term may be used occasionally, but this version of Ignition doesn't offer any particular "alerting" features by this definition.

Alert Bus removed

The alert bus previously was the mechanism by which different parts of the system received alert events. This system has been removed. Now, if a sub-system is interested in alarm events, it can subscribe through AlarmManager#addListener. That method, which takes a new QualifiedPath, subscribes to everything at or below the path. Therefore, a system can subscribe to all events by passing a null or empty path.

Authentication Profiles have become User Sources



Drivers now conform to the standard ExtensionPoint pattern
The driver system has changed quite a bit in order to remove unnecessary sub-patterns and adhere more closely to the design of other parts of Ignition. Driver module authors will need to adapt their code. The following are the key changes:
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.
More information can be found in the OPC-UA Driver Development section of this guide.
Image Removed Image Added