Today is...
Friday, September 22, 2017
Welcome to the Modbus Community, about
the world's leading automation protocol.
Replacing a Plc-based control to a computer control
Moving to Pc control system is good?
By Gnichi Mohamed on 7 October, 2011 - 10:09 am

Thank you for helping me first. My problem is that i have a machine controlled by siemens S5-90U that process food in the company where i work. I need to extract temperature value and water's debit for processing these data. So i was trying to find a way to connect the Plc to a Pc but in vain!:((.

So I decided to reverse engineer the whole system control and replace it by a Pc. I'm thinking of finite state machine or real time control to do this.

So have you any idea's that can help me?
Is this the better solution?

1 out of 1 members thought this post was helpful...

You will get a variety of opinions about the successes and failures of PC based control. But a PC is not a PLC and you will need to clearly understand the differences and just what to expect from a PC based control system. - In any case, just because you are using a PC for control does NOT automatically mean it will talk to another PC - You need OPC for that.

Kepware make OPC servers for connecting Siemens S5 and S7 PLC's to a PC. http://www.kepware.com/

If your S5 is getting old (and yes, it is getting old) the easiest upgrade path is probably a straight migration to S7. Code can be converted automatically and usually requires a minimal amount of manual tidying and changes - but get an experienced System Integrator to help you if you are not familiar with S7 programming.

Rob
www[.]lymac.co.nz

By James Ingraham on 10 October, 2011 - 6:55 pm
1 out of 1 members thought this post was helpful...

I could probably talk for days on this topic. (I know, I know, I can talk for days about any topic...) Please consider the problem to be, for lack of a better phrase, non-trivial.

PLCs are essentially computers, but specialized ones. PCs are general-purpose. Basically, a PC can do anything a PLC can do, but not necessarily as easily or elegantly. Let's start with interfacing to the real world, which is generically called "I/O" for input / output. PLCs are great at I/O, PCs not so much. So the first thing you'll have to decide is how to connect the I/O to your PC. There are so many ways to do this that it's difficult to summarize. I list a handful of methods on this thread: http://www.control.com/thread/1317478247#1317652739

Next, you'll have to decide how you're to control the process. A custom program written in a general-purpose programming language, e.g. C/C++, Java, C#? A more specific language like LabView? A software based PLC like WonderWare InControl? These all have their advantages and disadvantages.

If you write a custom program in a general purpose language then there will come a time when someone will hate you. Suppose you change jobs, get hit by a bus, or even just go on vacation. The guy who inherits the project will have no idea what's going on, and really no where to turn to for help. As old as the S5 is, there are still people who can look at it and immediately figure out what's going on. You can find spare parts on E-Bay. You can post a message on control.com and say "S5" and people know what you mean. If it's all custom then none of that will be true. They might not be able to get a compiler for the language you chose. They may have lost the source code. Even if all of that is okay, odds are you're not going to have a meticulously documented set up.

I've glossed over numerous issues. Speed and jitter, for example. Or the pain of re-engineering something, only to discover there's some bizarre corner-case that no one mentioned to you.

Another response said you should look at replacing the PLC with a more modern one. I second that, and I agree that starting by looking at the S7 is a good idea. What you really want out of this transition is something that your own people can support. Are there Siemens S7 PLCs all over the plant, or is everything Mitsubishi? (Or Schneider or A-B or ...) What vendors do you have a good relationship with? I do think it's a good idea to call in an outside systems integrator to handle the project. (Since I'm a systems integrator, I would think that, wouldn't I?) However, you don't want to be stuck back where you were with an unsupportable system. So make sure if hire someone from outside that they give you something you can work with. No locked source files, a PLC that your maintenance staff can work with, etc. If you've got a really good maintenance staff, they may be able to handle to whole project, or maybe yourself if you go take some training classes on S5 / S7. But consider whether that's a good use of resources vs. hiring someone who does it day-in and day-out.

I hope that helps.

-James Ingraham
Sage Automation, Inc.

> I could probably talk for days on this topic. (I know, I know, I can talk for days about any topic...) Please consider the problem to be, for lack of a better phrase, non-trivial.

> PLCs are essentially computers, but specialized ones. PCs are general-purpose.

PCs are also available in PLC format CompactPCI, PC/104,
PC/104Plus ... embedded PCs a.s.o

> Basically, a PC can do anything a PLC can do, but not necessarily as easily or elegantly.

PCs and PLCs are e.g. programmable with IEC1131-3 ... where is the difference?

> Let's start with interfacing to the real world, which is generically called "I/O" for input / output. PLCs are great at I/O, PCs not so much.

PLCs and PCs are using fieldbus systems where is the difference?

> So the first thing you'll have to decide is how to connect the I/O to your PC. There are so many ways to do this that it's difficult to summarize.

What's the problem ? A big choice is always positive.

> I list a handful of methods on this thread: http://www.control.com/thread/1317478247#1317652739

I'm missing the fieldbus systems: CANopen. Modbus, PROFIBUS, PROFINET, Interbus, Ethernet Powerlink, EtherCAT, EthernetIP, DeviceNet, ControlNet, Foundation Fieldbus a.s.o
These systems offer a broad range of I/Os.

> Next, you'll have to decide how you're to control the process. A custom program written in a general-purpose programming language, e.g. C/C++, Java, C#?

You have to add IEC61131-3, IEC61499 and function block programming like Labview, DACHSview a.s.o

> A more specific language like LabView? A software based PLC like WonderWare InControl? These all have their advantages and disadvantages.

> If you write a custom program in a general purpose language then there will come a time when someone will hate you. Suppose you change jobs, get hit by a bus, or even just go on vacation. The guy who inherits the project will have no idea what's going on, and really no where to turn to for help. As old as the S5 is, there are still people who can look at it and immediately figure out what's going on. You can find spare parts on E-Bay. You can post a message on control.com and say "S5" and people know what you mean. If it's all custom then none of that will be true. They might not be able to get a compiler for the language you chose. They may have lost the source code. Even if all of that is okay, odds are you're not going to have a meticulously documented set up.

> I've glossed over numerous issues. Speed and jitter, for example.

The most high speed control solutions are PC based :)

> Or the pain of re-engineering something, only to discover there's some bizarre corner-case that no one mentioned to you.

> Another response said you should look at replacing the PLC with a more modern one. I second that, and I agree that starting by looking at the S7 is a good idea.

Well, a better idea could be to look for a PC based solution. Why the S7? Also Siemens offers robust embedded PCs for control solutions :)

Best Regards

Armin Steinhoff
http://www.steinhoff-automation.com

By James Ingraham on 11 October, 2011 - 7:30 pm
1 out of 1 members thought this post was helpful...

Man, I can't believe we're getting in to THIS argument again. Oh, well. Here goes.

PCs are also available in PLC format
CompactPCI, PC/104, PC/104Plus ... embedded PCs a.s.o

A PC in a PLC format is not a PLC. PC/104 (and its descendents) are not really PLC format, either. CompactPCI (and its descendents) is a little closer, but it's still not the same thing. If you can touch a PCB I don't consider a PLC format.

PCs and PLCs are e.g. programmable with IEC1131-3 ... where is the difference?

Both can be programmed with IEC 61131-3 languages. It is NOT the case that PLCs are programmable in any arbitrary language available for PCs. PLCs are generally much more limited in processing power and storage, and can rarely connect to all the devices that a PC can. (Try finding a PLC with optical S/PDIF output.) On the flip side, PLCs generally require far less effort to set up for I/O control. It requires some expertise to set up a PC to talk to I/O, and handling things like proper start-up and shutdown are important. (Can I just drop a shortcut into the Startup folder? Or should I set My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run in the registry? Is that registry entry still the same in Win7?)

PLCs and PCs are using fieldbus systems. Where is the difference?

Good point. PCs even have an option most PLCs don't in USB. (Firewire is mostly dead.) With Ethernet becoming the norm we've converged even closer. However, consider how I add an EtherNet/IP I/O block to a Rockwell PLC. I right click and say "Add Module." I fill in a few fields mostly copied from a user manual and click okay. How do I do this in a PC? Well, first I spend 6 man-months writing an EtherNet/IP driver. Then I either hard-code the values into my app (AWFUL!) or create a configuration file (key-value pair? XML? JSON?). Then maybe I write a GUI program for editing the config file. Then I get hit by a truck, and no one can figure out how the hell to use my code.

What's the problem ? A big choice is always positive.

I wasn't so much complaining about having too many choices. Mostly I was trying to cut myself from going on too long.

I'm missing the fieldbus systems...

I wouldn't pick a fieldbus system for a new project that's PC-based. It is true that in that particular round-up I only mentioned Modbus/TCP (implied on Ethernet), leaving out the dozen or so major industrial Ethernet protocols. This was largely because you can write a Modbus/TCP driver in an afternoon, whereas most of the others are a little more complicated. Whether it's Modbus/TCP or VARAN is generally immaterial; connected over a network was really the point I was trying to get across.

You lump the industrial Ethernet protocols like EtherCAT and Profinet in with fieldbus, which I disagree with. These are NOT fieldbuses, because they are not buses. What makes a "bus" a "bus" is that every device is connected in one giant electrical short. With EtherCAT or Profinet or EtherNet/IP's DLR, each device receives electrical impulses and then re-generates them, thus isolating each device electronically. Note that they're not necessarily isolated in terms of DATA. This electrical isolation has advantages and disadvantages. Turn off a device on a bus, and the rest of the bus doesn't care. Turn off an EtherCAT node, and suddenly everything downstream of it is invisible. (Yes, I know I could set up a ring.) On the other hand, an electrical reflection won't kill some other node a half-kilometer away, and with active devices like switches you can partition the network to increase reliability and ease trouble-shooting. My company used Profibus for many years, but now that I can finally get stuff on Ethernet I don't ever want to go back to a fieldbus.

Man, PC-based control AND Ethernet vs. fieldbuses. All we need now is Coke vs. Pepsi.

You have to add IEC61131-3, IEC61499 and function block programming like Labview, DACHSview a.s.o

Funny, I mention LabView in the next sentence, and in the one after that I mention a specific IEC61131-3 software package without actually saying that it conforms to that standard.

The most high speed control solutions are PC based :)

Hm. I'm not sure I'm qualified to judge that one, and "most high speed" is probably going to be difficult to define. Nevertheless, I would argue that the "most high speed" control solutions are found in aircraft control and (ironically enough) anti-air defenses. These are not typically PCs. They are also not typically PLCs. The high speed, high reliability, and generally high unit costs of such systems allow for custom built solutions that are well outside the range of what is reasonable for controlling a small manufacturing process. I do acknowledge your point; my quad core 3GHz Intel Core i7 will run circles around any PLC, and if my code can take advantage of a GPGPU I could have more processing power than the total available for an entire petrochemical plant circa 1980. Of course, writing code to take advantage of that performance is again what I would call "non-trivial."

Well, a better idea could be to look for a PC based solution.

