In all this discussion it has not yet been pointed out that stock ethernet (CSMA-CD) is not particularly good for realtime applications because it isn't deterministic in itself. (Tho it is possible to layer determinism over the base transport at the application level). And this is one reason for the very slow uptake of ethernet and TCP/IP. Another reason is the very high
overhead of TCP/IP and UDP/IP vs the other fieldbus protocols. TCP over ethernet wastes well over 50 bytes per packet, much of it redundantly. If you are sending a bunch of 1 byte register values, this efficiency is woefull. Profibus has about 12 bytes and CanBus 11 - 22 bits (1.5-3) bytes but being partially TDM has severe length restrictions. This means that for single byte packets (theoretically) 1 Mbit/S CAN (2.5 bytes) is as fast as 8 Mbit/s Profibus (13 bytes) which is as fast as maybe 35Mbit/Sec TCP/IP over
ethernet (@ 51 bytes). By the time you layer another protocol such as ModBus over TCP/IP this is probably more like 60 or more.


As for "Openness" this is just related to the availability of information, certain CAN implementations, profibus, and some ethernet based protocols are open, in the sense that the documentation is available to anyone to implement a solution from the ground up. In the balance I have to say that all of these protocols are good for different things. You can buy a chip from Siemens or Profichip which does exactly what the ethernet controller chip does for profibus so that you can implement your own master (or slave)
very cheaply (I have already done this and it is very easy) Siemens even publish the design of the bus interface. There are a bunch of chips from
lots of vendors with CAN controllers in them. You wanna roll your own, go to it.


In the end the choice of fieldbus depends on

Cost sensitivity
Line Length
Required cycle time
Size of the datagrams
Electrical environment (Noise etc)

 

I imagine that the jumper cost GE less than actually having two different hardware designs at the sales volumes they were expecting. Marketing asked for two different models at certain target prices, and this was what the designers came up with. Even if they had actually put a smaller
RAM chip in, it may not have made the PLC significantly cheaper to make. Sometimes the smaller chips cost *more* money, if they are an odd size.

The jumper no doubt sounded like a clever idea at the time. Sometimes though you can be too clever for your own good. When customers find out about things like that, they assume that they are being over-charged for the 8k version. They will of course never assume that they were being under-charged for the 4k version.

This isn't really very unusual when you consider how many software packages come in low and high-end versions. The only difference between them is that the low end versions have some features disabled. Both versions were
compiled from the same source code with only a software "jumper" changed (and sometimes not even that).

What I found surprising is that GE wasn't using the common PLC and robot I/O as a *selling point*. If GE had instead told us that they had
purposely designed the I/O systems of their PLCs and robots to use the same modules, we would have remarked on how clever they were. Instead, they are now being made to look foolish and short sighted.


**********************
Michael Griffin
London, Ont. Canada
**********************

 

> Robert Lunnon wrote:
>
> In all this discussion it has not yet been pointed out that stock ethernet
> (CSMA-CD) is not particularly good for realtime applications because it
> isn't deterministic in itself. (Tho it is possible to layer determinism over
> the base transport at the application level). And this is one reason for the
> very slow uptake of ethernet and TCP/IP.

This is true in a strict sense. Pragmatically, it is fast enough and good
enough for the bulk of applications. When tunnelling existing protocols,
the packet sizes tend to be large enough to mitigate the overhead issue.
It's not a panacea. It is however, fast, very inexpensive, at least until
the vendors finish perverting it, widely understood and already in most
locations and open to the largest extent. I can write to it and use it
with no license hassle or expense and count on it being available for most
any platform. This makes it very important for integration. I attribute
the very slow uptake to the vendors reluctance to implement anything they
can't completely own or control along with the fact that 75% margins will
be hard to achieve with a commodity. Once they have put in a little
mumbo jumbo strictly to proprietize it, It will be ballyhoo'd to the
rafters and people will buy. At that point it will have lost it's value
nearly totally and will be just another option.

Another reason is the very high
> overhead of TCP/IP and UDP/IP vs the other fieldbus protocols. TCP over
> ethernet wastes well over 50 bytes per packet, much of it redundantly. If
> you are sending a bunch of 1 byte register values, this efficiency is
> woefull. Profibus has about 12 bytes and CanBus 11 - 22 bits (1.5-3) bytes
> but being partially TDM has severe length restrictions. This means that for
> single byte packets (theoretically) 1 Mbit/S CAN (2.5 bytes) is as fast as 8
> Mbit/s Profibus (13 bytes) which is as fast as maybe 35Mbit/Sec TCP/IP over
> ethernet (@ 51 bytes). By the time you layer another protocol such as ModBus
> over TCP/IP this is probably more like 60 or more.

CAN is a good option. However, right now the only widespread implimentation
is not much in favor. I would like to see a set of truly open protocols
based on CAN. CAN hardware is pretty rare here. It lacks the volume to get
packaged hardware prices into competition with Ethernet.

> As for "Openness" this is just related to the availability of information,
> certain CAN implementations, profibus, and some ethernet based protocols are
> open, in the sense that the documentation is available to anyone to
> implement a solution from the ground up.

I can't legally write free implementations for any but Ethernet that I know of.
This is a fairly stringent measure of openness, but it's what I need to do.
The fact that a $10,000.00 membership will get me the specs and such is not
remarkably usefull.

