Ignition Perspective vs. Vision Mobile Module: Best Practices for Moving Forward

A discussion with Adrienne Harvey and Andrew Geiger

Adrienne: Today we are talking about Vision Mobile Module versus Perspective. Originally, I was looking at this topic to confirm that the Mobile Module for Vision had been discontinued in Ignition 8.1, and to verify that Perspective was first launched as part of Inductive Automation Ignition 8.0.

But, before we get into that, what are the biggest differences between Vision Mobile Module and Perspective?

Andrew: Think of Perspective as a way to deprecate the Mobile Module. The Mobile Module essentially creates its own Vision clients and then serves them directly. It's closer to a VNC connection than it is to a webpage. By contrast, Perspective behaves as—and is literally—a webpage served from Ignition.

The resource usage is better with Perspective. You can handle more clients and more functionality because the technology behind serving webpages is better than when serving thin clients remotely—which is basically what the Vision Mobile Module did. It spun up a little Vision Mobile Module JVM, and would serve what it rendered over to a device. And all of that comes with the overhead requirements of spinning up your own Java application and more. It worked in the way that blunt force tooling approaches work, and it doesn't have the finesse of a properly served webpage.

Example JVM usage of the Vision Mobile Module

Adrienne: It sounds like there might be some real limitations on how Mobile Module could scale as an enterprise or facility grows.

Andrew: I think that's a huge part of the desire to move away from it. You may have a fairly beefy server, but if every single client takes a gigabyte of RAM and uses its own process, and all those processes have their own little threads and stuff going on... There might be an upper limit of a half dozen to a dozen clients before a reasonable production server starts to get loaded down.

By contrast, a Perspective session is lighter weight; it can share resources on the gateway so you don’t have the same subscription model going on. Plus, there are many optimizations that can go into Perspective. Reasonably, you can have dozens of Perspective sessions where you would otherwise be limited to a maximum of a dozen or so total with a Vision system and Mobile Module.

Adrienne: Wow. That’s a huge difference! Even though it’s being discontinued, are there any reasons to use the Vision Mobile Module or Vision in general instead of Perspective?

Andrew: There are a handful of situations where you may want to use a Vision client as an HMI. When you’re directly controlling equipment, occasionally there are situations where getting ports, certain applications, or things onto the network can be very difficult. In that limited use case, it might be easier to do VNC-style work. Or you may have someone who can't install the Java environment on their computer or whatever they're using, so the Vision mobile client gives you an immediate "okay" fix for getting your application in the hands of someone who has a tablet.

For example, if someone has an iPad and they need to be able to hit a button to turn a machine on and off, that could be an ad hoc HMI—with all of the overhead and gotchas of the fact that Vision clients aren't typically made for mobile. They don't click, interact, or scale the same way. The text will look a little janky, and when you hit the buttons it's just not quite right. But it works and if it's designed to be chunky enough, you're good to go.

For many applications, that's enough to put tooling in the hands of the operators. Sometimes that will lead to saying, “Now, imagine if we did this even better via Perspective” and “What if you had web layouting” and “Imagine if Webkit did its job!” That sort of thing.

Adrienne: That's a good segue into my next question. What happens if you're currently running Ignition 7.9 with Vision Mobile Module and need to upgrade Ignition at your facility? Will you need to make the jump to redeveloping those Vision projects on Perspective at that point if you've created an ad hoc HMI on a tablet? What would you recommend in that situation?

Andrew: There are a few different approaches, and they depend on the size and scale of your company. Even more specifically, you'll need to consider the size, scale, and complexity of your Vision projects. For basic HMI work like open/close pump gates, valves, motors, or whatever—where you've got chunky buttons that do simple things—just translate from one to the other by remaking the screens. Perspective is pretty quick to use, and—once you get used to it—fairly straightforward.

If you have giant sprawling screens that are fairly sophisticated—as many places do—depending on your complexity level you may choose to "automagically" convert them from Vision to Perspective. Or grab the structure in Vision, compile it down to a middling specification (such as a JSON description of everything in all your windows, all the bindings), and then translating that into Perspective. From there, you can tweak it by hand to make it look nice. That approach is necessary for places with a hundred screens that are doing reasonable things that aren't wild and complicated—and you have a team of only five programmers or developers to work on it.

When you have really large, complicated sprawling projects, it will really be remaking the project as a version 2. You'll rearchitect it from top to bottom with best practices. You'll put all your styling in one place, whereas you didn't really do that in Vision. You will take full advantage of nesting your views.

Adrienne: Once again, you're almost getting into my next question! Other than the two best practices you just mentioned for developing in Perspective coming from Vision—all styling in one place (I'm assuming with CSS), nesting the views... what are your ideas about the best practices for redeveloping Vision projects in Perspective—especially if your background is strongly in Vision?

Andrew: As with everything I say, it's going to vary with the situation, so take it with a grain of salt. I can come up with counter examples to everything! But, I think it can be challenging for people coming from Vision because they're not used to the paradigm that Perspective uses—which is closer to web development work.

It's not literally web development style work. And that's kind of a "gotcha". You mentioned CSS, and if you are really clever, you can absolutely use that in Perspective. But I was talking about the styles in the Designer related to making all the headings look like this, or choosing one font for all of our input fields. You can't do that in Vision because of the way Java beans work inside of it. You just don't get to control that in Vision, it's not an option!