I don't know about "better." It's certainly an option. And certainly a PC-based SOLUTION is viable. Getting a system from Beckhoff or B&R or whoever is perfectly reasonable. At that point, someone else has gone trough all the trouble of making a general purpose PC suitable for a specific purpose. It blurs the lines between PC and PLC, leveraging the power and economies of scale that are availabe from the PC, but taking care of the "boiler plate" that makes PCs inelegant for the task of control. That's a far cry from what the original poster was suggesting. Grabbing a PC and writing some code is NOT the same thing as buying a PC-based PLC. There is also a cost associated with this; a Beckhoff PC-based PLC is going to be more expensive than an equivalently spec'ed Dell, plus the software to program it is not free. That must be weighed against the cost of getting the PC to do what you want by yourself. I will guarantee you are better off buying vs building in a case like this.

Why the S7?

Certainly not because I'm a fan of Step 7. Nevertheless, it's a clear and well understood upgrade path from an S5. There's a conversion utility, even if it's not perfect. You can easily cross-reference parts. Presumably, if there's one Siemens PLC there are probably others, meaning someone around there is familiar with them. I may be stereotyping here, but I got the impression that the poster was not based in the U.S. or Japan. Worldwide, Siemens is the default choice. Here in the U.S. it's Rockwell, and in Japan it's Mitsubishi. I could be wrong, of course; it may well be that this facility is entirely run off TI-99 calculators. But given the limited information, S7 seems like a logical choice.

Also Siemens offers robust embedded PCs for control solutions :)

Yes, but... It is quite easy to call up a Siemens rep, pick a PLC, figure out which version of Step 7 you need, and go on from there. It's also fairly easy to find a Step 7 programmer. Once you move into Siemens embedded PC products things get more complicated. There aren't as many people who can spec them off the top of their head.

A final point. I came to automation from a computer science background. I don't have a problem using PC's for control. But here someone has asked for advice on a specific problem, and I really think it's a bad idea to grab a PC and Visual Studio. You're not going to build a good, working, reliable, supportable solution by Tuesday.

-James Ingraham
Sage Automation, Inc.

By Steve Myres on 11 October, 2011 - 11:48 pm

I really think it's a bad idea to grab a PC and Visual Studio. You're not going to build a good, working, reliable, supportable solution by Tuesday.

Even an experienced person isn't going to have a functional app by Tuesday starting with a PC and VS today. On top of that you have to allow for the extra risk that an inexperienced person may not have a robust industrial-quality app six months or a year from now, if ever. (This would still be true, perhaps to a lesser extent, of someone trying to program a PLC with no experience, but in this case the PLC app already exists)

Man, PC-based control AND Ethernet vs. fieldbuses. All we need now is Coke vs. Pepsi.

Excellent post, and to think that if you're a Pepsi man it was all for naught!

By James Ingraham on 12 October, 2011 - 11:16 am

Excellent post, and to think that if you're a Pepsi man it was all for naught!

Thanks. And actually I drink Dr. Pepper. :-)

-James Ingraham
Sage Automation, Inc.

James Ingraham said:

> I don't know about "better." It's certainly an option. And
> certainly a PC-based SOLUTION is viable. Getting a system
> from Beckhoff or B&R or whoever is perfectly reasonable. At
> that point, someone else has gone trough all the trouble of
> making a general purpose PC suitable for a specific purpose.

I would tend to agree with this statement from the standpoint of someone else has done the IO driver engineering for you. I know both offer variants of IEC languages with their own extensions. They also offer motion control if you choose to use it. We tried our own PC based control years ago and gave up on it until recently when we found a product that handles the IO and motion drivers for us and we can concentrate on our application code. We are using the Delta Tau Power PMAC, but I've heard very good things about B&R as well as Beckhoff. On our next application we are planning on using Beckhoff EtherCAT IO with the Power PMAC. I particularly like this setup because we get premier motion control and the ability to write our application in C on top of the RTOS if you want to (I prefer this but its not for everyone).

The other biggest aspect is the parts availability. If you buy from a "controller" company you almost always get mid to long term support or at least a relatively painless upgrade path. With a commercial PC or even some industrial PCs you will get a machine that has a different ethernet and video chipset on just about every new board release. This is fine if a company is providing you with a hardware abstraction driver, but when you are doing your own thing it adds up to more man hours for you to have all these different configurations of controller.

I personally believe at this point in time that using cheap off the shelf PCs cost you a lot of money in development time. This also depends on what you consider a control system. If you can use an off the shelf modbus driver and the speed is OK for your application... well, PC control might be fine for you. If you are interfacing to motion with low latency and needing high speed IO and deterministic operation...

Well.... It starts getting really complicated to go at it alone.

KEJR

> Man, I can't believe we're getting in to THIS argument again. Oh, well. Here goes. <

>> PCs are also available in PLC format
>> CompactPCI, PC/104, PC/104Plus ... embedded PCs a.s.o

> A PC in a PLC format is not a PLC.

Why not ?? It is just a PLC with a x86 processor! And there are a lot in the market.

>PC/104 (and its descendents) are not really PLC format, either. CompactPCI (and its descendents) is a little closer, but it's still not the same thing. If you can touch a PCB I don't consider a PLC format.

>> PCs and PLCs are e.g. programmable with IEC1131-3 ... where is the difference?

>Both can be programmed with IEC 61131-3 languages. It is NOT the case that PLCs are programmable in any arbitrary language available for PCs. PLCs are generally much more limited in processing power and storage, and can rarely connect to all the devices that a PC can. (Try finding a PLC with optical S/PDIF output.) On the flip side, PLCs generally require far less effort to set up for I/O control. <

That is not the case. Both systems are programmable with IEC61131-3.
There no difference in efforts to setup I/O control.

> It requires some expertise to set up a>PC to talk to I/O, and handling things like proper start-up and shutdown are important. (Can I just drop a shortcut into the Startup folder? Or should I set My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows>\CurrentVersion\Run in the registry? Is that registry entry still the same in Win7?) <

Forget win7 when we talk about x86 based PLCs. What you need at least is a reliable OS or a RTOS ...

> PLCs and PCs are using fieldbus systems. Where is the difference?

> Good point. PCs even have an option most PLCs don't in USB. (Firewire is mostly dead.) With Ethernet becoming the norm we've converged even closer. However, consider how I add an EtherNet/IP I/O block to a Rockwell PLC. I right click and say "Add Module." I fill in a few fields mostly copied from a user manual and click okay. How do I do this in a PC? Well, first I spend 6 man-months writing an EtherNet/IP driver. Then I either hard-code the values into my app (AWFUL!) or create a configuration file (key-value pair? XML? JSON?). Then maybe I write a GUI program for editing the config file. Then I get hit by a truck, and no one can figure out how the hell to use my code. <

There is a lot of professional support of fieldbus systems for x86 based PLCs ... since nearly 20 years. So there is no need to fiddle around to build your own e.g. PROFIBUS support for a RTOS system.

>> What's the problem ? A big choice is always positive.
>
> I wasn't so much complaining about having too many choices. Mostly I was trying to cut myself from going on too long. <

>> I'm missing the fieldbus systems...

> I wouldn't pick a fieldbus system for a new project that's PC-based. <

Why not ? Do you have any alternatives?

> It is true that in that particular round-up I only mentioned Modbus/TCP (implied on Ethernet), leaving out the dozen or so major industrial Ethernet protocols. This was largely because you can write a Modbus/TCP driver in an afternoon, whereas most of the others are a little more complicated. Whether it's Modbus/TCP or VARAN is generally immaterial; connected over a network was really the point I was trying to get across. <

> You lump the industrial Ethernet protocols like EtherCAT and Profinet in with fieldbus, which I disagree with. These are NOT fieldbuses, because they are not buses. <

EtherCAT is a fieldbus ... at least for the IEC org :) PROFINET is Ethernet based and a clean bus system.

> What makes a "bus" a "bus" is that every device is connected in one giant electrical short. With EtherCAT or Profinet or EtherNet/IP's DLR, each device receives electrical impulses and then re-generates them, thus isolating each device electronically. Note that they're not necessarily isolated in terms of DATA. This electrical isolation has advantages and disadvantages. Turn off a device on a bus, and the rest of the bus doesn't care. Turn off an EtherCAT node, and suddenly everything downstream of it is invisible. (Yes, I know I could set up a ring.) <

EtherCAT is basically a ring system ... you have to look at the topology of the signal transmission.

> On the other hand, an electrical reflection won't kill some other node a half-kilometer away, and with active devices like switches you can partition the network to increase reliability and ease trouble-shooting. My company used Profibus for many years, but now that I can finally get stuff on Ethernet I don't ever want to go back to a fieldbus. <

> Man, PC-based control AND Ethernet vs. fieldbuses. All we need now is Coke vs. Pepsi. <

I don't see your point. The discussion was at the end "PLCs and fieldbuses vs. PCs and fieldbuses" .

>> You have to add IEC61131-3, IEC61499 and function block programming like Labview, DACHSview a.s.o <<
>
> Funny, I mention LabView in the next sentence, and in the one after that I mention a specific IEC61131-3 software package without actually saying that it conforms to that standard. <

>> The most high speed control solutions are PC based :) <<

> Hm. I'm not sure I'm qualified to judge that one, and "most high speed" is probably going to be difficult to define. <

IMHO. we are talking about control systems of industrial automation systems. "high speed" means for me an application cycle time of 1ms or less .... used e.g. in high speed sorter machines.

> Nevertheless, I would argue that the "most high speed" control solutions are found in aircraft control and (ironically enough) anti-air defenses. These are not typically PCs. They are also not typically PLCs. <

Such special control systems are using also a lot of FPGA processing ...

> The high speed, high reliability, and generally high unit costs of such systems allow for custom built solutions that are well outside the range of what is reasonable for controlling a small manufacturing process. I do acknowledge your point; my quad core 3GHz Intel Core i7 will run circles around any PLC, and if my code can take advantage of a GPGPU I could have more processing power than the total available for an entire petrochemical plant circa 1980. Of course, writing code to take advantage of that performance is again what I would call "non-trivial." <
>
>> Well, a better idea could be to look for a PC based solution. <<

> I don't know about "better." It's certainly an option. And certainly a PC-based SOLUTION is viable. Getting a system from Beckhoff or B&R or whoever is perfectly reasonable. At that point, someone else has gone trough all the trouble of making a general purpose PC suitable for a specific purpose. It blurs the lines between PC and PLC, leveraging the power and economies of scale that are available from the PC, but taking care of the "boiler plate" that makes PCs inelegant for the task of control. That's a far cry from what the original poster was suggesting. Grabbing a PC and writing some code is NOT the same thing as buying a PC-based PLC. There is also a cost associated with this; a Beckhoff PC-based PLC is going to be more expensive than an equivalently spec'ed Dell, plus the software to program it is not free. That must be weighed against the cost of getting the PC to do what you want by yourself. I will guarantee you are better off buying vs building in a case like this. <

