ignition scada, communication flow

[jds8086]

I can't seem to find a clear answer on this. Say you have a plc and an hmi with ignition to control the plc(and of course all other things you do with hmi's). Do the plc and hmi communicate directly or does everything have to pass through the ignition server?

 

[the_msp]

If for example an AB PLC with a PanelView, and a separate Ignition SCADA, the PLC will talk to the PanelView direct.

If Ignition is the HMI, running as a client, then the PLC talks to the server and the server updates the HMI.

 

[Phrog30]

In ignition the server and client can be one in the same. Ignition is light weight enough that the gateway (server) can run on a touchscreen. In this case it is also the client.

 

[jds8086]

Thank you, my co-worker has be very confused on this subject. He claims that there is "an ignition server" on the network and when devices communicate everything goes through said server. This concerned me because he wanted to start controlling a good bit of our equipment out here with ignition and all i could think is that is not a good idea if everything has to go through the network to function, one network issues, everything goes down. Does anyone have a link to more in depth information about how communication works with ignition, or care to unpack a little more on what role this "server" has.


EDIT: So the way i understand the licensing is that you get 1 gateway per license, so that being said it may very well be as he described where everything would have to go through the one gateway to function (no local gateways in the machine so everything stays on a local (machine confined) network). Am i on the right track here?

 

[Paullys50]

All PLCs are configured to communicate to the Ignition Gateway, which usually resides on server-class hardware for large installations, however could run on a basic PC depending on your application requirements. Keep in mind this is actually best practice. Other platforms (WonderWare, FactoryTalk View...etc) will centralize PLC communications as well as PLCs are limited in communication bandwidth. Having numerous SCADA/HMI connections to a single PLC can cause performance issues.

Ignition clients are launched to run the actual application(s) you wish to use. The clients communicate with the Ignition Gateway. Never directly to a PLC.

So, you are correct. Should you have an issue with the Gateway for whatever reason all your clients are down. Ignition does offer options like local-client fallback, edge devices and redundancy to maximize your uptime.

However, if your network install is already a hot-mess no software solution is going to be able to withstand downtime because of it.

I suggest you review the manual, and inductiveuniversity.com start with the architecture section.


https://docs.inductiveautomation.com/display/DOC81/Standard+Architecture

 

[JordanCClark]

+1 to Paully's post. In particular, you may want to consider a 'hub-and-spoke' architecture.

 

[jds8086]

All PLCs are configured to communicate to the Ignition Gateway, which usually resides on server-class hardware for large installations, however could run on a basic PC depending on your application requirements. Keep in mind this is actually best practice. Other platforms (WonderWare, FactoryTalk View...etc) will centralize PLC communications as well as PLCs are limited in communication bandwidth. Having numerous SCADA/HMI connections to a single PLC can cause performance issues.

Ignition clients are launched to run the actual application(s) you wish to use. The clients communicate with the Ignition Gateway. Never directly to a PLC.

So, you are correct. Should you have an issue with the Gateway for whatever reason all your clients are down. Ignition does offer options like local-client fallback, edge devices and redundancy to maximize your uptime.

However, if your network install is already a hot-mess no software solution is going to be able to withstand downtime because of it.

I suggest you review the manual, and inductiveuniversity.com start with the architecture section.


https://docs.inductiveautomation.com/display/DOC81/Standard+Architecture

Thank you, i'll get some reading done.

+1 to Paully's post. In particular, you may want to consider a 'hub-and-spoke' architecture.

With this architecture you do have to purchase a license for each "spoke" correct?


I guess my biggest question now that we have boiled down communication would be is there any point to running ignition on machines that do not need to communicate external to themselves (these machines have no data logging or communications to other machines, they are pretty simple and just don't require such things). Co-workers thinking is we can use tablets instead of "real" HMI's (which these dam PanelView 550's are ridiculous to buy or repair now days) and save a lot of money with ignition in the long run. I just wonder if there is some other way that to use cheap x86 "HMI" hardware that would not have to run over the network to function thus removing that possible mode of failure.

 

[Paullys50]

You purchase licensing based on each Ignition Gateway you require. Hub-and-Spoke is advanced and I'd not pay much attention to it, yet, unless you know you are planning a large installation.

If you are trying to replace local HMIs which only control a local, isolated control system, you could look at Ignition Edge which is for this use case but you would then have a license for each Edge instance required, and you would need a PC and Touchscreen. You also won't be running tablets here. You won't save much money and you'll have to create new applications for everything. It's a hard sell IMHO.

Ignition doesn't compete well with islands of control. There is plenty of value in the familiarity of a PanelView.


What Ignition does well, is give you central access to control, monitor and collect data from those systems.

 

[Phrog30]

If you are interested in ignition get in touch with sales. They can schedule a web meeting and show you pretty much everything you need to know, then you can ask questions. They usually have an engineer on these calls that can answer very technical questions.

 

[JordanCClark]

Waxing biblical for a moment, Proverbs says 'without vison [see what I did there?], the people wander aimlessly.'

Is there a bigger picture of what your co-worker is looking to do? If it's just a cheap HMI, go with a Maple Systems, or some such.

However, you say that there is no data collection, and it's just not needed. He may be thinking otherwise, even if it's just for monitoring cycle times or efficiencies.

Either direction may require different ways to attack your problem.

 

[jds8086]

Waxing biblical for a moment, Proverbs says 'without vison [see what I did there?], the people wander aimlessly.'

Is there a bigger picture of what your co-worker is looking to do? If it's just a cheap HMI, go with a Maple Systems, or some such.

However, you say that there is no data collection, and it's just not needed. He may be thinking otherwise, even if it's just for monitoring cycle times or efficiencies.

Either direction may require different ways to attack your problem.

Honestly it's hard to say what exactly his vision is, I've been trying to boil that down. I think the main driving force is we already have an Ignition license and he wants to play. Also, the company won't buy anything but allen bradley as far as a "real" HMI goes, which means we will be stuck with the pv550's (because new AB stuff is $$$$) that are becoming a real constant problem on these machines. As far as data collection, if we do go this route we will certainly take advantage of that, but they do currently have a more manual, external way of recording the data that would be collected.


He got a green light on the deal by the sounds of it and was talking about ordering a bunch of tablets, i stopped him and strongly suggested that we do a thorough trial run, maybe load up a bunch of virtual machines on a couple of laptops and simulate the machines and make sure the performance is there (with plenty of head room for other projects).



To make me more uneasy about this, he want's to use an Anybus wireless bolt to connect these machines to the network. I know this is a completely separate subject but running controls over wifi is concerning, hopefully i'm overreacting.

 

[Phrog30]

Also, the company won't buy anything but allen bradley as far as a "real" HMI goes

Seriously? AB HMIs are real alright, real garbage.

 

[rdrast]

A main Ignition Gateway (server) is actually healthier for a network (and connected PLC processors) than individual Local HMI's, be they PanelViews, C-Mores, Red-Lion, anything. The reason is simple, with 3 local HMI's reading a tag, that is at least three, possibly more, separate communications sessions over the network to the PLC. Using a gateway server (like Ignition's full version), you can have 300 local HMI's, but there will only every be two connections (default, you can change it) to the PLC CPU.