We’re currently working with a customer who is considering the replacement of their existing SCADA platform which is riddled with bugs and issues, and is difficult to maintain.
The site currently has ~50,000 tags across 20 or so PLCs, all communicating via a Kepware OPC server. Most PLCs are Allen-Bradley. We would like to remove the Kepware middle-man and communicate these PLCs directly to Ignition (combo of SLCs, CompactLogix, ControlLogix, PLC5/05s)
I would like to know other users’ previous experiences in using Ignition SCADA on such large sites in terms of performance, both server and on clients. How suitable is Ignition for such applications?
Are there any gotchas or do-not-do’s that you have come across?
e.g. never pass UDT types around between pages and template objects - always pass the base tag path and use indirect addressing to access UDT tags.
We’re currently working with a customer who is considering the replacement of their existing SCADA platform which is riddled with bugs and issues, and is difficult to maintain.
The site currently has ~50,000 tags across 20 or so PLCs, all communicating via a Kepware OPC server. Most PLCs are Allen-Bradley. We would like to remove the Kepware middle-man and communicate these PLCs directly to Ignition (combo of SLCs, CompactLogix, ControlLogix, PLC5/05s)
I would like to know other users’ previous experiences in using Ignition SCADA on such large sites in terms of performance, both server and on clients. How suitable is Ignition for such applications?
Are there any gotchas or do-not-do’s that you have come across?
e.g. never pass UDT types around between pages and template objects - always pass the base tag path and use indirect addressing to access UDT tags.
Any feedback would be much appreciated.
Regards,
Nick[/quote]
I have done a few Ignition projects with close to 100,000 tags spread out over several PLCs.
I have found that spreading Ignition over 3 VMs is the best way to go.
VM#1 Ignition Gateway Service
VM#2 Ignition OPC-UA server ( free from Inductive if you purchase Ignition license )
VM#3 Database
Scan Classes are important on large installs. Group each set of PLC tags in its own scan class. Use a ‘driven’ scan class on tags that do not need to be scanned all the time. Driven has two rates, fast and slow determined by a tag. I usually use a tag that is TRUE when on a particular screen to scan the tags at the fast rate, and set the tag to FALSE on screen exit to scan the tags at the slower rate. Window Open and Window Close events are used to SET/RESET this tag.
[quote=“Curlyandshemp”]
I have done a few Ignition projects with close to 100,000 tags spread out over several PLCs.
I have found that spreading Ignition over 3 VMs is the best way to go.
VM#1 Ignition Gateway Service
VM#2 Ignition OPC-UA server ( free from Inductive if you purchase Ignition license )
VM#3 Database
Scan Classes are important on large installs. Group each set of PLC tags in its own scan class. Use a ‘driven’ scan class on tags that do not need to be scanned all the time. Driven has two rates, fast and slow determined by a tag. I usually use a tag that is TRUE when on a particular screen to scan the tags at the fast rate, and set the tag to FALSE on screen exit to scan the tags at the slower rate. Window Open and Window Close events are used to SET/RESET this tag.[/quote]
What do you mean with: “Group each set of PLC tags in its own scan class.”?
Can you please explain? I’m not sure I understand this… ?:
[quote=“zxcslo”][quote=“Curlyandshemp”]
I have done a few Ignition projects with close to 100,000 tags spread out over several PLCs.
I have found that spreading Ignition over 3 VMs is the best way to go.
VM#1 Ignition Gateway Service
VM#2 Ignition OPC-UA server ( free from Inductive if you purchase Ignition license )
VM#3 Database
Scan Classes are important on large installs. Group each set of PLC tags in its own scan class. Use a ‘driven’ scan class on tags that do not need to be scanned all the time. Driven has two rates, fast and slow determined by a tag. I usually use a tag that is TRUE when on a particular screen to scan the tags at the fast rate, and set the tag to FALSE on screen exit to scan the tags at the slower rate. Window Open and Window Close events are used to SET/RESET this tag.[/quote]
What do you mean with: “Group each set of PLC tags in its own scan class.”?
Can you please explain? I’m not sure I understand this… ?:[/quote]
Tags grouped into folders according to processor,
Each Processor has its own scan class
[quote]Tags grouped into folders according to processor,
Each Processor has its own scan class[/quote]
OK, Make sense to group tags into folders according to PLC. I always do that…
But what’s the difference to use a class with a different name with the same rate?
[quote=“zxcslo”]But what’s the difference to use a class with a different name with the same rate?[/quote]None. Sounds like a maintenance hassle to me.
I just make scan classes for the different purposes’ performance requirements (fast, slow, leased, whatever) and either add driver instances or upgrade hardware to get the utilization down.
[quote=“pturmel”][quote=“zxcslo”]But what’s the difference to use a class with a different name with the same rate?[/quote]None. Sounds like a maintenance hassle to me.
I just make scan classes for the different purposes’ performance requirements (fast, slow, leased, whatever) and either add driver instances or upgrade hardware to get the utilization down.[/quote]
Exactly. That’s also my way of doing it.
[quote=“pturmel”][quote=“zxcslo”]But what’s the difference to use a class with a different name with the same rate?[/quote]None. Sounds like a maintenance hassle to me.
I just make scan classes for the different purposes’ performance requirements (fast, slow, leased, whatever) and either add driver instances or upgrade hardware to get the utilization down.[/quote]
When I started my first large install and was having communication and response time errors, this was the recommendation from Inductive Tech Support to group PLCs into separate scan classes.
Each scan class it’s a different Thread. If you a have a multi core microprocessor server (todays is common), you make the communicacion load more faster. Also, if you have several tags from differents devices in one scan class and you have communication problems with one device, this could affect the adquisition from the other tags on the good device. Finally, never mix SQL querys tags with OPC tags in one scan class (you are mixing potential database problems with potential communication devices problems).
Summarizing, separating scan class in, at least, one scan class per device, could be more job, but make easy troubleshooting communication problems and in a multi-core server, makes the communication more efficient and faster.
[quote=“pdibenedetto”]Each scan class it’s a different Thread. If you a have a multi core microprocessor server (todays is common), you make the communicacion load more faster. Also, if you have several tags from differents devices in one scan class and you have communication problems with one device, this could affect the adquisition from the other tags on the good device. Finally, never mix SQL querys tags with OPC tags in one scan class (you are mixing potential database problems with potential communication devices problems).
Summarizing, separating scan class in, at least, one scan class per device, could be more job, but make easy troubleshooting communication problems and in a multi-core server, makes the communication more efficient and faster.[/quote]
Good explanation.
I didn’t know that. I’m always using, for example, 1s scan class (default) for all my PLC’s… maybe I was lucky but until now I didn’t have any problems…
But, if that’s true, then it makes sense. I’ll try this at my next project.
Is there any benefit to adding a second device connection to point to the same PLC?
I know normally you’d split out multiple PLC’s on different device connections, but is there any benefit in terms of load sharing to split half my tags out into one device connection, and half onto another, on the same PLC?
I still have pretty average performance on my large project with 50,000+ tags all reading from a single Omron NJ501 PLC, on a single device connection.
I am using different scan classes to try alleviate the comms problems but it doesn’t seem to be enough.
Thanks
[quote=“richardNZ15”]Is there any benefit to adding a second device connection to point to the same PLC?
I know normally you’d split out multiple PLC’s on different device connections, but is there any benefit in terms of load sharing to split half my tags out into one device connection, and half onto another, on the same PLC?
I still have pretty average performance on my large project with 50,000+ tags all reading from a single Omron NJ501 PLC, on a single device connection.
I am using different scan classes to try alleviate the comms problems but it doesn’t seem to be enough.
Thanks[/quote]
Well, I don’t know how Omron works (I’m Siemens guy, but I guess that PLC’s share the same principle…), but on Siemens PLC’s it definitely helps.
PLC can handle multiple simultaneous connections from ‘outside’ world. It depends on PLC type how much connections, but it can. The emphasis is on simultaneous.
When you create a device connection in Ignition (or any other OPC server), in the PLC one connections get reserved for that. So, all communication from PLC to the OPC server & vice versa is running over that ONE connection.
If you create two device connections than two connections get reserved in the PLC and PLC can serve data simultaneously over two connections. In theory, you cut the communications time on half but in practice is around 30 - 40%…
In Ignition I never had the need for creating more than one device connection to the same PLC yet, but I remember years ago with Kepware and MS Visual Studio app which I made for a hanging conveyor system (a few thousand meters long). At the beginning, there was an almost 10s delay from physical switch on the station gets switched ON 'till I get that signal tag in my app on True.
Then I made another device connection in Kepware to the same PLC and split the tags in half to each connection and delay dropped down to 3-4s. Then we’have done some optimization and at the end, we finished the project with 4 connections to the PLC and delay around 1s.
So, I would say that more connections definitely helps, but how much it depends on PLC type, network traffic, how much other ‘client’ are also communicating with the same PLC and how many connections they’re using,…
At the end, it always come down to try, try, try…
Multiple device connections to a single PLC for load balancing is very helpful in large Allen-Bradley systems. As long as your PLC processor itself isn’t overloaded. Best way to make sure the AB PLC has excess bandwidth is the change the default continuous task to periodic.
Use the tag diagnostics for each device to decide when to split into another. The key metric is the Avg Request Duration. It should stay in the milliseconds range – never more than your fastest scan class.