When I visit the big German automation fair "SPS/IPC/DRIVES" I see on every second corner a "PC" in a DIN rail mountable format ... low power ... no active cooling ... in other words: x86 based PLCs.

That's just part of my reality ... I would never got the idea to use a Dell desktop system as an automation controller :)

>> Why the S7?

> Certainly not because I'm a fan of Step 7. Nevertheless, it's a clear and well understood upgrade path from an S5. There's a conversion utility, even if it's not perfect. You can easily cross-reference parts. Presumably, if there's one Siemens PLC there are probably others, meaning someone around there is familiar with them. I may be stereotyping here, but I got the impression that the poster was not based in the U.S. or Japan. Worldwide, Siemens is the default choice. Here in the U.S. it's Rockwell, and in Japan it's Mitsubishi. I could be wrong, of course; it may well be that this facility is entirely run off TI-99 calculators. But given the limited information, S7 seems like a logical choice. <
>
>> Also Siemens offers robust embedded PCs for control solutions :) <<
>
> Yes, but... It is quite easy to call up a Siemens rep, pick a PLC, figure out which version of Step 7 you need, and go on from there. It's also fairly easy to find a Step 7 programmer. Once you move into Siemens embedded PC products things get more complicated. <

No ... that not the case Step 7 is also available for embedded PC systems from Siemens.
A lot of vendors of PC system offers preinstalled IEC61131-3 systems ...

> There aren't as many people who can spec them off the top of their head. <

> A final point. I came to automation from a computer science background. I don't have a problem using PC's for control. But here someone has asked for advice on a specific problem, and I really think it's a bad idea to grab a PC and Visual Studio. You're not going to build a good, working, reliable, supportable solution by Tuesday. <

Yes, grabbing a desktop PC and Visual Studio is not the way to go .... when we talk about industrial control solutions.

Best Regards
Armin Steinhoff

By James Ingraham on 13 October, 2011 - 5:37 pm

Me: A PC in a PLC format is not a PLC.

Steinhoff: Why not ?? It is just a PLC with a x86 processor! And there are a lot in the market.

Difference of definitions here. A PC is a general-purpose device. Let's say you take a PC and lock it down to purely running running IEC 61131-3 programs with no video output / keyboard input, no option for a user to run arbitrary software, and limited hardware by restricting the drivers that are allowed to run. THIS ISN'T A PC ANYMORE. I don't care if the processor is an Intel x86 chip. If you HAVEN'T done all of that, than this isn't a PLC.

Me: PLCs generally require far less effort to set up for I/O control.

Steinhoff: That is not the case. Both systems are programmable with IEC61131-3. There is no difference in efforts to setup I/O control.

Out of the box, a PC can NOT run IEC 61131-3. You have to get additional software to do that, and rarely does that software run on bare metal so you've almost certainly got an OS as well. Again, a PC is general purpose. Even loading e.g. InTouch on to it does not magically cut off all of the other things that a PC can do, which means there is a higher complexity level. I know that your argument is that I can buy a complete system, which I addressed in my last post.

Steinhoff: Forget win7 when we talk about x86 based PLCs. What you need at least is a reliable OS or a RTOS ...

The point remains. I used Windows as an example because I know it and I assumed most people would easily know what I was talking about. Figuring out the best place to start your software on Linux / VxWorks / QNX / ThreadX is equally important. (What is it with all the X's in those names?)

Also, going back to those off-the-shelf PC-based control solutions, many of them DO use Windows. They may have some fancy tricks, like running Windows as a process under an RTOS, but it's still there.

Steinhoff: There is a lot of professional support of fieldbus systems for x86 based PLCs ... since nearly 20 years. So there is no need to fiddle around to build your own e.g. PROFIBUS support for a RTOS system.

Sure. If you use it. The main thrust of everything I've said in this thread has been "buy don't build." But some people will be unaware of what's available, some will have "Not Invented Here" syndrome, and some will think it's easy enough to do on their own, so why not? I'm trying to make sure that people don't do that. If you're really good, fine, go ahead. But you are in way over your head if you're posting on Control.com, "Hey, can't I just swap this old PLC out with an old Dell I have lying around?"

Me: I wouldn't pick a fieldbus system for a new project that's PC-based.

Steinhoff: Why not ? Do you have any alternatives?

The answer to both questions is Ethernet, of course. We can go into why another time. As wordy as I've been up to now, if you get me started on Ethernet then Control.com may run out of storage space.

Steinhoff: EtherCAT is a fieldbus ... at least for the IEC org :)

While you should generally listen to the IEC over me, they are nonetheless wrong in this case. My explanation from before still holds; each node on an EtherCAT network is electrically isolated from every other. Turn off the power at a node, and everything downstream of it loses communication. Compare this to Profibus, where (usually) the bus is tied together for all nodes inside passive connectors. Of course, Ethernet was originally like this as well. In modern times, however, this is a fundamental difference between Ethernet and fieldbusses.

Steinhoff: PROFINET is Ethernet based and a clean bus system.

Not sure what you mean by "clean" in this case, but it is not a bus. Nodes can be daisy-chained, but only when the nodes contain an active repeater. Once again, not a bus.

Steinhoff: EtherCAT is basically a ring system ... you have to look at the topology of the signal transmission.

I explicitly acknowledged in my previous post that EtherCAT can be a ring. It also works just fine in a line topology. It can even pretend to be a star network. The topology is not what makes the difference. It's whether there is one giant connection or active re-transmission.

Steinhoff: I don't see your point. The discussion was at the end "PLCs and fieldbuses vs. PCs and fieldbuses".

Except I turned it into fieldbuses vs. Ethernet. You're saying Ethernet (at least when talking about a complete solution like Profinet or EtherCAT) is a type of fieldbus. I disagree.

Steinhoff: I would never got the idea to use a Dell desktop system as an automation controller :)

Well, we agree on something, at least.

-James Ingraham
Sage Automation, Inc.

[ clip]
>>> Me: I wouldn't pick a fieldbus system for a new project that's PC-based.

>> Steinhoff: Why not ? Do you have any alternatives?

> The answer to both questions is Ethernet, of course. We can go into why another time. As wordy as I've been up to now, if you get me started on Ethernet then Control.com may run out of storage space.

How many space you will spent ... plain Ethernet doesn't allow real-time communication. So it is not applicable for predictable control systems.

>> Steinhoff: EtherCAT is a fieldbus ... at least for the IEC org :)

> While you should generally listen to the IEC over me, they are nonetheless wrong in this case. My explanation from before still holds; each node on an EtherCAT network is electrically isolated from every other. Turn off the power at a node, and everything downstream of it loses communication. Compare this to Profibus, where (usually) the bus is tied together for all nodes inside passive connectors. Of course, Ethernet was originally like this as well. In modern times, however, this is a fundamental difference between Ethernet and fieldbusses.

Regarding the bus operation there is no difference between Ethernet as a bus and fieldbuses with a bus topology.

>> Steinhoff: PROFINET is Ethernet based and a clean bus system.

> Not sure what you mean by "clean" in this case, but it is not a bus. Nodes can be daisy-chained,

Yes, nodes "can be daisy-chained" but they "must not be daisy-chained". You can build "clean" bus topologies without daisy-chained segments.

> but only when the nodes contain an active repeater. Once again, not a bus.

