Considerations for migrating to Ignition SCADA

[RonJohn]

Our plant has been firmly entrenched in the FTView SE Network Distributed package for some time now. After a poor experience with Transaction Manager and reading several threads on this site, we decided to give Inductive Automation's Ignition a try for data logging, trending, etc. So far, we are impressed with what Ignition can do and how easy it is to set up.

Now the question has been raised about migrating our SCADA screens from SE over to Ignition. This is not a topic to take lightly as we're talking a couple dozen clients, hundreds of screens, thousands of alarms and about ten thousand tags scattered throughout 10-20 A-B PLCs of various vintage. The facility runs 24/7, so rolling out a change like this has to be well thought out. We do our best here to take ownership of our controls and handle modifications ourselves.

If there are any other plant folks out there who could share your experience with such an undertaking, I'd be appreciative. Integrators feel free to chime in, but I realize from 20+ years on that side of the process the perspectives aren't necessarily the same as those of the plant engineers.

Here are some questions we're pondering:
1. Assuming there's no software package to convert FTV SE screens to Ignition, how much pain is expected in the process to reconstruct the new screens in Ignition?

2. When adding new equipment to our plant, the OEM typically has no issue developing screens in FTV SE that we can import into our SCADA package. How challenging is it to find an integrator/OEM to develop such screens in Ignition?

3. I noticed posts in another thread that mentioned a dislike for Ignition's mobile app. Can anybody expound/update me on this? This feature is important to us, but even now were dead in the water as Viewpoint & SE haven't played nice with each other.

4. Any other caveats we need to consider?

Thanks in advance,

