Industrial Ethernet Implementation

Hi Derrick,

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

Hi Derrick,

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

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

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