PROFINET nodes have switches ... not repeaters. (http://www.profibus.com/technology/profinet/overview )

>> Steinhoff: EtherCAT is basically a ring system ... you have to look at the topology of the signal transmission.

> I explicitly acknowledged in my previous post that EtherCAT can be a ring. It also works just fine in a line topology. It can even pretend to be a star network. The topology is not what makes the difference. It's whether there is one giant connection or active re-transmission.

The topology you are talking about is related to the wireing ... it has nothing to do with topology of the logical signal transmission.

>> Steinhoff: I don't see your point. The discussion was at the end "PLCs and fieldbuses vs. PCs and fieldbuses".

> Except I turned it into fieldbuses vs. Ethernet. You're saying Ethernet (at least when talking about a complete solution like Profinet or EtherCAT) is a type of fieldbus. I disagree.

Ethernet is by definition designed for the transmission of mass data. It is not designed for short response times and its transmision is not predictable ... that means Ethernet isn't a fieldbus.

Best Regards
Armin Steinhoff

By James Ingraham on 14 October, 2011 - 6:06 pm

Steinhoff: How many space you will spent ... plain Ethernet doesn't allow real-time communication. So it is not applicable for predictable control systems.

Odd; I've been doing real-time control using plain Ethernet for over a decade. When I started with it, we were still using office-grade hubs, because there weren't any real options for industrial switches. I've got dozens of systems doing real-time control using EtherNet/IP, which is essentially plain Ethernet. Siemens goes on and on about how Profinet (NRT and RT, at least) is plain Ethernet.

Now, there is a question of LATENCY, which impacts certain kinds of applications. I'm generally shooting for a 10ms to 50ms update rate to my devices (drives, I/O, barcode scanners, etc.) This is fine for many applications. However, it wouldn't work for a multi-axis co-ordinated motion system. Thus, variations on Ethernet to get the latency down, like Profinet IRT, EtherCAT, PowerLink, etc. I think most of us still think of these as "Ethernet," even while acknowledging that they don't technically conform to 802.3.

Steinhoff: Regarding the bus operation there is no difference between Ethernet as a bus and fieldbuses with a bus topology.

You're saying that I can come out of an Ethernet device with a single cable, crimp the other end of it into an RJ-45 along with a SECOND cable, plug this "middle" connector into a device, then plug the final end into a third device? I do not believe that will work. With Profibus, DeviceNet, CAN, etc., it will.

Steinhoff: Yes, nodes "can be daisy-chained" but they "must not be daisy-chained". You can build "clean" bus topologies without daisy-chained segments.

I'm sorry; I still don't understand.

Steinhoff: PROFINET nodes have switches ... not repeaters.

Sorry; imprecise language on my part. I usually try to avoid that, but in this case it was deliberate. I didn't quite get my point across, however. My point is that the signal is received and then re-transmitted. I said "repeater" instead of switch because I didn't want to limit the concept to switches, but I admit that probably wasn't the best choice of words. EtherCAT nodes, for example, have no switch, but the data is nonetheless re-sent.

Steinhoff: The topology you are talking about is related to the wiring ... it has nothing to do with topology of the logical signal transmission.

Again, sorry, I don't understand what you're saying.

Steinhoff: Ethernet is by definition designed for the transmission of mass data. It is not designed for short response times and its transmission is not predictable ... that means Ethernet isn't a fieldbus.

And here I thought YOU were arguing that Ethernet IS a fieldbus. Here's a quote from your first post: "...the fieldbus systems: CANopen, Modbus, PROFIBUS, PROFINET, Interbus, Ethernet Powerlink, EtherCAT, EthernetIP, DeviceNet..." (Emphasis added.) Profinet and EtherNet/IP are unquestionably "plain Ethernet." So are they fieldbus or not?

-James Ingraham
Sage Automation, Inc.

By Vladimir E. Zyubin on 15 October, 2011 - 6:25 am

>>Steinhoff: How many space you will spent ... plain Ethernet doesn't allow real-time communication. So it is not applicable for predictable control systems.

>Ingraham: Odd; I've been doing real-time control using plain Ethernet for over a decade.

Deja vu... Practically every year.

Dear sirs!
Fuzzy terminology leads to the brain fuzzification. Ethernet (TCP/IP stack) is used in control system since the previous century, as well as the wintel platforms... and LabVIEW, and C++, and pure C, and Python, and MS DOS, and plain Linux.

Have a look at OPC, or just look inside CNC-machines.

All is "realtime" in our world, even the Word (it will be unusable in the case of a some latency, e.g. a minute after your mouse click).

As it concerns to the topic, I think we all will shift to the mainstream technology... wintel, ethernet, computer vision, etc. Magic spells kinda "realtime" have no sense comparing to a $500 PC with the work temperature -40, +70 C, GigE Vision Camera, and IP 67.

Best of my wishes, Vladimir E. Zyubin

By Armin Steinhoff on 16 October, 2011 - 8:57 am

> Steinhoff: How many space you will spent ... plain Ethernet doesn't allow real-time communication. So it is not applicable for predictable control systems.
>
> Ingraham: Odd; I've been doing real-time control using plain Ethernet for over a decade.

IMHO ... your understanding of "real-time" seems to be a little bit strange. The handling of collisions of plain Ethernet (layer 1) doesn't allow "real-time" communication! You need a "real-time" protocol to avoid collisions!

> Ingraham:
> When I started with it, we were still using office-grade hubs, because there weren't any real options for industrial switches. I've got dozens of systems doing real-time control using EtherNet/IP, which is essentially plain Ethernet.

So the Ethernet/IP protocol is just an empty black box for you? The ODVA has developed a complete unnecessary "real-time" protocol?

> Ingraham:
> Siemens goes on and on about how Profinet (NRT and RT, at least) is plain Ethernet.

That's completely new for me The transmission media of PROFINET for NRT / RT communication is based on standard Ethernet components (layer 1). In order to communicate in "real-time" (RT) you will need the PROFINET protocol.

The IRT communication needs special switches. These switches are integrated in the IRT devices.

> Ingraham:
> Now, there is a question of LATENCY, which impacts certain kinds of applications. I'm generally shooting for a 10ms to 50ms update rate to my devices (drives, I/O, barcode scanners, etc.) This is fine for many applications. However, it wouldn't work for a multi-axis co-ordinated motion system. Thus, variations on Ethernet to get the latency down, like Profinet IRT, EtherCAT, PowerLink,

Latency isn't the main issue of PROFINET, EtherCAT or Powerlink. It makes no sense to do a fast but wrong communication It makes no sense to get a fast response after an unpredictable time of handling of a collision.

> Ingraham:
> etc. I think most of us still think of these as"Ethernet," even while acknowledging that they don't technically conform to 802.3.

Ethernet/IP, EtherCAT, Powerlink a.s.o are using Ethernet components which are conform to 802.3.
Only PROFINET-IRT needs proprietary switches.

> Steinhoff: Regarding the bus operation there is no difference between Ethernet as a bus and fieldbuses with a bus topology.
>
> Ingraham: You're saying that I can come out of an Ethernet device with a single cable, crimp the other end of it into an RJ-45 along with a SECOND cable, plug this"middle" connector into a device, then plug the final end into a third device? I do not believe that will work.

What a weird idea That has never been one of my statements!

> Ingraham:
> With Profibus, DeviceNet, CAN, etc., it will.

Sorry that's not correct. The wiring of these buses looks like "daisy chaining" but it isn't "daisy chain". Each of these bus devices is providing internal "T connectors" ... and you will always find in the standards of these buses the maximal length of the trunks of such "T connectors".

> Steinhoff: PROFINET nodes have switches ... not repeaters.
>
>Ingraham:
> Sorry; imprecise language on my part. I usually try to avoid that, but in this case it was deliberate. I didn't quite get my point across, however. My point is that the signal is received and then re-transmitted. I said"repeater" instead of switch because I didn't want to limit the concept to switches, but I admit that probably wasn't the best choice of words. EtherCAT nodes, for example, have no switch, but the data is nonetheless re-sent.
>
> Steinhoff: The topology you are talking about is related to the wiring ... it has nothing to do with topology of the logical signal transmission.
>
> Ingraham: Again, sorry, I don't understand what you're saying. For instance: the media of PROFIBUS has a clean bus topology ... the master/master protocol is based on token passing which defines a logical ring for the communication.

If one station goes down only the logical ring would break ... and it's handled by the token passing protocol.

For EtherCAT you can build a "wire structure" which looks like a line/bus topology ... but the protocol is still based on a logical and physical ring. If one device goes down the physical ring is broken ... but this can't be handled only by the protocol software.

> Steinhoff: Ethernet is by definition designed for the transmission of mass data. It is not designed for short response times and its transmission is not predictable ... that means Ethernet isn't a fieldbus.
>
> Ingraham: And here I thought YOU were arguing that Ethernet IS a fieldbus.

That's a misunderstanding. Ethernet "based" fieldbuses are always a combination of Ethernet AND a "real-time" protocol which avoids collisions.

> Ingraham: Here's a quote from your first post:"...the fieldbus systems: CANopen, Modbus, PROFIBUS, PROFINET, Interbus, Ethernet Powerlink, EtherCAT, EthernetIP, DeviceNet..." (Emphasis added.) Profinet and EtherNet/IP are unquestionably"plain Ethernet." So are they fieldbus or not?

My statement was:

"Ethernet is by definition designed for the transmission of mass data. It is not designed for short response times and its transmission is not predictable ... that means plain Ethernet isn't a fieldbus"

Best Regards
Armin Steinhoff

By James Ingraham on 17 October, 2011 - 10:36 am

Steinhoff: IMHO ... your understanding of "real-time" seems to be a little bit strange.

Fair enough. "Real-time" can mean different things to different people. Most of my systems need to update I/O on the order of tens of milliseconds. Some systems need tens of microsystems. Other could handle tens of MINUTES. For me, real-time means "can it reliably do what I need." That's a rather non-technical definition, I admit.

Steinhoff: The handling of collisions of plain Ethernet (layer 1) doesn't allow "real-time" communication! You need a "real-time" protocol to avoid collisions!

First, in switched Ethernet there are no collisions. Second, this "non-deterministic" bugbear of Ethernet is not as big a deal as it's cracked up to be. True, there are certain applications Ethernet is not applicable. But there is a wide swath of applications where it works perfectly well. In fact, it often performs BETTER than some traditional fieldbuses. I'll take Ethernet over DeviceNet or Modbus Plus any day of the week. Third, EtherNet/IP and Profinet do absolutely nothing to Layer 1 / Layer 2 Ethernet, and thus can't possibly impact the collisions issue, or anything else related to the non-determinism of Ethernet.

Steinhoff: So the Ethernet/IP protocol is just an empty black box for you? The ODVA has developed a complete unnecessary "real-time" protocol?

No, it's not an empty black box, and while we can debate the necessity of it there are reasons ODVA came up with it. The reasons have nothing to do with the real-time (or not) nature of Ethernet, however. They have to do with standardizing how devices talk. "...EtherNet/IP implements CIP at the Session layer and above..."
End of first paragraph on page 2 of this http://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf

Ingraham: Siemens goes on and on about how Profinet (NRT and RT, at least) is plain Ethernet.

Steinhoff: That's completely new for me

Perhaps this is a regional difference. In North America, Rockwell has used the phrase "standard, unmodified Ethernet" so often they sound like a broken record. (I know you're old enough to remember broken records. :-) PI is annoyed at Profinet being cast as NOT standard, unmodified Ethernet, when it clearly is. The even came out with a brochure about it: http://us.profibus.com/sueform.aspx?type=pdf Maybe this debate is not as big a deal in Germany?

Steinhoff: The transmission media of PROFINET for NRT / RT communication is based on standard Ethernet components (layer 1).

And layer 2, for that matter.

Steinhoff: In order to communicate in "real-time" (RT) you will need the PROFINET protocol.

Well, no, actually. There are lots of ways you could do this, and Profinet is certainly one of them. And Profinet RT claims to have a leg up on the competition because it does NOT use TCP, UDP, or IP. It uses a much more streamlined protocol with far less overhead. This is great, as far as it goes, but it doesn't fundamentally change anything about Ethernet.

Steinhoff: Latency isn't the main issue of PROFINET, EtherCAT or Powerlink. It makes no sense to do a fast but wrong communication It makes no sense to get a fast response after an unpredictable time of handling of a collision.

Again, collisions don't exist on switched Ethernet. Profinet doesn't do anything that would deal with collisions if there were any. EtherCAT avoids collisions entirely by its nature. (Not sure about Powerlink.) To your point, I was oversimplifying. Bandwidth, latency, jitter, minimum update rate, network overhead, processing overhead... there are a lot of things to consider. My point was that Ethernet hits a wall, and there are various ways to deal with that. Mostly, these ways abandon standard Ethernet and do something different. As you said, Profinet IRT devices need special ASICs and switches. EtherCAT uses a special ASIC (which doesn't have a MAC address, so it can't really be Ethernet, can it?). etc.

Regarding my comment on daisy-chaining Ethernet cabling:
Steinhoff: What a weird idea That has never been one of my statements!

Yes and no. I keep trying to draw a distinction between the way fieldbuses are wired and the way Ethernet is wired. You keep saying there's no difference. So if there's no difference, what I said should work with Ethernet, as it does with Profibus, DeviceNet, etc. This is the key distinction I am trying to draw between a fieldbus and Ethernet; fieldbuses are a "bus", where the entire network is one giant short. Ethernet cannot be passively connected.

Steinhoff: Sorry that's not correct. The wiring of these buses looks like "daisy chaining" but it isn't "daisy chain". Each of these bus devices is providing internal "T connectors" ... and you will always find in the standards of these buses the maximal length of the trunks of such "T connectors".

I'm pretty sure Profibus specifically forbids T connections, and other fieldbuses (e.g. SDS, DeviceNet, ControlNet) only allow one device connected via the T. But that doesn't change anything about my point; these T connectors are passive devices.

Steinhoff: That's a misunderstanding. Ethernet "based" fieldbuses are always a combination of Ethernet AND a "real-time" protocol which avoids collisions.

ARGH! Here we go with collisions again. (a) There are no collisions on switched Ethernet. (b) Several of the Ethernet based fieldbuses (your definition) do absolutely nothing about Layer 1 / Layer 2 collisions.

Ultimately, this is a matter of semantics. What you call "Ethernet based fieldbus" I would call "industrial Ethernet." Part of the reason I care about this is the fact that Ethernet requires active devices to connect nodes, where fieldbuses do not. This is a blessing and a curse. On the one hand, switches cost money and represent a possible fail point. On the other hand, segmenting the network makes it much easier to design, troubleshoot, and fix.

-James Ingraham
Sage Automation, Inc.

By Armin Steinhoff on 17 October, 2011 - 4:50 pm

> Steinhoff: IMHO ... your understanding of "real-time" seems to be a little bit strange.
>
> Fair enough. "Real-time" can mean different things to different people. Most of my systems need to update I/O on the order of tens of milliseconds. Some systems need tens of microsystems. Other could handle tens of MINUTES. For me, real-time means "can it reliably do what I need." That's a rather non-technical definition, I admit.

Real-time doesn't mean speed. A real-time system must produce results discrete in time ... at so called deadlines. The time between deadlines can be milliseconds of hours.

> Steinhoff: The handling of collisions of plain Ethernet (layer 1) doesn't allow "real-time" communication! You need a "real-time" protocol to avoid collisions!
>
> First, in switched Ethernet there are no collisions.

Yes, the day of the good old CSMA/CD collisions are gone. But every switch can loose frames and every switch port has to compete for the right to use the resource "uplink".

That means the transmission of an ethernet packet is still unpredictable in switched Ethernet.

> Second, this "non-deterministic" bugbear of Ethernet is not as big a deal as it's cracked up to be.

That bugbear is still there and there are a lot of strategies to avoid it ... QoS, priority of switch ports a.s.o are the trials.

> True, there are certain applications Ethernet is not applicable. But there is a wide swath of applications where it works perfectly well. In fact, it often performs BETTER than some traditional fieldbuses. I'll take Ethernet over DeviceNet or Modbus Plus any day of the week. Third, EtherNet/IP and Profinet do absolutely nothing to Layer 1 / Layer 2 Ethernet, and thus can't possibly impact the collisions issue, or anything else related to the non-determinism of Ethernet.

Correct so far ... Profinet does for IRT proprietary modification on
switches.

> Steinhoff: So the Ethernet/IP protocol is just an empty black box for you? The ODVA has developed a complete unnecessary "real-time" protocol?
>
> No, it's not an empty black box, and while we can debate the necessity of it there are reasons ODVA came up with it. The reasons have nothing to do with the real-time (or not) nature of Ethernet, however. They have to do with standardizing how devices talk. "...EtherNet/IP implements CIP at the Session layer and above..."
> End of first paragraph on page 2 of thishttp://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00138R3_CIP_Adv_Tech_Series_EtherNetIP.pdf
>
> Ingraham: Siemens goes on and on about how Profinet (NRT and RT, at least) is plain Ethernet.

That's really correct for NRT and RT.

> Steinhoff: That's completely new for me
>
> Perhaps this is a regional difference. In North America, Rockwell has used the phrase "standard, unmodified Ethernet" so often they sound like a broken record. (I know you're old enough to remember broken records. :-) PI is annoyed at Profinet being cast as NOT standard, unmodified Ethernet, when it clearly is. The even came out with a brochure about it:http://us.profibus.com/sueform.aspx?type=pdf Maybe this debate is not as big a deal in Germany?

IMHO ... such a debate isn't known in Germany. This brochure is a little bit strange :)

> Steinhoff: The transmission media of PROFINET for NRT / RT communication is based on standard Ethernet components (layer 1).
>
> And layer 2, for that matter.

correct to be precisely.

> Steinhoff: In order to communicate in "real-time" (RT) you will need the PROFINET protocol.
>
> Well, no, actually. There are lots of ways you could do this, and Profinet is certainly one of them. And Profinet RT claims to have a leg up on the competition because it does NOT use TCP, UDP, or IP. It uses a much more streamlined protocol with far less overhead. This is great, as far as it goes, but it doesn't fundamentally change anything about Ethernet.

IMHO ... you need that protocol for avoiding e.g. overload situations of switches.

> Steinhoff: Latency isn't the main issue of PROFINET, EtherCAT or Powerlink. It makes no sense to do a fast but wrong communication It makes no sense to get a fast response after an unpredictable time of handling of a collision.
>
> Again, collisions don't exist on switched Ethernet. Profinet doesn't do anything that would deal with collisions if there were any.

Profinet avoids collision (or resource constrains) by a controller/device protocol.

> EtherCAT avoids collisions entirely by its nature. (Not sure about Powerlink.)

Powerlink avoids collisions by a master/slave (managing node/ managed
node) protocol.

> To your point, I was oversimplifying. Bandwidth, latency, jitter, minimum update rate, network overhead, processing overhead... there are a lot of things to consider. My point was that Ethernet hits a wall, and there are various ways to deal with that. Mostly, these ways abandon standard Ethernet and do something different. As you said, Profinet IRT devices need special ASICs and switches. EtherCAT uses a special ASIC (which doesn't have a MAC address, so it can't really be Ethernet, can it?). etc.

EtherCAT is in the first approach "abusing" the media of Ethernet :)

> Regarding my comment on daisy-chaining Ethernet cabling:
> Steinhoff: What a weird idea That has never been one of my statements!
>
> Yes and no. I keep trying to draw a distinction between the way fieldbuses are wired and the way Ethernet is wired. You keep saying there's no difference.

A bus system is a system which allows to remove and reconnect a station without impact of the operation of the system. IMHO that's true for Ethernet and real fieldBUSES.

> So if there's no difference, what I said should work with Ethernet, as it does with Profibus, DeviceNet, etc. This is the key distinction I am trying to draw between a fieldbus and Ethernet; fieldbuses are a "bus", where the entire network is one giant short. Ethernet cannot be passively connected.
>
> Steinhoff: Sorry that's not correct. The wiring of these buses looks like "daisy chaining" but it isn't "daisy chain". Each of these bus devices is providing internal "T connectors" ... and you will always find in the standards of these buses the maximal length of the trunks of such "T connectors".
>
> I'm pretty sure Profibus specifically forbids T connections, and other fieldbuses (e.g. SDS, DeviceNet, ControlNet) only allow one device connected via the T.

There is always only one device connected to a T connector ...

> But that doesn't change anything about my point; these T connectors are passive devices.
>
> Steinhoff: That's a misunderstanding. Ethernet "based" fieldbuses are always a combination of Ethernet AND a "real-time" protocol which avoids collisions.
>
> ARGH! Here we go with collisions again. (a) There are no collisions on switched Ethernet.

But there are other constrains which are making the packet transmission unpredictable. For instance: how big is a time-out after a lost package ?

> (b) Several of the Ethernet based fieldbuses (your definition) do absolutely nothing about Layer 1 / Layer 2 collisions.

No, no ... they do a lot against it with its protocols.

> Ultimately, this is a matter of semantics. What you call "Ethernet based fieldbus" I would call "industrial Ethernet." Part of the reason I care about this is the fact that Ethernet requires active devices to connect nodes, where fieldbuses do not. This is a blessing and a curse. On the one hand, switches cost money and represent a possible fail point. On the other hand, segmenting the network makes it much easier to design, troubleshoot, and fix.

For instance: Profibus allow backbone structures by PROFIBUS repeaters. These active repeaters are doing segmentation against the backbone cable ...

Well ... the fieldbus, "non-bus fieldbuses" and Ethernet seems to be really complex :)

Best Regards
Armin Steinhoff

replacing a plc with a pc is not a good idea simply on the basis of reliability and self-checking (i,e, failsafe provisions). this is especially important with food processes. such conversions were made in the early days, often with very bad results.

you can get your data without touching the plc; you or your manager may be hesitant to do so due to cost

1 out of 1 members thought this post was helpful...

Have you tried OPC for this? It's quick and easy way to accomplish what you want to do.

Try this OPC Server:
http://www.matrikonopc.com/opc-drivers/opc-siemens-s7-plc/base-driver-details.aspx

Cheers,
Wassim

By Tallak Tveide on 13 October, 2011 - 10:59 am

While I agree that S7 is the pragmatic way to go (and don't particularly like it), I think this is being oversimplified. I believe that PC based control, with a simple robust OS (linux), simple serial or preferably ethernet worked IO modules (preferably modbus based), could in some cases end up simpler than plc systems for applications where plc's weaknesses are apparent:

- massive duplication
- remote management and configuration
- less hardware dependency
- easy integration with other computer resources (web, sms, databases etc)
- complex systems

These systems must not be built from scratch but on an existing platform (wrt style and way of doing stuff) such as the mblogic system.

I cant see why a cleanly written python mblogic project should be much less accessible than a S7 project. This is even more evened out due to the fact that S7 is firmly stuck in the eighties usability wise.

But of course, the most sensible approach to building a simple, one-off machine with the least time and effort, in particular when you have little prior experience, is going with one of the big vendors

> I agree to I believe that PC based control, with a simple robust OS
> (linux), simple serial or preferably ethernet worked IO modules (preferably
> modbus based), could in some cases end up simpler than plc systems for
> applications where plc's weaknesses are

Once you can read/write remote I/O the PLC logic on a PC is only a simple endless loop.

If you have a library for automation tasks / closed loop control you can then easy build a control system (eventually using a realtime extension to linux).

Our pvbrowser project already comes with daemons for a lot of filedbus / PLC protocols that will read the remote I/O cylically and write it to shared memory within the PC. From there it can be used from any process on that PC. These processes might be our visualization servers as also a soft PLC. Outputs are send to the daemons from processes via a mailbox.

By Leonard Misner on 20 October, 2011 - 9:36 am

"PC with a simple robust OS" is an oxymoron.
there is no blue screen of death on a PLC.

You can talk about how fast your PC is and how it runs circles around that x86 PLC...until you have your PC running soft PLC, driving animated graphics, handling a hundred analog process devices, calculating statistics and creating paretos and productions reports...and when you can't even get 4 temperature samples while attempting to monitor a single analog device at a tenth-of-a-second sample rate, then tell me how a pc is any comparison at all to a plc. Consider: Why does a PLC exist at all? Why was it created? If a PC architecture is EVER the optimal option, how does 'plc' ever exist and continue to exist? Do you have some magic PC that doesn't slow down whenever you open more and more applications?

A pc is a single tasking slow stupid device which is incapable of having a few hundred process applications running simultaneously while still processing the entire program, scanning all I/O and updating the image table repeatedly and absolutely reliably at a rate of a few milliseconds even with the plc sitting alone in an oil saturated box for decades at a time.

Yes...there are industrial pc's...but they're still limited by their architecture. I'm speaking from 10 years experience leading multimillion dollar plc based automated assembly and test systems internationally from concept through 6-sigma runoff...add another 25 years of working with automated systems in automotive, pharm and food manufacturing facilities - both plc and pc based systems. Test engineers cry whenever I point out that even their test stands (typically pc based controls) can be done easier and more reliably with a plc. One of the biggest reasons the United States has had so many manufacturing plants closed down is because we simply have lost the ability to being competitive in the world market. You have to get the best quality product out the door at the lowest cost. that's a pretty simple concept, but it seems so many engineers believe the company they are working for is there to facilitate their own personal technical experimentation and entertainment. Not nearly the challenge of a PLC application then to do all that forced integration and special configurations and code of most pc systems. You have mentioned how a PLC is more readily supported, more easily programmed by more people who have that knowledge, ethernet integration is simply a module and copying some config junk from a manual as you suggested. So why would intentionally compromise the future of the company you're working with by forceably integrating a pc with various uniquely concepted techy toys that were NOT DESIGNED SPECIFICALLY TO the task of reliable machine control. If you (or the support team left in your dust) can access your controls, understand the process as programmed and have an ability to improve analog monitoring and controls...then you can improve product quality and production efficiency. The market wants to buy less expensive golden nuggets...not some terd product that was produced by a "black box" that nobody can work with to make that terd product any better than the terd product that it is. If your stuff can't compete in the market, your company shuts down...welcome to America. Engineers are supposed to be a pretty sharp group...why haven't they figured THAT out?

Anybody ever hear of Dr. Deming? ...don't get me started. lol.

By James Ingraham on 20 October, 2011 - 10:25 pm

I know this is going to seem odd, but I'm going to have to disagree with Leonard Misner. Yeah, I know I just spent like 8 billion words arguing with Armin about it, but that was over a fairly nuanced distinction between "PC" and "PLC." I believe Mr. Misner's strong dislike of PCs for control is a bit unwarranted.

Leonard Misner: "PC with a simple robust OS" is an oxymoron.

There is ample evidence to refute this. Many PCs have uptimes comparable to PLCs. QNX, VxWorks, and other RTOSes that run on x86 can run indefinitely. Then there's all those LAMP web servers out there. There are numerous PC-based solutions for control from Beckhoff, B&R, etc. Kuka and ABB robot controllers are PC-based.

Leonard Misner: There is no blue screen of death on a PLC.

An over-rated concern, and not necessarily accurate. PLCs do die, even if it's relatively rare. Most Windows blue screens are the result of hardware problems and/or improperly written drivers. Within the limited environment of a PC-based controller those issues go away, particularly if using a boxed solution (e.g. Beckhoff again). For anecdotal evidence, I have quite a few PCs doing control that have run for a decade or more. Hardware failures is in fact one reason my company moved to PLCs instead of PCs, but even then we're talking about five year or so life spans. Sure, you expect 20 out of your PLC. Of course, I'll spend less over the course of 20 years on hardware even if I have to replace it every four or five years.

And don't forget Stuxnet; it turns out that the only reason PLCs haven't been infected by viruses before was that no one was trying. Security researchers are now looking at the PLC manufacturers and are horrified at the complete lack of security consciousness.

Leonard Misner: You can talk about how fast your PC is and how it runs circles around that x86 PLC...until you have your PC running soft PLC, driving animated graphics, handling a hundred analog process devices, calculating statistics and creating paretos and productions reports...and when you can't even get 4 temperature samples while attempting to monitor a single analog device at a tenth-of-a-second sample rate, then tell me how a pc is any comparison at all to a plc.

It is certainly true that PCs have a lot of overhead that PLCs don't, and that PLCs can take advantage of being closer to the "metal." Nevertheless, a PC can bring some horsepower to bear that PLCs cannot conceivably match. A 3GHz quad-core i7 is on the order of 100 GFLOPS. I can write some pretty crappy software and still run unbelievably fast. The hard part is connecting to real world I/O. Most PLC manufacturer's won't tell you the speed of their backplanes, but I seriously doubt that it's even close to the 500MB/s and 5GT/s of a PCI Express 2.1 x1 slot. And if you REALLY need it, you can jump up to a PCI-E 3.0 x16 for 16GB/s and 128GT/s. Let's round that to a byte per 100 picoseconds. Assuming those 4 temperature sensors need 2 bytes each, I should be able to retrieve them in under a nanosecond. I can run 100 mathematical operations in another nanosecond, then send them back. This is a thought experiment, of course. I doubt you'd actually be able to this in under a microsecond, possibly even tens of microseconds. But I won't have any trouble hitting your 100 milliseconds. Heck, I was doing better than that back when all the PCs we shipped had 486 processors.

Leonard Misner: Consider: Why does a PLC exist at all?

There are lots of reasons, of course. For one thing, when the PLC was invented circa 1970 there was no such thing as a PC. It definitely took some time for the general purpose nature of the PC to get the horsepower needed to compete with a dedicated-purpose box. Even relatively recently, PLCs weren't required to communicate all that much. As businesses have tried more and more to increase productivity, reduce downtime, and match production to demand, it has become more important to feed data from control systems up into management systems. Without that necessity, the PC didn't have as compelling an argument on the shop floor.

Leonard Misner: Why was it created? If a PC architecture is EVER the optimal option, how does 'plc' ever exist and continue to exist?

This is a somewhat specious argument, and can be equally flipped around. If PLCs are ever the best solution, why do PC-based solutions exist and continue to sell well?

Leonard Misner: Do you have some magic PC that doesn't slow down whenever you open more and more applications?

Actually, yes. Most PC-based solutions have some way of dealing with this. Kuka and Beckhoff both run their control software on a RTOS. Windows then runs parallel to (or as a guest of, depending on things are set up) the RTOS. You can launch Crysis and your control will still run just fine. This isn't really necessary, however. I have five robot systems in the real world running on stock Windows 2000. The fact that they are running on Windows 2000 gives you an idea of the age of the machines. It's true that if you launch Crysis on one of THOSE boxes, your robot will not run very well. DON'T DO THAT. We've never had a problem with this. And I certainly allow operators to pull up PDFs etc. on the controller, and it handles that just fine.

Leonard Misner: A pc is a single tasking slow stupid device

Is this deliberate trolling? Single tasking? Slow? This hasn't been true for at least 15 years.

Leonard Misner: which is incapable of having a few hundred process applications running simultaneously

Some high-end servers (x86 or otherwise) can probably handle a few hundred process applications simultaneously. Obviously, this sounds like a clustering or mainframe application. Certainly not something you could do on a PLC. Most PLCs can't handle a few hundred PID loops, much less a few hundred APPLICATIONS.

Leonard Misner: while still processing the entire program, scanning all I/O and updating the image table repeatedly and absolutely reliably at a rate of a few milliseconds

If we're discounting the aforementioned hundreds of applications and talking about one program, this is trivial.

Leonard Misner: even with the plc sitting alone in an oil saturated box for decades at a time.

I think that was supposed to PC, not PLC in that sentence. In other words, a PC wouldn't survive that, but a PLC could. I've never let any of my PLCs get saturated with oil, although some of them have gotten quite dusty thanks to filters never being cleaned. My handful of experiences with water haven't been all that great. "Decades" is probably pushing it. Certainly, 20 years is not unreasonable for a PLC. Much longer than that is an aberration. Most mechanical systems won't last that long anyway. I pulled out a 20 year old PLC-3 and replaced it with a ControlLogix because nobody could work on the damn thing any more, but it was in fact running just fine. I'm not sure what my oldest PC I've replaced is; certainly more than 10 years, but probably less than 20. You may have a point here, but it's still something of an open question. We didn't HAVE ruggedized, fanless, all solid state PCs 20 years ago. Now I do. I have no particular reason to think they won't last as long as a PLC.

Leonard Misner: Test engineers cry whenever I point out that even their test stands (typically pc based controls) can be done easier and more reliably with a plc.

I think this is going to be rather application specific. There are certainly some test applications that a PLC will do great in. However, there are certain things that are just beyond the PLCs reach. LabVIEW can do a lot of really cool things, and handles masses of data quite well. I have trouble envisioning a PLC recording thousands (or millions) of samples per second for days at a time and then analyzing it.

Leonard Misner: One of the biggest reasons the United States has had so many manufacturing plants closed down is because we simply have lost the ability to being competitive in the world market.

Okay. Although that's nearly a tautological statement.

Leonard Misner: You have to get the best quality product out the door at the lowest cost.

Hard to argue with that.

Leonard Misner: It seems so many engineers believe the company they are working for is there to facilitate their own personal technical experimentation and entertainment.

This is not my experience, but I understand your point. We want to ship product, not play with cool toys. However, the original question was not posed in this vein. It was more of a "when all you have is a hammer, every problem looks like a nail." The guy has no experience with PLCs. Apparently no one around him knows anything about PLCs. The PLC is obsolete. Well, he knows he could crank out some C / MatLab / LabVIEW / JavaScript and do this application. I believe that to be a naive solution, but not a self-centered one. My original response was that that was opening a can of worms, and that there are a WHOLE lot of things you have to deal with to take a general purpose device and use it for this particular task. I stand by that. That doesn't mean that everyone who thinks a PC might work is either (a) an idiot, (b) mesmerized by the "shiny object" effect of playing with bleeding-edge tech, or (c) anything other than fully committed to their task.

Leonard Misner: You have mentioned how a PLC is more readily supported, more easily programmed by more people who have that knowledge, ethernet integration is simply a module and copying some config junk from a manual as you suggested.

I'm not sure who the "you" is in this sentence, but it seems to be referring to statements by me. I stand by those statements. I did NOT say "Any one who uses PC-based controls is delusional." Somehow you and Armin both seemed to have gotten that impression.

Leonard Misner: So why would [you] intentionally compromise the future of the company you're working with by forceably integrating a pc with various uniquely concepted techy toys that were NOT DESIGNED SPECIFICALLY TO the task of reliable machine control.

Is this the same "you?" I was essentially making this same argument, so I'm not sure why you're repeating it back to me. I'll answer anyway; I do not believe choosing PC-based control is "intentionally compromising" the future of my company. A customer recently requested a Kuka robot, and we had no problem selling it to them. Kuka uses a PC-based robot controller. They have gone through the work to make their controller a reliable machine control device. It is supported and robust. If a customer asked me to integrate a Beckhoff or B&R system I would have no problem with it. There were reasons my company chose to use PCs for gantry robot control when it started in 1995, and even in hindsight those were valid reasons. (Mainly, PLCs were simply incapable of doing what we needed them to.)

Leonard Misner: The market wants to buy less expensive golden nuggets...not some terd product that was produced by a "black box" that nobody can work with to make that terd product any better than the terd product that it is.

(a) I believe the word you want is "turd."

(b) This line is reminiscent of a scene in Kevin Smith's "Jay and Silent Bob Strike Back." http://www.imdb.com/title/tt0261392/quotes?qt=qt0392693 Not safe for work language. moderator's note: not safe for work language and possibly offensive to some

(c) As you say, who cares what made the product? We want to get product out the door, not sit around arguing about what controller is best. If a PC works, use it. If a PLC works, fine. What matters is product goes out the door.

Leonard Misner: If your stuff can't compete in the market, your company shuts down...welcome to America.

Again, hard to argue. But also not really a point in your favor. What I take that statement to mean is use the best tool for the job. A blind devotion to one solution or another is not in anyone's best interests.

Leonard Misner: Engineers are supposed to be a pretty sharp group... why haven't they figured THAT out?

A rhetorical question, but I'll answer it anyway. Engineers have long been accused of being disconnected from business realities. On the flip side, one could argue that engineers are stretched thin thanks to older works being forced out and a lack of new workers interested in the manufacturing / process sectors.

Leonard Misner: Anybody ever hear of Dr. Deming?

Sure, but I don't think he said anything about PC-based controls. :-) Virtually nothing he said impacts this argument, with the possible exception of "don't rely on technology to solve problems." I suppose your argument would be that choosing a PC to save up front costs reflects a lack of long-term planning, or that fiddling with PC tech shows a lack of constancy of purpose. You have a point. As I said originally, grabbing a Dell and copy of Visual Studio is not the right solution. That DOESN'T mean that PLCs are always the right choice, or that a PC is always the wrong one.

-James Ingraham
Sage Automation, Inc.

> "PC with a simple robust OS" is an oxymoron.
> there is no blue screen of death on a PLC.

I would have to agree on this to a certain degree. But - a stripped down linux installation is a lot simpler than the Microsoft offerings, and I would dare say not much more advanced than the software inside a PLC, with the benefit that the source code is open and therefore may be inspected by anyone who desires it.

> soft PLC, driving animated graphics, handling a hundred analog process
> devices, calculating statistics and creating paretos and productions
> reports...and when you can't even get 4 temperature samples while attempting to

I think we actually agree on this point. A PLC is a quick and simple way to implement many systems, in particular small simple systems. Logging data and controlling a lab process is probably one of these. But the low cost also depends on that the user is knowledgeable on PLC/SCADA/Database setup, and for many people it seems simpler to start with for instance labview and excel on windows, and not have to learn to program a PLC. I would think the results are not as good, but I disagree that a PLC based solution is always cheaper.

What I am talking about is using proper machine separation for 'logic tasks' (in a computer or in a PLC), and for HMI tasks (in a computer or a industrial panel) and also for running the database. As you can see, I would recommend at least three machines in this scenario. So not a lot similarity with the labview+excel setup described above.

And as I also said, while PLC/SCADA based systems are fine, a system based on a programming language could perhaps excel in more complex tasks (dynamic size lists, hashes, sorting, integration with other computer systems etc). But the task of creating such a system is difficult and time consuming, and should not be done for fun in a project, but taken seriously as a project on its own. Then, after the concept is proven, it may be used as a tool in projects that aim to build a plant.


> "PC with a simple robust OS" is an oxymoron.
> there is no blue screen of death on a PLC.
[clip]
> A pc is a single tasking slow stupid device which is incapable of having a few hundred process applications running simultaneously while still processing the entire program, scanning all I/O and updating the image table repeatedly and absolutely reliably at a rate of a few milliseconds even with the plc sitting alone in an oil saturated box for decades at a time. <

Never heard about multi tasking, multi threading on multi core CPUs of a PC ? ...

Regards
Armin Steinhoff

[ clip]

> ...welcome to America.

IMHO .. the first PC based control systems was used in America. Have a look to the history of QNX and oil platforms.

Best Regards
Armin Steinhoff

By James Ingraham on 21 October, 2011 - 12:53 pm

Steinhoff: IMHO .. the first PC based control systems was used in America. Have a look to the history of QNX and oil platforms.

This may well be correct, although it's probably impossible to find the "first" example. Although I thought QNX's first deployments were in aerospace, but I could be wrong.

Oh, and QNX is Canadian. :-)

-James Ingraham
Sage Automation, Inc.

P.S. Armin, what gives? You went 15 rounds with me and we didn't even disagree that much. Then you let this vitriolic rant go through with an off-hand, non-technical response? Is that an insult or a compliment?

>> Steinhoff: IMHO .. the first PC based control systems was used in
>> America. Have a look to the history of QNX and oil platforms.

> This may well be correct, although it's probably impossible to find
> the "first" example. Although I thought QNX's first deployments
> were in aerospace, but I could be wrong.

> Oh, and QNX is Canadian. :-)

