Communication protocols

C
Hi Phil

That's why the pressure for standardization must come from outside the automation establishment. Hell, they've just ended years of trying to do this very same thing with worse than no results, along the way they actually gained protocols. The push for Ethernet had very little to do with this bunch of self-interested NIH mavens. The push came from customers who have already
standardized on Ethernet and TCP/IP who know that connectors shouldn't cost $80.00 and a serial card shouldn't cost $450.00 and the whole purpose of networking is to interoperate. I expect this
trend to continue until proprietary solutions get you shown to the door. Only then will someone come up with the bright "idea" of standardizing on open protocols. I don't have a problem with
proprietary protocols so much as what they are used for which comes close to extortion. That and the bald faced liars calling them open. My questions are: When will the reasonable expectations of the customer start to matter. When will systems integrators start to matter? And when will networks begin to connect things together rather than keep them isolated by vendor?

Regards

cww
 
S

Sam Moore Square D Company/Groupe Shneid

Ralph:

What I meant was that OPC is based on distributed object technology (DCOM) and MMS is an application protocol that is implemented as a linkable library of functional calls. I didn't go on to say that if you want to develop MMS
applications you have just a couple of vendors that support MMS development environments.

If you want to plug MMS in the back of an OPC server you could, but I wonder why you would do that. MMS is based on a truly dead network stack called OSI and to get it to work on TCP you have to load a couple of the old OSI network layers on
top of TCP.

MMS is not object based.

Sam
 
H
No, Colin:
That's not the core message I was intending to pass on. My attitude is that if we all feel like little nobodies who have no control over these decision then we deserve what we get. If you don't like the protocol, don't buy the product. But we all want the thing we want, and we close our eyes and cringe about the part we dont like, but most buy anyway! That is why companies like
AB are able to stay bullies, and the Westburnes of this world are just order takers. Where would the PC be today if it had been made closed like the Mac, where would Modbus be (do you remember how in the eighties everbody was saying that recycling paper could not be done economically?). We know that open works for everybody, but we can't get everybody together to put pressure on the unreasonable guys because everybody is in their own isolated situation.

Hugo
 
R

Rob Hulsebos Philips CFT

>MMS is not object based.

What makes you say this?
Do you mean ' object' in the meaning of 'object oriented programming' ?

I do not know MMS very much, but since FMS is based on MMS (only simpler), I have the experience that the 'objects' in FMS are just a collection of bytes, only with a meaning administrated somewhere. There are definitely not objects in a C++ or Java way. No class is associated with them.

Greetings,
Rob Hulsebos
 
G

Georg Hellack

Dear Sam,

While OPC may be used on DCOM, in practice it is used locally based on COM. DCOM can become a nightmare with all the security/authorization relevant parts in it. Looking at the present
technology promoted by Microsoft like COM+, which is MSMQ based, and SOAP, which is XML and HTTP based, it makes you wonder on the future of DCOM.

Just a few facts that have so far apparently missed your attention :)

MMS is a message specification. It is therefore separated from the way the MMS messages are transferred from A to B, although there is set of existing profiles and the most widely used is OSI.
This is IMO the reason for much of the criticism towards MMS. However there are products that offer MMS over TCP/IP with an empty OSI session and presentation layer as specified by ITU. The
different profiles can exist in the same MMS product simultanously and the profile to be used is determined upon the connect request from the initiating MMS node. BTW: have you ever bothered to look with the network monitor in the additional protocol overhead on top of TCP/IP, that is generated with DCOM ?

Why is MMS not object-based ? Does object-based equal object-oriented ? The properties of an OO-system are:

1. Inheritance

2. Encapsulation

3. Polymorphism

While you may argue that 'inheritance' is perhaps not realized by MMS, encapsulation and polymorphism are (e.g. different meaning of 'set'/'get' methods of different MMS 'classes' like named variables, domains etc.) It is a different issue, how this object-orientation is
reflected in an API. But you may miss the object-orientation in DCOM (in case there is any), if you use it from a C-language program and not with the ATL C++ lib.