In Perspective, it's perfectly natural. So there's a lot of little things to look out for—in Perspective, Views are similar to templates in Vision, but they are not literally templates. The way you move values into Perspective views is not the same as in Vision templates. It feels similar, but it's not the same. You have to know what direction your parameters are going in, and many people mix that up. Even when they're taking the Gold certification test, a lot of people—and it even happened to me—wondered why it wasn't working and it was because the parameters were going the wrong way. Oops.

It's the little “gotchas” where you may have not noticed making a little mistake. The other issue is that Perspective has a lot of analogs that are more refined than their Vision equivalents. For example, Vision has client tags that are basically "in memory" tags that just run on the client. They're super helpful for caching and buffering, given as global variables in the JVM. Perspective has session properties, some of which are controlled by Ignition itself. Take advantage of those because they're your version of the Vision "in memory" tags.

Also keep in mind that in Perspective, you have sessions not clients. They're not an isolated JVM. You can send messages between sessions and pages. There's a lot of scoping, and a huge amount of keeping the layers straight in your head. It's difficult at first, but with practice you'll get used to it. Whereas in Vision, you have a window and it's got a template. If you're a glutton for punishment and/or abstraction, you've got a template repeater with templates inside it that themselves may have a template canvas, but it's very obviously layered that way. You can see it on the window itself, whereas in Perspective you're going to see each one on their own until you render it in a test.

Adrienne: What's your advice for developing in Perspective in general, as opposed to coming from Vision?

Andrew: Don't be afraid of having more very specific views. In Vision, it might have seemed absurd to have four or more layers of nested templates. But in Perspective, you'll go past that a lot. I don't want put a number on it, but a dozen to twenty, and you might not need to reason about it. You want to design your views so that they're self-contained, and do their own thing. They shouldn't care what other views are doing. You want to make little self-contained bits that you can add to your screen as desired.

The more you can self-contain and reduce the coupling between components, the better off you'll be. Perspective makes that easier, but it's also a little bit harder to put coupling between windows—unless you abuse messages (and try not to abuse things).

I'll also mention that it's fairly easy to use transforms for projects of reasonable size and scope. Transforms are just a godsend. Now, instead of having all of these "on property change, check which properties change" you just put a binding down and add a transform to it. Then you put your script specifically on each thing that you care about changing. Get into the habit of isolating your work to where it matters. Also keep in mind that everything can be written to for the most part. It will take time to get all the little details in Perspective.

Every component has its own characteristics, just like in Vision. A power table has extra properties beyond the data property—and is different from a regular table even though there's some overlap. The same is true for Vision and Perspective, you just need to learn the differences. So memorize, experiment, change things, and relearn.

The only other thing I recommend is to really learn and understand how the layouting works in Perspective. You need to know how auto grow and auto shrink affects the flex layouts. Coming from Vision, it's going to be frustrating at first. But understand that there's a logic to it, but it's much different than the layouting engine that Vision uses. It's closer to what you might expect for webpages and is similarly very sophisticated.

Adrienne: I definitely noticed that working with Flexbox didn't seem intuitive at first.

Andrew: Right, it's not quite what you think it is at first glance. Perspective is a bridge between controls engineering and web development, but it's neither, it's in the middle. As a result, the abstractions leak both ways. But once you get used to it and [start] understanding how they're married, it becomes much more intuitive in the same way. Ignition is difficult because it has expressions, SQL, Python, and Java—and you have to understand how they all work together.

In Perspective, it’s very easy to switch between themes to dramatically change the way your views look.

Adrienne: Do we know if Inductive Automation plans to eventually get rid of Vision entirely?

Andrew: As I understand it, they have been threatening to get rid of Vision for a long time and can't because people are still using it. Yeah. And let's be honest: in this industry, if something hasn't been out for 10 years, then it hasn't really been tested. There's a reason why the Logix 70 series processors had a Pentium 90 in it. And it was screaming fast, because the previous version was an i386. They do that because they're bulletproof. And even in SCADA software, you still have this desire to use older bulletproof technology that has people who can support it. Because if it's been around for five years, there's probably people who've been using it for a couple years.

But, they want to get rid of Vision, because of the upkeep and complexity of maintaining discreet Java clients all over the place—and managing Java installations are hard. But the utility of having a remote client and remote viewing on something that can be managed by IT separately is really nice to the point where Inductive Automation made Perspective Workstation. It was specifically made to take the place of Vision clients for situations where there's a computer inside a $10,000 cage sitting next to a machine with asphalt flying all over the place. They can't just put an iPad out there. But Perspective can do that, and they will get rid of Vision as fast as they can.

Adrienne: That's similar to the impression I was getting. When I was first learning about Ignition, I was a little confused as to why are there were two modules that seemed to do nearly the same thing.

Andrew: We're in the "missing link" phase of going from Vision to Perspective where both are available. We need both because we're running production and the machines can't stop just because developers want to change a font more easily. Sometimes you need both at the same time and you might want to run both in parallel—there's many, many reasons to have both while transitioning over. But if you start new projects, start them in Perspective, even if you're more used to working in Vision.