Hello all. New here, and to control in general, and find this site quite informative!

Looking at creating my first "real" control network. I'm primarily responsible for the HMI, which I'd like to do in .NET (winforms, possible Flash UI, potential to do remote monitoring over the WWW). This is not just an industrial app - this thing has to look sharp.

The .NET stuff I can handle. In the past I've worked with Modbus over serial (RS-485), but now want to move onto "industrial ethernet". Will be communiting with some PLCs and some custom data acquisition hardware (which will also have to support whatever protocols we choose). I'm a little concerned about the .NET app talking to the network, and wondering if someone can share their experiences/advice.

I'm assuming the easiest thing I could do is implement Modbus/TCP, but true "industrial ethernet" seems to be so much more...

The root of Ethernet/IP seems to be this "Control and Information Protocol" (CIP) over TCP/UDP/IP. I assume that at a minimum, I could do standard TCP socket stuff (or UDP) in .NET and interpret the packets based on CIP, thus creating my own Application Layer (a la OSI)? Do I really need to pay the money to get this CIP spec, or are there libraries available (I'd sooner pay for libraries if they exist)?

We're also looking at ProfiNET, which seems to sit on top of CIP. Same question: do I have to pay to get the ProfiNET spec, or are there libraries available? I assume ProfiNET would hide the CIP details. Also, with ProfiNET, would I be needlessly limiting myself to Siemens gear (I know ProfiNET is "open", but it seems to be mostly Siemens)?

Thanks for reading all that. Hopefully someone had a similar experience and help me figure this stuff out - there only seems to be bits and pieces of this information available. Feel free to email me (or post here) if you have any specific questions about what I tried to explain here.

Thanks all!!

Derrick

 

I would look into libraries/drivers from Cimquest or Automated Solutions. They could make your project a bit easier.

Bill Sturm

 

Hi,

No, the easiest thing you could do, especially with Siemens, (the others will catch up!) is to use a CP module (X43-IT). if you can create sharp web pages, then you can use this. Don't get bogged down with all the layers, if you're using the internet then eventually your data will end up in a Tratvian Telecom rack that got accidentally unplugged, so your QOS is as good as the weakest link.

The downside is that you may need to use Java, and as we know -

'Java technology is not fault tolerant and is not designed, manufactured, or intended for use or resale as on-line control equipment in hazardous environments requiring fail-safe performance, such as in the operation of nuclear facilities, aircraft navigation or communication systems, air traffic control, direct life support machines , or weapon systems, in which the failure of Java technology could lead directly to death, personal injury, or severe physical or environmental damage'. (from the java licence)

...then again neither is windows.

marc sinclair

There is a CP243-IT on line at http://s7-200.germainesystems.co.uk

 

Hello there,

It sounds to me like you are heading down a path of needless wheel-reinventing. Have you heard of OPC? It should help you hide the complexities of vendor-specific device communication from your app. Kepware is one company that makes OPC servers for a very wide variety of devices.

You also mentioned that you wanted a slick, web deployed interface. You could save yourself the time of writing your own HMI from scratch by looking into Inductive Automation's web deployed HMI/SCADA package, FactoryPMI. Custom programming is a giant maintenance and support headache that you might be wise to avoid.

Good luck,
CG

 

I can't answer all your questions, but I can point out the following. Firstly, you appear to have a misconception regarding the nature of some of the network protocols. Modbus/TCP is a protocol which originated with Modicon (now part of Schneider). Ethernet/IP is a completely different and incompatible protocol from Allen Bradley (Rockwell), and is proprietary. ProfiNET is yet another incompatible proprietary protocol, this time with Siemens being the main vendor. There are still more proprietary protocols by other vendors. None of these are compatible with each other. Most are an extension of their older RS232/RS485/etc. protocols onto Ethernet (but not necessarily by simply tunneling the protocol).

Most of these protocols are centred around a single large vendor, with various smaller vendors providing supporting products (primarily specialty I/O, switches, etc.). Most will claim to be "open", but in fact are completely proprietary. For example, Profinet is tied up with patents to prevent anyone from outside the Profinet "club" from reverse engineering and re-implementing it independently. Modbus/TCP is the closest thing to an "open" Ethernet control protocol that exists in the industrial area.

Another important point to note is that although these protocols may use "Ethernet", that doesn't necessarily mean TCP/IP or UDP. For some of the protocols you may get certain basic features with TCP/IP, but the advanced features require using a special proprietary layer which operates in parallel with TCP/IP. This means that to use all the features you may not be able to use standard network components (e.g. network cards, switches, etc.), but instead have to use that vendor's special (and expensive) hardware. The vendors have adopted Ethernet in order to reduce their component costs, not for the benefit of their customers.

If you have complete freedom to specify the protocol and wish to support only one, then your best bet would be Modbus/TCP. This seems to have the widest selection of third party I/O available.

 

Why are you doing all of this? Do you have an end objective in mind? When you are done what will it look like, what will it be?

 

It would seem that anything but Modbus/TCP would be needlessly limiting yourself to one segment or another. It is the only even arguably, open protocol. Modbus, TCP/IP, UDP and the rest of the IP suite are Open and trusted. Every other name or buzzword (bussword?) you dropped is proprietary and none are open or universal, including .NET which MS may cast by the wayside as they have so many other schemes to take ownership of your data and future. The industrial stuff is less volatile as they will live with their small captive audience and continue to beat their dead horses long after they figure out that just another proprietary protocol is unlikely to set the world on fire and bring gold pouring in. Even if you sully the good name of Ethernet with it. They have missed what MS didn't, you must do the trapping first before you can force people to adapt to your schemes.

I see a time of change, not too far ahead, that would have me cautious to get sucked into any new proprietery schemes as lock-in is forever and the future will require agility and the ability to adapt that is the achilles heel of the status quo. By design, you will be on one side of the change or the other as closed stays closed and dies slowly as Open takes over. There will be a time when we will look at the automation vendors and MS controlling everything with the same disdain as we now look at Bell/ATT controlling all telecommunications. Would you like to go back to only choosing black or pastel? The advance will be staggering as in the case of telecommunications and the Internet. One could well steal a march on their competition by building in the ability to use what comes along and drop what dies. Coding for .NET and embedding any of the fractional protocols pushed by the vendors may well become regrettable decisions.

Regards

cww

 

It might be easier to answer your protocol questions if we knew which specific devices you intend to communicate with.

Automated Solutions offers numerous libraries that can be used in .NET, but just specifying EthernetIP or Modbus/TCP does not provide enough information.

EthernetIP/CIP is object based and supports a vast number of object types, so the driver that you choose must support those object types.

Modbus/TCP is simpler and only specifies about 20 functions. Functional support is specified as class 0, 1, or 2, with most slave devices supporting class 0 & 1. Our master supports class 0, 1, & 2 with the exception of FC24.

You can download fully functioning trial versions of our .NET compatible ActiveX Controls and .NET Components from http://www.automatedsolutions.com.

 

I'm going to save some time by not replying to each individual.

I thank you all for your input. I posted this early in my "research", and I was obviously confused. Things have since become clearer.

We've decided that we don't need to do any real "control", but we should focus more on monitoring and configuration. Modbus/TCP seems like the way for us to go (at least at this point). At the time, I didn't realize how vendor specific the other protocols were - they do a good job of hiding!

I did find OPC after the fact, and it looks great. This may very well find its way into the design.

I am also evaluating some of the HMI suites mentioned. Some look promising, though I need to sort through the details such as licensing and compatability. No, I don't want to reinvent the wheel, but I do have some specific requirements that I need to meet first and foremost.

Thanks again for all your input. It is appreciated, and will all be taken into consideration. Hopefully as I learn more about this stuff, I'll be able to return the favor.

Derrick

 

OPC sounds "nice", in that it can act as a universal driver interface to proprietary protocols. However, it can also be a performance bottle neck. I don't know what your application is, so I don't know if that matters. If you do require fairly rapid updates however, then you need to research and benchmark the OPC software before relying on it. Sometimes you need to avoid using OPC and go direct from your application.

As for industrial MMI software, most of it is intended for "one off" applications where you are willing to limit your requirements to what the software is capable of in order to take advantage of the pre-built functions. Again, you should research it carefully to make sure it does ALL of what you need before relying on it. If you are not careful you can run into problems that have no way around them.

If you are producing a large number of identical units, then the standard industrial MMI software looks less attractive due to licensing costs and long term support problems (you can't support your systems through OS upgrades if the MMI software product is discontinued). Long term support is less of an issue for a "one off", as you could normally replace it with something completely different if necessary. That option looks less attractive though if you are supporting 500 identical units in the field and just want to push out a minor change with minimal impact to the customer.

I am not advising against using OPC or industrial MMI software, I am just pointing out that they have their limitations which you need to take into account.

 

Hello Michael
You've hit the nail right on the head.

To summarize, my project is similar to a "smart home". I plan on having several UI/HMI (whatever you want to call it) screens which monitor data acquired either through a custom piece of hardware or PLC.

To ease the load on the hardware, there will probably be a single computer which directly communicates with the hardware (via Modbus/TCP), and the rest of the HMI clients will talk to this computer (many protocol options here). Because of this server/client approach, OPC may be suited to the application.

As you said, given the number of clients, licensing of HMI software packages is an issue. I also don't want the industrial look & feel that some of these packages seem to have - looking for something a little more "multimedia". So custom software looks more attractive. Then deployment is an issue, but I don't see it as being a big one.

Thanks for your input!!

Derrick

 

Derrick,

If you're going to have a single computer communicating with the hardware via Modbus/TCP and HMI clients spread over the TCP/IP net, SeeThru would be a viable candidate (http://www.tractrola.com). It's lightweight and fast. It does OPC too if you really need it. To make the graphics "look sharp" you could use a graphics package like Paint.net to make/edit the backgrounds, icons, etc. (pro graphics editor but free from Washington State U., http://www.eecs.wsu.edu/paint.net/).

 

That's just Sun covering their rear. Face it, they all run on Windows so how reliable is any HMI anyway?

With web-launched Java you at least can launch it again or on another computer, nearby laptop or whatever.