Your argument on the limited number of MMS vendors misses the point. There are already several and the number will increase, when there is an increase in the market (which is underway with the use of MMS in utilities). As the specs and all necessary information is publicly available (aside of the exaggerated fees charged by the IEC ;-), anyone can develop such a product, although it may not a weekend job like writing one's own Modbus driver is apparently for
some people on this list ;-). And using Microsoft proprietary technology with only a single source of supply appears to be no issue for a lot of companies in automation.

Best regards,

Georg Hellack

GHF automation GmbH
Technologie-Park Herzogenrath
Kaiserstr. 100
D-52134 Herzogenrath
e-mail: hellack @ ghf-automation.de
http://www.ghf-automation.com
 
R
Or take a seat in your national standardisation committee and disapprove of any unwanted 'standards'. Have the 'user's groups' be filled with users, and not with product sellers. Etc. etc...

Rob Hulsebos
 
S

Sam Moore Square D Company/Groupe Shneid

Yes. And in in an distributed object architecture where you can make connections to objects across a network.
 
>Dear Sam,
>
>While OPC may be used on DCOM, in practice it is used locally
>based on COM. DCOM can become a nightmare with all the
>security/authorization relevant parts in it. Looking at the present
>technology promoted by Microsoft like COM+, which is MSMQ
>based, and SOAP, which is XML and HTTP based, it makes you
>wonder on the future of DCOM.

I don't see a problem with this. And I don't think that the SCADA companies do either.

>Just a few facts that have so far apparently missed your attention
> :)
>
>MMS is a message specification. It is therefore separated from
>the way the MMS messages are transferred from A to B, although
>there is set of existing profiles and the most widely used is OSI.
>This is IMO the reason for much of the criticism towards MMS.
>However there are products that offer MMS over TCP/IP with an
>empty OSI session and presentation layer as specified by ITU.
>The different profiles can exist in the same MMS product
>simultanously and the profile to be used is determined upon the
>connect request from the initiating MMS node.
>
>BTW: have you ever bothered to look with the network monitor in
>the additional protocol overhead on top of TCP/IP, that is
>generated with DCOM ?


I don't see a need for MMS.

My point is that you have the extra overhead for simple messaging. You still don't have objects.

>Why is MMS not object-based ? Does object-based equal object-
>oriented ? The properties of an OO-system are:
>
>1. Inheritance
>2. Encapsulation
>3. Polymorphism

Yes. But also distributed objects that are integrated completely in the OS and every aspect of the development environments. I will get beat up over this, but whether or not my "open" UNIX
friends want to admit it the dominant operating system in the world and in the controls arena is Windows NT. Pick any of the major SCADA packages and you will see this.


>While you may argue that 'inheritance' is perhaps not realized by
>MMS, encapsulation and polymorphism are (e.g. different
>meaning of 'set'/'get' methods of different MMS 'classes' like
>named variables, domains etc.) It is a different issue, how this
>object-orientation is reflected in an API. But you may miss the
>object-orientation in DCOM (in case there is any), if you use it
>from a C-language program and not with the ATL C++ lib.
>
>Your argument on the limited number of MMS vendors misses the
>point. There are already several and the number will increase,
>when there is an increase in the market (which is underway with
>the use of MMS in utilities). As the specs and all necessary
>information is publicly available (aside of the exaggerated fees
>charged by the IEC ;-), anyone can develop such a product,
>although it may not a weekend job like writing one's own Modbus
>driver is apparently for some people on this list ;-). And using
>Microsoft proprietary technology with only a single source of
>supply appears to be no issue for a lot of companies in
>automation.


I don't see anyone running to develop MMS as a messaging system.
What I see is OPC sitting in front of the various controls network protocols like Modbus. MMS doesn't seem to have a place. It just doesn't make sense to put it behind the OPC server and it isn't adding value in front of it. Maybe I am wrong. I would like to hear someone from one of the major SCADA companies commenting on it.
 
H

Hullsiek, William

> Rob Hulsebos wrote:

