Ask the experts: Centralized and distributed logic

Josh Kingsley:
All right, let's get into it. Our first question is coming from Ryan on LinkedIn, and Ryan wants to know, "What's the difference between distributed and centralized control systems?" Travis, as an application engineer, I'm going to let you kick us off with that one.

Travis Quinn:
Thanks, Josh, and great question, Ryan. So, centralized control systems, they utilize a single PLC, which contains the logic and I/O for either an entire machine, or possibly all the way even up to an entire plant. So, centralized control systems are best suited for applications that contain groups of equipment that greatly interact with one another, or are typically in a centralized location. On the other hand, distributed control systems split the logic and I/O for a machine between multiple PLCs, or even other devices, over multiple physical areas. Those types of systems are best going to be suited for highly independent processes or for machines that are spread over very large areas. I hope that answers your question, Ryan.

Josh Kingsley: 
Thanks for being clear about that, Travis. That's the thing I was wondering myself, and glad that you were able to put that to bed here quickly

Josh Kingsley: 
So, our next question is going to come from Rahul on LinkedIn, and he asked, "Does a distributed control system necessarily need to use multiple PLCs?" Adam, I think this is a great one for you.

Adam Bainbridge: 
Thanks for the question, Rahul. You don't need multiple PLCs to do it; you can use multiple devices that are controlling things. If you have a drive, or a device like that, that has a PID loop in it, you can tune all those PID loops to work together and control a system in a sequenced way. But, of course, you can use multiple PLCs as well, so it really just depends on the application. And yes, you can do it without a PLC and just some intelligent devices.

Josh Kingsley: 
Got it. Great question, Rahul, and I hope that Adam was able to answer that for you, but if not, please do feel free to put any follow ups in the comments section below and we can always try to get back and answer that one a little more deeply. 

Josh Kingsley: 
All right, we're going to go ahead and stay with LinkedIn, and we've got a good scenario coming from Robin. Travis, I'm going to throw this one at you. The scenario that she's writing about is having a centralized control system for a car wash. And the question is, if they want to expand and add more car wash lines or bays, can they run all the logic on the same PLC?

Travis Quinn: 
Sure. Thanks for the question, Robin. Really, the answer to your question is ­– it depends. If you have a current PLC that you're using, and its current utilization still has room to expand, then you certainly can go ahead and add in the new car washes. However, if you're nearing the full utilization, maximum number of I/O points or connections, as in Ethernet connections for drives, you're probably going to need an additional PLC or two. Also, depending on the distance between the current car wash line and the two additional car wash lines that you're adding, the length of those cables and wires that need to be installed might actually cost more than just buying an additional PLC or two. So, if these factors are not an issue, you're definitely going to be okay using the original PLC.

Travis Quinn: 
But, other thing to keep in mind is downtime. If you do add those two additional car washes to your current PLC, and that PLC needs to be taken down or powered down for whatever reason, you're going to actually have to power down and not be able to use any of your car washes. So, it might be better off for you to actually just purchase a couple separate PLCs so that you can actually keep those other car washes up and running, in case you need to perform maintenance on one of the car washes that you need to take down.

Josh Kingsley: 
Got it. So, this is a really good scenario. I think we can pry a little bit more into that. I appreciate the answer so far, Travis, but is there anything that you need to think about in terms of memory usage, based on how complicated the program might be? I know you mentioned I/O and different connections. Can memory be a thing that comes up as well?

Travis Quinn: 
Yeah, definitely. If you have a large program, and your PLC only can take a certain amount of memory, that's certainly something you need to watch out for. So, if you're nearing that maximum usage for memory, you're probably going to also need to buy an additional PLC just due to that factor as well.

Josh Kingsley: 
Got it. What about signal fidelity? I know that you were talking about the potential, the need to run a long cable, and I know, in a lot of situations where you're running long cables, you need to add some kind of signal booster. Talk about that a little more.

