Tower of babel

B

Thread Starter

Bob Peterson

I was wandering around in our shop yesterday and noticed a panel with an interesting set of modules in a Contrologix rack.

It has Profibus, devicenet, ethernet, and controlnet interface cards. Should be a real interesting project for someone.
 
T

Terry Miller

Interesting how the single "industry standard bus network" that everyone supposedly was working toward in the early nineties has evolved. I guess that is what happens when the commercial (profit) aspects of a standard take precedent. Based on the description of the hardware on hand for this project I would say you have a very pricey data gataway system, a la Rockwell.

Terry Miller
 
B
Could those modules be Schneider Electric's Momentum I/O Bases. They have all the protocols listed above in the form of communication adapters. Nice way to use generic I/O.
 
S

Steve Myres, PE

I did a job with a Control Logix one time containing almost as motley a collection: A DeviceNet Scanner, an ethernet module, and an MVI56 talking RS232 to a host PC.

That job was a bit of a OBF and near OBF nightmare. Every comms module, the processor, the power supply, and I think even the chassis were all replaced at one time or another by AB. Don't tell Curt. ;-) At least the servo and generic I/O modules worked the first time.
 
E

Eddie Willers

>> It has Profibus, devicenet, ethernet, and
>> controlnet interface cards. Should be a real
>> interesting project for someone.

Not necessarily, Bob, if you mean "Interesting" = "Incredibly Painful and Difficult". I rag on my A-B reps about how long it took them to develop ControlNet into something useful, but in the applications I do something becomes startlingly clear: they invested their time wisely.

Have you ever seen RSLinx "drill down" from Ethernet, across ControlNet, down to DeviceNet to read a value out of something like a motor starter ? There's no programming involved; it's a natural consequence of the "Common Industrial Protocol" elements that Rockwell wrote into the EtherNet/IP, ControlNet, and DeviceNet networks. They give it the hokey name "NetLinx", but the fact that I can send a message across three different network types without any extra "exchange blocks" or "store and forward" logic is *incredible*. I can't do that with Profibus DP/PA or DP/ASi or Modbus/TCP-Modbus or anything else on the market.

The Profibus module, being a non-CIP network, is probably going to be the biggest challenge in that panel.
 
I saw a similar configuration in 1999, it also had PC control with Steeple Chase. I said it wouldn't work. Five years later, it has spent over 65% of its life as cold iron. It now has 2 plc's running it, devicenet and ethernet and profibus disconnected. 2 robots were disconnected to run independently. I guess the moral of the story is: Life is like a bowl of M and M's, eat the red ones, save the yellow ones, throw the rest away! or Let's just use one platform (and please let it be closed)
regards.....kc
 
M

Matthew Hyatt

> Should be a real interesting project for someone.<


Probably more painful then interesting, that is why it is sitting around doing nothing except taking up space and generally acting like a boat anchor looking for a boat!


MJH
 
C

Curt Wuollet

Perhaps a less cynical observer might hope that eventually all this stuff might simply run on one wire and one protocol, which would make for a far better world and cost everyone, vendors included, much less in both monetary terms and pain and suffering.Especially since support for competing protocols seems to always be mysteriously, somewhat broken. Of course, that's the most obvious and sensible solution and thus has no place in automation. One is reminded of Deming's definition of insanity.

I personally keep wondering if the cost of this insanity will ever come down anywhere near the meager profits derived by it. By their reasoning, I should build a business model around creating a parallel Internet, so I can control what goes on it. I won't have many nodes, but I'll have total control. No..... darn! Microsoft tried that already.

Regards

cww
 
B

Bob Peterson

I agree controlnet is reasonably well thought out, but the software supporting it has a LONG way to go. Way to many quirks and outright bugs, plus the documentation is just plain bad, and full of misleading statements and outright errors. I did indeed mean its liekly to be very painful for whomever does the software unless he has previous experience with each of the crads and protocals. Even so he will no doubt spend much time on the phone with tech support.

> Have you ever seen RSLinx "drill down" from Ethernet, across ControlNet, down to DeviceNet to read a value out of something like a motor starter ? There's no programming involved; it's a natural consequence of the "Common Industrial Protocol" elements that Rockwell wrote into the EtherNet/IP, ControlNet, and DeviceNet networks. They give it the hokey name "NetLinx", but the fact that I can send a message across three different network types without any extra "exchange blocks" or "store and forward" logic is *incredible*. I can't do that with Profibus DP/PA or DP/ASi or Modbus/TCP-Modbus or anything else on the market.
>
> The Profibus module, being a non-CIP network, is probably going to be the biggest challenge in that panel. <