> Or take a seat in your national standardisation committee and
> disapprove of any unwanted 'standards'. Have the 'user's groups' be
> filled with users, and not with product sellers. Etc. etc...

I used to attend SP72 meetings when they were being held. My employer stopped paying for them, because it did not directly add to the bottom-line.

I also took vacation and spent my own money going to a POSIX meeting.

I would make a comment about pointy-hair bosses, ala Dilbert but it would be censored off the list.


- Bill Hullsiek
 
R

Ralph Mackiewicz

> > The problem that I see with a "common" protocol is trying to get
> > everyone to agree on what that "common" protocol should be.

...snip...snip...

> That's why the pressure for standardization must come from outside
> the automation establishment.

Who outside of the automation industry cares about interoperability of automation equipment?

...snip...snip...

> My questions are: When will the reasonable expectations of the
> customer start to matter.

If users care so much about open and interoperable standards then why do they keep buying things that are not open and not interoperable?

I am serious: Can someone please answer this question?

> When will systems integrators start to matter?

When they start making the purchase decisions on the equipment they integrate.

> And when will networks begin to connect things together rather
> than keep them isolated by vendor?

When users (or the people who make purchase decisions) stop buying those solutions that isolate them by vendor.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R

Ralph Mackiewicz

> What I meant was that OPC is based on distributed object technology
> (DCOM) and MMS is an application protocol that is implemented as a
> linkable library of functional calls.

Certain MMS products are implemented as linkable libraries of function calls. Others are implemented as DLLs, DDE servers, MMS executable servers, monitors, OPC servers, SCADA, HMI, EMS, etc. etc.

> I didn't go on to say that if you want to develop MMS applications
> you have just a couple of vendors that support MMS development
> environments.

Anyone can buy the standards and develop their own MMS. There are a number of companies that have done this. The couple of vendors you
refer to, like my company, provide a service to eliminate the protocol development effort so that OEMs can focus on application development. So the point is....?

> If you want to plug MMS in the back of an OPC server you could, but I
> wonder why you would do that.

The answer is obvious: to connect an OPC enabled application to an MMS/UCA/ICCP enabled device or application. Exactly like any other OPC server that is out there.

> MMS is based on a truly dead network stack called OSI and to get it
> to work on TCP you have to load a couple of the old OSI network
> layers on top of TCP.

So what? The presentation and session functions you refer to are completely transparent to both users and developers (using the development tools available from a couple of vendors). They add no
significant overhead to the system. They do provide a simple and interoperable mapping to the TCP/IP stack that is endorsed by the IETF and allow multiple applications to coexist independently on the same TCP socket.

> MMS is not object based.

MMS IS object based. The VMD model may not be object-oriented in the classical sense as it is applied to programming techniques. However, the object charateristics of MMS allow it map much more readily to object-oriented environments than register access protocols which support integer variables via addresses.

Regards,
Ralph Mackiewicz
SISCO, Inc.
6605 19-1/2 Mile Road
Sterling Heights, MI 48314-1408 USA
T: +810-254-0020 F: +810-254-0053
mailto:[email protected] http://www.sisconet.com
 
M
But we do settle for 50 (and many more) types of power cell, for the myriad of electrical and electronic devices in use.

And if you include other types of vehicle/transport, with different needs and fuel requirements to the domestic vehicles, you would find that the number of fuel types also increases. Different problems require different
solutions, hence http,ftp, etc. not to mention tcp and ip.

The next great thing (or one of them) will be XML, this effectively gives every body the ability to create their own protocol(s).

Infinite protocols.
 
W

Warren Postma

> When users (or the people who make purchase decisions) stop buying
> those solutions that isolate them by vendor.

This is a very pragmatic way of seeing it. Customer pressure might some day increase, or it might not. I agree, and I think it'll never happen.

Diverse ways of communicating are a fundamental part of being human. Just try to make everyone speak English. Or worse yet, try to get everyone to speak Esperanto. A doomed idea, maybe noble, maybe just dumb, but in the end it leads to nothing. On the other hand, a lot of people learn English who need it only to conduct business. Having a "lingua franca" is more useful
than to ban or deprecate any particular single language, protocol, or other simple standard.