Travis Quinn: 
Sure. As you get to longer lengths, depending on the type of communication protocol, that length will differ, but you will need to have some sort of boosters, or other devices, switches, whatnot, to be able to boost that signal back up and run long lengths. My guess is that you're probably going to have your car washes installed next to one another, and if you're using an Ethernet-based protocol, you're probably not going to run into issues. However, if they are in separate buildings, you definitely need to take that into consideration. And, this might be another factor that would lead you to purchasing individual PLCs for each line.

Josh Kingsley: 
Got it. Adam, I want to get your input on this as well. You got a lot of nodding going on, so I know you have some thoughts on this. Talk about anything you would add. And, I know that we got into redundancy, in putting the entire car wash down as opposed to an entire bay, so give us your thoughts on this.

Adam Bainbridge: 
Travis is absolutely spot on. Just to elaborate on the redundancy piece ­- if  you need to power down the system, lock it out, tag it out to work on it, having a centralized control system in that particular application may not make sense. You just have to think through the serviceability of it and make sure that it's going to meet your needs moving forward. So, there's a lot of aspects to evaluate, redundancy cost, all of those things. But, even needing to lock out, tag out or service it doesn't necessarily force you out of a centralized control system, but in most cases you would have a separate control panel for each bay, just so that serviceability is where it needs to be in that specific application.

Adam Bainbridge: 
But, outside of that, on the technical aspects of centralized versus decentralized in a car wash, like Travis said, location, and how things are communicating, is key. If you're using a lot of communications, some of those issues of long cable runs become less of an issue, because you're not running multiple conductors long distances, so the costs may be feasible. But, you still could do a bit of a hybrid system, where you have centralized and distributed, where you have a central processor monitoring some higher level functions, and then a local controller coordinating some of the fine details of what's happening in that bay.

Josh Kingsley: 
So, like a lot of these topic that we do, just be really comprehensive in your planning work upfront, when you're architecting your system, and you can avoid some trouble later down the road.

Adam Bainbridge: 
Absolutely.

Josh Kingsley: 
Travis, anything else to piggyback on what Adam said, or we good to move on?

Travis Quinn: 
I think Adam nailed it on the head right there. I think we can probably move on.

Josh Kingsley: 
Got it. All right. Well, thanks, Robin, for giving us that great question, which we were able to expand quite a bit on. Hopefully that answer helps you out, but if that isn't everything that you were needing to know, or you have some extra factors to throw in, please let us know in the comments section and we can look at rehashing that topic.

Josh Kingsley: 
All right, Eaton Nation, keep those questions coming, and I'm going to go pick up the next one from Facebook this time actually, throw some love at that social platform, and this time it's coming from Ivor. He wants to know, "What is the easiest and most cost effective way to communicate with drives in a centralized control system?" So, Travis, we'll have this one go to you. As the application engineer, I think it was made for you.

Travis Quinn: 
Sure. Ivor, thanks for your question. Really, the best way to communicate with the VFD in a centralized control system is definitely using an Ethernet-based protocol, such as Modbus TCP. An Ethernet-based protocol is going to be able to pass all the data that you want in a single cable, whereas the traditional method of passing data in a hardwired, so to say, system is going to require you have multiple wires, which also still cannot pass the same amount of data and not nearly as quickly.

Travis Quinn: 
Actually, as Josh has alluded to, Eaton has actually put together an application note, that he is going to point to later, that's going to walk you through how to connect a drive via Modbus TCP. It's going to walk you through everything from setting up the parameters on the drive to allow the drive to communicate from a remote command, such as a Modbus TCP command, and then walk you through how to set up those Modbus TCP commands to communicate with the drive, what the data correlates to, so for instance, register 2000, 2001, are maybe the drive control word and status, and then how to set up the programming within the PLC to extract and to write the data that you want.

