Replacing a Plc-based control to a computer control

G

Thread Starter

Gnichi Mohamed

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?
 
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
 
J

James Ingraham

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
 
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
 
J

James Ingraham

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

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

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.

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

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?)

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

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.

<i>What's the problem ? A big choice is always positive.</i>

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

<i>I'm missing the fieldbus systems...</i>

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.

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

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.

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

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."

<i>Well, a better idea could be to look for a PC based solution.</i>

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.

<i>Why the S7?</i>

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.

<i>Also Siemens offers robust embedded PCs for control solutions :) </i>

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.
 
S
<i>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.</i>

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)

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

Excellent post, and to think that if you’re a Pepsi man it was all for naught!
 
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
 
J

James Ingraham

<i>Excellent post, and to think that if you’re a Pepsi man it was all for naught!</i>

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

-James Ingraham
Sage Automation, Inc.
 
> Man, I can't believe we're getting in to THIS argument again. Oh, well. Here goes. <

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

> 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.

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

>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 ...

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

> 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.

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

>> <i>I'm missing the fieldbus systems... </i>

> 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" .

>> <i>You have to add IEC61131-3, IEC61499 and function block programming like Labview, DACHSview a.s.o </i> <<
>
> 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. <

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

> 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." <
>
>> <i>Well, a better idea could be to look for a PC based solution. </i> <<

> 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 :)

>> <i>Why the S7? </i>

> 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. <
>
>> <i>Also Siemens offers robust embedded PCs for control solutions :) </i> <<
>
> 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
 
T

Tallak Tveide

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
 
J

James Ingraham

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

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

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: <i>That is not the case. Both systems are programmable with IEC61131-3. There is no difference in efforts to setup I/O control.</i>

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: <i>Forget win7 when we talk about x86 based PLCs. What you need at least is a reliable OS or a RTOS ...</i>

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: <i>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.</i>

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: <i>Why not ? Do you have any alternatives?</i>

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: <i>EtherCAT is a fieldbus ... at least for the IEC org :) </i>

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: <i>PROFINET is Ethernet based and a clean bus system.</i>

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: <i>EtherCAT is basically a ring system ... you have to look at the topology of the signal transmission.</i>

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>I don't see your point. The discussion was at the end "PLCs and fieldbuses vs. PCs and fieldbuses".</i>

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>I would never got the idea to use a Dell desktop system as an automation controller :)</i>

Well, we agree on something, at least.

-James Ingraham
Sage Automation, Inc.
 
> 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.
 
[ clip]
>>> Me: I wouldn't pick a fieldbus system for a new project that's PC-based.

>> Steinhoff: <i>Why not ? Do you have any alternatives?</i>

> 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: <i>EtherCAT is a fieldbus ... at least for the IEC org :) </i>

> 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: <i>PROFINET is Ethernet based and a clean bus system. </i>

> 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: <i>EtherCAT is basically a ring system ... you have to look at the topology of the signal transmission. </i>

> 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>I don't see your point. The discussion was at the end "PLCs and fieldbuses vs. PCs and fieldbuses".</i>

> 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
 
J

James Ingraham

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

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: <i>Regarding the bus operation there is no difference between Ethernet as a bus and fieldbuses with a bus topology.</i>

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: <i>Yes, nodes "can be daisy-chained" but they "must not be daisy-chained". You can build "clean" bus topologies without daisy-chained segments.</i>

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

Steinhoff: <i>PROFINET nodes have switches ... not repeaters.</i>

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: <i>The topology you are talking about is related to the wiring ... it has nothing to do with topology of the logical signal transmission.</i>

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

Steinhoff: <i>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.</i>

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

-James Ingraham
Sage Automation, Inc.
 
V

Vladimir E. Zyubin

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

>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
 
A

Armin Steinhoff

> 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
 
J

James Ingraham

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

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: <i>The handling of collisions of plain Ethernet (layer 1) doesn't allow "real-time" communication! You need a "real-time" protocol to avoid collisions!</i>

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: <i>So the Ethernet/IP protocol is just an empty black box for you? The ODVA has developed a complete unnecessary "real-time" protocol?</i>

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/Libra...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: <i>That's completely new for me</i>

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: <i>The transmission media of PROFINET for NRT / RT communication is based on standard Ethernet components (layer 1).</i>

And layer 2, for that matter.

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

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: <i>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.</i>

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: <i>What a weird idea That has never been one of my statements!</i>

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: <i>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>

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: <i>That's a misunderstanding. Ethernet "based" fieldbuses are always a combination of Ethernet AND a "real-time" protocol which avoids collisions.</i>

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.
 
A

Armin Steinhoff

> 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
 
Top