My physical equipment layout will be 10 to 20 PLCs, each connected to its own OPC UA connector in Ignition, and then reading the same 20-30 tags from each PLC.
What I am not sure of is what the advantages/disadvantages of these architectures are:
All the tags from all PLCs contained within folders within the same tag provider?
Create one tag provider per PLC and keep each PLC’s tag within its own tag provider?
And is there a level of system complexity that would suggest one architecture over the other?
FWIW the system is also going to be implementing an SQL transaction group per PLC in order accumulate the data from all PLCs into a common historical data table.
All your PLCs will be connected to the same OPC UA server, right?
I’ve never tried using more than one tag provider per GW. I can’t see any benefit for doing so, unless there are special security concerns that you are trying to address by using multiple tag providers.
I have used multiple tag providers before but it was to segregate between different projects. With what you described though, I don’t see any advantage to doing multiple tag providers. I would use multiple tag groups. I don’t know if its as important in 8 as it was in 7.9 but out of habit, I like splitting up tag groups by PLC.
Just for reference, one project I’m working in a lot, has 80k tags in one tag provider. I have multiple transaction groups, I could count them but I haven’t seen a reason to. I also do data collection through scripting for some functions. Even with that, my gateway is normally running between 10 and 20% CPU and 2 to 4 GB RAM. Its in 7.9 but already tested and will be going to 8.1 before to long.
If its the same tags out of each PLC, I’d also make use of UDT’s in your tag structure so you can build it once and just point to different devices.
Multiple tag groups make sense to me and may or may not be applicable in this particular case.
Definitely a UDT if I can make it work. However I may run into some, shall we say, "not so uniform coding practices" as the machines were built over phases and potentially by different people and we don't need no steenkin' standards
I also realize that this project is pretty well on the trivial side of things. So I have no intention of overcomplicating things if I can help it.
I think it can help when you’re the kind of org that has hundreds of thousands or million+ tag systems, though that’s usually accomplished with remote tag providers these days.
As someone else mentioned, if your tags are not shared between various projects then that’s one good way to organize them so they appear as less of a global resource and it’s more difficult to accidentally start using tags you shouldn’t be.
The nice thing about UDT's is if you do have some inconsistencies then you can use overrides in those spots to correct the path. By using a UDT though, it ensures your consistent on the Ignition side though which still helps with building the project. By being consistent, any objects that are repeatable you can make use of templates and template repeaters. Depending on what your doing, both can save a lot of time in the end.
While there are currently about 30 tags per PLC (and 10-15 PLCs), the entire project is supposed to scale up to around 100,000 tags. (a lot more PLCs and about 1500 tags/PLC).
Meh, if it were me I’d just use the default provider pretty much always.
Maybe take my advice with a grain of salt, though, because unlike the regular users here I have zero experience actually deploying Ignition in the field
I always create a tag provider per project and I have gotten into the habit of changing the tag provider name from default to something that actually matches my project name.
The use of folders is a separate idea from having different tag providers. And I will be using separate folders for each PLC, and using a UDT in order to fill in the actual tags themselves.
Keep in mind that with the 8.1 redesign. It is even harder to switch between tag providers. In 7.9 you could see all your providers in the browser at one time. I thought that was better IMHO.
Your post leads me to nice idea… I have let say “universal” project for our production line but sometimes there is Simatic and sometimes Schneider PLC acc. to client demand.
Two different providers are the best solution. Renaming them acc. to PLC used and disabling one of them solves everyting. Thanks for Your idea.
We solved this at least for our generic device templates by creating an expression tag for the status and mode tags that converts the integer value of the tag into its descriptive value. E.g. If status values are:
0=stopped
1=running
2=faulted
Then the descriptive value would return the 'stopped' string. Then I use the descriptive value everywhere such as in generic device templates. This way, if another contractor comes along and doesn't care for our standards, we can still use our generic templates as we can simply set the descriptive values up to suit