I just wish AB was as good with its documentation as in producing the products in the first place. i am tired of having to try umpteen different random variations to get something to work, or giving up after an hour and having to call tech support for some obscure tech note that describes the situation I have.

Bob Peterson
 
J

Joe Jansen/TECH/HQ/KEMET/US

Omron's FINS protocol has been doing this for several years. Ethernet, controllerlink, devicenet, RS-232, whatever. There are one or two older implementations of the RS-232 that won't do this, but anything modern (last couple years) will reach thru 3 networks without any programming involved.

In addition, it is not only supported on their most expensive platform, but across nearly the whole product line. Mostly because they have been able to do it for so much longer than AB.

--Joe Jansen
 
R

Ralph Mackiewicz

I think blaming profits for the "tower of babel" that is modern industrial automation networking is, to be kind, simplistic. IMHO, there are at least 2 underlying reasons that communications in industrial automation is so fragmented which I will repeat here:

1. Industrial automation encompasses a wide range of processes and equipment, each with its own unique set of requirements. The result was a highly fragmented market with many different application niches and groups of companies serving those niches, with different dominant players in each niche.

If you look carefully at the archive of this list you will see discussions where experts in their particular niche express their reluctance with having to make the tradeoffs necessary to use a single networking solution across all these different application niches. Soemtimes this reluctance is well founded (such as applications requiring instrinsic saftey). Other times, it is because many just don't want a sub-optimal solution for their own niche and therefore, discount the benefit of using fewer solutions.
In many cases, they are stuck with a particular dominant vendor who, given #2 below, has little incentive to do anything about it.

2. More importantly, the majority of users (albeit not people on this list apparently) don't really care about having a single open standard that all their vendors support. Quite simply, if users really cared, they wouldn't be buying all the proprietary stuff. Most users standardize on vendors, not on technology. The fact that
vendors do what they do is a natural reflection of the way most users want to be treated. Again, IMHO, most users grossly underestimate the true cost of building, supporting, operating, and integrating industrial automation systems and focus way too much on the cost to purchase the equipment.

The result is a fragmented approach to communications with each dominant vendor supporting their own pet standards and leaving it to third parties to support other "non-strategic" systems (a.k.a. the "tower of babel").