Josh Kingsley: 
Got it. Very nicely done, Travis, and good reference on that application note. It sounds like you had a pretty good time putting that together, so thanks for that. And also, Ivor, I hope that answers your question.

Adam Bainbridge: 
I'd like to add something on the physical side of this too if I could, Josh?

Josh Kingsley: 
Yeah, go for it.

Adam Bainbridge: 
Travis covered a lot, the actual communication methods, but I want to elaborate a little bit on how you'd physically do this. There's really three main methods that most people would use. It's serial communications, which is generally two wires, and you have one main serial trunk and then each drive connects into that trunk, right? Then you have Ethernet based communications, and there are two that are used there. It's called star topologies and it is probably the most common, then a ring, There are  pros and cons to each. So, star topology, you run one Ethernet cable from a switch to each device. A ring, you'd need a device that supports a ring Ethernet network, it would've two ports and you'd daisy chained them. The thought process on a ring network is that you don't have to run so many home runs back to your switch, you can daisy chain everything down the road. But there are some disadvantages to that.

Adam Bainbridge: 
So, star is the most common. Run a simple Ethernet switch, run an Ethernet cable from each drive to the switch, and then from your controller, like the easyE4 nano PLC, to that switch as well. Then, you can add all your devices in your PLC program, set all the IP addresses, and start setting up your program to command and sequence those.

Josh Kingsley: 
Got it. Travis, anything to add before we move on to the next question?

Travis Quinn: 
Yes. I guess just one other benefit to add if you do use the ring approach. If one end of the ring goes down to one end of the loop, the ring controller, the ring master actually is smart enough to know to send the signal the other way. So, when it comes to communications, you have a safety net. So, that whole topology that Adam's getting into is definitely important, and something to talk to a control engineer about before you start setting up your application.

Josh Kingsley: 
Got it. So, once again ­– go back to prepare, prepare, prepare, and make sure that you put all the thought possible into your system before you decide on what the final structure is going to be. 

Josh Kingsley: 
Let's get into the next question. And again, thanks to Eaton Nation for all the wonderful questions coming through. This is great for us. The next one is going to be from LinkedIn again, and definitely want to get both of your takes on this one. This one's from Rosemary, and the question is, "What control system is better for high speed applications that have numerous I/O and drives?" So, Adam, let's have you go first on this one.

Adam Bainbridge: 
Anytime you need to make quick decisions, you want to make that decision as close to the actual process as you can, to really ensure that it's being made in real time. With that said, I'm going to say that my answer is – distributed control system. That way you can split the decision-making between multiple devices. And again, you're doing it as locally as possible to eliminate transport times or a big lumpy PLC program. Do  you have anything to add Travis?

Travis Quinn: 
The only other thing I would add is, as you separate that data, or I should say the control logic, between two or more controllers, is to really prepare and think about how you want to split that data up. If you do it effectively, you can minimize the amount of data that you need to pass between the controllers, which also helps to speed up your application. So, if you need to obviously send less data, that's more time for the free controllers to actually control other tasks.

Josh Kingsley: 
Got it. Do you guys have any examples that you've specifically worked on where you're moving high speed like this, with multiple I/O and drives? Is there any specific application you can talk about that you've seen before, personally?

Adam Bainbridge: 
Positioning applications come to mind, where you're using a variable frequency drive to control positioning, rather than a PLC. It can be interesting to think through those applications, because generally, it's easier to put all that logic in the programmable logic controller. The control engineer is already working within that program, and it's easier, in many ways, to do it that way. However, if you pass that off to the variable frequency drive itself, you can really eliminate how much communication, how much data, has to go back and forth. So, in a positioning application you might have a positioning coder feeding back information to the drive, so it knows the exact location of where the motor platform, whatever it is, is, and the PLC might just be passing the position set point.  It'll say, "Go to position this", and the drive is looking at that signal itself, motoring up to that position, and the PLC's just telling it where to go, and the drive's actually figuring out how to get it there.