For automation industries, Modbus is exactly that. It's a least common denominator. While unspecialized, and not very powerful, it works. Any expectation that everyone will suddennly start being "more consistent" in the Automation or communications protocols realm than Human Beings are wont to be in general, is in fact a pipe dream. I find the smaller the niche, the greater the potential for "balkanization".

Warren
 
M
> The next great thing (or one of them) will be XML, this effectively gives
> every body the ability to create their own protocol(s).
>
> Infinite protocols.

I've never really understood the problem of multiple protocols - why should we only have "N" protocols unless we also limit the number of
PLCs, RTUs, controllers, etc in a similar way?

What I do find frustrating is the way protocols are often so closely guarded (or made open but documented in a vague or inaccurate way), and the way that manufacturers often charge so heavily for the drivers (and cables and manuals and ...), but these are commercial issues for the manufacturers concerned. As has been pointed out, unless end users demand either a standard protocol, or (my preference) a well documented open protocol, then they'll get what the pay for.

[Working for a SCADA supplier my take on this may be different from that of the end user, of-course. To sell to a customer using brand/model X of PLC we need to have a driver for that PLC. We can't write one unless the protocol is open, so we either use OPC which is usually a chargeable extra from the manufacturer (and slower than a
native driver would be), or talk through some other software layer (eg AB's RSLinx - again a chargeable extra and unlikely to be as fast as a
native driver). Where a "standard" protocol is used, eg modbus, it is very common to find that it is a new variation (I'll avoid saying
"incorrect implementation") of modbus which nobody else is using, so we're back to square one anyway. From my perspective, as a support
engineer, the other thing that a documented protocol gives you is the ability to debug problems - it's all very well being given a byte
level trace of comms if you have no idea what it should look like.

Now, if the manufacturer of the PLC also sells a SCADA of some type then there is a clear commercial advantage to them in all of the above
scenario. Since we are all in this, at the end of the day, to make a living, this can and will only change if end users insist on changes. If using an open or standard protocol meant more PLC sales then it would happen, but there is no evidence that this is the case.]

My apologies for the indiscriminate use of the word "open" in the above, by the way, since we all know how many different ways that can be interpreted.

Mark
 
R

Ralph Mackiewicz

> What I see is OPC sitting in front of the various controls
> network protocols like Modbus. MMS doesn't seem to have a place. It
> just doesn't make sense to put it behind the OPC server and it isn't
> adding value in front of it.

MMS' place in an OPC world is exactly like that of Modbus. Here is the scenario: you have a MMS/UCA based device that you want to connect to an HMI/SCADA system on Windows NT. The HMI/SCADA supports OPC. You use a MMS/UCA OPC server to connect the HMI/SCADA to the device.

I will restate this again: OPC is not a replacement for MMS (or Modbus) and MMS (or Modbus) is not a replacement for OPC. OPC is an
application programming interface. MMS and Modbus are application layer protocols. When Windows is the only O/S and every device manufactured has an OPC server supporting DCOM built into it, then
neither Modbus nor MMS will be needed. I don't think it is snowing outside the devil's house yet.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
R
Peter Placek wrote:

> Dear Tassos,
>
> It is very hard to answer your question. I am afraid there is no
> clear answer. We can ask similar question: "Why people all
> around the world do not speak the same language? It would be
> so much easier!" We are probably just of the nature.
>

Cannot totaly agree. Firstly many protocols have different characteristics for different requirements. CAN goes short distances, but with tightly controlled timing. Profibus DP is easy, but costly and not scaleable.

Then there are hardware constrainsts, adding a ethernet controller and TCP/IP stack to a little microcontroller based temperature regulator would up the cost 4 fold as well as increasing size and power consuption wheras MODBUS, by contrast,
is ideally suited to such a task and is freely implementable without costly licences and/or
association fees.

