Nice comparison! It looks like Ignition stomps all over it 
3 Likes
No wincc is still the same as before. It is like a cancer in industry.
10 Likes
ifix of GEFanuc Itās worse
The only respectful rivals are wonderware system platform and winccOA.(not winCC)
They are superior in:
- cluttering and decluttering which deal breaker in some power grid application
- performance.
- only wonderware is provide real object oriented for user. For example if you have pump all signals, faceplate, popup, script,ā¦ are encapsulated in one object. Unlike other system that popup, faceplate and tag structure are 3 separate things.
But in end, if you consider every aspect of SCADA system Ignition wins at the top.
1 Like
ClearSCADA (now renamed by Schneider to StruxureWare Geo SCADA Expert because they added a google map component to it 
) also had this concept of including anything within a template: graphics, tags, PLC, users, etc. It's very easy to make a terrible project in it if you don't know what you're doing or don't think about how you're going to structure it. You can also add things to instances of templates as well, which is useful sometimes. ClearSCADA is great from an automation perspective and is very easy (once you've developed the tools) to make bulk changes to the project. You can also edit configuration of tags via SQL queries which is super powerful. What lets it down is its graphics side, which is horrible to work with - super clunky and inefficient. There is also an overwhelming number of configuration properties on almost all types of objects which is both good and bad.
Few questions about WinccOA:
- Is evaluation version available for it for download? If yes can you please share the link? How big is the download? Does it require .NET?
- Does it support OPC UA? If it does then which version and which modules (Information model, AE, HA?)
Does it have OPC UA or DA support?
Can you share the link for download please? How big is the down load? Does it require .NET?
Is the API well documented like Ignition?
How good is the OPC UA implementation? i.e. the modules and services supported?
You can configure it to be an OPC-DA server and it can connect to OPC-DA servers, but I donāt believe itās moved into this century yet; I donāt believe it supports OPC-UA
1 Like
I guess thatās a serious limitation in that case. Going forward interoperability based on open standards in industrial automation will be a must rather than closed propitiatory solutions, however efficient it may be.
Cancer for me is Wonderware
4 Likes
May be Iām wrong but the only thing that teasing me in ignition is performance Ang high memory usage.
Please feedback your experience about this if you have large project.
For example a GIS page include a map with 10000 point and line which show power network of a city. This cause perspective crash.
Within perspective typically the killer is CPU usage and not memory usage, since every client is technically running all of its scripting on the gateway, so this is surprising you are seeing that sort of problem. With Vision I could see that though
In regards to this its really on a case by case basis, but when I started working in perspective I couldn't make a page with 200 data points on it without this same struggle. Over time I started to get a better understanding of how to show "big data" on a perspective page without the same issues, make things more optimized, and things got quite a bit better.
Granted, I still have never had to show 10,000 points on one screen I dont think, so I am not sure I have a great comparison. Typically when I get to showing that much data on one screen I am aggregating it for easier understanding. Most direct points I have probably shown is 500-1000
Consider this. There is a map the color coded the voltage of grid.
I can't replicate even 1/10 in perspective.
1 Like
And with that application it is polling 10k+ tags at some frequency?
I would think even showing 10k plus tags on any kind of page (web based or not) would struggle, as opposed to bundling the data and managing it a bit more efficiently.
For example letās say the 10,000 data points are broken into 100 sections of 100 points. Then if each point in a section is of the same status you just look at a static variant of that section, until one of those points isnāt. Then you only look at the āspecial casesā when they exist instead of looking for them all the time. For instance if you had a ādetailedā and a āhigh levelā version of each sections view, then you could show the high level and save resources when possible, and only show the detailed versions when needed.
That way Iād say 60% of your whole app is of an clear status then you would be able to save 6000 points worth of calculation at whatever polling rate.
Definitely a bit more complicated than just putting them all on one screen, but itās a bit like google maps, you only show what you need to in that moment for that detail. Like when they show a high traffic area as red on the map; they are only calculating and showing the slower areas, not the whole map.
Presuming you are already doing all of this, there would surely be other optimizations needed along the way as well, like storing the current status of each section as a json for the āinstancesā prop of the view canvas could allow you to heavily cut down on binding calculations, or having static views for each color ābranchā instead of binding a color on the view, and then just changing the static view youāre looking at in that top level JSON. Letting the gateway calculate those json sections at whatever rate and then just let perspective look at them, minimizing the performance ācostā to the client
Not necessarily easy, but I would think youād have to do all of those same things in any web based format, as well as that application you showed probably does a lot of that inherently as well (thatās a guess)
Edit: the popups are the easy part, hence why I didnāt really mention them
1 Like
This is an electrical distribution system SCADA where things remain static for 99% of the time! There is nothing more boring than watching these static screens in normal situations for an electrical distribution system SCADA! Hence report by exception can easily take care of 10K values or even more! That too most of it is binary! As far as the images are concerned they could be cached in clients for a web based scada. In all probability this seems to be a legacy client server type SCADA based on UNIX/LINUX and XWINDOWS and MOTIF GUI library. This could be requiring a client to be installed on each client machine that could contain the GIS images and data base on each client! In web based environment caching is the best option for such large static data! There has to be a trade off , you canāt get best of both the worlds with one approach (web v/s Client/Sever architecture). Ultimately the response is important to the user , not what lies under the hood!
1 Like
These were the words I was looking for but just could not come up with hahaha
1 Like
Leaflet (the library used by Ignition) is a simple library, but not really suited for these amounts of data.
If you want to work with big datasets, you will probably need WebGL based rendering like with the Mapbox GL library. But I don't think it's possible in perspective. Certainly not without writing your own module.
If you are talking about only the GIS information, then obviously commercial maps like map box and google maps will be richer set of data than an Free and open Library . Secondly the data about a small location may be required for GIS not the entire earth! Google maps for example allows you to download data of a local region for off line viewing .
This is getting quite off topicā¦
But Mapbox GL is an open source library: https://github.com/mapbox/mapbox-gl-js
But itās a lot harder to configure it than leaflet. For really big maps, you need a GIS DB (like PostGIS), and you need to query the parts that come into view to render them with mapbox. Thatās a lot more work than just slapping a JSON in a property and using pre-rendered tiles as background.