Josh Kingsley: 
Got it. Travis, anything specific you've seen that fits this bill?

Travis Quinn: 
Yes. Just, to build on top of what Adam was saying, there's a lot of material handling-type applications where the servo motors themselves, that have different masters, need to still communicate in order to synchronize different processes along a manufacturing line. That's where a lot of that handshaking can occur. But, those high speed servo applications with position control are definitely a very common application where you see this type of system.

Josh Kingsley: 
Well, thank you for all of that information. That all makes sense to me. So, Eaton Nation, please do keep putting those comments, or those questions, in the comments section below the easyE4. Adam, Travis and I would love to see as many as possible on this session today. We do have another one coming in from Facebook that I want to jump on, and this one's coming from Patel. He wants to know, "Is it more difficult to program a distributed control system than centralized?" Is it more difficult to program a distributed system? Adam, what are your thoughts on that?

Adam Bainbridge: 
That's an interesting question, Patel. I think the short answer is no, not really, it just takes a different approach, a different mindset.  I mean, if you have one big program, it's often easier to think through because it's sequential, top to bottom. You're working through the program, you can visually see how it's working through the steps. However, the con of that is you could end up with a really big program that is thousands of steps long, that it might get complicated anyways. Where breaking it down into smaller pieces that go into different controllers might actually simplify it then, because instead of having one program that's 1,000 lines long, you might have 10 programs that are 100 lines long. And, you're looking at each small piece, and you have to think through how those pieces interact with each other in a different way than if you were looking at just one sequentially running program.

Adam Bainbridge: 
So, I'm going to say not really, it is definitely different. I think I'm going to leave it at that. It's just a different approach, different mindset, and it really depends what you're more comfortable with. I like the smaller programs, it's easier for me to work through.

Josh Kingsley: 
It sounds like you have a potential pitfall though, by having 10 programs, as opposed to one, you have 10 programs that have to communicate with each other. Does that potentially throw some wrenches into the system, making those all communicate together? Talk about that a little.

Adam Bainbridge: 
It's a good question. I mean, typically, if you have multiple PLCs, for sure. You would set up one master global variable list, and those variables would stay in sync across all of them. Going back to the last application I discussed, if you had a position set point, any one of the 10 controllers could read it, get the latest value. So, if you're just synchronizing it through global variables, it's really not so difficult. If you're communicating with a PLC and a device, it's a little different because you have to actively pull out that information to each PLC. But, once you have a mechanism in place to synchronize all that data to all the devices, and you've figured out what that list of data is, it's pretty straightforward, pretty simple.

Josh Kingsley: 
Do you have to think about any kind of constraints about programming software or protocols or platforms that you're using? Let’s say you have a drive for manufacturer A, a PLC for manufacturer B, and then you're running a servo motor. Is there going to be universal platforms that can run all this code, or are you going to have to do any kind of code translation across platforms as you're building this?

Adam Bainbridge: 
There's a number of different industrial communication protocols out there. Each have their own benefits. Typically, they're more tied to manufacturers than anything else. However, a lot of devices support multiple protocols, so it's less of an issue. You just want to look at the spec sheet of each device that you've chosen, make sure that they're talking the same language, and it's pretty straightforward. In some cases, you might have a couple of different communication protocols happening at the same time, where you're talking to a sensor with one protocol and a drive with another. And, that's okay too, it doesn't all have to be the same. You just have to make sure at least one thing is talking to both, usually it's the PLC. A PLC might be talking a couple protocols to two different devices, and that's pretty common.

Josh Kingsley: 
Travis, you're nodding pretty furiously, which makes me think that you have something to add to this. So, Adam and I will be quiet now and let you throw your two cents in.