Then there are the manufacturers. Everybody makes products that conform to a 'standard'. Of course what they really do is just take what they have always done and create an 'independent open standards body' to promote it. Well OK, that last remark is a bit cynical, but you have to admit there is a bit of truth in it as well;-)

Have you ever asked yourself 'why do we not all drive the same standard type of automobile', 4 door sedan, 5 seats, standard sized boot that takes a standard set of luggage.......

>
> But instead of trying to answer your question, more
> important might be to find a solution. There is several
> activities and groups around, but I believe more successful one
> is OPC Foundation. The OPC communication has become
> quite common in industry automation lately, providing connection
> among all protocols you mentioned.

Nearly all OPC applications I have seen do not replace these protocols, it simply sticks a wrapper on top, often superfluous and often with
very expensive price tags.

IF OPC is a solution I am bewielderd! Indeed the OPC foundation has left me perplexed, as has the whole OLE>ActiveX->DCOM caboodle.

When OPC started out (around '95) there was much enthusiasm and jubilation, and everybody talked about common standard access to peripherals and WinCE and embedded NT, I spent hours drooling over the WinCE developers CD......

Well, WinCE has been radically reincarnated 3 times now, each time being rationalised in the direction of embedded consumer products (TV set top boxes, PDA's, cellphones etc.). This enormous market is what MS is really after, and we industrialists are left with something that is not at all suitable for e.g. a DIN rail mounted active gateway.

As for embedded NT4.........They never got round to finishing many common desktop requirements such as USB scanners before they embarked on W2K, and now the process starts over. I have never seen any serious effort on the part of Redmond to make a decent embeddable version of NT (like something that can be used without a disk drive
etc), and given that they have their hands full with W2K, which they must now port to 64 bits
for the new Intel processors......well, frankly, I am not holding my breath.

This is serious for OPC, which nowdays does little more than define DCOM calls, because the DCOM technology they use only works (too all intents and purposes) on windows. And yet MS are making no effort to make a windows suitable for
industrial appliances.

What happens in pratice is that I must interface my PLC, axis controller, whatever, to a PC running NT4 using Profibus, MODBUS, whatever, and then access the NT4 machine via DCOM from e.g. my EXCEL spreadsheet (and pay a hefty license for
the DCOM server software I require on the NT box). Of course if I do not want headaches I will be running all this under an NT domain so at least one NT box on the network must be an NT server with a $2000 price tag and a MCSE to configure it. Then in the not too distant future I find I have to upgrade all this to W2K, but to do that need to upgrade the hardware.............

This is absurd. An ever increasing amount of industrial hardware is capable of supporting
ethernet interfaces with TCP/IP stacks, and I can buy miniature flash based industrial PC modules for a few 100 dollars which will run the Datalight embedded DOS with TCP/IP (around $30 license fee). I can communicate directly with such devices with a few lines of VB script in my EXCEL spreadsheet, or just use the object supplied by the manufacturer. I do not need this DCOM caboodle in the middle, although I can optionally route my TCP/IP communications into a DCOM server if that IS appropriate, and be no worse off.

For VB scripting cynics out there, take a look at the MSDN VB entry for WinSock, there is a ready made example that demonstrates how easy it is to send messages between two programs over a TCP/IP network. Allthough this example uses two VB programs, one side could just as easily be a 'SENDTCPMESSAGE' command in a PLC program.

Of course what is missing is the format of the message to be sent. Allthougth in many cases
ad hoc messaging is quite adequate, in order to facilitate messaging between off the shelf
products it is much simpler if standardised profiles are available.

This is basicly what OPC are doing nowdays, they are defining formats for the interchange of data, not the actual communications protocol themselves. IF they were a serious independent standards group (as they claim to be), they could design these message formats such that they could be sent over basic TCP/IP message streams (i.e direct to a PLC etc), OR be encapsulated in a DCOM object (or a DLL or CORBA object) as appropriate. Instead they insist on DCOM objects that are so intertwined with the Win32 API it is
unlikely that they will ever break free.

Now they are moving onto higher things, XML for the standard interchange of intelligent data. XML is also an open interoperable standard, but I will be little suprised if the OPC XML implementations are only actually capable of being used in conjunction with office 2000.
 
C
Hi Roger and all.

I quite agree on your views on OPC and especially the facade of openness that is put upon the whole business. Kinda like calling black white and overcoming objections through massive and pervasive marketing. What I don't understand
is the resistance to real open protocols and this fierce, rabid, Windows everywhere and nothing but Windows concensus in the automation market. It
seems as if no technical argument can stand this "Windows at any cost" mindset. So many of the incompatibilities and problems could be overcome by examining the example of the Internet, universal, ubiquitous exchange of data with high
reliability and incredible ease in comparison to the exixting state of the art in this market sector. I agree that ethernet is not the solution to all problems, but it would be a good start if and only if the mistake of proliferation of proprietry protocols can be avoided. The cost of silicon for Ethernet is diminishing rapidly
and licensing costs can be eliminated by using any of the Open Source stacks that are widely available. If people can build and sell NICs for $9.00 it should be competitive with even serial hardware at reasonable volumes. If one was to listen to the "experts" in the automation field, the problems with ethernet and TCP/IP are so severe that the Internet is absolutely impossible,
there would be no data left after traversing all those unreliable, non-deterministic links :^)
What drives this denial and rejection of the obvious? What makes people so desperate to implement automation and process control on systems known to be unreliable and invent new private protocols instead of even attempting to
use what's already available? What form of the Stockholm Syndrome is it, that makes people so fiercely defend the vendor who is responsible for so many of the problems and service calls that really have nothing to do with the actual
automation and controls work performed? On these platforms, even if I make the most perfect product, there will be goodwill lost that's beyond my control. Yet the next product will absolutely, without question, use that platform?
Why do people in this industry reject, out of hand, efforts to improve their lot by opening and commoditizing the very things that they fight with and complain about the most, often with a vehemance and closed mindedness reserved for
religious issues and other articles of faith?

This is a very curious and counterintuitive phenomena and as someone who is interested in providing alternatives, I seek to understand it. Is it fear?, Money? Is absolute conformance and universality _that_ important that so many will
persue it at any cost? It boggles the mind if you look at it with any degree of detachment. What is the essence of this attitude and what causes it? Why are people so reluctant to talk about the reasons and rationale? Why is proprietary good?


Regards

Curt Wuollet, Owner
Wide Open Technologies
 
M
>So many of the incompatibilities and problems could be overcome by examining
>the example of the Internet, universal, ubiquitous exchange of data with high
>reliability and incredible ease in comparison to the exixting state of the
>art in
>this market sector.

We're probably too late. It seems that most people attribute internet communications to the 'fact' that all the computers run one operating system.

Mark
 
J
Hi Curt!

I will take a try at responding to some of these issues:

I think that part of it is that the automation and IT industries are no longer made up of the 'geeks of old', so to speak. The way I put it to people is that "I was a geek before it was cool'.

Those of us that were writing assembler programs on our Commodore 64 oh-so-long-ago are by nature out of the mainstream. we were the ones that usually ate at the lunch table by ourselves with our noses buried in the apple II programmers
reference. And we liked it that way! We did not want to be bothered by the peer issues of the mainstream.

(trying to keep flames to a minimum, realize that I do not mean everyone, just some people.)

Many of the new automation engineers and (especially) IT staffers do not remember the world before windows. If I go upstairs to the
computer room right now and ask the 3 people in there what they know about the "Trash-80 coco 2", I would get a blank stare. They literally would be unable to even translate that into the correct
model name. And forget about file redirection. I spent about 1/2 hour explaining redirection at a DOS prompt once.

These groups of people got into it after windows was dominant. And since they came to it after it was cool, they are squeamish about going outside the accepted boundaries. Their comfort zone
is smaller.

Also, as more business managers get involved, they have even less understanding of what is out there. All they know is windows. And this is because they go to best buy, circuit city, Wal-Mart, or whatever other chain store, and that is what they see.

For those of us that remember the "holy wars" of Commodore vs. Apple II vs. PC-compat., it is easy to get the concept that if you don't like one product, you just switch to the other. For those that have grown up on only a single platform, there is literally nothing else out there. They cannot accept that there is a viable alternative
to windows.

I am the same way on some things, and I am sure you have some things that people consider "quirks". I still keep track of all of my
project notes in bound journals, using a pencil. I realize that there is software out there that is better. I realize that there are a
thousand and one arguments for making all of my notes electronically rather than on paper. I still do it because when I developed the habit, there wasn't any viable alternative.

Likewise, Microsoft is their habit. It is all they are comfortable with.

In fairness, Windows does have redeeming value: It is VERY easy to set up. I have computers that cannot run Linux because of hard drive sizing issues, monitor incompatibilities, video and network drivers, etc. But they run windows as well as any other machine. MS has a very simple interface for the user. When I set up a
database and file server, I used NT 4.0 SP6. Not because it was my preference, but because I needed it up that day, and Linux would have taken longer to get drivers and such ready, install,
compiled, etc. (Note: I am in the process of migrating :^} )

