DDE

B

Thread Starter

Brian P

I have recently learned a lot (or a little) about DDE because we are considering using a DDE server to access plc data. I have heard and read about various characteristics of DDE. Most of them I can understand. But I am not sure if there is any evidence to back up some of these claims, listed below. Can anyone help shed some light?

1) I thought DDE was pretty slick because of the drag and drop ability where you can drop an application/topic/item address into a cell. But I was told it is not possible to write to a DDE item from an Excel cell without using VBA Macros and adding custom buttons. Is this the case, or if I change the value in the same cell that's updating - will this be written to the plc?

2) DDE is difficult to use over a network, setting up shares is messy, etc., and anyway it's only possible via NetDDE, AdvancedDDE or FastDDE.

3) Throughput is very slow, because DDE is limited to 1 data item per request. Any hard figures on this?

4) DDE is a very heavy consumer of system resources, especially for large numbers of tags. I have been told that OPC would be better here.

5) DDE is unreliable, again especially for large numbers of tags. Again, I have been told that OPC would be better here.

6) DDE server cannot be accessed simultaneously by several client applications.

Are the above 6 points true? If so, why? If not, why not?

Thanks in advance.
 
M

Michael Batchelor

> 1) ...VBA Macros and adding custom buttons. Is this the case, or if I change the value in the same cell that's updating - will this be written to the plc? <

Will this be written to the PLC? Depends on how you have DDE set up. Maybe, maybe not. If you're using Excel as the client you will need a whole bunch of VBA code, but you won't necessarily need a "button" if you do the code right. I wouldn't do it this way, but it can be done. The fact that's it's "possible" doesn't make it a good idea.

> 2) DDE is difficult to use over a network, setting up shares is messy, etc., and anyway it's only possible via NetDDE, AdvancedDDE or FastDDE. <

NetDDE is messy, OPC is messy, network security in general is messy. You will *NOT* get a secure implementation without messy, no matter what you use, NetDDE, OPC, Corba, whatever. Once you hook up that CAT5 cable, things get messy if you need secure. Period.

> 3) Throughput is very slow, because DDE is limited to 1 data item per request. Any hard figures on this? <

50 items, 50 DDE links. No way around it. Yes, it's slow. But it's over 10 years old for crying out loud. In computer terms that's dinosaur age.

> 4) DDE is a very heavy consumer of system resources, especially for large numbers of tags. I have been told that OPC would be better here. <

True. In fact, OPC would be better for a single tag. DDE is essentially obsolete. That's not to say that there aren't boatloads of older DDE applications out there still clicking away. And without a compelling financial reason to change them, they'll stay there. But I certainly wouldn't put in a new one today.

> 5) DDE is unreliable, again especially for large numbers of tags. Again, I have been told that OPC would be better here. <

True.

> 6) DDE server cannot be accessed simultaneously by several client applications. <

Not true. One DDE server can service multiple clients, but it takes a performance hit. But so does OPC. *ANY* program that has to handle multiple clients has more work to do than the same program handling a single client. DDE just scales poorly compared to OPC.

OPC is the modern "descendant" of DDE, not some strange new animal. All of DDE and NetDDE genes are contained deep in the bowels of OPC. Think of it like this, a modern Ford (or GM or take your pick of car companies) Delivery Van is a descendant of a 1935 Ford V-8 Panel Van. I certainly wouldn't use a 1930's panel van for a delivery route I'm
starting up today. That doesn't make the 1930's van "bad" per se. It's just not a great choice for a modern implementation. If you were stuck somewhere and a 1930's van was all you had, then go for it. But if you get a choice, use a modern tool unless you're trying to start a museum. A modern van still has an engine, a transmission, ya-da, ya-da, ya-da, but it's certainly not the same old car.

Like I said above, some applications still exist. I know where one DDE application I put in a decade ago (originally on Windows 3.1, written with VB 3.0, now rolled up to WinNT 3.51!!!) still sits. I won't go back
and touch it, but the guy is content, and it still works. (At least it did the last time I was there.) It's his plant, and it ain't broke. But I wouldn't put it in today.

Michael

--
Michael R. Batchelor

www.ind-info.com/training/Schedule.pdf
 
F

Fred Loveless

As the Support Manager at a major OPC/DDE Communicaitons Product developer we get this question all the time. Let me see if I can explain the Pro's and many Con's of using DDE.

First, you should know that Microsoft is doing away with support for DDE in any product created after 2003. The products might have legace support but you will probably get none if you call Microsoft with a question about DDE.

So why is this you ask?

DDE is 1986 technolog and it is a resource hog. If you are going more then a couple of hundred items you performance will decrease dramatically. OLE for Microsoft and OPC for the Automation Industry replace DDE and NetDDE. Most manufacrures still support DDE, Advnaced DDE(Rocwell) and FastDDE/Suitelink(Wonderware) but all support OPC as well and push customers to this technology. As OPC foundation members we do this to promote an off the shelf standard for Client Server connectivity.

So let me answer some of your questions now.

1. If you are using Excel you have to create Macro's to Poke the data back to the DDE Server. There is no way around this. You can configure objects in a regular VB application to write back when you change the data in them but not in Excel.

2. Yes DDE is difficult to use over a network and because Microsoft is discontinuing support for it they make it even harder on newer OS's for XP and Win2003 you have to create exceptions in your fire wall for it. There are less issue with Suitelink and I have not heard of anyone using AdvancedDDE for quite awhile as Rockwell is very embedded in OPC technology.

3. Yes Throughput is very slow. DDE is synchronous so there must be a response to every DDE request whether the data has changed or not. AdvancedDDE and FastDDE use a sigle link for all the data and have improved throughput a bit but I feel that overall OPC is better at this point.

4. Yes DDE is a very heavy on system resource use. Each DDE link can consume as much as 20-40 KB of RAM. Mostly because the transfer is all ASCII and every DDE Link Is updated regardless of data change.

OPC is much better in resource management. by defualt data is reported back when it changes only and OPC uses a Mutli Threaded Apartment Model. Suffice it to say that you can process a significantly larger amount of data to more clients then with DDE.

5. Again this is correct. Because OPC is designed for the Automation Industry it has built in methods for error handling and reporting between the client server. This does not exist in DDE.

6. This depends upon the DDE application but most DDE Servers can support multiple client connections. The problem is resources management. Every DDE link is treated as an individual request in most DDE Servers so that means that the servers requests to the devices can be doubled or trebled, and since they are seperate each client could get different data. In OPC is you have serveral clients that are subscribed and getting from the same item at the same rate the the OPC servers will make one request to the device and update all the cleints at the same time.

Hopefully this answers all the questions here. If not you can contact the OPC Foundation or any of its member companies for information.

This information is provided by the Members of Kepware Technologies Technical Support Team.
 
Top