I would like to have a general discussion about the appropriateness of which method I should be directing my efforts toward. And if there is a more appropriate place to have this discussion, please tell me. I'm just over half way through the Inductive university and discovering stuff that concerns me. Went out on a limb to promote Igniton over PlantPAx (that I know well) on a CLX plant control system - while knowing nothing about it. The current demonstration plant has some 500 I/O and about 50 VFDs and protective relays connected via Modbus. The eventual real plant will have 10 times of each type of hardware. The amount of code for each little thing has me quite concerned. At first I tought Perspective would be a good solution because there is a desire to have operators with iPads or iPhones in the plant. Then I find out that there are no drawing tools for Perspective. Should I develop the solution using Vision? What do I loose with that? Is there a better/other way to learn that I should be exploring. Got to admit I'm finding it painful.
If you have prior experience with conventional HMIs and branded SCADA (Rockwell, Siemens, Aveva, etc.), you will get up to speed fastest if you develop in Vision.
If you have specific things you want available on mobile, buy both Vision and Perspective licenses (I recommend this to all my clients) and do those tasks separately.
Perspective does require more code than Vision, for a few reasons:
-
The historian and databases produce datasets that usually need transformation into web-friendly JSON. ("Usually" meaning "any time you want per-row styling", and sometimes more often than that.)
-
Perspective strictly isolates components in its views from components in other views, including nested or repeated views (the equivalent of Vision templates), requiring message passing architectures with code on both ends. Vision has no such restrictions.
-
Aside from datasets, there is an "impedance mismatch" between strictly-typed java objects, and loosely-typed JSON/javascript objects, which can require developer intervention to get the right results, particularly for date/time data types.
You might find the various pros and cons discussed in this topic helpful:
Other topics linked within that one may be helpful, too.
Thank you pturmel, those are some good hints (and I followed down the rabbit hole on some). For now I have decided to concentrate on the Vision side to be able to make some progress building something real (and keep aware there are other possibilities when the learning curve tapers down). Thanks again.
I agree with everything @pturmel said.
some notes on perspective.
There is a learning curve and you have to learn responsive web design techniques, SVG development techniques and CSS to develop perspective apps that people would not realize are webpages.
Perspective handles embedded SVGs very well. Drawing tools are on the roadmap but you can develop amazing and responsive HMIs in perspective if you know how to draw SVGs. It is certainly possible to run entire plants on Perspective apps.
I use inkscape to draw my SVGs and always save the production version of an SVG as "Optomized SVG" which reduces the metadata and makes it a smaller load. If you do this you can draw symbols that load very fast. I have replaced a lot of legacy HMIs with Perspective apps that look better and load faster than the original because I'm loading small SVGs. You can accomplish load times with animations that basically look like a flash.
Perspective doesn't do momentary buttons. IMO, you should generally avoid using momentary buttons. You probably have some in places they don't need to be and would need to add some PLC logic to make them work well with perspective.
General Ignition notes...
You can scale Ignition to basically any level but you want to make sure you build infrastructure that can support the amount of things you're integrating. My recommendation is to start with a server and 1 system. Keep an eye on server statistics as you add systems and either "scale out" the system or split out to additional tag servers as needed. You can adjust scaling as needed down the road and this forum is loaded with people that can help you do that right.
Just because you can drag/drop tags to sub them doesn't mean you should. I've seen people sub 200k+ unused tags... It's not a good idea because it needlessly consumes system resources. I wanted to mention that because every tag you sub will create load on your gateway so don't get carried away.
Ask questions on this forum if you're having tag performance issues and a number of people will typically help you come up with a good solution. I use the search here a lot as well because I seldom run into something that isn't already answered here.
I don't post much on this forum. I mostly lurk but it is a very good place to get information.
Edit:
I forgot to mention. You can try things out without buying Ignition. Just download Ignition, configure a topic to a PLC and try things out. You can run off of it till you have an activation because you have to reset the trial every 2 hours but it's great for proof of concept efforts.
Thanks for your detailed comments Steve! At the moment I am really conflicted. I'm working through some (on-line with a PLC) examples. Originally with Perspective as that was the path I was intent on going with my first project. Then, based on some forum comments that my background in RSView and PlantPAx development is likely more applicable with Vision, I pivoted to Vision. With some help did some coding for a conveyor object on a canvas. But since that's not visible in design mode I really don't like the solution either. Now I will try out some SVG as you are suggesting, I do value that Perspective opens up the iPhone and iPads for use in the plant. Are the SVGs under Perspective fully visible in design mode, so that someone not so fully versed in development can make minor adjustments without destroying the whole thing?
Do you mean "design mode" versus "preview mode" or just "in the designer" ? As the paintable canvas certainly works in the designer's preview mode.
There's no wrong answer here. The community is great; official support is easily accessible; the documentation and training programs are the best I've seen (and free). Whichever way you choose to focus in ignition, you will have a high level of support, so it won't take you long to become proficient at creating.
Yes the paintable canvas content is visible in the designers preview mode. But that makes for a very annoying effort positioning something: in design mode, move it a few pixels - maybe change the angle, into preview mode to have a look at the alignment, back to design mode to move it some more, back to preview mode to have another look and maybe repeat a few more times. That's not a reasonable setup.
Oy! And you expect pixel-perfection from Perspective? Brace yourself.
Phil, is that an unreasonable expectation? Am I looking at the wrong product altogether? In the various demos and Ignition tutorials on Youtube I do see a lot of flashy animation and colourful transitions that my operator interface designer self discounts as not just unnecessary but undesirable, but given that ability I was expecting that it should be able to do a better job than say Cygnet at aligning process piping, tower innards, and so on. When I show some 50 or 60 valves on a screen I sure want them on the same pixel alignment. I don't care that they anatomically look like a valve. Are my expectation out to lunch?
I hadn't considered this, but see your point. Another option would be to create a png of a horizontal conveyor, and use the image component to render it. The image component has a rotation property that could adjust the angle, and it renders the image in the designer even when not in preview mode. Just make sure the png is perfectly square so it stays in bounds during rotation
I do this sort of thing all of the time in Vision. That's what these buttons do:
You can also select a component and press ctrl-p to explicitly specify the location and size:
I do too, but only when setting everything to Anchored layout. It is not, cannot be, completely reliable with any scaled layout. Unless, perhaps, you draw everything with a paintable canvas.
In Perspective, it can only really be achieved with unitary SVGs. So far.
Justin, I dug into the code you used for the conveyor example and in general I like the way it is done (and I have experimented a bit with it. It's just when I look ahead, after I complete a project, I do not like to leave an end-user staff with something they cannot be expected to support (I'm not interested in building myself a bunch of dependents). And to follow the conveyor example a bit further, I will likely create a motor canvas object and an adjustable gearcase that will have to bemated up with the conveyor at some angle and still look good (well aligned). Phils comment got me a bit worried, It looks to me I will really have to stick with Vision to create the interfaces my clients have come to expect from me.
Also, you don't necessarily have to build everything from scratch. Ignition has an exchange where contributors share things they have developed:
https://inductiveautomation.com/exchange/
To save some time, you can always check it to see if what you're imagining has already been created.
As an end-user, I'm not sure how to take that. I'm expected to support anything on our floor.
Then again, perhaps I'm increasingly becoming an exception.
Jordan, the client technical people that I work with are usually quite explicit about not wanting any scripting in their HMI applications. And while there is usually someone in their organization that can support such things, the regular shift support people (such as electricians and instrument techs) might at one time have taken the required support courses, but hardly ever are expected to dig into scripting. You should take my comment in no other way than that I'm trying to support the client staff in the best way that I know how.
I understand this desire, and agree for many, maybe even most, cases. Expression bindings should always be used before scripts of any kind, where possible. Unfortunately, as mentioned above, Perspective, out of the box, requires script transforms almost everywhere. (Only a slight exaggeration.)
This past summer's expansion of the venerable Simulation Aids into my Integration Toolkit was entirely due to my frustration with that. Consider adding it to your projects, whether you use Vision or Perspective, but I think its tools are essential for development in Perspective.
I think Vision is the closest to a direct analog to the platforms you mentioned. I haven't used plant PAX so I'm assuming there.
As for scripting, you're more likely to need to write Python scripting in Perspective. Anything advanced will have script transforms. That said, there are 2 levels of scripting. There's simple scripting to do simple things such as you'd do in a script transform and there's library scripting to do code library kind of things. You usually don't need to do that.
Perspective drawing tools aren't out yet and you can have scaling issues in some situations. I saw some other people gave some tips there and I would heed their advice. I don't have time at the moment to thoroughly read all of it and give you additional tips.
Perspective has a lot more learning curve than Vision because it's new and web oriented. Vision is a mature product so it has more tools out of the box already built for you and it's more similar to other HMI technologies. Perspective does responsive design though. They aren't built to solve the same problems.
I would recommend learning both. You don't need to have an activation to tinker. Both are very useful. Ask questions on this forum and experts in both will typically help you.
Also, when you build things; make them modular and easy to understand. People are against scripting in HMIs because they're thinking of the old school custom ActiveX and VBA stuff that caused a great deal of pain for generations of people (DLL hell, etc). It doesn't have to be that way.
This is perhaps the most compelling reason that people look forward to Perspective due to its responsive nature that fits all devices like phones/ipads/Android devices/web browsers.
However, I wonder how much of SCADA functionality is accessed thru iPhones/iPads? In my opinion a smaller % or a subset of SCADA functions based on roles or areas of plant should suffice on iPhones/iPads leaving full features of SCADA to be accessible only on desktops/laptops on web browsers clients in control rooms/LAN clients where the responsive design isn't a must.