PLCs / tags associated with projects

Is there a way to quickly determine what tags on a server are being used by a specific project? We’re planning to migrate to Ignition 8 and we’re trying to assess the needs of each project on a given server. WE want to do a gateway backup and restore to new hardware, then deploy the updated projects a fw at a time. We don’t want 2 servers simultaneously reading the same PLC tag if that tag has an alarm or tag change script associated with it though. Being able to track down and disable the tags associated with a project on the old server would be really helpful.

Nada. All manual.

1 Like

ooof. I suspected that.

What’s your tag organizational strategy? We’ve debated a couple of ideas that have occurred to us and we keep arriving back at “keep all your project’s tags under at least 1 base folder” so, if we have to move or delete a project, there’s no doubt where the tags are at. Unfortunately that’s not how we started developing projects…

If none of your tags will be used by multiple projects you could create a provider per project.

As I described above, recently we’ve been keeping all of a project’s tags under its own folder. This means that sometimes we could have multiple tags point back to the same OPC path but this felt less problematic than not knowing for sure the locations of all the tags used in a project.

Can you elaborate a little on the provider per project strategy you suggested?

But I wonder what was behind creating common data base for all projects! Was it accidental or was it premeditated? Commonsense says the each project will have its own tag database! The common tags data base is a source of many issues like event trigger will cause a scripts to run in multiple projects if tag name is same!

I don’t think there’s anything more to it than creating a separate tag provider per project and using that for organization. It’s similar to just using folders. It’s just something I’ve seen more than once, not something I’m prescribing for any other reason.

One reason, and a gaping one to me, for not doing this, is that my projects share the same UDTs. If I need to add a new UDT or modify an existing one, multiple tag providers would be a significant PITA :slight_smile:
The benefits you get from separate tag providers are outweighed imo by their drawbacks, and their benefit can easily be ported into a single tag provider by, as already stated, creating area tag folders for each of your areas. This is a pretty common sense thing to do anyway.

What’s your tag organizational approach? How do you keep track of what tags belong to what projects?

Each project to me would be used for an individual area or group of areas of a site, and the tags for each area would be placed into a folder for that area. Of course there might be some common system folders used across multiple areas, but for the most part, a project’s tags will be confined to the folder for its area.
Where separate tag providers do make sense is for completely independent projects where their udts don’t match up. For example I have an andon overhead project that uses its own tag provider, as the tags for the project are completely different to those for the main plant.