Creating client for Ignition OPC-UA server

I’m just curious if there is a protocol, API, or library for creating an OPC-UA client to connect to the Ignition OPC-UA server. Is this part of the planned developer program? I get the feeling the developer program leans towards creating drivers so Ignition can communicate to devices, not for creating OPC-UA clients. Should I be looking at the OPC-UA SDK from the OPC Foundation instead? It seems there isn’t anything available to us regular non-members and I don’t have $1500 to blow on a membership at the moment :slight_smile:

There isn’t right now. We weren’t aware that this was something people would be interested in… but thanks for the feedback. We may have something to think about.

We DO have a client api… it’s called Ignition :smiley:

But in reality, we won’t be making a client api. The developer program is focus first on drivers, and then down the road on additional modules and services.

There will be many toolkits hitting the markets soon, I’m sure. In particular I can recommend looking into Unified Automation/AscoLab… they do a lot of UA stuff. The OPC Foundation website’s UA Product list might turn up some other ones.

I think the needs of many custom OPC-UA clients could be satisfied, more easily in most cases, by writing your own Ignition module, which will be possible as the API is released.

[quote=“nathan”]I think the needs of many custom OPC-UA clients could be satisfied, more easily in most cases, by writing your own Ignition module, which will be possible as the API is released.[/quote]Is this a different API than the OPC-UA API? Will it allow direct reads/writes to SQLTags without going through OPC?

So, the original idea was to have an API just for drivers. But, the thing is, drivers are just elements provided by modules. One thing we’re trying to figure out is how to balance all of this, as we’d like the focus to be on drivers, but in reality we probably should just go all the way with full modules. If this were the case, you could certainly plug into the SQLTags system and offer whatever you wanted. I’m not sure we’d really recommend that, though, as it would be better to do it on the OPC side so that other clients could use it, or you could easily use them remotely through the UA connection.

I can think of some scenarios such as maybe a custom interface to an ERP system where it may not make sense to use OPC communications and be constrained by some of the limitations of the OPC protocol.

Automate - to answer questions on your last 2 posts.

  1. Writing Ignition modules is different from writing an OPC-UA client.

1a. An OPC-UA client is a program that could be written in any language (C++, .NET, Java, etc) that, for the purposes of answering OPs question, communicates with PLCs via the Ignition OPC server - exclusively speaking OPC-UA. The client doesn’t need to know the particulars of the device that it will be communicating with - that’s been abstracted with OPC.

1b. An Ignition Module is a set of Java code that knows how to interact with the Ignition platform via a custom API. It gets to leverage all that the platform has to offer, including the web launched Designer and Gateway, and your second question, SQLTags access without going through OPC. The platform has so much to offer; developers should be able to produce quality, useful, plugins with minimal effort.

  1. I agree with you on the ERP systems. In some cases our customers use Vision (FactoryPMI) to exclusively deal with SQL databases. No OPC involved - just the JDBC database communication. In other cases you see hybrids, or exclusively OPC for basic HMI applications. It’s important to choose the right tools for the job and the Ignition platform is capable of supporting widely varying requirements across industries, project scopes, etc.

@nathan, thanks for the clarifications. In this topic it is mentioned that drivers could be written in Python via Jython. Is the same true for modules or are they limited to Java?

Python is feasible, but honestly there’s probably not much motivation on our part to maintain two separate sets of API docs. The only bonus to Python is that it doesn’t need to be compiled so could be developed more “on-the-fly”.

If you are only going to support one language I would rather it be Python. It makes since to me since you already require your users to know and use Python for scripting. Python is sometime called executable pseudo code since it is a very natural language. With Python it is fairly easy for someone besides the code author to determine what the code is actually doing.

You make a very valid point. Of course, technically we already have the Java API, I mean, it’s what all of our modules are written in. But it is true that we could simply support and publish only a Python API. Not sure how it would play into our whole module distribution architecture though…

We’ll have to mull it over a bit.