This 'ease of use' is the biggest driver. Since everyone has less time to do more stuff, we like to grab something that we can slap into place, and deal with minor issues as they arise. I have never gotten a bit of argument when my server is offline, as I just say "Windows crashed. It will be back up in about 15 minutes". All the suits just smile and say "Oh. OK. Let us know when it is ready".

Since there is the windows buy in on ease of use, everything else comes part-and-parcel. Don't like what MS did to Netscape? Still want windows? Then you compromise your principles and fire up IE.

Translate that to the automation world, and you have AB/Rockwell. Nobody has ever told me that they thought AB was price competitive. Nobody has ever accused AB of having the latest technology. They are usually a step behind and twice the price. But they are "standard". Many, many, many places spec it, just because that is what they are used to. And again, you get what they offer as a package deal.

I will stop here, as I could end up writing a book if I get going... All responses are welcome, provided that they are thought out and
civilized.

--Joe Jansen
 
I

Ing. Pietro F. Maggi

> Cannot totaly agree. Firstly many protocols have different characteristics
> for different requirements. CAN goes short distances, but with tightly
> controlled timing. Profibus DP is easy, but costly and not scaleable.

Just curious, what do you mean with the statement that CAN has a tightly controlled timing?
CAN is an event based protocoll with an automatic collision detection that can prevent a message object to be trasmitted if there is an higher priority m.o. waiting. With CAN you can just have best case or average case timing, (as I know it ;^).
Another point, is the short distance of CAN link...
Simply speaking, the max distance of a link comes from the link length, you can only get 40m for 1Mbit/s, but you can get 500m with 125Kbit/s and even 1000 with 50Kbit/s. And this without repeater.

