Tags related changes from Ignition 7.9 to 8.1

Module Development
, ,
1

Hi Team,

We have few custom modules in Ignition 7.9. We are working on migrating those to Ignition 8.1. In our modules we are using couple of tags related interfaces and classes such as,

com.inductiveautomation.ignition.gateway.sqltags.SQLTagsManager
com.inductiveautomation.ignition.gateway.sqltags.TagProvider
com.inductiveautomation.ignition.gateway.sqltags.simple.SimpleTagProvider
com.inductiveautomation.ignition.gateway.sqltags.simple.WriteHandler

I don’t see these classes/interfaces in Ignition 8.1. Could you please help me with guiding how we can migrate these to 8.1. Also could you please guide me with some documentations available (if any) related to the changes, so that I getter a better understanding about it as I’m pretty new to Ignition as well.

1 Like
2

(I’m not an expert in either the old or the new tag system)

You will hopefully be able to switch to the new ManagedTagProvider concept; it’s a simpler scaffolding that helps with setting up the basic idea of “Java code that provides Ignition tags”.

I’d start from the SDK example and work from there:

As a general rule: Anything under the sqltags package is deprecated or outright removed.

3

Look to the tags package for replacements. The sqltags package hangs around for weird backwards-compat reasons.

4

Thanks for your reply @PGriffith and @Kevin.Herron. I have gone through the sdk-example shared above. Although some of my queries got resolved, there are still couple of them. So wanted to check if there are any documentation/release notes around how the functionalities provided in 7.9 could be achieved in 8.0/8.1 ?

5

Subscription related classes and interfaces are also missing in 8.1 which are present in 7.9 sdk
Can anyone help me finding the alternatives/ upgraded classes for below.

com.inductiveautomation.ignition.gateway.opc.Subscription
com.inductiveautomation.ignition.gateway.opc.SubscriptionChangeEvent
com.inductiveautomation.ignition.gateway.opc.SubscriptionChangeListener
com.inductiveautomation.ignition.gateway.opc.SubscriptionModel

Thanks

6

For my Modbus module’s abstract driver, the v7.9 imports look like this:

import com.codahale.metrics.Snapshot;
import com.codahale.metrics.UniformSnapshot;
import com.inductiveautomation.ignition.common.execution.TPC;
import com.inductiveautomation.ignition.common.logging.MDCUtils;
import com.inductiveautomation.ignition.common.util.LogUtil;
import com.inductiveautomation.ignition.common.util.LoggerEx;
import com.inductiveautomation.opcua.nodes.Node;
import com.inductiveautomation.opcua.nodes.NodeManager;
import com.inductiveautomation.opcua.nodes.builders.NodeBuilderFactory;
import com.inductiveautomation.opcua.types.AccessLevel;
import com.inductiveautomation.opcua.types.DataType;
import com.inductiveautomation.opcua.types.DataValue;
import com.inductiveautomation.opcua.types.Guid;
import com.inductiveautomation.opcua.types.LocalizedText;
import com.inductiveautomation.opcua.types.NodeId;
import com.inductiveautomation.opcua.types.QualifiedName;
import com.inductiveautomation.opcua.types.StatusCode;
import com.inductiveautomation.opcua.types.UByte;
import com.inductiveautomation.opcua.types.UInt16;
import com.inductiveautomation.opcua.types.UInt32;
import com.inductiveautomation.opcua.types.Variant;
import com.inductiveautomation.opcua.util.NodeIds;
import com.inductiveautomation.xopc.driver.api.BrowseOperation;
import com.inductiveautomation.xopc.driver.api.Driver;
import com.inductiveautomation.xopc.driver.api.DriverContext;
import com.inductiveautomation.xopc.driver.api.DriverMetrics;
import com.inductiveautomation.xopc.driver.api.DriverMetrics.AggregateStats;
import com.inductiveautomation.xopc.driver.api.DriverMetrics.RateStats;
import com.inductiveautomation.xopc.driver.api.DriverSubscriptionModel;
import com.inductiveautomation.xopc.driver.api.DriverSubscriptionModel.ModelChangeListener;
import com.inductiveautomation.xopc.driver.api.items.ReadItem;
import com.inductiveautomation.xopc.driver.api.items.SubscriptionItem;
import com.inductiveautomation.xopc.driver.api.items.WriteItem;

That driver’s conversion to v8.1 has these imports:

import com.codahale.metrics.Snapshot;
import com.codahale.metrics.UniformSnapshot;
import com.inductiveautomation.ignition.common.execution.TPC;
import com.inductiveautomation.ignition.common.logging.MDCUtils;
import com.inductiveautomation.ignition.common.util.LogUtil;
import com.inductiveautomation.ignition.common.util.LoggerEx;
import com.inductiveautomation.xopc.driver.api.BrowseOperation;
import com.inductiveautomation.xopc.driver.api.Driver;
import com.inductiveautomation.xopc.driver.api.DriverContext;
import com.inductiveautomation.xopc.driver.api.DriverSubscriptionModel;
import com.inductiveautomation.xopc.driver.api.DriverSubscriptionModel.ModelChangeListener;
import com.inductiveautomation.xopc.driver.api.PollingMetrics;
import com.inductiveautomation.xopc.driver.api.PollingMetrics.AggregateStats;
import com.inductiveautomation.xopc.driver.api.PollingMetrics.RateStats;
import com.inductiveautomation.xopc.driver.api.items.ReadItem;
import com.inductiveautomation.xopc.driver.api.items.SubscriptionItem;
import com.inductiveautomation.xopc.driver.api.items.WriteItem;
import org.eclipse.milo.opcua.sdk.core.AccessLevel;
import org.eclipse.milo.opcua.sdk.server.api.NodeManager;
import org.eclipse.milo.opcua.sdk.server.nodes.UaFolderNode;
import org.eclipse.milo.opcua.sdk.server.nodes.UaNode;
import org.eclipse.milo.opcua.sdk.server.nodes.UaNodeContext;
import org.eclipse.milo.opcua.sdk.server.nodes.UaVariableNode;
import org.eclipse.milo.opcua.stack.core.Identifiers;
import org.eclipse.milo.opcua.stack.core.StatusCodes;
import org.eclipse.milo.opcua.stack.core.types.builtin.DataValue;
import org.eclipse.milo.opcua.stack.core.types.builtin.DateTime;
import org.eclipse.milo.opcua.stack.core.types.builtin.LocalizedText;
import org.eclipse.milo.opcua.stack.core.types.builtin.NodeId;
import org.eclipse.milo.opcua.stack.core.types.builtin.QualifiedName;
import org.eclipse.milo.opcua.stack.core.types.builtin.StatusCode;
import org.eclipse.milo.opcua.stack.core.types.builtin.Variant;
import org.eclipse.milo.opcua.stack.core.types.builtin.unsigned.UByte;
import org.eclipse.milo.opcua.stack.core.types.builtin.unsigned.UInteger;
import org.eclipse.milo.opcua.stack.core.types.builtin.unsigned.ULong;
import org.eclipse.milo.opcua.stack.core.types.builtin.unsigned.UShort;
import org.eclipse.milo.opcua.stack.core.util.TypeUtil;

That should get you started.

7

Same package, the related classes are probably:

  • com.inductiveautomation.ignition.gateway.opc.OpcConnection
  • com.inductiveautomation.ignition.gateway.opc.OpcConnectionManager
  • com.inductiveautomation.ignition.gateway.opc.OpcSubscription
  • com.inductiveautomation.ignition.gateway.opc.OpcSubscriptionModel
  • com.inductiveautomation.ignition.gateway.opc.OpcSubscriptionModel.ModelChangeListener
8

Thanks @Kevin.Herron

I will look more into OpcSubscription, OpcSubscriptionModel, OpcSubscriptionModel.ModelChangeListener to achieve same functionality with above classes in v7.9

9

Hi @Kevin.Herron, we also have few use case around subscriptions.

  1. We are using subscriptionModel.getSubscriptions(name) to get all the subscriptions on a given server name. Could you please suggest how we can achieve the same in Ignition 8.1?
  2. We are using getRate() of Subscriptions, but in Ignition 8.1 I don’t see rate. Can you also provide some inputs here as in how we can get around this in Ignition 8.1.
10

It doesn’t look like there is equivalent functionality.

Instead, you’d have to register a ModelChangeListener via OpcSubscriptionModel::addModelChangeListener and keep track of subscriptions you are interested in yourself.

The PropertySet object that onSubscriptionCreated and onSubscriptionModified get called with will contain a value for the rate under the key “opcRate”, or alternatively you can use the static field OpcTagGroupProperties.OpcRateMS.

I don’t really see any way to get the OpcSubscription objects that don’t belong to you any more.

12

Thanks for sharing.

But I am still getting error when I try to import xopc.driver.api classes usig Ingnitionv8.

java:5: error: package com.inductiveautomation.xopc.driver.api does not exist
    [javac] import com.inductiveautomation.xopc.driver.api.DriverState;

How can I import xopc.driver.api classes in latest Ignition version ?

13

Some classes no longer exist. Refactor your code to not need them. Use the examples repo on github to review what might be appropriate.

14

Hi

I have question related to OPC connection.

I have upgraded SROPCServer with OPCConnection as part of upgrade to v8. But I don’t see the verifyConnectionState method which is invoked by regardless of server state.

In v7.9, we override this method to verify connection state and re-connect if it is faulted. Do we have a similar method to override in v8.1 or should we write custom implementation to invoke that method at regular interval.

VerifyConnectonState Method in SROPCServer : SROPCServer (ignition 7.9.5 API)

15

There is no similar replacement method, connections need to be responsible for detecting connection loss and reconnecting on their own.

16

Thanks for the quick response.

17

I want to simulate exact behavior in 8.1 and want to invoke VerifyConnection() at regular interval just like how it is being done in v7.9 SROPCServer related APIs. Could you please share some low level details on how it is being invoked in v7.9.

18

It’s just a periodic task that calls SROPCServer::verifyConnectionState every 5 seconds on all connections that aren’t disabled. There’s nothing more to it.