Documenting the Event-Driven-ness of Ignition programs?

Our company is trying to document our projects so if someone has to come and work on a screen in a project they don’t know anything about, they can read the documentation and be able to dive right in. How do you document your Ignition projects?

I was thinking perhaps each possible user event is how I can divy up each screen - pressing X does Y processes, checking this box alters Y processes with this condition, pressing this other button calls script Z. And in addition to each window having each user input documented in what it does (either sematnically or with code), that we would have a separate page regarding all gateway driven and run scripts. This is only what I just brainstomed though, I’m not sure if it’s actually a good way to implement documentation. How do you guys document your Ignition projects so that if someone had to take over a project you worked on, they could read something and be able to jump right in?

We document inline in code.
The standard interface documentation is done by the operators in VWI or SOP forms.
The actual inner workings of buttons, scripts, functions are documented right in the code so the developers can read it as they go into it.

1 Like