Tags in Ignition appear to have unique IDs but I don't know how they are used. A question I have been meaning to ask. What exactly does Ignition use the IDs for?
1 Like
VTSCADA is not web based its client server based (as most of other SCADAs are) so the response on clients may be faster. I think it uses internal tables to store history instead of an SQL database. The server footprint is small so it may be faster to replicate servers as backup servers. However, I think VTSCADA may be OK for smaller projects where tags are less than 5000 or so whereas Ignition is meant for really large projects with 10's of thousands to millions of tags! VTSCADA's forum is horrible (almost nonfunctional) as compared to Ignition which is alive and vibrant with so many helpful users and Staff members. So in VTSCADA its difficult to proceed if you are stuck. It doesn't have OPC UA server, it supports drivers to PLCs to connect to its internal tag database.
2 Likes
VTS is both Client Server and web based both options exist. Yes natively history is stored in internal tables but you can also have that data to SQL server and read / write to SQL if you want. Ignition handles SQL events "easier" but still possible to do.
VTScada has PLC drivers AND OPC UA server/ client you can google it.
I have personally done 10k+ tag system on VTS without getting to any point where there was some feature that either I or the client wanted and I wasn't able to do easily. I have also worked on a system that is spanning across canada, texas, florida that consists or will consist of 100 ish servers and 100k-mil tags when done. (company is still in process of rolling it out one site at a time essentially) I think it is a disservice to suggest that just because tag count is > x or < x that system x is better then system y. To me the biggest difference in what functions will it perform and how the end users will interact with it and development time / budget / functionality.
Yes VTScada's forum is horrible because nobody uses it and it isn't used for tech support. instead you just call/email and in my experience you get a faster response then with ignition using those methods. Support structure is different between the 2 products and I wouldn't give either a "you are better then the other" nod as it is mostly personal preference. There are also aspects of the Forum that stink. Looking for the answer to a question doing a search (I was searching something on UDTs I think when I found this post) and getting an answer that is out of date because of revision or only applies to perspective when you want vision or vice vs.
1 Like
HUH?
Both are capable of IIoT. Both go past the traditional SCADA system. What about Ignition makes it more IIoT then VTS? You can host in the cloud or local, you can connect directly to end devices and not PLCs. you can do direct control with both.
This part sounds amazing tbh
2 Likes
For simplicity, I wish there was a clear cut choice on "The Best SCADA system". As it has been pointed out both are very capable for various reasons and the choice will need to be case by case (also taking into account personal preference).
On the other hand, I'm glad this is a point of discussion and we are in this scenario. I think this type of environment pushes both softwares away from complacency hopefully to the point of driving better features and stability.
3 Likes
This doesn't seem like redundancy, in the full sense, to me. Sure you require less servers in total, but IMO you have 6 servers for a reason. If a server goes down and you continue to operate on just 5, or 4,3... then your system has fundamentally changed its operational capacity. Critical expressions, scripts, and tags could be delayed significantly. Therefore, I ask the question, is this truly a redundant system, or just a soft failover mechanism? In some cases, this may make perfect sense, in others, not so much.
If you need 4 servers in ignition for Load and you want 100% redundancy such that loss of 1 server does not impact any operation then you need to have 8 total servers. Each gateway needs it's own redundant backup.
In you need 4 servers in VTS for load and you want 100% redundancy such that loss of 1 server does not impact any operation then you need 5 total servers.
The added redundancy is that you could continue to Lose servers and still be able to operate limited by loading (tag updates aren't as fast but still occurring, clients are slower but still loading) While with ignition beyond the single redundancy loss you just completely lose operation.
Bigger the scale out the more savings with VTS method.... 20 server + redundancy = 40 with ignition or 21 with VTS Want to add ANY 2 server loss to that ignition = 60 or VTS = 22
In VTS the same project is synced between all gateways including all the IO, history etc. Load balancing on front and back end are handled by VTS. The only thing really setup at the server / gateway equivalent level is How thin clients connect to that server.
For those more familiar with Ignition the best comparison would be if all the Tag provider, Database settings etc where in the project. Then in the project you assign Tag ProviderA use ServerX for connection, then ServerY, then ServerZ. TagProviderB use Y,Z,X and so on. If you want TagProviderC to only use ServerT, and ServerS you can set that as well. Fully customizable. I am not sure about all the details of how it works but I am fairly certain that if you have ServerX,Y,Z in the list for ProviderA and X is slowed below a threshold then it will try using Y,... then Z. So if your loading dynamically changes the drivers automatically reroute to keep comms up to set rate as much as possible.
With ignition if you have ServerX with PLC1,2,3 and ServerY with PLC4,5,6 and you need to add load to PLC6 you have to manually do some work to move PLC4 to ServerX to try to balance the load. that change can be done in under 10 sec with no potential impact to any scripting/references with VTS if not done automatically.
7 Likes
Basically Ignition is the only answer in my opinion. VT SCADA is nice, but clients absolutely love the mobile design aspect that ignition provides. My other concern with VT SCADA is the inability to archive historical data. You can't touch that data in VT SCADA so I hope you don't run out of storage space!
It is stored in files so you just move that months file that you want to archive which is easier then archiving historical data from ignition. If you don't like file storage you can also log to SQL Database.
That does sound better than my original thoughts on the matter.
Really? We had a sales rep come do a demo and he said the data is essentially inaccessible and they have some special compression method they use
For the Default historian the data is essentially inaccessible at the granular level. you can't go in and modify Tag X at time Y. but all the data is stored in a file structure and you can pull out files to archive if you want, you are limited to archiving a month at a time.
I am not sure if Ignition has a similar feature but you can go into the historical data through built in functions in VTS and mark data either at a time or range of time with "manual" data indicators (say sensor is broke but you run reports on that data and want to show the manual readings at that time) . That data is marked and note added if desired and you can reverse those changes at any time.
1 Like
I recently thought about this a bit more and these questions of yours came to mind. Apologies in advance...
I don't have experience with VTScada, but I do have experience with [other SCADA platform] (I can PM you the name if you're interested) in a previous life, and the ease at which you can add additional IO (and alarm/trend) servers in this was one of its biggest advantages in particular for large distributions.
Below is essentially the simplified IO model architecture:
Firstly, all configuration is done in a single "project" (gateway backup, in Ignition terms) which can be a collection of projects with an inheritance structure - contrast this to independent gateway configurations for each Ignition gateway. This project is then restored to all servers in the architecture, including all IO servers, alarm servers, and trend servers which are essentially just application services that run on each machine. Multiple services can be run on a single server for example when you are only using a single server architecture. To assign services to a machine, you simply specify the IP address it should run each service on. The difference between this and Ignition, is that for Ignition, each gateway is a completely independent configuration. The configuration of a single "project" could span multiple gateways, with each gateway holding only the configuration that it is responsible for. For example, one gateway might house TagProvider1 and 2, another gateway might house Tag Provider 3, and another might house the Perspective project. To get tags from another gateway, you need to configure remote tag providers with their own independent names in each of the gateways that need access.
In [other SCADA platform], because it's a single project that's rolled out to all physical servers, it means that it's really easy to move tags (or rather, their PLC connections) between IO servers without affecting any of their references (e.g. from graphics, scripting, alarms, etc.). You can simply specify that PLC 1 should be attached to IOServer1 with a hot-standby connection to IOServer2 in case the comms goes down. In this case, if a client is connected and has access to IOServer1 it will use that; if it only has connection to IOServer2 it will use that.
If you wanted to add a 3rd IOServer3, then you just add it in the project's servers configuration, and then add another PLC connection which is attached to IOServer3, and set it to standby mode with a lower priority than IOServer2 (see note in the graphic). Similarly, if you want to change the primary connection from IOServer1 to IOServer2 to load balance, you just change the mode (primary/standby) and priority in the project configuration and you're done.
If you compare this to Ignition, it's a bit more involved and breaking process to try to move tags around. The redundancy process is also more limited and far more expensive (each IO server would need to have a redundant server licence and gateway install), and you're limited to only a pair of redundant servers.
In Ignition, to move a PLC connection from one IO server to another, you need to:
- add the PLC connection into the other gateway
- add the tag provider into the other gateway
- export the tags from the original tag provider and import into the other gateway
- create a remote tag provider on whichever gateways are affected which will most likely be a different name to the remote tag provider link in the original gateway
- go through each project and gateway that utilised the tags in the original tag provider and modify the tag references to use the new remote tag provider (this could be a potentially significant amount of work!)
The other issue with splitting out IO servers in Ignition, is that each time you do this, you gain tag providers and therefore completely separate, independent UDT definitions which now need to be maintained.
hopefully this gives you a better insight into how other platforms have implemented redundancy and their configuration in general.
The key takeaway from this is:
Centrally managed configuration (projects, tags, etc.) is extremely beneficial, especially when multiple gateways are concerned. This would solve many of the pain points of managing multiple gateways, reassignment of gateway roles, etc.. EAM makes this somewhat easier, but it's expensive and still doesn't address some of the issues like going from 1x IO server to 2 or 3 and managing distributing the tags and the remapping required.
Edit:
Maybe it would be nice to be able to merge remote tag providers together if they should be included within a single provider. This way, you wouldn't need to remap any tags in graphics/scripting/etc. that are moved between gateways.
Currently the almost equivalent of above is this:
But this would be much nicer:
4 Likes