Want tips -How Do You Organize Your Ignition 8.1 Projects?

General Discussion
1

Hey everyone,

I am working on a medium-scale project that involves multiple UDTs, tags & views. I have gone through the official docs & a few tutorials but I still feel a bit lost when it comes to organizing everything for long-term scalability and ease of maintenance.

I want to get input from those with more hands-on experience. How do you usually structure your projects? Any go-to naming conventions for views, templates or tags that help keep things clean and consistent? Also, do you prefer using embedded views or templates when building reusable UI components?

While brushing up on related tools, I also came across a helpful jira course online, which gave me some ideas around workflow & version control—curious if anyone here integrates JIRA with Ignition for project tracking?

I Appreciate any tips or suggestions.

Thank you.:slight_smile:

2

Check out this thread for some good ideas on conventions and best practices

https://forum.inductiveautomation.com/t/dos-and-donts-when-developing-first-project-with-ignition

1 Like
3

Some guidance on project style can be found in this file. It's written for Exchange projects, but still very applicable — just ignore the “exchange” root folder shown in the examples.

For Views, I usually create a folder for each main navigational section of the UI (e.g., Dashboards, Admin, Energy, etc.), and additional folders for logical groupings like Framework, PopUps, and Widgets.

When building a view, I try to minimize the use of 1-off components — I rely heavily on reusable elements in my Widgets folder. The same concept applies to styles: minimizing 1-off colors and applying centralized styles is a big help when coordinating (and updating!) a unified color palette across the project.

I've used Git for version control in the past, but with a fair amount of friction. I've held off on further refining that workflow and am eagerly awaiting Ignition 8.3, which should make this much easier.

4 Likes
4

I mostly use embedded views for reusable components, but be aware that they come with a performance cost, especially if you go multiple levels deep. There's a good discussion about this here.

For folder structure, I typically nest /Embedded and /Popups within my main view folders. My projects all inherit from a Master project that has a root UI folder where I store all the reusable components.

Every project has a corresponding development version where I do all my building and testing before exporting changes to the live version. They use the same name, but lowercase and starting with an underscore, so I develop in _master and deploy (export) tested changes to Master.

2 Likes
5

"Template" Views are great, but you do have to be cautious of not nesting too deeply otherwise you'll run into 2 issues: client page load speed impacts, and more importantly, bugs where params at lower nest levels are not consistently passed down. I'll try to come back to this post with other things when I'm back in the office

Edit: looks like @Ryan_Deardorff beat me to it!

1 Like
6

In terms of organizing projects at the gateway level, I do like to dedicate a separate project for just alarm notification pipelines. This allows you to make changes/additions without causing a change in your visualization projects. I even go as far as creating a separate project for reporting and scheduling delivery. However, the report viewer can only display reports within that same project. I have lobbied for reports to be a shared resource across multiple projects, but unfortunately have been unable to convince the powers that be on this.

1 Like
7

Good or bad, I can tell you what I've done for a new green field with a dozen projects, 20 or so PLC connections, etc.

Each Project, Device Name, Tag Provider, etc, keep the same name with a suffix if that's applicable. Most of my clients are tied to a specific PLC, so that naming helped keep everything related and organized.

Within Projects, Folders are organized for windows by function. Each function has a Main Windows folder and a popup windows folder.

I know many believe in inheritable templates, but for me personally, it's easier to just export the templates I need from one Project to others. I'm in designer anyway, so if i modify a shared template, it's literally a couple of clicks to send it to other projects.

Same for copying UDTs between projects. Having to move UDTs to different Tag Providers is an extra step, but one I prefer to use for portability and keeping everything tied to a project. Many may frown on this approach, but it's worked very well for me.

Early on, design your alarm management. Whether using Display Paths, Pipelines, etc, put alot of time outlining this before creating the first tag. Im personally a fan of Display Paths and have that routing buried in my UDTs, but theres many ways to skin that cat.

Create a navigation scheme and stick to it. I created a two level navigation scheme that creates groups, and specific areas within a group. I'm personally not a fan of the Tab navigation widgets. Share this navigation to all projects for consistency.

My personal preference, design in the common native resolution that will be most used by clients. Ignition does a fair job of scaling, but why should it. Build to the pixel size of your native resolution.

Read all the tips for how to pass tagpaths for popups, how to optimize data and communications, how to optimize historian data collection etc. Making a wrong turn can severly hamper server performance. We're at about 150k tags, shared among a dozen tag providers, a dozen clients, and our server load is less than 20%, our device overloads are at 0%, and our memory is between 3GB and 5GB. So far, fingers crossed, everthing remains snappy.

3 Likes
8

I typically create a "Backend" project for this reason and add other scripts and gateway events, WebDev resources and such in there that will not affect my front end projects.