If you want to know why there is such a lack of interest in user-driven standards in the industrial automation networking market there is a telling example from the last great effort made in this regard: MAP. In about 1994 (I can't be sure of the date anymore but it was after it effectively ended), I happened to meet one of the most well-known and vocal proponents of MAP at an unrelated industry event. This person worked for one of the largest consumers of industrial automation products in the world. We got to talking about what went wrong and this is what he told me: "user-driven standards don't work". This was the lesson learned from the same organization that for the previous 6-8 years insisted that the only viable networking topology that could be used effectively is broadband token bus. As if this was somehow irrelevant to what happened.

Profit is not the problem here. Profit is the answer. Users can make demands and vendors will respond because of profit. But users need to look at industrial automation as a tool to improve the company, not just as a cost of doing business. Until they do, they will never see the benefits of interoperability and, as a result, will never justify doing anything different. These benefits are not derived at the time of purchase. The benefits of interoperability are derived after the purchase in most cases. Standardizing on a vendor is not the right way to use the profit motive to enable change.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
You seem to be making the assumption that what is profitable for the vendors is good for the users. While this assumption is true in a perfect classical market, the automation market is neither perfect nor classical. It is
dominated by monopolies, some government-granted - copyrights, patents - others privately created - trade secrets and the like - along with a heavy dose of network effects. Hardly a situation in which classical economical
models could be taken for granted.

Do you have any evidence that the assumption nevertheless holds?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
C
Hi Ralph

On February 10, 2004, Ralph Mackiewicz wrote:
> I think blaming profits for the "tower of babel" that is modern
> industrial automation networking is, to be kind, simplistic. IMHO,
> there are at least 2 underlying reasons that communications in
> industrial automation is so fragmented which I will repeat here: <

I wasn't blaming profits so much as chiding the majors for expending lots of resources on redundant development. I could probably develop a competitive scheme for making hardware talk on the wire. The real question is whether I should, when it makes so much sense to use an existing standard. If one exists. Or at least attempting to make
something a standard by having at least one more entity use it. Think how much many instrument makers save by simply using Modbus rather than rolling their own. For all it's faults, it is something of a standard and permits some degree of interchangability. Of course, it's just this interchangability that the majors are trying to avoid
in areas such as IO and motion control. Lock-in is a much larger factor than direct profits. Expensive modules that are exclusive to your line are where the cost of developing the network is made up.

> 1. Industrial automation encompasses a wide range of processes and
> equipment, each with its own unique set of requirements. The result
> was a highly fragmented market with many different application
> niches and groups of companies serving those niches, with different
> dominant players in each niche.
>
> If you look carefully at the archive of this list you will see
> discussions where experts in their particular niche express their
> reluctance with having to make the tradeoffs necessary to use a
> single networking solution across all these different application
> niches. Soemtimes this reluctance is well founded (such as
> applications requiring instrinsic saftey). Other times, it is
> because many just don't want a sub-optimal solution for their own
> niche and therefore, discount the benefit of using fewer solutions.
> In many cases, they are stuck with a particular dominant vendor who,
> given #2 below, has little incentive to do anything about it. <

Given the universal adherance to suboptimal solutions for tools and HMI, I find it a little overly optomistic that they are trying to craft the finest solution for a niche. There are certainly valid specialities served by perticular vendors, but the vast majority of applications
could be done with nearly any vendor's product line. And the bulk of networking needs could be met with a simple but very flexible suite of protocols and perhaps three types of media. After all, we've connected the whole world with totally inadequate protocols :^) and it's an amazingly good job. If half the effort expended in building the Tower of Babel were expended cooperatively to make one thing work, I'm certain we would see a similar triumph of human ingenuity. I know for a fact, that if we could interest the OSS community in solving this mess, it would be working soon. Depending on competitors to solve it is contradictory. Until dire need and customer pressure make it necessary.

> 2. More importantly, the majority of users (albeit not people on
> this list apparently) don't really care about having a single open
> standard that all their vendors support. Quite simply, if users
> really cared, they wouldn't be buying all the proprietary stuff.
> Most users standardize on vendors, not on technology. The fact that
> vendors do what they do is a natural reflection of the way most
> users want to be treated. Again, IMHO, most users grossly
> underestimate the true cost of building, supporting, operating, and
> integrating industrial automation systems and focus way too much on
> the cost to purchase the equipment. <

Can't agree at all. If you want to automate something with a PLC right now, you have the choice of closed, or closed, or closed. To not buy what is the only choice readily available, is to choose simply not to automate. This is the same old "Let them eat cake" argument, saying people would be buying red Model T's if they wanted them.

> The result is a fragmented approach to communications with each
> dominant vendor supporting their own pet standards and leaving it to
> third parties to support other "non-strategic" systems (a.k.a. the
> "tower of babel").
>
> If you want to know why there is such a lack of interest in user-
> driven standards in the industrial automation networking market
> there is a telling example from the last great effort made in this
> regard: MAP. In about 1994 (I can't be sure of the date anymore but
> it was after it effectively ended), I happened to meet one of the
> most well-known and vocal proponents of MAP at an unrelated industry
> event. This person worked for one of the largest consumers of
> industrial automation products in the world. We got to talking about
> what went wrong and this is what he told me: "user-driven standards
> don't work". This was the lesson learned from the same organization
> that for the previous 6-8 years insisted that the only viable
> networking topology that could be used effectively is broadband
> token bus. As if this was somehow irrelevant to what happened. <

User driven works if it's not odious or prohibitively expensive for the users. That's why oral thermometers are greatly preferred among autonomous consumers even if the vendors think the other type more amusing. Unfortunately, we have only the other type in our market. There is a great opportunity selling something that consumers will
like better as long as it does the same job. Many customers are getting a little sore, but what choice do they have?

> Profit is not the problem here. Profit is the answer. Users can make
> demands and vendors will respond because of profit. But users need
> to look at industrial automation as a tool to improve the company,
> not just as a cost of doing business. Until they do, they will never
> see the benefits of interoperability and, as a result, will never
> justify doing anything different. These benefits are not derived at
> the time of purchase. The benefits of interoperability are derived
> after the purchase in most cases. Standardizing on a vendor is not
> the right way to use the profit motive to enable change. <

