Industrial Ethernet Implementation

If you want your HMI solution to be compatible with other means of
networking (not just Industrial Ethernet, but maybe serial or anything else
you can think of) I would suggest the OPC path.  Your HMI is then an OPC
Client and you can buy an OPC Server package 'off-the-shelf' for whatever
protocol or comms system you want to use (IE, Profinet, Modbus/TCP, etc.
etc.) - that way you don't have to program anything other than your HMI, it
is all just configuration.

As far as the choice of protocol goes, that is entirely up to you.  All of
the Industrial Ethernet protocols are still in their infancy and have a lot
of implemetation issues yet to be worked out (some are worse than others),
so just choose a brand and go for it - I would suggest Modbus/TCP for the
beginner.

If you have any specific questions, this is Usenet - post away. :-)

Cameron:-)

Cameron Dorrough wrote:


Just to back up what Cameron just said.  I'm using CIP based protocols
at the moment and it really doesn't extend much past
Allen-Bradley/Rockwell Automation type products and those that wish to
communicate to them.  So unless you are forced to use a ControlLogix or
other type of PLC that uses CIP natively I would use OPC, Modbus, DNP
V3 and IEC 60870-5-101.

If you want to remotely monitor your system over the internet I would
probably use the .net framework (since your using it anyway) to create
xml or html pages from your hmi and publish them using a web server.
Then you can just use a browser to view the hmi.

If you are really lucky, you may be able to get Triangle Microworks to
provide you with the source code or a compiled library containing one
of these protocols stacks.  It will integrate directly into the .net
framework.  Tell them it is for a university (or whatever) project and
you'll give them some free publicity at your school/university for
educational use of the stack.

Gadz

Thanks for the input Gadz.

No, we're not "locked in" to a particular PLC product.  We initially
started looking at which protocols would provide the level of service
we wanted to provide and then choose hardware based on that (ethernet
was the only requirement provided), but that quickly turned into an
excersise in futility.  Now we're looking at hardware first.  I guess
there's a reason everyone does it that way :)

We decided on the .NET framework for a couple of reasons.  One is the
remote monitoring.  Another is rapid UI development, and the ability to
create "rich" UIs (I don't want this to look like an industrial HMI).
Plus, that's where my experience lies - I'm a Computer Engineer, not a
Control Engineer, though I'm trying :)

I haven't come across Triangle Microworks yet.  I'm going to
investigate right now!

Thanks again,

Derrick

Thanks Cameron - very helpful indeed!!

I was able to find a couple of good articles on CodeProject.com about
OPC, and basically came up with the same answer as you provided.  Nice
to have confirmation from someone who knows better though :)

I'm new to this control stuff (though I've always wanted to do this
kind of work and am fascinated by it), and it seems my first obstacle
is one that has plagued the industry for years - every vendor seems to
use their own protocol (even if it isn't "proprietary").

Your post does provoke one question though.  I've looked at some
commercial OPC servers, but they all seem to be targeting specific
hardware, not a protocol like you indicate.  I still have to do some
digging, but if I find a server which supports ProfiNET for example,
won't I still have to customize/configure that server to talk to my
specific hardware?  That's OK - I'd prefer that route as opposed to
purchasing a server which is only compatible with a single piece of
hardware (which would be a net gain of 0, IMO)

We are still evaluating which PLCs to use, and as you mention
Modbus/TCP seems to be the recurring theme.  I have experience with
Modbus/RTU anyway, so this would be pretty straight forward.  We are
also considering using some custom hardware, so it would be
easier/faster/cheaper to implement Modbus on that as well instead of
trying to make it speak ProfiNET or CIP.

Finally, at this point in time we will be developing a closed system
(i.e., 3rd parties will not have to communicate with our product).  As
such, strict adherence to OPC is probably not a requirement.  I'm
tempted to not purchase an OPC server, but rather create my own that is
loosely based on the OPC architecture and chalk it up as a learning
experience (i have plenty of time to develop).  It should then be
fairly straight forward to migrate to a fully OPC compliant interface
should the need arise.

Thanks again!!

Derrick

Generically speaking Ethernet can have problems depending on your
environment.
Medium voltage can drive it nuts. (from experience)  Consider the "grounded"
Ethernet connectors and devices.  I have had some good luck with it.
Mikerowesoft can be  seconds behind any real data.

My experience stems from WW, Iconics and Intellision.  There is a company
called Data Trax that
I worked around in another life. Rumor has it Eaton bought the parent
company.
Data Trax has the I/O already hammered out. Might be worth a look see. Not
that you want to purchase what they have. Just ideas as to what they do.
Everything I worked on with them was solid. I suggested that CH look into a
collaboration. They ignored me at the time.
They had the remote notification stuff knocked, 7 years ago.

Just an opinion from an ex-field automation engineer.

Thanks SQLit.

I'm actually expecting Ethernet to cause a bunch of problems, but it's
a requirement I have to work around.  This system is supposed to work
in a marine environment - lack of real "ground" and high EMI - so it
should be a real challenge.  I will definately be using at least
shielded cables/connectors (possibly up to IP67), and possibly fibre
wherever I can.  All short lengths, so the plastic fibre obtics (HCS?)
is probably the way to go.

As an aside, the real "control", for the most part, may not be done
over ethernet - there is potential to use other buses between the
controller and the device/io.  The ethernet is primarily for the HMI
(config & monitoring).  I'm OK with that being *a little* slow.  The
reason for going with Microsoft is so we can standardize on development
- as mentioned, we also want to do web and looking at some Pocket PC
interfaces too.  We have a very small development team (2 people!), and
think it would be less efficient to be switching between tools &
languages.  Though if performance becomes an issue, we'll see...

Thanks again.  I'll look into the companies you mentioned!

Derrick