[Paully's5.0]

First good choice on moving to Ignition! It's good stuff!

My Systems Integrator perspective - I had a new project challenge a couple of years ago where Wondeware InTouch simply wasn't going to give me the flexibility I needed but I knew (took a gamble) Ignition would. At the time our "standard" SCADA package was Wonderware, so I had to re-build our Wonderware standard onto the Ignition platform then build all the additional features I needed for the project (essentially a big recipe managment/batching(ish)) system. Keep in mind this was my first project w/Ignition and our base Wonderware SCADA package was pretty complex.

The biggest things that hung me up were doing things in Ignition the way it HAD to be done on WW. I had a flawed mind, leading to artificial roadblocks that I thought existed but really didn't. I rebuilt things 2-3 times as I learned more about how powerful Ignition was, constantly re-factoring things to eliminate the wasteful methods WW forces upon you. You'll have the same issues when looking at FTViewSE. Don't let methods/philosophies established in your current FTViewSE system poison your mind. I highly recommend rebuilding it all and just make the final project "look & feel" like the existing FTViewSE screens.

There isn't much risk at all. As you start this project know that you simply run Ignition in parallel w/FTViewSE until you are confident you have covered all the functionality. Then cut over to using Ignition, keeping FTViewSE as a backup "Just in case", then remove it all together. From an operational perspective, risk can greatly be reduced and predicted. Obviously much of this depends on the complexity of what FTViewSE is actually doing for you.

Originally Posted by RonJohn

Here are some questions we're pondering:
1. Assuming there's no software package to convert FTV SE screens to Ignition, how much pain is expected in the process to reconstruct the new screens in Ignition?

No nothing to convert it, and if you could it wouldn't take advantage of Ignition's abilities, so it would be converted junk much like a PLC5-ControlLogix conversion. Sure you can convert it and it will work, but you are wasting so much potential of the platform.

Ignition is easier to learn, the pain is decrypting FTViewSE, then porting the same/more functionality to Ignition. Still you do you have a learning curve with Ignition. Depending who is actually going to carry out the task, you may want to attend training. Personally I didn't, my years of experience and the Inductive University got me up to speed quick. I've actually gotten certified a few times w/o any formal training from IA. But you have to evaluate your resources.

EDIT: Start learning python! Ignition uses it (technically jython) as it's scripting language. Much easier and simpler than VBA in FTViewSE.

Originally Posted by RonJohn

2. When adding new equipment to our plant, the OEM typically has no issue developing screens in FTV SE that we can import into our SCADA package. How challenging is it to find an integrator/OEM to develop such screens in Ignition?

IA has a large listing of Integrators. I will PM you some recommendations. What industry are you in?

Originally Posted by RonJohn

3. I noticed posts in another thread that mentioned a dislike for Ignition's mobile app. Can anybody expound/update me on this? This feature is important to us, but even now were dead in the water as Viewpoint & SE haven't played nice with each other.

Mobile is a bit of an issue because it runs a virtual instance on the Ignition server, which the mobile client then connects too. So it increases the loading on the Ignition server. It's not html5 based. ICC 2016 is underway this week, I'm sure they will be announcing a new version of Ignition, perhaps improved mobile experience will arise.

Originally Posted by RonJohn

4. Any other caveats we need to consider?

My experience with Ignition has been rather motivating than De-moralizing. It's a platform that excites me and fuels drive in this profession. Touching InTouch/System Platform/FTViewSE guarantee headaches and frustration most of the time.

Ignition isn't perfect, but it's pretty darn good. I'd say the hiccup is with the PLC drivers. They work, and do pretty well however this seems to be the weak point. Now, my experience is testing out Ignition w/v21 firmware of a ControlLogix shortly after it was introduced and all sorts of problems/performance issues. Granted, AB changed a bunch of things forcing not only IA but everyone else to re-do their drivers so it wasn't limited to IA. However IA's dev team is smaller and took them a decent amount of time for good v21+ drivers. Hopefully it's all behind them but keeping kepware as a backup or primary driver for PLC comms is something to consider.

Check your PM!

[OkiePC]

Use Inductive University (online training). I probably have spent 40 hours going through their most excellent courses and I have completed less than half of them.

Use their templates and UDT structures. These are huge time savers.

Some things that are very different.

1 It's fast. Easy to install and deploy.
2. It's reliable. I have had very few problems with it. I have had the designer crash a couple of times, probably self inflicted. I have not had the gateway crash but I have had it fail to start up with the computer once.
3. In the designer, you are "live" so your displays will look like they do as if it were running. the only time I find this annoying is when I have conditional visibility on something that is not visible due to a tag status while I am working on it.
4. Python scripting is very different from anything else I have learned. Very powerful, but very different.

How I feel when working with Ignition:
https://www.youtube.com/watch?v=TBX5CP1HMBs

[TConnolly]

We've been using Ignition for two years now. We have been so happy with it that we have retired 29 FTView HMIs and four CiTect HMIs and have added data logging to applications that didn't previously have it where no HMI is present.

We've also expanded it to show OEE and status information and announcements on large screens all over the plant. It also logs maintenance and repairs and emails notifications when something needs attention. It is also doing some non-automation tasks like project tracking and software change tracking applications used within our team, and also it has replaced a number of previously hand written log books and printed checklists. It's doing a lot more than just HMI for us.

[RonJohn]

Thanks for all the replies. Lots to digest.

Originally Posted by Paully's5.0

The biggest things that hung me up were doing things in Ignition the way it HAD to be done on WW. I had a flawed mind, leading to artificial roadblocks that I thought existed but really didn't. I rebuilt things 2-3 times as I learned more about how powerful Ignition was, constantly re-factoring things to eliminate the wasteful methods WW forces upon you. You'll have the same issues when looking at FTViewSE. Don't let methods/philosophies established in your current FTViewSE system poison your mind. I highly recommend rebuilding it all and just make the final project "look & feel" like the existing FTViewSE screens.

Thanks Paully. Any quick examples of "wasteful methods" you can share? I'm not sure I follow.

I like the idea of converting & running the two side by side whilst working out bugs. Conventional wisdom in these parts oftentimes is to "convert junk" as you mentioned and then neaten it up later. As we all know, "later" rarely comes.

Originally Posted by Paully's5.0

IA has a large listing of Integrators. I will PM you some recommendations. What industry are you in?

We're in the dairy industry. I was thinking more in line with when we purchase a piece of equipment, will the OEM be willing/able to adapt their canned HMI screens to Ignition so we can add to our SCADA. In the past, this has not been an issue with FTView.

Originally Posted by Paully's5.0

Mobile is a bit of an issue because it runs a virtual instance on the Ignition server, which the mobile client then connects too. So it increases the loading on the Ignition server. It's not html5 based. ICC 2016 is underway this week, I'm sure they will be announcing a new version of Ignition, perhaps improved mobile experience will arise.

Any idea where/when this info will come out?

Originally Posted by OkiePC

Use their templates and UDT structures. These are huge time savers.

OkiePC,
Thanks for the thoughts. The additional endorsements of IU and learning Python are encouraging. When you mentioned UDT's, how does that relate to the UDTs we have in our Logix processors?

Cool link, BTW. One of my favorite bands of all time!!

Originally Posted by TConnolly

We've also expanded it to show OEE and status information and announcements on large screens all over the plant. It also logs maintenance and repairs and emails notifications when something needs attention. It is also doing some non-automation tasks like project tracking and software change tracking applications used within our team, and also it has replaced a number of previously hand written log books and printed checklists. It's doing a lot more than just HMI for us.

That sounds like it would be a huge plus for some of the folks here. How much effort was needed to implement all this?

[Paully's5.0]

Originally Posted by RonJohn

Thanks Paully. Any quick examples of "wasteful methods" you can share? I'm not sure I follow.

Layers, layers and more layers. Objects stacked with visibility/conditions to get a desired effect. Gobs of scripting to allow indirection, SQL db access quirks, dealing with parameter files, creating all sorts of "memory" tags to track object conditions.

FTViewSE/WW...they have been around and alot of smart people have come up with ingenious ways to get these platforms to do something they need, which at times can be creative and mind-numbing due to the limited tools available. Much of it depends on how complex/simple your application is. Access databases with either of these platforms is a bumpy road.

Originally Posted by RonJohn

We're in the dairy industry. I was thinking more in line with when we purchase a piece of equipment, will the OEM be willing/able to adapt their canned HMI screens to Ignition so we can add to our SCADA. In the past, this has not been an issue with FTView.

Depends on the OEM, FTView has the advantage with FTViewME, OEMs know PanelViews and ME can import into SE pretty easily.

Originally Posted by RonJohn

Any idea where/when this info will come out?

v7.9 is being released now, I think they discuss the new features later this afternoon. Look for the release notes/videos that will probably make their way to their webpage.

UDTs in Ignition are just like UDTs in ControlLogix. When I did this I created our device face plates to use UDTs which matched our AOI structure in our ControlLogix. Made tag generation 100x faster it seemed. I pretty much created UDTs in Igniton to match any UDT in the ControlLogix that Ignition had to access.

Templates are simply just objects, spend time building quality templates. Pay attention to the "template repeater" tool, very very handy. Used it to create dynamic screen footer information simply by configuring a database table. No scripting, no layers and layers controlled by visibility. It was really slick once I figured it out. Also get to know all the object properties hat you can modify and reference w/o needing tags, this is a HUGE advantage.

The effort required to make Ignition 'more than just a SCADA' is really going to be dependent on the ability of your team to embrace Ignition, learn it, and then get creative. Sky is the limit if you have driven resources. If you are limited either by number of hours in a day, fires to fight, management to cater too, then it will take a large number of tiny steps to move forward. Hopefully your company puts a premium on automation.

[arlenjacobs]

Originally Posted by Paully's5.0

Ignition isn't perfect, but it's pretty darn good. I'd say the hiccup is with the PLC drivers. They work, and do pretty well however this seems to be the weak point. Now, my experience is testing out Ignition w/v21 firmware of a ControlLogix shortly after it was introduced and all sorts of problems/performance issues. Granted, AB changed a bunch of things forcing not only IA but everyone else to re-do their drivers so it wasn't limited to IA. However IA's dev team is smaller and took them a decent amount of time for good v21+ drivers. Hopefully it's all behind them but keeping kepware as a backup or primary driver for PLC comms is something to consider.

I would also recommend Kepware.

It is included with PanelView Plus from AB (Rockwell Automation) and it is sold by AB as an option for FactoryTalk View. So, you know the Kepware drivers are going to work well with AB PLCs and if there are changes to the PLC they will update the driver fast.

Their drivers are efficient, which matters when you have 10K+ tags. You could run a Wireshark capture and look at the PLC loading to see it's efficient. Not sure how the Kepware drivers compare to the drivers from Ignition; but it's not possible for the Ignition drivers to be better than the Kepware ones.

[arlenjacobs]

Originally Posted by RonJohn

2. When adding new equipment to our plant, the OEM typically has no issue developing screens in FTV SE that we can import into our SCADA package. How challenging is it to find an integrator/OEM to develop such screens in Ignition?

For those who've done this:
How easy is it to bring new screens into an Ignition project?

Say for example you have your SCADA all set just fine. Then you get a new filler, or palletizer (or ??), but it has a stand alone HMI.
You can bring in new screens to a FTView SE project, but it has some pitfalls.

• tag name conflicts with existing tags
• screen name conflicts with existing tags
• have to create a new HMI server? extra $$$ and PC server
• troubleshoot screen navigation conflicts
• import alarm tags, add new filters to everything

I haven't used Ignition to combine/merge a project into an existing one.
But RonJohn's question seems like a big deal.
How well does Ignition handle merging new equipment into the existing SCADA?

[Paully's5.0]

Originally Posted by arlenjacobs

Say for example you have your SCADA all set just fine. Then you get a new filler, or palletizer (or ??), but it has a stand alone HMI.

Lets not get carried away on FTViewSE abilities, sure if OEM equipment arrives and it happens to have a PanelView, then yes you can import it. But if it comes with some "other" HMI, you aren't importing anything into SE.

You can also spec the OEM to provide Ignition files that you can import into your system. So it really depends on how you spec and purchase that equipment.

Ignition fully supports importing/exporting like everyone else. But of course you can't import non Ignition files.

[arlenjacobs]

Originally Posted by Paully's5.0

You can also spec the OEM to provide Ignition files that you can import into your system. So it really depends on how you spec and purchase that equipment.

Ignition fully supports importing/exporting like everyone else.

Importing graphic files into FTView is very specific. Yes you can do it, but you are likely to have conflicts with tag names, display names and a few other items. Importing a PVP project adds another layer of troubles.
The easy solution is to buy another HMI server license and h/w (or virtual) server to host it = big $$$.


That was my point; what are the gotchas when you spec and import a complete Ignition project (equipment) into another project (plant)?
Or is that a naïve question because it just works so well?

[Paully's5.0]

Originally Posted by arlenjacobs

That was my point; what are the gotchas when you spec and import a complete Ignition project (equipment) into another project (plant)?
Or is that a naïve question because it just works so well?

Well, I suppose if you happen to get a project with screens/tags that are named the same you will have to make adjustments. I'll give it a try later this evening to see exactly how it prompts you.

The other option is to simply keep the projects separate. Ignition does a good job of allowing a user to redirect from one project to another on the server. Say you have 10 areas of a plant, and each has a unique Ignition project, you could simply have 10 navigation buttons representing each plant area on a screen and just redirect to the specific project and run that specific project when you want to access that area of the plant. This eliminates any mess of trying to merge multiple projects. Same could be done with OEM equipment.

That should be as simple as importing the new Ignition project into the server and adding navigation buttons to the existing project to allow it to redirect from one to the other.

[VAN]

One thing I don't see mentioned is make sure your gateway is configured correctly! (CPU/Memory/RAM/etc.)

Also, I recommend having your databases stored on a separate computer (not the gateway computer).

[curlyandshemp]

I recently upgraded an RSView32 batching system to FTSE with FTTM. What a pain in the a @@ FTTM is compared to Transaction Groups in Ignition.
Where Ignition excels is in getting data into and out of databases.

Based on the attendance at this year's ICC in Folsom CA, finding an integrator that knows Ignition should be simple:

https://inductiveautomation.com/integrators/find

The mobile module is an issue, but it has been slightly improved to allow VNC connections. This is a better interface, but the resource to host the VNC is still at the Gateway.

V8.0 release will resolve the mobile module issues ( sometime in 2017 )

Installation is quick and simple, and adding another client is simple as providing a device that has a web browser, Java and can ping the Gateway .

[the_msp]

Originally Posted by Paully's5.0

The other option is to simply keep the projects separate. Ignition does a good job of allowing a user to redirect from one project to another on the server. Say you have 10 areas of a plant, and each has a unique Ignition project, you could simply have 10 navigation buttons representing each plant area on a screen and just redirect to the specific project and run that specific project when you want to access that area of the plant. This eliminates any mess of trying to merge multiple projects. Same could be done with OEM equipment.

I have done exactly this... multiple projects running on way gateway each totally unique to their respective machines. One supervisors (master) project that can redirect to them, with a template for each machine showing alarms unique to only that machine. A home button from each project to take you back to the master project.

[diat150]

Originally Posted by curlyandshemp

V8.0 release will resolve the mobile module issues ( sometime in 2017 )

what are they planning?