OPC and Modbus/TCP

G

Thread Starter

G.Lexau

I've worked with Modbus/TCP for a while, and I think it's very easy to implement in most control applications where I need a robust link for my data from one controller to another (or between PC's). I've also tried different OPC servers and client programs(Scada), and have had some bad experience with them. The main problem have been that either the server or client program have been 'shut down' or 'locked/frozen' by the OS (Windows is the worst one). I have a great need to supply my costumers with a large MTBF number.
When I ask the OPC-Client/Server sales personell about the stability of their products, they of course say it's 'the state of the art' and that the OPC is built on 'proven software technology' and Standards. When I talk to the technicians (of the same suppliers) they tell me that OPC is 'not yet' fully accomplished as 'Standard' and some of them prefer that I use Modbus/TCP for connection to peripher equipment for collection of data for instance from one of their server software.
I've tried this, and it seems to be correct in most cases.
My question is therefore (finally) this :
What is your experience as users or suppliers in the issue of Modbus/tcp versus OPC for transportation of data between different systems?
 
M
Just a note - MTBF does not apply to software - because it does not deteriorate and fail over time (hardware does). Even though software seems to fail "out of the blue", it is probably a design bug that will manifest itself forever.

Meir
 
C

Curt Wuollet

If you have the need to communicate with "different" systems, Modbus/TCP would seem to be the better choice. If you have the need to communicate with Microsoft systems, OPC is pretty much mandatory. As far as reliability goes, why wouldn't you trust your own observations? On this list we have the five people who have never had problems with MS products, and I'm sure they will give you the same message as the vendors. Why would you ever want to be at the mercy of vendors that obviously wish to ignore your issues and deny your experience? It's a very lonely and heartrending experience to be between a customer who knows there is a problem and a vendor who insists there isn't, and watch all goodwill melt away while you are powerless to remedy it. I've been there, many times, when I was stuck using closed systems. This is, in fact, the biggest reason I am an "OSS zealot". I can _always_ do something.
I would use the MB/TCP wherever possible, preferably with Open Source Software that I can debug and fix if there is an issue. You will find many cases where OPC is your only choice. I suggest a "no bid" or language in the contract that disclaims reliability of shrinkwrap beyond your control. It won't keep your customer from getting angry, but it might keep you from getting sued. It's not the OPC, per se, it's the environment around it. You know up front how that all works.

Regards

cww
 
I used to build the clients application for my custmers using different OPC server types and everything works perfect (I didn't get any problem so far).

Also I used to work with MODBUS/TCP - ! remember which it is just a communication protocol - I would say again without any problems.

Regards
 
J
Like you I have experience of both OPC and Modbus/TCP, albeit slightly different. First of all I would like to point out that Modbus/TCP (and other industrial Ethernet solutions such as FOUNDATION(tm) Ethernet (HSE)) and OPC
are complementing each other rather than competing one versus the other. The application areas are slightly different:

Modbus/TCP (and other industrial Ethernet solutions such as FOUNDATION(tm) Ethernet (HSE)):
+ Modbus/TCP is ideal for closed loops and interlock communication between controllers
- Modbus/TCP is not the best choice for communications between software applications or between computers. Why? Because the simplicity of Modbus/TCP come at the expense of a lack of standard data types and a logical object structure. Modbus breaks down data to the lowest possible denominator. That is why it can go anywhere, but once it gets there it takes a lot of user configuration effort to map Modbus registers back into parameter names and group them logically in objects and sorting out what all the data types are supposed to be after all has been converter to Modbus words. For a few parameters it is viable, but with the large amount of information available in modern systems it doesn't fly.

OPC:
+ OPC is ideal within the Windows environment to take data from your I/O server to other applications such as graphics, trend, soft alarms, auto tuning, advanced control, statistical process control etc. regardless if the applications are executing on the same or different computers. Why? Because you can "see" what information is available in the server and simply point and click to get it, no data mapping. This saves you tremendous amounts of
time.
- OPC is not the best choice for closed loops and interlock communication between controllers. Why? It is not completely real-time or deterministic.

So depending on the application use one or the other.

Though I must agree that Windows 95 and 98 are more unreliable than just about any product ever released (personal opinion of course), I must also say that Windows 2000 is extremely solid and I cannot say that it is causing any trouble. We use Windows NT4 and 2000 in plenty of installations and it just runs and runs. I have also come across bad implementations of OPC clients and servers, particularly in the early days of OPC. Using Windows does not mean you are forced to use OPC. You can use Modbus/TCP between two Windows machines easily. Crashed OPC products are usually due to memory leaks due to software bugs in the client or server. Server shutdown is a common "problem". Server shutdown is a correct behavior when no client is accessing the server. Users get irritated with the long startup time as the server reestablishes communication, users see this as a failure. The solution is either to run the server as a NT service or permanently run a client in the background that is always on, thus ensuring the server does not shut down.

OPC is not a "standard", it is an open specification based on an ubiquitous infrastructure (DCOM) so from that perspective they are wrong. However, with probably many thousands of instances running of hundreds of products from scores of manufactures for many years around the world in basically every possible application you must agree that OPC is indeed a very proven technology.

OPC is not an IEC standard and I don't think they strive to be. Is OPC working? Definitely. Has the development stopped with version 3.0? Definitely not. And I agree as explained above that for connecting hardware to hardware you use e.g. Modbus/TCP. OPC is used for software to software.

It is not one versus the other. Modbus and OPC complement each other. For connecting hardware to hardware you use e.g. Modbus/TCP. OPC is used for software to software.

To know more on where to apply Fieldbus, Ethernet, or OPC take a look at chapter 5 of the book "Fieldbuses for Process Control: Engineering, Operation, and Maintenance" (buy online in hardcopy or download immediately in softcopy):
http://www.isa.org/fieldbuses

If you can't buy the book now, you can download chapter 1 (overview) for free in softcopy form. It's free, but you must register an account. If your email does not support this hyperlink feature correctly, please copy the entire link and paste it into your Internet browser. Mind the line wrap, make sure to get the complete path all the way to the 4585:
http://www.isa.org/Template.cfm?Sec...=/Ecommerce/ProductDisplay.cfm&ProductID=4585

Jonas Berge
SMAR
==================
[email protected]
http://www.smar.com
Learn Fieldbus at your own pace: http://www.isa.org/fieldbuses
 
Hi,

The last post on this discution was dated back to 2004. I wounder if there is any update on this issue.
 
Top