Oh ... sorry about that !

> -James Ingraham
> Sage Automation, Inc.
>
> P.S. Armin, what gives? You went 15 rounds with me and we didn't
> even disagree that much. Then you let this vitriolic rant go
> through with an off-hand, non-technical response? Is that an
> insult or a compliment?

Two times no. As an "old fighter" of this mailing list I know when I
have to give up :)

Best Regards
Armin Steinhoff

By Lynn August Linse on 21 October, 2011 - 2:54 pm

> So I decided to reverse engineer the whole system control and replace it by a
> Pc. I'm thinking of finite state machine or real time control to do this.

(* Smile *)

Quite a political topic! The race to replace PLC with a PC began what ... 15 years ago? For some reason, PLC still exist and most "PC working like PLC" companies have gone bankrupt. Those who say the PC will displace the PLC are kin to those who say IPv6 will replace IPv4 and lots of other forward thinkers :-)

You as an individual can of course create a PC app which reads in a temperature.

The biggest problem with "PC as controller" is the hardware changes so fast that it is nearly impossible to provide the exact 'spares' expected for more than a few years (or months) ... unlike the PLC companies who happily charge an arm-and-a-leg (and half the other leg) for a 15-year old replacement part.

I'm sure there are poster-children out there on this list running 15-year old PC. Not I - my oldest CPU is a P4 dual-core which is perhaps 5 years old and runs my RSLogix stuff - and spends 99% of its time powered off. I'm sure I could NOT find any direct replacement parts for it - unless they are used parts on ebay.

