Network latency will absolutely crush OPC driver performance. An A-B driver running over a connection with even 20 ms ping time will have a tenth of the usable capacity as a local LAN connection. This is true of basically any request-response OT protocol.
Don't pinch these pennies. Put Ignition in every facility that has humans.
Not sure that we are talking pennies here, as I understand if I run Ignition localy from a gateway server in 5 plants, I am looking at 5x 30.000$.
All HMI’s are in the machine network of the OEM, so speed and latency is not as relevant. We are not controlling processes, we are monitoring them from a single location. And to be honest, if I want performace, I would use drivers to directly connect to a machine, and not OPC.
I agree offcourse, from a performace point of view it is not ideal. But for performance we will use the on-site Scada run by on-site operators. (iFix, PASS, WinCC etc.)
The aim would be that when we have new technology, it will have a Scada which is custom here in Hungary (ifix is a popular choice). But while we plan the project with the OEM, we request for certain data to be shared. And that data will end up in our “Enterprise” Scada. And we are mostly talking about production data, and not process data.
Possibly my explanation makes more sense now?
I understand your situation better now. But you’ll still have to watch out that you won’t use Ignition for too many things in that case.
Once you get used to Ignition, the tendency is to use it for more and more features. And in your case, this could cause network issues.
Like when taking in orders from a database that have to be send to the PLC, and write back the results. It’s so easy to do via Ignition as it has all the connectivity options and the GUI tools. This would still be possible in your case, but the more towards process control you go, the heavier it will become.
I don't think you can rely on anecdotal opinions to complete a project.
Your questions fall under "performance evaluation" of an IoT platform. which I'm
afraid you'll have to answer for yourself if you want your project to succeed.
There are too many variables to answer the question.
We have run 200,000 tags in our environment:
But again, don't take our (or anyone else's) word for it.
Well, I still consider user feedback more reliable than the manufacturer’s sales pitch 
Anyway, can you tell a bit more about the video? In the comment is says “from 20k devices behind 2000 EON nodes.” this implies that the data of those 200k tags is dynamic. But the video is to promote a MQTT simulator, this implies that the tags might be static.
And I am not fammiliar with MIMICview, but it seems that the synchronisation time takes about 8 seconds. Your 1st change was a second before the sync update, and your second change a second after the sync update. So is in this case the update time in Ignition not inherent to the MIMIC software?
Thanks!
As you saw in the video, every tag is independent in MIMIC MQTT Simulator.
EVERYTHING in our simulator is configurable, as is every single tag.
You can have static or dynamic tags. The video tries to convince you that the tags are driven by
the simulator (predictable simulation). If they were dynamic, that would not be so convincing.
Our Youtube channel has many interesting scenarios related to platform testing.
Here is one with dynamic tags:
I am curious in what configuration you are getting this number.
If you are not concerned about the visualization happening locally, you could still use Ignition Edge for your data collection, and to reduce the network latency from the Hub gateway to the PLCs. This would mean that if a plants network went down, the edge gateway could still internally collect data, and provide it to the hub when communication came back up. Then the hub would have any interactions with your database, and also host the visualization.
This would be the cost of a pretty lightweight edge device and a license. Eg. an Edge Onboard device like this one from Onlogic would be perfect, and even overkill in some cases I would presume, for less than $1500 USD per location (so the 5x 30.000$ would be 5x 1.500$).
This would add local polling and store and forward to each location, so that you wouldnt need to worry about all the issues mentioned above with OPC polling latency.
Of course in the future if you DO want local visualization at each plant, you could easily add the Edge Panel license (For approx. $1300 I think) for any realtime information, but for the database data you would still want to use your Hub gateway.
Note, you do not need Enterprise Administration for this one, only if you were trying to centrally schedule updates, push out projects, and things like that to the edge gateways. They can still act as data collection points without EAM.
Answer to the second question about update time: in that video every tag is updated every 10 seconds.
That is one of the variables alluded to in my original answer: how frequently is each tag updated.
We assumed every 10 seconds is a common case.
Some tags update 10 times a second, some 10 times a day.
Of course you can do that in MIMIC.
In al honesty I have to admit that my price is based on the assumtion that I need a gateway server in each plant with all modules to safeguard performance as suggested by the contributers in this Topic. Unfortunatly we do not have an official Inductive Automation agent in Hungary, so the source of most of my information is the website and therefore quite possibly incorrect.
I admit that the hierarchy as you mentioned sound like a logical one, and maybe this also what pturmel was refering to. In that case I do consider the benefits of local data collection and storage againt the cost of an edge device peanuts.
However I do not know the cost of the Edge licenses, I have requested this from Inductive automation customer care.
The device that I provided you is an Edge OnBoard device, meaning it comes with Edge already installed AND licensed! Meaning that the $1500 that I mentioned would cover the computer and the license 
. If you were buying enough of them for all your different plants, you might could squeeze some kind of bulk pricing discount from the vendor.
If you cant get anything there (Hungary) with Edge OnBoard, you could always just get a lightweight PC and install edge yourself. The licensing for your installation would be around $400, or $800 if you used MQTT.
Clarification: This is unincluding any integrator discounts and what not, and you should definitely get an official quote from your agent. But I am talking about Sync+Core or IIOT+Core. These are also numbers I get in the US, so I am not sure about Hungary, and import/export tax.
Remember, to tie these Edge devices all together, you will also need a standard gateway licence. But you almost certainly wouldn’t need all the bells and whistles version and could probably get away with something more like a $15-$20k licence. You really need to speak with an integrator or the Ignition sales team about the objectives of your system so that a design can be laid out.
This is a great thread, and I echo all the sentiments of the grizzly old veterans.
Agreed, this is a great topic. I think I’d be using the edge nodes and a central gateway, with a separate DB next to the ignition gateway. If I understand correctly, this would be $1.5k for the nodes, and a single 15 to 25k for the gateway depending on options ticked etc.
You should also consider how many tags you are going to have on the edge nodes? I believe the edge devices have limitation of number of tags and some reduced features such as lack of DB support etc. Perhaps someone can tell what the limitations are of the edge devices.
If I can bring down the gateway cost to 20K and deploy a number of Edge devices for on-site data collection we may have a win!
I did reach out to Ignition for more detailed information, waiting for a response now. Regarding integrators, I have seen to reference projects, and I was not impressed by the impementation. And since Ignition is a niche product in Hungary, it proves hard to find companies where Ugnition is deployed.
I think you'll find that's not uncommon for projects in any SCADA package. Quality of implementation often comes down to the individuals working on the project (not the company itself) and their care for quality design and technical skill. Unfortunately, a lot of engineers have the technical skill, but not a flare for design and UI. This is the main reason software design firms separate their interface design and the technical components to different departments who specialise in one or the other. This would simply be cost prohibitive for industrial projects however, as usually the implementation is custom-tailored to each client.
That being said, if your country doesn't have many companies that work with Ignition, you're in a bit of a pickle. Also, I feel sorry for them as they probably don't know what they're missing out on.
It is simmilar to the Siemens vs AB topic. In europe mostly all PLC's are supplied by siemens, while in North America AB is king. But for SCADA this is even a bigger "issue" the main SCADA is still WinCC, and if there is one platform that I despise as non OEM, than I nominate Siemens...
But hey, at least we are considering expanding the Ignition platform in Hungary (Europe)
Over here in Australia, we tend to see a large percentage of sites using AB PLCs. However we do certainly see Siemens and Schneider PLCs about the place, as well as some GE and Mitsubishi PLCs.
I hope Ignition pushes its way in!
Siemens and Ignition works good enough. If you use a recent S1500 series, you can communicate over OPC-UA, so you get all the benefits of browsing and easy configuration. You should limit what you make available over OPC-UA tough (it’s a checkmark you can enable per data point). Otherwise the PLC may choke.
For other Siemens PLCs, you have to use the Siemens driver, which requires you to type the addresses yourself (or generate them in some way if there’s some logic in the addresses).
We normally use Beckhoff, but very often bump into Siemens when integrating third party machinery. Normally it’s not an issue to get them integrated in our system. In a few cases we even had to replicate their WinCC HMI because the operators liked to operate the machine from their controlling office.
For us as as a non OEM or integrater, Siemens is a nightmare to provide troubnleshooting and diagnostics on. If I have 5 OEM's, and the projects are made in different versions of Step7, WinCC and Tia Portal, I as the automation responsible within the company am required to purchase 5 Siemens licenses, and before TIA, there were issues running different versions of Step7 on one laptop or desktop. Therefore it also means investing in multiple hardware platforms to run the software on.
So it is not the integration of Siemens in Ignition thats the issue, it is limiting me as user assigned with the upkeep of the plaftform who is handicapped. Therefore in new projects, or migrations, I tend to "gently force" suppliers to look to alternatives like Opto22, B&R or IPC's. They are way easier to manage when working cross platform. And as long as I am not managing a powerplant or nuclear reactor, I really do not need a S7-400 PLC to control the technology. (This is unfortunatly still offered by the big names here in Europe)