Can the Ignition Client be embedded in a Web Browser?

I am working on a project where Ignition is being used primarily for database interaction, historian, reporting, and some limited user screens. The bulk of HMI screens and process control is being done with Factory Talk View SE. I’m being asked if the Ignition Client can be embedded in a Browser Object (ActiveX control) in a View SE screen. I’ve done a quick search but as yet haven’t seen whether that can be done and if so how. I’d like to get some input from anyone who has done this, or at least tried to.


I haven’t done this, but I can think of two approaches:

  1. Use IE’s embeddable browser with an Ignition App in Plug-in mode,
  2. Experiment with Java’s NetBeans Bridge for ActiveX.
    The latter probably would need some guidance from IA, but looks like a relatively low-overhead approach.

If the Browser Object supports HTML5 canvas, you could try using the mobile module. It’s probably going to be a poor user experience, but it might be the only realistic way to do it.

pturmel, our View developers were expecting to use the solution you labeled as #1. I’m not familiar with the “Ignition App in Plug-in mode”. I did a search on that phrase but came up short. Can you point me to any documentation on this?

Kevin, you’re not giving me much hope! :slight_smile:


And my guess is that the control in View uses an older version of the IE browser, but I don’t know that for sure. It would surprise me if the control that comes with View is HTML5 compliant.

To work, the browser control has to support the java plug-in, have all of the relevant security blocks lifted on java applets in the browser, and the ignition client app has to have applet mode enabled (see the project properties page in the designer). See the applet section of this page in the manual.

Here’s what I’ve discovered in the event anyone else stumbles across my question.
There seem to be 3 ways to do this:

  1. Using a Web Browser control that can load a Java Applet Plug-in. Tech Support suggested to NOT use this solution due to the trend for browsers manufacturers to remove support for this plug-in.
  2. Using the Web Development Module web pages can be created (outside the Ignition Designer) that can then display data on pages in a browser. This requires, as Tech Support put it, “specialized programming expertise” to program the web pages. It would also create other components that need to be maintained and supported. Not a great option for what I need.
  3. Using the Mobile Client Module a URL is utilized to launch the client on the Gateway, in its own JVM, and the graphics and data provided to the browser. This increases resource requirements on the Gateway server based on how many concurrent JVMs are launched. For my use I think this will be the best option, though I’m not 100% satisfied with it.

There you go and I hope that helps someone else down the road.

You can also chose not to embed Ignition into SE and instead run a client in the background and have the operators use ALT + TAB (assuming Windows OS) to switch between the two applications. This is what we do, because of AB’s, let’s call it, non-support of Active-X objects.

This also shortcuts the less user-friendly mobile client which is not great for applications that need a lot of operator interaction (imo).

1 Like

I would assume that this is not a single touchscreen HMI that you are using… Another option would be to put a second monitor just for the Ignition Client. I have a system that uses 10 RSViewSE Clients with Ignition for History / Reporting / Alarm/SMS Dial-out. This system uses 12 screens between 3 desktops - at any given point the operator can make whatever screen work as they need.

These are single monitor Thin Clients which access the View app on a Terminal Server. The project leads are directing us to utilize only the View screens as the HMI so the customer only has one package to deal with (or at least it will feel that way to the operators). These recommendations follow how I would do things if I had my choice. Unfortunately I’m having the choice provided for me and I have to make it work as seamlessly and efficiently as possible within those constraints. Hence I think the Mobile Client is going to be the best of 3 not so great options! :frowning:

Thanks for the input!

Note that there is a fourth, significantly faster/more cross-compatible solution coming with Ignition 8.0; see: Ignition Community Conference 2017

While it’s certainly going to be a better UX, the demand for a modern browser is actually far greater than the current mobile module.

We have a similar set up.

13 single monitor Thin Clients accessing the View and Ignition on 2 Thin Manager redundant terminal servers. Windows 2012 R2 OS.

I understand the need give the appearance of interaction with just one application.

One viable option that I can think of is to provide a navigation button in the SE App which appears to function like any other navigation button, but in reality is bringing the Ignition Application to the foreground. You would have to use (in my case Windows API) to accomplish this which understandably can be finicky and difficult, but if in the end it allows for a better experience that doesn’t run quite the risk of being broken, then it would be worth it. Obviously just a suggestion to add on to your already not so great options.

Option No. 3 can definitely be made to work, just be warned that at any time Rockwell can, and probably will, stop providing or supporting the object with the SE application, in which case you’ll end up with a broken application. Been there, done that.

The best practice is to keep the plant operation HMI from the analytics/reporting system isolated. In this case, already both systems are very well isolated. Embedding the analytics/reporting screens from Ignition into FactoryTalk View SE will create extra load on the system, trigger instability and may even crash the system.

1 Like