All of my active PC systems (Windows or Linux) are running on hardware from 1 to 3 years old at most.

By James Ingraham on 21 October, 2011 - 7:30 pm

Lynn August Linse: ...most "PC working like PLC" companies have gone bankrupt.

Huh? Beckhoff, B&R, ABB, and Kuka are just the ones that spring to mind off the top of my head. True, Think & Do and Steeplechase kinda vanished... but (a) they were pure software plays, and (b) neither actually went bankrupt. Both products are still available from current owner Phoenix Contact, though I'm sure their sales are a fraction of their late-90s / early aughts peak. QNX, VxWorks, Advantech, Kontron, etc. all do just fine in this space. National Instruments is going great guns.

Lynn August Linse: Those who say the PC will displace the PLC are kin to those who say IPv6 will replace IPv4 and lots of other forward thinkers :-)

Jiminy Cricket! Are we going to have a go at IP v4 / v6 now? Why don't we debate something less controversial, like how to achieve peace in the Middle East.

To your point, there was an initial enthusiasm for PC-based control that was unwarranted. The theory that PCs would eventually dominate PLCs had some serious flaws. The most obvious in hindsight is that the PLC guys weren't just going to sit there and let their products die. Hence the whole "PAC" nomenclature. Bottom line is that PLCs gained a whole host of new features to compete with PCs. Also, at the very low end (a handful of discrete I/O, say) PLCs could compete on cost despite the theoretical price advantage of a PC. The threat of PCs forcing PLC vendors to implement things like motion control, data structures, open networks (well, sorta), web interfaces, etc. is a good thing. So your point is correct, but misses the forest for the trees. PCs will not replace PLCs. However, PCs have thoroughly established themselves as an important option in industrial controls, and forced PLCs to improve.

