I am attempting to connect ignition to a Citizen Swiss lathe. Is ignition compatible with MTConnect?
We don’t have any support for MTConnect.
You can use Kepware though, which does have an MTConnect driver, and the make an OPC UA connection to their server.
You are missing out on a significant portion of the market by ignoring MTConnect.
Seriously though, I’ll try to keep it on the radar for after 8.0.
7 Likes
Innorobix Automation developed an MTConnect module for Ignition that can be connected to multiple agents. The neat feature about this module is that it will dynamically create and sort the associated tags per agent and make them available in designer under providers.
Feel free to reach out if you want to see a demo.
5 Likes
What are the benefits of getting MTConnect data into Ignition? I can think of OEE as the only obvious usage, but other than that? Reports? Dashboards? Will Ignition not be an overkill for it? Would appreciate your thoughts on this.
The main push for this connector was to collect OEE data but like you mentioned, the reporting and dashboards turned out to be as important. Implementing Ignition just for the sake of OEE would be an overkill but the intent of such driver is to complement to the overall offering of Ignition and the convenience it provides.
4 Likes
the tags are not creating automatically. I am on Ignition version 8.1.15
The driver is particular on the version of ignition running and the correct module version must be retrieved from us. Reach out to us on our website contact form and we can make make sure you have the correct file and get you sorted out.
We are about to start using MTConnect with some of our machines. Is Innorobix the only solution for Ignition? Or does Ignition have plans to start supporting it?
There's nothing imminent, use whatever is available now.
MTConnect is a relatively simple protocol - I used a Gateway timer script with system.net.httpGet and import the python xml library to get the few pieces of data I want from the machine.
1 Like
Since I don't know yet exactly what kind of data I'll be needing to pull from it, that might be an acceptable way to go. But if you want real-time updating of the data, isn't that a bit clunky? You'd have to execute an HTPP GET request at least once a second...
Just a note on this because I was browsing MT Connect topics.
OEE, Reports, Dashboards but more importantly ALERTS and Ignition makes it easy to integrate with other factory floor devices and software (like Maintenance).
If I can avoid one more application-specific software package, I'll do it.
Inevitably a machine monitoring solution for MT Connect won't have the flexibility of Ignition, and it's one more proprietary-report-building-system that you have to get to know.
1 Like
I started playing around with MTConnect this afternoon, some experimentation: GitHub - kevinherron/mtconnect-java: JAXB code generation for MTConnect with Java.
Not to imply this is suddenly on the roadmap, but at least this unknown is now known. Maybe useful to somebody else in the meantime.
MTConnect has a surprisingly complex data model and while they've been disciplined in the evolution of the schema, that means there currently FIFTEEN different versions of it, which means as an application (as defined here) that wants to consume MTConnect... you potentially need 15 different sets of generated bindings.
And then presumably your code would be a nightmare of switching on the types (the names of which will clash except package name, btw) across all the binding versions as you tried to consume/process the data from the MTConnect HTTP endpoints.
Kind of disgusting, really...
@cmisztur2 for some reason I've associated you with MTConnect - does this sound about right?
Note to self: what this really means is the JAXB approach is a dead end, and applications instead need to use a generic approach, i.e. either parsing the whole XML document with DocumentBuilder, or probably better, processing it with XMLStreamReader. Boo.
You aren't wrong. I penciled this in on my longer-term to-do list, with an expectation of using stream parsing. It won't hurt my feelings if you beat me to it. /:
@Kevin.Herron sure does. Are you counting 15 because of the XML schema versions?
The device model isn't that complex. It's dataitems/observations within components within components. But very few people take advantage of the model (/probe endpoint) and are more interested in the key-value pairs of DataItem Id and DataItem Value. So something like Device/Axes/Linear/X/AbsolutePosition doesn't mean much to most, they're more interested that XPos=15.12.
The exchange goes like this, hit /probe endpoint to get the model. Do something with the model. Hit /current endpoint to get the current values for everything, then poll or stream /sample endpoint to get the deltas. In Agent 2+ there is also MQTT and Websocket sinks. If you have an old agent and can't upgrade it, you can setup an Agent-Agent connection, in which the newer version Agent is now able to serve up over MQTT/WS/HTTP.
Alternatively, DIME (Machine Data Integration — Mr. IIoT) has support for MTConnect and SpB.
Last year we started working on a MTConnect SparkplugB companion spec with Arlen. The work stalled but we came up with a nice demo. The right way to implement bridging the specifications is to use SpB Templates so everything unfolds nicely into Ignition UDTs.
Yeah, there are 15 schema versions, and with the JAXB code generation approach that's 15 sets of bindings only compatible with the version it was generated for.
I was looking at this in the context of mapping it to OPC UA using the MTConnect companion spec, which brings with it the burden of the full complexity of the schemas.