With ProfibusDP you can obtain a maximum link of 9600m with 93.75Kbit/s AND 7 repeater.

> Then there are hardware constrainsts, adding a ethernet controller and
TCP/IP
> stack to a little microcontroller based temperature regulator would up the
cost
> 4 fold as well as increasing size and power consuption wheras MODBUS, by contrast,
> is ideally
> suited to such a task and is freely implementable without costly
licencesand/or
> association fees.

I agree that ethernet is not the right choice, but I think that, actually, we have to much "standard" link available. Even if you choose an low level bus as CAN then you have multiple choice for the higher Layer (CANOpen and all the family).

> Then there are the manufacturers. Everybody makes products that conform to
> a 'standard'. Of course what they really do is just take what they have always
> done and create an 'independent open standards body' to promote it. Well
> OK, that last remark is a bit cynical, but you have to admit thier is a bit
> of truth in it as well;-)
>
> Have you ever asked yourself 'why do we not all drive the same
> standard type of automobile', 4 door sedan, 5 seats, standard
> sized boot that takes a standard set of luggage.......
>

If the manufacturer create a products with an "open standard" you are lucky... even try to communicate with a Siemens S7/200 using PPI? ;-P

Best Regards

Pietro F. Maggi
http://www.studiomaggi.com/ p.maggi AT studiomaggi DOT com
 
Top