This was something when I first started with Ignition that I was concerned with - documenting each window and each component in each window etc.
What I’ve found and what I think is more important is defining some general guidelines and coding patterns/GUI patterns.
For instance, any window that requires a dataset to populate it’s components - this should be done in exactly one spot on the root container, based on a parameter with the record ID. Then each component should have it’s won custom property that I call initialValue that reads from the dataset with a fallback default value in the event that there is no record so of the form try({Root Container.ReadData}[0, 'someColumn'], 'myFallBackValue') - and then your components value is bound to this. Knowing that every window is setup the same way (or at least very close to the same way) gives me a lot of knowledge over the structure of the program while knowing very little about each individual component.
Other pattern’s I would heavily recommend -
Put all business logic in scripting modules, never on a GUI component itself.
Treat the GUI as just a means of getting parameters to feed to functions in the scripting module - the less I have to click on each component looking for business logic, and the more I can just look at the codebase, the easier debugging is.
Try to come up with naming conventions for your components. Any component that ends up feeding data to the function called on the submit button of a window should have a _out_ prefix to the name - thats what I use, you don’t have to use it, but it makes finding where a certain value is coming from in a function from the GUI much easier.
Regarding templates in vision - since providing inputs and getting outputs from a template are both in the template parameters part, this is even more useful - properties that have an _in_ prefix I know must be provided to the template and then that the template will give me values in parameters that have an _out_ prefix.
“X tag corresponds to Y device”,
Stuff like this I think is best handled with proper folder structure of your tags. Everything being on the top level, even with documentation, I think would be harder to manage then well named folders and tags being in the appropriate folders. You could document the fact that you have a folder per PLC, or a folder per Machine, or per Line, or per whatever unit of “stuff” makes sense for the system you are making.
“Z tag is calculated by function A”
Stuff like this I don’t think it’s necessary to document tbh. If I need to know how Z Tag is calculated, I’m going to open up designer and look at it directly, I’m not going to trust a potentially out of date document.
Just my two cents. The big point I am trying to make - decide on what conventions you want to use in your project and document those.
), creating themes with unique color palettes, and assigning colors to tokens on a per-theme basis. All the data is stored in a version control compatible format, and based on initial results the client-side performance is much better than existing client tag/script module color storage methods.