I can agree with that, especially the last clause. The problem is that resolving a standoff requires simultanious action or unusual bravery by one party in the name of avoiding mutual destruction. Or a very brave and objective party to intercede. We are seeing some small hints of character, but no one is lowering their guns just yet, no matter how tired they get.

Regards

cww
 
R

Ralph Mackiewicz

On February 10, 2004, Jiri Baum wrote:
> You seem to be making the assumption that what is profitable for the
> vendors is good for the users. While this assumption is true in a
> perfect classical market, the automation market is neither perfect nor
> classical. It is dominated by monopolies, some government-granted -
> copyrights, patents - others privately created - trade secrets and the
> like - along with a heavy dose of network effects. Hardly a situation
> in which classical economical models could be taken for granted. <

I do not assume that what is good for vendors is good for users. My assertion is that users can influence vendors if they really wanted to because vendors are motivated by profit to the same degree that users are motivated by profit. I also assert that there is nothing inherently wrong with being motivated by profit.

> Do you have any evidence that the assumption nevertheless holds? <

Are you asking for evidence that users continue to buy proprietary technology (which was my assertion)? Seems obvious given that if automation companies are indeed currently selling proprietary stuff to someone that it was users they were selling it to.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
J
"Me too"

FoundationT Fieldbus also permits you to drill down from one network level to another such as from HSE to H1, for the same reason: a common object model. The same function blocks used in the Fieldbus (H1) devices are also used in the Ethernet (HSE) devices. No patching required.

It's explained in chapter 1 (overview) of the book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or download immediately in softcopy):
http://www.isa.org/fieldbuses

You can download this chapter for free in softcopy form. It's free, but you must register an account. If your email does not support this hyperlink feature correctly, please copy the entire link and paste it into your Internet browser. Mind the line wrap, make sure to get the complete path all the way to the 4585:
http://www.isa.org/Template.cfm?Sec...=/Ecommerce/ProductDisplay.cfm&ProductID=4585

Jonas Berge
SMAR
===========
[email protected]
www.smar.com
Learn fieldbus at your own pace: www.isa.org/fieldbuses
 
Indeed, classical market theory says that being motivated by profit will result in the best compromise between all the competing interests.

However, classical market theory makes certain assumptions, which are not necessarily true in the automation market. This may give rise to a situation where one or another side has an advantage, while the total sum of profit is lower - a suboptimal situation.

You seemed to be implying that this suboptimality is small, so that it can be reasonably ignored; I was interested in your reasons for this belief.

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools
 
R

Ralph Mackiewicz

> However, classical market theory makes certain assumptions, which are
> not necessarily true in the automation market. This may give rise to a
> situation where one or another side has an advantage, while the total
> sum of profit is lower - a suboptimal situation. <

I think it is debatable that the automation market is subject to non-classical economics due to market-distorting monopolistic-like companies. In fact, IMHO (not necessarily Adam Smith's opinion) the tower of babel in industrial automation protocols is partly due
because there is no market-distorting monopoly. If there was such a company in IA with such market power we would all be using only their protocol.

> You seemed to be implying that this suboptimality is small, so that it
> can be reasonably ignored; I was interested in your reasons for this
> belief. <

Actually, I was not trying to make any implication regarding the optimality or sub-optimality of the industrial automation marketplace. I think that any such observation about what is optimal and what is not is strictly a matter of opinion. Much like the weather. If you like to ski, then cold snowy weather is good. If you
like the beach, then it is bad. Some people don't like the way that the industrial automation market works based on criteria that they personally think is important. To others, those criteria aren't important.

My original post on this topic was simply suggesting that the tower of babel that is IA communications is not due to commercial interests "polluting" an otherwise pristine market that would have naturally migrated to a single protocol if only all these people would stop pursuing profit (that was the implication of the post to which I responded). I think that the IA market is the way it is
because it is a reflection of the aggregate behavior of all the users and vendors that participate in it. The tower of babel exists for these resons. The fact that the market participants are commercially motivated is only one factor among many and, IMHO, not the most signficant factor.

Ralph Mackiewicz
SISCO, Inc.
 
Top