How easy it was to to extend an ignition platform with custom Java classes/modules?
If you are an experienced Java developer it’s not very difficult to take our Module SDK and get started building custom modules.
If you aren’t an experienced developer, well… you’re gonna have a bad time.
Yep, Java/J2EE is not for the faint of heart, Python was a good call in that regard.
So following that, I’m assuming JNI is also possible? And are there possibilities for rolling your own non python modules etc. to your “native” client?
I’m still trying to get a handle on the capabilities of your product, as a system and as a platform.
[quote=“timoc”]Yep, Java/J2EE is not for the faint of heart, Python was a good call in that regard.
So following that, I’m assuming JNI is also possible? And are there possibilities for rolling your own non python modules etc. to your “native” client?
[/quote]
You don’t actually need any J2EE knowledge. Our gateway happens to run inside a Tomcat, but that’s about it. At most you might need to know how to implement a Servlet if your module needed to add one.
Sure, JNI is possible, but not exactly encouraged. It’s hard to keep up the cross-platform promise when you start using JNI. We use it for a few of the modules (OPC-COM, Serial Support, ActiveX) and it’s not without problems.
And yeah, you can create modules that have a presence in the designer/client as well as in the gateway. All of the OEE/Downtime stuff, for example, are modules that play in that scope.
[quote="Kevin.Herron"]
You don't actually need any J2EE knowledge. Our gateway happens to run inside a Tomcat, but that's about it. At most you might need to know how to implement a Servlet if your module needed to add one. [/quote]
I'm new to Ignition, so I thought it used Wicket at its core, but now I'm guessing Wicket came later. What do you use for client to gateway communication/synchronisation?
[quote="Kevin.Herron"]
Sure, JNI is possible, but not exactly encouraged. It's hard to keep up the cross-platform promise when you start using JNI. We use it for a few of the modules (OPC-COM, Serial Support, ActiveX) and it's not without problems. [/quote]
Understood, JNI can be a nightmare, but cross-platform is less of an issue from my perspective.
Great.
[quote=“timoc”][quote=“Kevin.Herron”]
I’m new to Ignition, so I thought it used Wicket at its core, but now I’m guessing Wicket came later. What do you use for client to gateway communication/synchronisation?
[/quote][/quote]
It does use Wicket for the gateway. Client<–>Gateway communications are done via HTTP calls.
[quote=“Kevin.Herron”][quote=“timoc”][quote=“Kevin.Herron”]
I’m new to Ignition, so I thought it used Wicket at its core, but now I’m guessing Wicket came later. What do you use for client to gateway communication/synchronisation?
[/quote][/quote]
It does use Wicket for the gateway. Client<–>Gateway communications are done via HTTP calls.[/quote]
HTTP? That changes a few assumptions I had. Possibly I’ve got it wrong, but i have been assuming that you have a gateway server that manages a Web Interface that is capable of deploying local Java Swing clients.
If you’re using HTTP for both, then i Guess you synchronise state with pull rather than push? If that is true, how do manage real time performance without saturating your link/increasing latency? Or is the real time only for JVM based controls?
While the clients can be launched on the same machine as the gateway, they are typically launched all over the network. They use a configurable poll rate to keep their tag subscriptions up to date. I think this is 250ms by default. Network saturation has not yet proved to be an issue for anybody… We tend to have as many as 50 clients open for one of our internal Ignition-based applications with no problems.
As with anything that is supposed to be real-time on non-real-time hardware/OS, it’s only “real-time”.
But I think you’ll find it’s plenty fast enough. I can toggle a switch on a PLC sitting on my desk and see it update in a client satisfyingly quick.