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 @PGriffith 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 customisers (i actually don’t know the word for them…) 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.