Lynn August Linse: The biggest problem with "PC as controller" is the hardware changes so fast that it is nearly impossible to provide the exact 'spares' expected for more than a few years (or months) ... unlike the PLC companies who happily charge an arm-and-a-leg (and half the other leg) for a 15-year old replacement part.

One of the major benefits of PCs is that you don't NEED exact spares. I can take software written 15 years ago and run it on a brand-spanking new machine. I did it last week, in fact. Sometimes you have hardware problems; this is where networks really help, especially Ethernet. I don't need a motion control board or a DAQ board or whatever any more. I connect to all my real-world devices via Ethernet. It's true that eventually Ethernet will go away to join serial ports, floppy drives, and AT keyboards. But we've got a LONG time before that happens. And with virtualization, we can keep that old software going even longer.

One final point. In all this back and forth, nobody has brought up the fact there are virtually no industrial control scenarios that DON'T involve a PC. They are frequently used for HMI / SCADA. They are used for programming the PLCs. They're used for troubleshooting, and reporting, and all sorts of things. Does it help you that your PLC is running if the HMI is dead? PCs are already critical pieces of the infrastructure.

-James Ingraham
Sage Automation, Inc.

By Steve Myres on 21 October, 2011 - 11:48 pm

One of the major benefits of PCs is that you don't NEED exact spares. I can take software written 15 years ago and run it on a brand-spanking new machine

An excellent point and one that I was going to point out myself.

Does it help you that your PLC is running if the HMI is dead? PCs are already critical pieces of the infrastructure.

Yes. Yes it does. There's a PC-based package that I use a lot, which is pretty script oriented, and you can see that the publishers are envisioning customers using it for control; they include PID control capability and so on. And yet I just use it for an MMI. No logic is solved, nor any critical information stored on the PC, nor will its sudden, unexpected, or spectacular failure even cause the process to burp.

Roll up another PC, load the runtime license and app, configure the network connection, (hopefully all this has been done beforehand, actually) and you're online with the process again just like that with no loss of anything nor a bump in the process! Now I'll admit that if you're working with a PC-based solution where you DO trust the reliability of the computer hardware, OS, and software to a level comparable to a PLC, just using the PC would yield a more reliable solution as it eliminates one potential point of failure.

I also take issue with your inclusion of programming terminals as critical pieces of the control architecture. Typically, if your laptop dies, it does so while you're doing something other than making online edits, and even in that case, the regard given to reliability by the PLC designers will generally save the day and continue to maintain the process in control till you replace the PC.

By James Ingraham on 24 October, 2011 - 6:13 pm

Me: Does it help you that your PLC is running if the HMI is dead?

Steve Myres: Yes. Yes it does... No logic is solved, nor any critical information stored on the PC, nor will its sudden, unexpected, or spectacular failure even cause the process to burp.

This may or may not be helfpul. Most of my machines have a Cycle Start button on the HMI. If you lose the HMI, you can't re-start the machine. Granted, our machines probably start / stop a few times a shift, where as some process may go months or years without a stop. So perhaps you can live without your HMI for a little while.

Steve Myres: Roll up another PC, load the runtime license and app, configure the network connection, (hopefully all this has been done beforehand, actually) and you''re online with the process again just like that with no loss of anything nor a bump in the process!

Again, it depends on the process. What you just described might take days. Just as one example, if you lose a Siemens license in the middle of the night or on a weekend, tough luck. Many software packages can't just be download off of the supplier site, so you have to pray you have the disks somewhere accessible. If there's some special hardware (like a Profibus card) then you could be in for a long lead time. There aren't too many processes that can be left alone for days at a time with no monitoring by a human.

Me: PCs are already critical pieces of the infrastructure.

