Say we require to connect to multiple PLCs to read data points.
We want to organize and manage the data as it comes in into our scada. Manage means, be able to properly name and group in hierarchy order these tags.
Who can do this better, Kepware or Ignition?
If I go with Kepware, I could custom name a Channel.Device.TagName for each data point being access from PLC. - this way when it comes in to ignition, data point is easy to refer to.
How do I do this with ignition?
When Ignition connect to devices via its device drivers or opc-ua, the tag identification will follow the naming of data points on PLC.
How can I, in ignition, create a level of abstraction, to rename and organize tags that comes in?
You can create folders or UDTs.
You might want to learn more about Ignition tags.
I think Ignition allows for a more holistic approach to organizing tags.
For example, I'll create folders based on production lines, and within each folder, I'll further organize them into categories like lighting, compressed air, pure water, and electricity.
Specific equipment, such as air compressors and electric meters, will be organized into UDTs.
This way, I can use a common script to analyze the status of each production line.
Ignition allows UDT tags to come from different sources.
Of course, if you want to keep the Kepware style, simply replace Channels and Devices with folders.
In addition to tag folders, use Tag Providers to identify your tags by PLC. In the Gateway, define a Tag Provider in the real-time Tags for each PLC. You can also define each project to use a default tag provider for easy accessibility, although any project can still use tags from any provider.
A Tag Provider would be more synonymous with a Kepware Channel definition.
No, this is only a side-effect of drag-n-drop from the OPC Browser to the Ignition Tag Browser. Ignition tags and folders do not have to follow the PLC's data layout at all. And usually should not, at outer layers.
(Lot's of PLCs use Modbus or Melsec or similar legacy protocols, which offer no data layout anyways.)
I disagree with this as a global statement. There is no synonymy with the Kepware channel definition in Ignition. Channels in Kepware are intended to group communication devices based on driver type and poll devices sequentially - if one has a comm issue, it will wait to timeout before polling the next device which is handy for slow serial connections to prevent overloading connections). When used on a local network for faster comms, you should always put each PLC in its own channel.
There's no reason to put each PLC in their own tag provider as device comms are independent of the tag providers and tag providers I typically use on a one-per-site basis or one per backend gateway basis if working with multiple gateways on a single site. Then organize all your tags within folders in a way that makes sense using UDTs to group related tags that follow a common structure together.
Vehemently disagree. On a plant wide roll out, tag providers offer a very structured approach at organizing tags in functional groups. Especially where multiple developers are involved. Having a single tag provider for 100k tags on a single gateway seems odd to me.
I have over 100k OPC tags in a single tag provider (granted they're organized in UDTs, folders, etc, but they're very easy to manage since there's folders for each area, and then nested folders under those to break things down further)
Operative word, YOU have. In a situation with a shared gateway with multiple integrators using their own UDTs, I much prefer the isolation of UDTs to a tag provider. We still of course use folders for further grouping, but by using tag providers, I can have a Motor Folder in each tag provider, unique to the process or PLC. And when I'm working in designer where you assign a default provider to the vision project, I don’t see 100k tags in my project tree. Only the tags that are likely pertinent to the project.
Also, when importing and merging tags from offline developers, there’s no danger to overwriting any folders or tags that may share the same name. Tag Provider isolation keeps them segregated.
The way I handle multiple vendors is all my UDTs are organized in the following manner/folder structure:
OPC Server (Usually just Ignition and/or Kepware)
Device Driver (Logix, Modbus, ABB, etc)
Vendor (Typically the company name the UDTs are for/by)
The OPC server highest level is due to having built the same UDTs for the different OPC item paths and I can keep them separate. The drivers are self-explanatory, and the vendor/company names keep everyone separate so I can have a Motor UDT for each vendor independent and isolated from each other. Sometimes under the vendors I'll even have a folder for different "versions" of things. For instance, GE Multilin relays use a different modbus mapping for different hardware versions, so I can have a folder with the same UDTs with different mappings for the various major hardware revisions.
Interesting..you didn’t mention this a year ago when I laid out the organization.
I agree about discipline, but please explain how it’s going to blow up on multiple site rollout. It’s been a time and organization saver on this particular rollout.
Once you start trying to link all the sites together and if each site has a tag provider for each PLC, your remote tag providers are going to grow very quickly.
Let's say you have 10 tag providers at each site, and you have 10 sites you want to bring into a central SCADA system for corporate dashboards, etc. You'll now have 100 remote tag providers on that central SCADA system, and that's for a small set of sites.
I'm doing work for a company right now where I have about 60-70 OPC device connections at each site and this company is building 5 new plants/sites just this year. That would be 300-350 remote tag providers in their corporate SCADA system to monitor all those devices. They have about 60 sites/plants in total. This would be unmanageable.
Well, recently burned. I'm prone to change my mind when evidence rolls in.
The key to the problem is that scale out architectures with remote tag providers end up with numerous RTPs in each front end. Ideally one per back end. Much more than that and it becomes difficult to keep RTP names the same as the backed original provider name. This name correspondence is crucial to front end UIs that can render multiple sites' data.
Actually it was the beginning of development, for the current rollout I'm doing now.
In regards to your other point, why would your company dashboard need access to a tag provider covering 60 OPC connections and their tags at multiple sites? We do similar for MES, but since it’s limited tags, we just aggregate them into an MES tag provider. That way, the plant level can service the info to an MES request. All MES does is monitor one tag provider at each facility.
Maybe I'm not following. In our case, there is a gateway at each facility…no more than a dozen PLCs. Enterprise wise, each facility gateway would communicate to a central gateway that has no OPC connections. Only the facility gateways talk to PLCs, and therefore, none would exceed more than a dozen or so PLCs. As explained above, central gateways need relatively few tags for dashboards…so they are aggregated into a single tag provider.
It really depends on what corporate wants to see. In my client's case, they're trying to analyze efficiency of all the equipment and processes in their gas processing facilities. So they want to see valve positions, temperatures, pressures, flow rates, motor speeds, etc to see how the real-world design compares to their engineering models to see if anything is off or if they need to make improvements, if something isn't working as designed, or even if operators aren't operating the plant correctly, so it's not just a handful of tags, it's almost everything. It's a lot of extra work aggregating all of that data into yet another tag provider vs just having a single tag provider in the first place.
But how would you describe your challenges and experience using Kepware vs using Ignition to get thousands of data points from PLC into Ignition SCADA, in terms setup and organization of tags?
When using Kepware as polling engine for Ignition, I prefer to NOT configure tags/nodes in Kepware, and instead utilize Dynamic Addressing for all devices on the Kepware side. Then, organize them into meaningful [Provider]Folder1\Folder2\UDT1\Tag1 structures within Ignition, where the OPC path defined on a tag is sufficient for Kepware to dynamically build the node and poll the end device. I always let Ignition define the path to the end device, where possible.
Kepware has vast & fantastic suite of drivers (at a cost), Ignition has a smaller suite of core drivers…both are likely capable of polling your end device. For me, organization of tags has never been a consideration in terms of which product to use.
