It was probably prior to version 8.x
1 Like
Or âWhere in the World is Carmen Sandiego?â
It was slightly mentioned, regarding the 2 hour trial version in ignition.
What this mean for end customers is that they can have a full scale development architecture environment without any license fees. As long as they can bother to reset the trial and login again.
I get good response from my customers when I mention this.
You can develop all the live long day regardless if the trial expired. Once the trial expires it doesn't kick you out of the designer.
1 Like
Yes, forgot to mention that!
When it comes to Ignition, they provide us a platform and its upto the SI to build the whatever / however it suits the customer. There are advantages and disadvantages to it. As SIs we expects some basic properties when configuring certain points, I was surprised to find all of that have to be created through UDT and Parameters. So the success of an Ignition solution comes down to a proper baseline design.
Yes Ignition has unlimited tags which is great but in reality what is the maximum number of tags a single gateway can support without having a performance hit. Then if you need to add more gateways to share the load then the unlimited tags feature really is not that valuable
Then comes High Availability architecture support. Ignition supports 2 Gateways In Hot Standby mode. GeoSCADA support 3 servers (Hot - Standby - Standby) and VT SCADA support Quadruple redundancy. When you can have more than 2 servers in a failover cluster, it becomes easy to implement DR sites
Just throw more CPU cores at it. There are installations for distributed applications with millions of tags.
I donât think baiting ignition celebrities is ethical.
As someone who integrates with both systems, I personally prefer Ignition.
Ignitionâs a developers Scada, although I come from a technician background and love it. If you want to do something, itâs possible. Itâs very flexible if youâre willing to learn the potential of the different modules, python and sql. The complexity of the project can really vary depending on your needs, it is powerful enough to have lots of scripting and dynamic screens or can be much simpler and utilize all the regular functionality (like tag and property bindings) to build a very capable system. On this forum Iâm sure you can find a million reasons as to why everyone likes Ignition more so Iâll highlight the pros and cons of VT.
VTScadaâs number one pro is that it has tons of drivers. As someone who works in O&G mostly, I deal with a lot of different flow computers, RTUâs and PLCs. VTScada more than likely has a driver built for that device, saving you the hassle of messing around 3rd party opc software.
Secondly, the tag udts (tagtypes in VT). If you create an instance of a tagtype and opt to not use all the different tags in the tagtype, that tag will not throw a configuration error like it does in Ignition. It cleanly lets you use and address tags or not.
Templating-wise, like Ignition, you can template everything with tag paths and relative tagpaths on VT. A plus for VT is that you can also parameterize objects as well (think global object factorytalk). You have the ability to use mix and match if you want as well, allowing great flexibility when developing.
More graphics and templating, if you move a tag thatâs been linked to a graphic, that link will automatically update rather than breaking. As others have mentioned, it also has built tools so that if you click on a tag, youâll get popups with trends and historical info, tag properties and meta data, flow computer screens and communications screens where applicable, etc.
The biggest con of VT is itâs reporting. If you want to do anything more than a simple csv, youâll need to do it out of application.
Overall I would say VT is faster to develop in and has better drivers. Ignition can really let you do anything you want. Once youâve got templates built I would say the development speed then becomes very comparable. I mentioned VT having trending and tag data popups when you click on tags, all that same functionality can be in Ignition, itâs just needs to be built first.
Iâve also been working on more with MQTT and and Edge gateways as of late. Ignition has a lot of tools to integrate into different systems and lots of ways to view and analyze data within itself. I think its an extremely useful system for any company forward thinking company whos wanting to better utilize their data.
Both system have free trials, download them and check them out. Get a feel for each and see what you like better. I think either way you go, youâll have a good system in the end.
3 Likes
One basic question, is VTScada Client Server based or WEB based? My guess it that its a C/S based SCADA as its older than Ignition. C/S based systems have advantage of rich clients and fast response like a standalone desktop application. Disadvantage over web based systems is that its limited number of clients.
Yes, you can of course parameterise any component in Ignition as well by creating custom properties. How does VT do this better?
And what do you mean by use mix and match?
All of this can obviously be done in Ignition, but doesn't come out of the box. I would also argue that in leaving these for the developer to make, it means we can do whatever we want without being restricted to what IA provides. Obviously at the cost of development time. These would be good additions to add to the exchange. I actually have a tag info popup I use both for single tags and for udts. For example right clicking on a device symbol will show a list of all tags in the device udt and clicking on a tag in the list will show all of its properties and a chart if it's historised. Super useful when commissioning.
Oh, you already said this further down
Your right, Ignition is able to do the same, more in-fact. I didn't really get into the details of that on the Ignition side, I was more so just trying to highlight that there is some flexibility to the development methods in VT.
Ignition, you have your various types of bindings. (Expression, Direct Tagpath, Indirect Path, Query, etc)
VT basically breaks it out into two binding types. Your standard Widget (Property binding) and Tag Widget (Direct and Indirect Tag Bindings) for your different components.
By mix and match, I mean you're not necessarily restricted to one binding type or another if you choose a regular widget or tag widget. If you want parameter bindings and tag paths bound to the same widget you can do it.
Ignition has more options and is more capable when it comes to this. There's some more small differences but at the end of the day they are capable of doing similar things.
VTScada has a lot of built in functionality that is really great.
Ignition has capability to do a lot but not out of the box. If you have the development time and you are going to be repeating the same / very similar type project and you need a lot of customization it might be better for you.
Lots of stuff has already been mentioned in this thread, but I feel it is missing some key points that Ignition doesn't do as well on.
-
Version history. If you want a version history in ignition you need to use 3rd party resources. In VTScada it keeps version history of everything and you can easily go back at any time find a change that was done by user x 3 months ago and either undo that change or undo all changes since then. This is built in and you don't have to work to do it.
-
Redundancy / adding Gateways / project backup. I think VTScada does this better then ignition. For instance with ignition if you want 3 backend IO servers and 2 frontend servers and you want redundancy you actually need 6 backend io servers and 4 frontend servers. + 3rd party load balancer.
For VTScada load balancer is built in. Same or greater level of redundancy can be accomplished by using half the servers in VTScada. For the 3 backend IO servers in ignition If you want to move device x tags 1-100 to being run from backend A to backend B you have to make some major changes in ignition. To change which server is communicating to a group of tags it is one simple change and nothing would be broken anywhere in project. -
Event history is built into VTScada ... you need to build your own for Ignition. Depending on your project that could be a + on either side.
Are you forgetting about Ignition's Audit log that captures events? It captures everything from tag writes, logons, to modifications to configuration of tags/graphics
I do agree with you with the redundancy/scale out architectures in Ignition being somewhat painful. I haven't been there yet for larger scale-outs, but splitting a single GW into frontend/backend was more work than I was expecting
1 Like
I'm wondering how, implementation wise, stuff like that actually works. I don't see how you would abstract over renaming/moving tags without some abstraction in place that implies a lookup table residing somewhere.
Audit log in ignition isn't as effective as the event history is in VTSCADA.
Advantage is all depending on resources that you want to spend on the project. Based on my experience the VTScada solution gets what is needed without development work for 99% of projects while Ignition Audit log when I have used it has been lacking. Now the information might be there or in other logs in ignition or in diagnostic tools etc, but that takes more work to get to.
Don't get me wrong I am not saying VTScada is just a better system. But I also disagree with the thought that seems to be expressed here that Ignition is just a better system. Bottom line IMO which is better is all going to be project dependent (both scope and personnel who will be operating). Both Scada systems IMO are significantly better then any other SCADA system I have worked on. They just work differently and depending on the situation either could be the right choice. Both have a much smaller learning curve then other older systems like Ifix, Cimplicity etc.
I don't follow you, can you elaborate?
Ignition isn't a SCADA system though, VTSCADA is. Ignition is an IIOT Platform that can do many things that the traditional SCADA systems can't do. If all you need is HMI buttons and Values VTSCADA will work.
1 Like
Well, for starters, this just seems mathematically impossible. How would you have a "greater" level of redundancy with less servers? The whole point of redundancy is that your hosts are isolated from each other.
I guess this is the part I'm most confused by. Ignition uses string-ish tag paths everywhere; does VTScada do something else? How do you say "these tags are coming from X" in a way that doesn't couple you to X? Is there an ID somewhere? Or a 'unified namespace' or something? MQTT gets you some of that benefit, I know, with some other potential drawbacks.
I'm just not sure how it actually works, and I'm curious. Is there even a way to guarantee things, in the other direction? Can you say, as a developer, "I want these tags to come from server X"? Or do you just say "I want these tags" and everything is figured out for you?
I'm really not trying to pick fights here. Obviously I have some personal stake in Ignition, but I'd also like Ignition to be better, so being aware of the weaknesses only helps 
Most of the regulars here on the forum are definitely in the "Ignition enthusiast" category, so it's far from a representative sample 
9 Likes
The fundamental way VTScada handles server config is different.
Ignition you want 3 IO gateways (not edge devices on separate networks/locations just 3 different gateways to handle load from multitude of devices)
each of those backend gateways is standalone so if you need redundancy with those you need a second server / gateway for each handling redundancy. Same thing for Front end server. So 3 backend + 2 Front end with redundancy such that failure of any 1 server = no system impact = 10 total servers running.
VTScada on the other hand for same setup you can have 5 servers and still have 100% redundancy. Now in this case that would mean based on your config the load from the lost server would then be on one of the other 4 servers but it would still operate. You could add a 6th server and then loss of any 1 server everything would still operate with no double loading. The greater level of redundancy For example is you can setup with VTS that in this case with 6 servers even if 5/6 servers fail the last remaining server can still operate all the functions of backend and frontend. Obviously it would be loaded and response time / update rate wouldn't be good but compared with ignition if you lose 2 "wrong" servers you would lose I/O connections completely.
I think the simplist comparison would be that Ignition works more like a group of Raid 1 arrays and VTS works as a Raid 5... Not a perfect comparison but close enough
How VTS handles this is there is just one "Project" file across all the servers. In that project file you can assign function priority to different servers. -- PLC01 use serverA then serverB then ServerC PLC02 use ServerB then ServerA then ServerC ... Same with other core functions (historian etc)
Tags reference a Driver and server lists tell the servers which server connects to what device.
Tags in VTScada have unique identifiers associated with them so that is how the system in most cases keeps tag assocation without breaking things (in most cases you don't deal with this unique identifier at all or even care it exists) It would be like ignition using an Unique ID per tag and then when you use the TagPath somewwhere behind the scenes ignition uses the Unique ID then if you change the tag path because you rearange the folders etc the UniqueID doesn't change and tag path is updated.
If you want to have a discussion sometime about key ways I think that could really improve ignition IMO I would be open to that. Probably be easier to do that over a live chat/voice then in a forum though.
Just FYI there are several things I do like better about ignition then in VTS and I have given a lot of recommendations to them as well and several of those have been implemented already.
3 Likes