Travis Quinn: 
Sure. The only thing that I really wanted to add is, Adam keeps referencing the global variable list, however, there are some PLCs that act off of a produce and consume on either a back plane or over Ethernet, so global variable lists sometimes aren't an option in order to synchronize the tags between them. In that case, you need to be really careful that you're reading and writing to the correct data. So naming conventions, and other standards that you create internally to recognize what data's going out and what's coming in via your broadcast, however that works, is definitely very important, so that you can make sure you can recognize that data within your program and nobody's getting confused while troubleshooting.

Adam Bainbridge: 
Good point, Travis.

Josh Kingsley: 
So, give an example of how you could possibly do that incorrectly. Or, saying that you would name an output from one device differently than you'd name an output from a second device. Expand on that a little bit more.

Travis Quinn: 
Sure. Say you have a tag that's named dog in one controller and you're broadcasting that out on the network. But, when you're synchronizing it on the other end, if you don't pull it into another tag that's named dog, and you pull it into a tag that's named cat, or sometimes maybe an upper case versus a lower case, if there's a buffer in there, you might get confused on where all the data's being passed back and forth, and what the tag is that's actually being broadcast out onto the network.

Josh Kingsley: 
So, like any kind of programming language, mind your syntax and make sure you're being consistent. This all comes back to the preparation up front that we've been talking about quite a bit. Adam, anything else to add to that after hearing Travis' extra?

Adam Bainbridge: 
He's spot on. And, there are different methods for doing it, too. I mean, there are certain communication protocols, one that comes to mind is OPCUA, it takes a lot of that out. You can take a controller, grab a list of variables, and then it publishes them as what's being available. Then, you go to the other end and say, "Yep, I want this variable, this variable and this variable." And, once you do that, it stays in sync. So, there are options out there that really simplify this as well.

Josh Kingsley: 
It looks like we have time for one more question, so I'm going to jump back into LinkedIn on this one. We've got a question from Michael and he wants to know, "If I'm using a centralized control system, how do I prevent my entire manufacturing line from going down if there's an error in the PLC?" Travis, you talked about this a little bit in our car wash application earlier, but how would you expand to answer that question more generally across applications?

Travis Quinn: 
Sure. That's a really great question, Michael. Really, the only option that you have ­– to totally prevent the entire line from going down – is to buy redundant PLC. The redundant PLC essentially acts as two PLCs within one, so when the diagnostics within the device detect an error, the PLC switches from the current running call PLC to the backup PLC within the device. Besides using the redundant PLC, the only other option that you really have is to take preventative actions upfront, such as making sure you are saving your program on your PLC frequently, so that any online edits that you've made or any tweaks to parameter values are frequently saved. That way, when you replace the PLC, the startup time is greatly reduced.

Josh Kingsley: 
Adam, is there anything that you would add to Travis' answer?

Adam Bainbridge: 
No, he's right. And, there are toolkits within the PLCs that allow you to set up those redundant things a little bit more seamlessly. It's not a terribly complicated thing, you just have to think through the architecture of the system. If you're going to make the I/O redundant, or use a single rack of I/O, because there can always be bottlenecks somewhere, so you just have to decide how redundant you want to make it. Do you just want a redundant processor, common I/O, common sensors, or do you want redundancy to be baked throughout the system, and you want redundant I/O, redundant processors, redundant sensors? The cost goes up, but obviously, your level of uptime goes up proportionately with that. So, you just have to think through, from a hardware standpoint, how much you want to bake into there.

Josh Kingsley: 
So, when you guys are putting together a system, do you typically start with a flow chart and run through asking all these questions? Or, how do you normally approach putting something together to make sure you're being thorough?

Adam Bainbridge: 
Typically the requirements are outlined in user specifications, that it has to have this level of redundancy. I mean, they know their applications. If it's going into a hospital ventilation system, for example, in a surgical room, that's different than it would be in just a general maternity ward room or something like that. So, sometimes the specifications are written up front, you know this project is for this and it has to meet these requirements, and then you work backwards from there. That's typically how they get approached. Other times, if the user's less certain, then you'll just speak with them, understand what their needs and requirements are and make recommendations.