Steve Myres: I also take issue with your inclusion of programming terminals as critical pieces of the control architecture. Typically, if your laptop dies, it does so while you're doing something other than making online edits, and even in that case, the regard given to reliability by the PLC designers will generally save the day and continue to maintain the process in control till you replace the PC.

I guess it depends on what you mean by "critical." True, if a PLC is running the process and my programming terminal dies I am not likely to blow up Pennsylvania. In that regard, it's not critical. On the other hand, things always go wrong in waves. The process shuts down for some bizarre reason, so you go grab the maintenance laptop. It's dead. So now you can't get online to figure out what's going on. And you can't just re-install the software on another laptop because that one had the license key. Plus, it was the only laptop left with a serial port.

-James Ingraham
Sage Automation, Inc.

By Steve Myres on 24 October, 2011 - 10:32 pm

This may or may not be helpful. Most of my machines have a Cycle Start button on the HMI. If you lose the HMI, you can't re-start the machine. Granted, our machines probably start / stop a few times a shift, where as some process may go months or years without a stop. So perhaps you can live without your HMI for a little while.

For any intervention the operator has to do with the machine on a frequent basis like every cycle, I provide hard pushbuttons. $50 to replace vs. the cost of a touchscreen. Plus, some things have to be hardwired anyway, like two-hand inputs, E-Stops, etc. Stuff on the screen is reserved for information and occasional (say few times per hour max) button pushes.

Again, it depends on the process. What you just described might take days. Just as one example, if you lose a Siemens license in the middle of the night or on a weekend, tough luck. Many software packages can't just be download off of the supplier site, so you have to pray you have the disks somewhere accessible. If there's some special hardware (like a Profibus card) then you could be in for a long lead time. There aren't too many processes that can be left alone for days at a time with no monitoring by a human.

Well, like I said, preferably the customer or I has had the foresight to get this all set up on a replacement machine before the primary broke. If you've allowed yourself to have a vulnerability where an easily foreseeable failure will stop your process for days on end, either you haven't finished optimizing the process or you should be looking for a job. Besides, your hypothetical makes it a WORSE idea to use a PC in a process setting, and the post I was responding to basically said it was OK. You're proving MY point.

The process shuts down for some bizarre reason, so you go grab the maintenance laptop. It's dead. So now you can't get online to figure out what's going on.

Yeah, that sounds about like a normal day! ;-)

And you can't just re-install the software on another laptop because that one had the license key. Plus, it was the only laptop left with a serial port.

But that's a strawman IMO. "I'm capable of planning so badly as to create more points of failure in my system, therefore it's safe to use PC's in critical locations" Have a backup plan. Have a backup plan for your backup plan.

Run your automation software from within VM's, preferably VM's on an external hard drive. (Just unplug your hard drive and plug into the replacement laptop. And even if the hard drive isn't external on the original laptop, take it out and use it externally to the replacement -- but remember, VM's on that drive, not a native install) And the VM's should be backed up besides.

As far as the serial port, make sure you have one, or a solution. Test it beforehand and make sure it works.

By James Ingraham on 25 October, 2011 - 8:00 pm

Steve Myres: your hypothetical makes it a WORSE idea to use a PC in a process setting, and the post I was responding to basically said it was OK. You're proving MY point.

Yeah, my message has been a little muddled, hasn't it? (Not the first time.) The whole thread started with me arguing against PCs, then for them, then apparently against them. This schizophrenic back-and-forth is the result of reality being messy. For the original question, I thought grabbing an off the shelf PC and throwing it a control applications was a bad idea. Then someone came back and said never use PCs under any circumstances, and anyone who does is contributing to the Decline and Fall of America. I think this position is far too extreme, and ignores the fact that PCs are already a critical piece of the controls world. You (Steve, for others reading this and getting lost in my ramblings) basically said, "Meh, the way I use PCs they aren't so critical." My examples were to show that PCs are, in fact, critical, even if a momentary blip in one won't necessarily take down your plant. We ALREADY have to deal with PCs as critical pieces of infrastructure. Like you said, we've got to plan ahead and deal with them. Because they're IMPORTANT. Because we basically couldn't run modern facilities without them. They aren't just for accounting and marketing folks, or even the design engineers who never leave their cubicles to see what's happening on the plant floor. The guys in the trenches NEED their PCs. You said (specifically) that PCs for programming do not count as critical; then you said it's important to make sure you have solutions so that a PC failure doesn't wreck your life. That sounds like "critical" to me.

So to clarify; PCs are here to stay, and must be dealt with. There are applications where PCs are a good fit, and ones where they are a bad fit. There are, in particular, some issues with PCs that must be considered when using them in a controls application, and ignoring those issues is going to create long-term problems. There is no one perfect solution for all scenarios.

-James Ingraham
Sage Automation, Inc.

Everyone is in a heated debate, but the Original Poster (OP) is nowhere to be seen....

:o)

KEJR

By James Ingraham on 26 October, 2011 - 3:06 pm

We scared him off, I guess. Is that a good thing or a bad thing?

-James Ingraham
Sage Automation, Inc.

Hopefully he purchased an OPC Server since that was all he needed.

By Lynn August Linse on 27 October, 2011 - 11:33 am

This same topic comes up a few times a years for the decade+ that control.com has been running. Always the same PRO/CON - not much has changed. :)

>> Lynn August Linse: ...most "PC working like PLC" companies have gone bankrupt.

> Huh? Beckhoff, B&R, ABB, and Kuka are just the ones that spring to mind off the top
> of my head. True, Think& Do and Steeplechase kinda vanished... but (a) they were
> pure software plays, and (b) neither actually went bankrupt. Both products are still
> available from current owner Phoenix Contact, though I'm sure their sales are a fraction
> of their late-90s / early aughts peak. QNX, VxWorks, Advantech, Kontron, etc. all do
> just fine in this space. National Instruments is going great guns.

>> Lynn August Linse: Those who say the PC will displace the PLC are kin to those who
>> say IPv6 will replace IPv4 and lots of other forward thinkers :-)

> Jiminy Cricket! Are we going to have a go at IP v4 / v6 now? Why don't we debate
> something less controversial, like how to achieve peace in the Middle East.

> To your point, there was an initial enthusiasm for PC-based control that was
> unwarranted. The theory that PCs would eventually dominate PLCs had some serious
> flaws. The most obvious in hindsight is that the PLC guys weren't just going to sit
> there and let their products die. Hence the whole "PAC" nomenclature. Bottom line is
> that PLCs gained a whole host of new features to compete with PCs. Also, at the very
> low end (a handful of discrete I/O, say) PLCs could compete on cost despite the
> theoretical price advantage of a PC. The threat of PCs forcing PLC vendors to
> implement things like motion control, data structures, open networks (well, sorta), web
> interfaces, etc. is a good thing. So your point is correct, but misses the forest for the
> trees. PCs will not replace PLCs. However, PCs have thoroughly established
> themselves as an important option in industrial controls, and forced PLCs to improve.

>> Lynn August Linse: The biggest problem with "PC as controller" is the hardware
>> changes so fast that it is nearly impossible to provide the exact 'spares' expected for
>> more than a few years (or months) ... unlike the PLC companies who happily charge
> an arm-and-a-leg (and half the other leg) for a 15-year old replacement part.

> One of the major benefits of PCs is that you don't NEED exact spares. I can take
> software written 15 years ago and run it on a brand-spanking new machine. I did it last
> week, in fact. Sometimes you have hardware problems; this is where networks really
> help, especially Ethernet. I don't need a motion control board or a DAQ board or
> whatever any more. I connect to all my real-world devices via Ethernet. It's true that
> eventually Ethernet will go away to join serial ports, floppy drives, and AT keyboards.
> But we've got a LONG time before that happens. And with virtualization, we can keep
> that old software going even longer.

Yes, that's the reality ... I share your view.

> One final point. In all this back and forth, nobody has brought up the fact there are
> virtually no industrial control scenarios that DON'T involve a PC. They are frequently used for HMI/SCADA.

We have customers in that area who do complex calculations on a PC instead of a PLC ... requests and responses are communicated between the PC (SCADA) and PLC via PROFIBUS.

Best Regards
Armin Steinhoff

By Armin Steinhoff on 22 October, 2011 - 6:31 am

>>So I decided to reverse engineer the whole system control and replace it by a
>>Pc. I'm thinking of finite state machine or real time control to do this.

> (* Smile *)

> Quite a political topic! The race to replace PLC with a PC began
> what ... 15 years ago? For some reason, PLC still exist and most
> "PC working like PLC" companies have gone bankrupt.

... and how many PLC companies have gone bankrupt in the same time
frame?

> Those who say the PC will displace the PLC are kin to those who
> say IPv6 will replace IPv4 and lots of other forward thinkers :-)

>You as an individual can of course create a PC app which reads in a
>temperature.

When you are using an automated teller machine from VISA .. are you
aware that this system is controlled PC-based?
When you depart from the international airport Frankfurt [FRA] are you aware that the gasoline pumps for the aero plans are controlled by QNX systems with a fieldbus?

Most baggage sorting systems on airports worldwide are PC based controlled.

However ... there are a lot of other PC based solutions which are
supporting your day by day life.

>The biggest problem with "PC as controller" is the hardware changes
>so fast that it is nearly impossible to provide the exact 'spares'

The normal interfaces of PC based control systems are provided by POSIX based operating systems and not by the low level hardware. There are no problems as long as the new version of the PC hardware is supported by the POSIX operating system. MS-Word e.g. is working unmodified on different PCs ... isn't it ? Same story with other applications for other POSIX operating systems.

Yes, after a run of 15 years it's difficult to buy a PC with an ISA or PCI slot ... but there are similar problems to buy an IO interface board for e.g. an old Siemens S5 system.
I don't see here big differences ...

> expected for more than a few years (or months) ... unlike the PLC
> companies who happily charge an arm-and-a-leg (and half the other
> leg) for a 15-year old replacement part.

Yes, why should I buy expensive spare parts for an old PC system when I'm able to buy a newer, faster, cheaper and compatible one ?

> I'm sure there are poster-children out there on this list running
> 15-year old PC. Not I - my oldest CPU is a P4 dual-core which is
> perhaps 5 years old and runs my RSLogix stuff - and spends 99% of
> its time powered off. I'm sure I could NOT find any direct
> replacement parts for it - unless they are used parts on ebay.

What parts do you want to buy? Most components of a PC are on the motherboard and on the CPU (Soc chip) ...

> All of my active PC systems (Windows or Linux) are running on
> hardware from 1 to 3 years old at most.

Well ... and the reason is: You want to use the newest version of
Windows or Linux. And the reasons are not problems with spare parts,
isn't it? :)

Best Regards
Armin Steinhoff

By Nathan Boeger on 27 October, 2011 - 7:20 pm

I think OP started this debate and left for a good laugh. It's not the first and certainly won't be the last.


---------
Nathan Boeger
http://notanotherindustrialblog.blogspot.com