In the balance I have to say that
> all of these protocols are good for different things.
Agree here. And the wide area where they overlap, where one would be just
about as good as another, is where dramatic cost savings could be achieved
with commodity Ethernet and TCP/IP.

You can buy a chip
> from Siemens or Profichip which does exactly what the ethernet controller
> chip does for profibus so that you can implement your own master (or slave)
> very cheaply (I have already done this and it is very easy)
I believe you need certification or validation to sell it though. I could be
wrong, but I believe there are substantial barriers yet. I know "open"
devicenet makes it nearly impossible for LPLC to write a software
implementntion. I am certain this could be fixed if significant amounts of
money changed hands.

Siemens even
> publish the design of the bus interface. There are a bunch of chips from
> lots of vendors with CAN controllers in them. You wanna roll your own, go to
> it.
>
> In the end the choice of fieldbus depends on
>
> Cost sensitivity
> Line Length
> Required cycle time
> Size of the datagrams
> Electrical environment (Noise etc)

And in our case openness. The advantage of having a ubiquitous medium that
meets most needs cannot be overstated. Protocols that we can not use for
our operation in the public interest are mostly irrelevent to me. Truly
open protocols would clearly be in everyone's best interest and are much
more likely to grow the fieldbus market than more of the SOS and the lock
in games.

It's not a critical issue however. Unless the greed and averice are less
pervasive than they have been, True Ethernet will never see widespread use
unless people demand it and demand it now. The plethora of proprietary,
incompatible and therefore useless versions are just around the corner.
Sure they will work but will have absolutely no significant advantage
over the way too many other proprietary offerings.

Deming's definition of insanity is when you keep doing the same thing over
and over and expect the results to be different.

Regards

cww

 

> In all this discussion it has not yet been pointed out that stock
> ethernet (CSMA-CD) is not particularly good for realtime applications
> because it isn't deterministic in itself. (Tho it is possible to layer
> determinism over the base transport at the application level). And
> this is one reason for the very slow uptake of ethernet and TCP/IP.
> Another reason is the very high overhead of TCP/IP and UDP/IP vs the
> other fieldbus protocols. TCP over ethernet wastes well over 50 bytes
> per packet, much of it redundantly. If you are sending a bunch of 1
> byte register values, this efficiency is woefull.

I will have to respectfully disagree on several points:

1. Determinism is a red herring. Determinism is colloquially used to
describe the ability to determine the maximum network access time for
a given node on a given network type without having to resort to
statistical/probabilistic means. This does not make something
suitable for realtime by itself. For example, with a token passing
system (e.g. Profibus) that is operating normally you can accurately
predict how long it takes for a token to return to a given node based
on the hold times, slot times, number of nodes, etc. in a very
straightforward manner. Ethernet, on the other hand requires that the
maximum network access time be stated probabilistically (e.g. the
probability of a given node gaining access to the network within x
milliseconds is y) and the equations are more complex. This
probabilistic nature is only relevant if the access time (x) is too
large and/or the probability is too small for a given
application. In fact, Ethernet's network access times have extremely
high probabilities of resolving access in very short periods of time.
Ethernet's probabilistic access method is completely irrelevant for
the vast majority of IA applications including many that would be
termed "real-time" control. Now include some real-life situations
into your real-time system like noise and bit errors. You will soon
find that ALL systems become probabilistic. Ethernet may not be
deterministic but it's raw performance is so large that it makes its
probabilities mostly irrelevant for the vast majority of IA
applications.

2. Wasting 50bytes per packet on a 10-100Mb (or 1-10Gb) network is,
once again, mostly irrelevant for the vast majority of IA
applications. 50 bytes (500+ bits) will take only 50+ microseconds on
a 10Mb network. Profibus was originally concerned with byte
efficiency only because it had to run over 9600 baud serial links.
There are dialog/buffer management issues related to TCP that are
much more significant to control applications than the byte overhead
of either Ethernet or TCP/IP. TCP/IP Ethernet may not be suitable for
every single possible application in IA but it is very suitable for
the majority.

3. I don't think that the uptake of TCP/IP-Ethernet in IA has been
slow. Historically speaking, its uptake seems to be much faster than
that of most other special purpose buses. In 1-2 years every bus out
there, including Profibus, now seems to offer a TCP/IP-Ethernet
option. That's pretty quick compared to the rollout of other
technologies.

Regards,

Ralph Mackiewicz
SISCO, Inc.

 

Hi Ralph,

I would add that very, very, few of the PLC's can even sample the
bus at a rate that would make these resolution times relevent.
Often they take more than one scan to send or recieve a packet
or frame. If you lose every other transition in a 50 hz pulse
train, uncertainty is a much bigger problem than determinism.
With trashy input waveforms and 15ms filtering to compensate,
bus determinism is the least of your timing issues. Put a scope
on many common automation events and you see ringing that exceeds
the times we are talking about by an order of magnitude. We are
talking about very slow devices with exceedingly low temporal
resolution and worrying about errors the equipment couldn't
possibly see. There are other problems relating to heavily loaded
networks but most PLC's simply can't fill a 1mb/sec pipe.

Regards

cww