Hi, I am new to Ignition but has anyone had any experience of converting a system from Aspentech GCS? Are there any issues that I should be aware of? Ignition seems very nice, as a programmer from way back and SCADA user it is pretty much what I would have written myself.
Possibly open ended question. Is this just quirks with Ignition itself or GCS specific integration issues?
Ignition can be sometimes be very limiting and sometimes very scalable depending on workload. When we used a mysql database for the tag datastore we had scaling issues around that with 100,000s of points and frequent updates. We ended up writing a custom module that removed that problem altogether but took some effort and requires regular changes as Ignition gets updated but infinitely better. Ignition’s designer is extremely powerful and is its best feature in my opinion.
I’m ashamed that I never heard of GCS (former HYSYS/A+ developer and IP.21 user). I think it depends on how you plan on integrating data. I didn’t use GCS so dont know its quirks (and being Aspen it must have quirks) and a lot will depend on how you plan on getting data into Ignition.
Aspen IP.21 ODBC adapters worked though I never got the 64-bit adapter working before we dropped it and had the occasional problem of it freezing the whole database thread in Ignition which would break all other database connections. So I had to monitor that and kill the socket connection periodically. We never used the OPCUA adapter with Ignition so no experience with that.
Well, since the original question was fairly open ended, I guess that is to be expected. I guess the question is two fold. GCS had / has some lovely features. Came from the Infoplus 21 days when people thought about systems. Ignition seems to be a welcome return to a server centric approach. I have two options as I see it. Engineer a replacement for GCS using Ignition which I think it is flexible enough to do and is similarly object oriented the way IP 21 was originally designed. Or go for the complete replacement option. Now I understand that as a Historian IP21 logs data faster than a SQL option but the question is does it really matter? The plant is normal process not a steel mill where microseconds matter. I was wondering if anyone out there had experience of either approach and had salutary tales…
IP.21 is a superior historian backend but its certainly more expensive in probably all cases. I’m also talking pure historian here. Ignition is incredible value for the price in my estimation but there are better products if price is not an issue.
Pulling in trends into Ignition with IP.21 backend is possible via ODBC adapter for sure as I did that in several cases but its not a first class experience but definitely do able on a windows box. Not sure about via linux and jdbc or via OPCUA interfaces. Not sure I’d recommend it unless you had the infrastructure in place and wanted to keep IP.21.
We used the Ignition Tag History aspect in a standalone project with probably up to 200,000 realtime tags available at 1-3 second updates (not all continuously updating on screens) and probably 10,000 continuously logging historian tags at about every 3 seconds. Exporting data to CSV was the hardest part requiring jython custom scripts to meet our needs since existing tools didn’t quite meet our needs at the time.
Ignition performed reasonably ok for us with very little maintenance over 3-4 year span. Most operational problems were with mysql once the initial bugs were shaken out and that was mostly non-issue. Though we did have some issues with tag updates breaking a couple hundred historical tags in the project in a way we never resolved. How Ignition handled import of tags a few years ago was a bit of pain for us but that may have been improved.
We used mysql for the historian and a server with 2 TB of storage. With this trends worked well and HMI displays were easy to develop. There was no equivalent of Process Explorer for operator to use where they could define their own chart with own points list out of the box so there was a bit of custom work to make dynamic trends in displays but it was possible which is testament to Ignition’s flexibility.
Thanks very much, that is very interesting. The import of tags seems fairly straight forward using python, I can see that using xml would be a real pain. I am also interested by your comment about better products? As far as I am aware all the other products have a fatal flaw in that they are not server centric, managing the clients is a pain, one of the beauties of IP21 and GCS. One place to make the changes even with large numbers of clients. This appears to be the case with Ignition, or have I missed one somewhere?
The designer is the easily best feature of Ignition. Ability to publish to all clients is enormously useful. Most issues we have usually come down to Java and not Ignition though its client-side cache sometimes corrupts or is incomplete and has to be manually deleted (maybe fixed in latest version) when following specific workflows. Getting “normal” users to understand how to self-administer java fixes like deleting apps from javaws or java console takes training.
I love being able to run the Gateway on linux and some of my users use linux and I’ve never really seen issues with that.