Hey there, I am a relatively new controls engineer who has found myself a job where I do a lot of work with and in Ignition. I have a couple of years with java and python each so I have some idea of good coding practices but as far as Ignition goes I am more or less using my best judgement and following some of the practices my predecessor had already implemented. Is there a place/videos/class where I might be able to find some good implementation practices for various aspects of Ignitions suite? I just want to more or less make sure I am creating legible, maintainable, and future-proof systems in Ignition. Any help is greatly appreciated! (Sidenote: I do believe I know how to use and navigate most of if not all aspects of Ignition so not really a novice in that aspect, IMO) Thank you!
This is an interesting question, because it's true that most of IU is geared toward beginner level/just getting started content, and we don't really have much that targets the intermediate-to-advanced skill level.
I'll start with some general wisdom:
- If you don't have to script it, don't.
- If you do have to script it, prefer to write it in a project script rather than a 'magic pushbutton'.
- Don't repeat yourself, but also write everything twice, because bad abstractions can hurt more, and chances are pretty good you aren't gonna need it
- In general, lean on the tools that are available to you, and practice saying 'no' to feature requests. Ignition is a flexible enough platform that the answer is often "yes, technically", but maintaining that one-off (that turns out to not be very important after all) is often a huge pile of technical debt that wasn't worth it.
This is actually super helpful! Thank you very much!
In addition to everything @paul-griffith just said which I endorse (especially avoiding the magic pushbutton which in my experience is the biggest obstacle to making a project easily maintainable/expandable) and covers scripting concerns, the other biggest item that can make a project nice and easy or a nightmare to maintain is database design.
Learn how to design normalized databases with proper foreign key/uniqueness constraints, with proper security roles, and putting all your data concerns as NamedQueries which will help you create single sources of truth for datasets. In addition, know how to interact with a database via scripting the right way especially regarding UNIQUNESS as I outline here - Insert into database only if the entry doesn't exist - #2 by bkarabinchak.psi
Unrelated but avoid using runScript in expressions if the script you are calling involves round trip communication to the gateway as it can cause problems.
Yeah, database design is a good note to hit.
It applies more to new systems than maintaining/upgrading existing ones, necessarily, but designing your tag structure well is a big point. Reorganizing tags (and their associated history, alarming, uses in scripts, etc) after a system is in place can be a bit of a headache. Better to decide on as much of the structure as possible before putting everything else in place.
Interesting! The database design at my current job is pretty well done (appropriate lookup tables, unique entry IDs, and great logging of changes) but doesn’t have but a few NamedQueries but that makes a lot of sense and keeps all the queries you’d want to edit in SQL and not in random tables or components. About to take a read of that outline you linked right now! Thank you very much!
Just some other general things:
Perspective:
- create and use a CSS theme with all of your standard colours defined + other customisations
- use Perspective Styles wherever you can to style components where these styles reference your css theme variables for all colours and potentially a lot of other values as well such as margins, border settings, etc.
- know that embedded views add a hit to performance and load speed. A lot of the time this is unavoidable for the sake of maintainability, but just know that every time you embed a view you're adding load time, and nesting embedded views multiplies that for the component.
- knowing some CSS will go a long way to making your screens look better and your designs cleaner. There are a lot of CSS props that can save you from adding extra components to your views for example using margins and padding to add spaces between components.
Vision:
- create a tag (dataset) or tags to hold your standard colours as HEX in the vision client tag area and use these everywhere in your project.
- avoid periodic calls to any of the round-trip, long-running functions such as system.alarm.queryStatus, tag.browse, tag.read/write, etc. As these will kill your GUI.
General:
- create separate databases, one for your history and one for your data. It makes it easier to work in your data database without having a multitude of other history tables cluttering the display. It also makes it easier to backup
- turn on auditing at the very start of the project (this should really be the default option imo - who doesn't want an audit log??)
- UDTs are your friend, UDTType parameters are less of your friend and limit your Template's use-cases.
- when creating more complex expression bindings or even scripts, make them more easily debuggable by not simply reading values directly in the expressions that aren't transparent or easily deduced. Read these values first into intermediate properties and then use those in your expressions. (read into variables for scripts). Otherwise, debugging can become a nightmare
I'm sure I will add more!
There used to be Gold-level only accessible tutorials from Travis etc, is this still current? Tried to find a link and couldn't.
Ah, that’s true, there are webinars and other materials put out by sales engineering geared more towards integrators. I’m not familiar with the exact thing you’re referencing, but it’s also not my area 
You mean this one?
Thanks, yeah it was the Tea with Travis, Coffee with Kevin etc I was remembering (or trying to ).
Well, now I'm sad that I'm not a registered integrator. I can't go there. 
If our only customer is our own company, will I get in trouble for signing up at the basic "registered integrator" level just to go see things like that?
No,
However just take in account that registered integrator is not the same as gold integrator.
Maybe you can talk with your account executive to provide access to the videos you like.
Don’t know why nobody cited this yet but i personally really liked the Design Fundamentals elective studies course on Inductive University, this kind of material really helps beginners like me; Browse the Lesson Library at Inductive University
I would also like to reinforce the tip about tag structure, it makes everything easier because you save a lot of time when making indirect bindings and scripts that work for the whole project
Does anyone know if the whitepaper mentioned around minute 6 has been released yet?
Hi Mr plarochelle, where you ever able to get the whitepaper mentioned? i look forward to your timely response.
Looks like they’re refering to this article: https://inductiveautomation.com/resources/article/ignition-server-sizing-and-architecture-guide
Hi drewdin. Unfortunately I have not. Nice cat.
If I can make a quick gripe/critique about that.
I think someone coming into Ignition, specifically Perspective, from a more traditional PLC/SCADA/HMI environment often has a lot of difficulties adjusting to the more web-based technologies that Perspective uses. There are a ton of considerations in designing a Perspective project that someone from that side of things never had to even think about before, so they're not going to intuitively think of all those factors when designing their first Perspective projects. If you're developing a Panelview Plus for example, you don't need to think about tag scan rates and grouping and structure most of the time. Most of the time, it all just works. You point the object to the PLC tag and you're done. Only in the absolute biggest projects do those things become a factor. (And I'm definitely not suggesting Panelview Plus should ever be used over Ignition Edge. Panelview Plus is evil and gross).
And I'm not saying that's IA's fault or that it's even bad to make people think about those things (I actually think it's good to force some of us old fogies to be more organized and purposeful). I'm just saying that the dinosaur software based on 1990s-era codebases we're used to working with lets us get away with a lot more and obscures a lot of these under-the-hood performance factors away from us. I do recognize that this is often with proprietary knowledge that IA can't have. There's always an inherent disadvantage the more you rely on third party technologies you don't control, but interoperability with standard web browsers is also a huge advantage, and I will say you guys have done a way better job than others.
I have a lot of other examples of pain points with older engineers and good design practices with Perspective, but the point I'm trying to make is that IU is focused on "here's how you do X" but aside from this forum, I haven't found a lot of material focused on "when you should and shouldn't do X" out there. My experience so far has been a lot of:
- Find a way to do something the customer asked for
- Have weird problems creep up later, or the feature breaks
- Search for help on the forums
- Find out the way I did it was totally wrong and I should have done it a different way because of some factor I had no idea to even think about because I've literally never had to in my 20+ years of doing controls, and then go through the painstaking process of finding that balance between reworking the whole thing (which most of the time, there simply isn't enough budget in the project to do so) and cobbling it together to the point where it's acceptable.
I do take those lessons to the next project, and as time goes on, those situations happen less and less, but my experience with Perspective is lots and lots of "if I knew then what I knew now". And none of the really meaty, important things I've learned came from IU. So many times I've done something I shouldn't have done because I didn't know to even look for a reason I shouldn't have done it.
I get it though. Ignition can be used for a lot of different things, and it's such a wide variety of applications, it's really, really tough to say something like "you should never use script bindings," because sometimes, you should. And that situation is more often than not a judgement call with a dozen different factors. So, I don't know, maybe there can't be a definitive "never do this/always do this" list for most things, but maybe there are some really big, common mistakes people make that could be warned about in IU that aren't already. I'm sure you guys are conscious of this. I'm just putting in my two cents.
To be fair, that happens with Vision projects as well. Okay, I'll say it... all projects. I look at some of the stuff from fifteen years ago, and say, "What idiot wrote this... oh... I withdraw the question."