We have an MHE vendor who without saying their name, they are a german company and the #2 world based on 2020 revenue. I think it's because they saved money by not switching to OPC-UA. OK, gripe complete.
Part of the equipment which Ignition would monitor and control has a data source which is OPC XML-DA, which seems cutting edge, first announced in 1999.
We have read this post:
For us, we're not willing to pay for kepware because we already pay for Ignition. What is coming to mind is to use the module SDK to combine the two things below:
Basically create a driver for OPC XML-DA that would use existing drivers for OPC XML-DA and make the data available inside of Ignition's normal workflow.
As a basic mandatory question before we started such investigation I'd like to ask the group if anyone has ever worked on such a thing or knows of any other existing example which is similar enough to be helpful.
OPC connections are an extension point, so if you were going the module SDK route you could technically build a module that adds an “OPC XML-DA” type of OPC connection.
I don’t know if you’ll have any luck finding an OPC XML-DA toolkit/SDK for Java. If you can’t find a toolkit to use I would personally consider this whole idea a nonstarter.
There’s no way this costs you less than just paying for Kepware or some other OPC gateway product, either in actual dollars paid for the toolkit, or the time you and others will spend trying to get this working.
It looks easier than I had originally thought as long as you just need the client side. I looked at the spec and the WSDL… definitely the worst part is going to be dealing with the XML/SOAP/JAX-RS/ part of the Java ecosystem. If the GitHub repo he linked to happens to “just work” that would be a lucky break.
Finding servers in the wild to develop and test against might be a bit of a challenge as well.
He said they don't even want to pay for a Kepserver... do it for the exposure?
edit: okay, maybe there's a hidden market for this module somewhere, but he's only the 2nd person in the last ~13 years who I've heard ask about OPC XML-DA.
walmart is such that going and getting the funding for kepware is probably a larger task than building the module. Its called b-e-a-u-r-a-c-r-a-c-y.
Our general approach is going to be to ask this vendor to jump into the 21st century and move to OPC-UA in the future and/or put this so that we can just access it through the AB PLC that is literally 20 feet away from the equipment in question.
I am going to test that JAVA OPC XML DA SDK since we do of course have an actual live source of OPC DA-XML data with a known IP, port, and open firewall route.
I spent a few hours on this and there is some actual substance in this library.
Here are a few things I have found so far.
It requires JDK 1.8 for mvn clean package to work so compatibility to JDK 11 would have to be sorted.
There is a function in test called “OPCXmlDaClientITest” and when you first try to run it, you get a 301 redirect error. What appears to be a test website its trying to access is here:
So because it seems to contain functionality which can communicate with what appears to be a valid OPC XML DA server, I think I will continue to research its contents and figure out what it will take to merge it together with the Ignition SDK opc-ua-device example.
My concern after looking at it is that it’s expecting to run inside a Spring application and Ignition is not a Spring application. If, for example, you just created a simple Java command line application and tried to use the client in the main method it would likely fail.
Advosol Inc., Advosol Inc.
OPC XML-DA V1.0, XML DA Simulation Server
Started
RUNNING
[en-us, de]
[XML_DA_VERSION_1_0]
Process finished with exit code 0
@Kevin.Herron greatly appreciated thank you. I see that you have not only done java version compatibility but also made it so its mainly based off of
import org.opcfoundation.xmlda.*;
Looking at the available SDK examples I had originally thought about using “opc-ua-device” but it seems like the wrong entry point because what we want to end up with is this:
So it seems to be that if there happened to be an example that is the OPC-DA driver modifying that is really the shortest path. But I see that the OPC-DA module is a paid module so probably not.