Best Practice for Using Similar UDT's and Global Objects Across Projects/Customers?

Ignition
1

I'm pretty new to ignition. Did the Core training last year and have done two separate projects for the same customer (2 separate sites) and that's it so far. I'm looking for some best practice tips for how to utilize resources (global objects/templates, UDTs, popups, etc.) from one project/customer to the next and for how you develop them on the same gateway (hosted on my laptop) before the gateways get installed on site.

For the first project (let's call it site Customer1, SiteA), I initially used the system tag provider to hold my UDT's and my tags. I made templates (conveyors, photoeyes, etc.) that have parameters of those system UDT types. I made popups that also use those same UDT-type parameters. Popups got called using scripts on the global objects and the parameter of the global object just got passed through to the popup.

Then, when I started on the project for Customer1, SiteB, I realized the PLC programming was a bit different so I had to make new/modified UDTs. I decided to make a separate tag provider for each project to keep the tags/UDTs separate. I copied the templates to the new project and copied the UDTs into the tag provider for the new project. Doing this meant that my parameter types for the templates and popups are now incorrect (they were referencing a UDT type within tag provider 1A when they now need to reference the UDT type within tag provider 1B). I had to go through every template and popup and anything using a UDT-type parameter and change it to the new path to that parameter type.
Is there any way to avoid having to do this when copying UDTs and templates between projects (tag providers)? I can't remember if a find/replace works on parameter types or not, but regardless, I'm curious if there is an easier way.

Thanks for any advice.

2

Don't do this. Use virtual machines or docker containers to maintain separate development environments per site/client/whatever.

Do not install any Ignition instance directly in your primary workstation. (Maybe for training, but uninstall ASAP afterwards.) Only designer launcher, Vision Client Launcher, and Perspective workstation should be locally installed.

3

As for maintaining UDTs across sites despite addressing changes, UDT inheritance is your friend. You can have parent UDT A, with children UDTs B and C that contain custom addressing. You can maintain a standard namespace and apply any changes/upgrades to the parent A, and they will propagate to B and C.

4

Do not install any Ignition instance directly in your primary workstation.

Is there a performance related reason for this or is it purely just the best practice/a suggestion to keep projects separate and in their own space? I can understand wanting separate gateway instances for the sake of having gateway settings and configurations unique to each customer/site, but in general why wouldn't you host it locally aside from being a potentially unnecessary use of resources when not developing.

5

Multiple reasons:

  • Ignition gateway backups contain hardware & OS dependent information, particularly in ignition.conf, that don't always drop into a local workstation. And, often, your workstation is way more capable than the real hardware, giving you a false sense of future performance. You can allocate resources to VMs or containers to closely match real systems. (In other words, performance matters, but usually inversely to your implication.)

  • Handling networking in your dev environment in a way that at least somewhat mirrors production is crucial to smooth deployments. That means network names for your gateways and for the resources to which they connect (databases, emulated PLCs, other APIs). If you are using localhost or 127.0.0.1 anywhere in your dev environment, you are screwing up.

  • Local resources (databases, emulated PLCs...) need to be tailored to the client/site situation. VMs and containers help you do that with isolation, so work on client A's project doesn't corrupt the database you need for client B's project. And so on. Where local resources are PC-based, put them in VMs or containers, too, organized by client/site.

  • Spinning up just the VMs or containers needed minimizes the workload on your dev environment, if working solo or in a small team.

  • When your workstation really is resource constrained, using VMs or containers provides a simple path to running some or all of them in server hardware, instead of locally. Particularly important for work in teams.

I'm sure others can chip in more reasons.