Created Date: June 24,2000

Created by: Robert Kennedy

I am using dsDDE and a visual basic program to download data from a DL250. The data download consists of a total of about 5000 V locations. This download takes over an hour to perform. I have also tried it by writing an excel routine to do the same thing in excel...takes about the same time.

Can you suggest anything I can do to either speed up this download...or to communicate directly with the PLC...bypassing dsDDE.

I have about 3 systems in the field now using this download routine...and I have another 4 that I am building right now...I would like to resolve this as my customers find this download time unacceptable and I'm afraid I may have to look at another platform for datalogging.

Created Date: June 24,2000

Created by: Russ

Hi Robert,

Data transfer has a lot of variables that influence performance, but the first question I have is what sort of physical link are you using? If you are using a serial connection at 9600 baud ( the default for port 1 on the PLC ), a transfer rate of 4-6 V words per second is typical in my experience. A faster serial connection or Ethernet module ( the H2-ECOM ) will improve your performance at the physical layer.

There are multiple software layers involved that can also influence how fast data can be transferred too. On the PLC side, you need to watch your scan time, and be aware that communications are influenced by and are part of the scan cycle. See Chapter 3 of the 205 user manual for detailed information. On the PC side, performance is dependent on the speed of your computer and what other tasks are being performed. Some people will probably disagree with me, but I have never had good results with DDE running more than 70 to 100 Vwords concurrently.

The new DSData server now supports OPC ( OLE for Process Control ). OPC communications are much more efficient than DDE and are primarily limited only by the system hardware and the PLC. If you are interested in learning more about OPC performance, the articles at http://www.intellution.com/opchub/opc_interfaces_overview.asp and http://www.intellution.com/opchub/performance.asp gives some OPC background and hard numbers to think about.

You can download a functional demo of the new DSData DDE/OPC server from Host Engineering at http://www.hosteng.com/Download.htm#Upgrades if you are interested in giving OPC a try.

Good luck with your application. If you have any other questions, feel free to ask!

Regards,

Russ O 'Rourke

Created Date: June 26,2000

Created by: Mike McClanahan

I have to agree with what Russ stated. The first and foremost question is what are you using for a communication link. We are using OPC with the DSData server over the ECOM module and we can update 1100 points in less that 5 seconds directly into an Acess Database so I suspect that you are using a serial protocol at maybe 9600 baud. If you are using ethernet and the ECOM module you can get a lot faster downloads.

Created Date: June 26,2000

Created by: franji1

See if this solves your problem...

First, collecting 5000 data points using DDE is no easy task from a PC standpoint. DDE utilizes lots of system memory, which on 95 and 98, is still limited. Don't ask me why, but NT4 does NOT have this problem. I have seen downloads of a thousand points on NT4 with ECOM modules take 30 seconds to download, but crash 95/98 - due to their "16bit O/S " roots, which NT does NOT have. 95 and 98 run "low on system resources " quicker than you can say "Thank you, Mr. Bill! " NT4 is a true 32bit O/S and these system resources are not "limited " like they are in 95 and 98.

Second, instead of using VB or VBA in Excel, just enter the data points as entries in the spreadsheet, e.g. enter into cell A1 something like

=DSData|MyTopic!V2000

Enter all of the data that way.

Excel is "smart " regarding DDE. It sends a special DDE message to the server with a LIST of points (be it 2, 3, or 5000). But VB or VBA in Excel is NOT smart. It requests each point, 1 point at a time. So here's what happens - VB says "give me data for V2000 ", it gets sent across to the DSData server, which queues up a message to the PLC, sends it, waits for a response, and sends the data back to VB. VB then does the 2nd point, "give me data for V2001 ", ... It does this for all 5000 points! No communication optimization, no DDE message optimization.

From an optimization standpoint - VB is SLOW. Excel spreadsheets send the request across as one request, with a list of points. DSData then can optimize the requests. For example, V2000 and V2001 can be read in a single communication request. For VB, this had to be done with 2 requests.

If you have any DDE expertise, Excel uses "XL_TABLE " type DDE message, which is a DDE message optimized for acquiring LISTs of data. If you know how to implement this type of DDE message from VB, PLEASE LET ME KNOW. This is actually a client problem (VB/Excel/InTouch), not a DSData problem, but it is perceived as being as a DSData problem.

Also, due to the protective nature of Win32, our 32bit server has more overhead when acquiring a single point versus our old 16bit server (the price we paid for "stability " versus "speed "). Hence, when multiplied across 5000 points, it can be a big difference. Actually, I don't think our old 16bit server could handle more than a 1000 points, but DSData should be able to handle 5000 points on NT4.

If after implementing these first 2 recommendations, it speeds it up but it is still not fast enough, there is a third thing you can try. Use ECOM modules, not serial ports. You can get AT LEAST 10x the speed using ECOM modules and your PCs Ethernet card. DSData natively supports these, no need writing any special driver code - it just works - and works FAST.

Let me know if any of this helps.

Created Date: June 26,2000

Created by: Tom Jenkins

I don't have any experience with the DirectSoft DDE, but I can tell you that there are much faster ways to communicate than 5,000 values per HOUR. I suspect that overhead (setting up headers, calculating and testing checksums, displaying in Escell's cells, etc.) is taking up most of your time, since using other techniques I routinely get several thousand V registers per MINUTE at 19.2 kBaud.

A couple of suggestions:

1) Group your data so you can read values in blocks rather than one at a time. This minimizes the impact of overhead

2) Consider using Modbus instead of DirectNet. I don't have hard test data, but it seems to be a little faster.

3) Consider using a graphic operator interface program like Lookout to communicate with the PLC. Most of them will log the data either directly in spreadsheet format or as comma separted variable (CSV) format, that you can then pull into a spreadsheet. We have used Wonderware, for example, to log hundreds of points with a response time of about 3 minutes over 4800 baud radios. Shift reports are done in Excell from the archived data. (Make sure you get an interface package with enough tag capacity - some are limited). You can probably eliminate some of your spreadsheet functions, since the display, trending, and archiving funtions in Lookout and many other packages are top notch. You'll probably save enough in configuration time to pay for the software.

Created Date: June 26,2000

Created by: kurlandk

If you decided to use Modbus RTU at 19200 the time to recieve 1000 registers goes like this:

Max modbus block that can be asked or recieved at 1 time is 125 registers. So this means to get 1000 consecutive registers you'll need to make a minimun of 8 polls(or requests).

Assuming your polling cycle is 500 milliseconds or 2 polls per second means that you should be able to read all the registers in 4 seconds.

I 've used a GE Modbus/DDE server that can easily do the above(if the device can). Running on NT it routinely updates projects in real time containing over 40,000+ registers . Exact update times depend how many registers per device and how many devices are on a RS-485 line.

I think a striped down version of the server costs ~900 bucks.

Created Date: June 26,2000

Created by: Robert Kennedy

Thank you to everyone for your replies...I have learned a lot...our intention was to datalog 4 analog channels in the PLC, and do away with a chart recorder on the site. The users of our equipment typically have, or would use either a laptop on site running Windows 95 or 98, or a dial up connection through a modem. This limits the options available...as all the high speed options seem to involve either ethernet, NT or a more expensive server.

Created Date: July 10,2000

Created by: Mike McClanahan

Robert,

You want to explore the Modbus RTU option for what you are using. We are using Modbus over a 1200 baud radio and retrieving 120 bytes (60 V locations) per poll we are doing the same thing (storing the data and then downloading it). We can download about 360 V locations per minute over the radio. On a modem or direct connect you should be able to do 10 times this easily.

Created Date: July 12,2000

Created by: Mike McClanahan

The modbus program we are using is a freeware modbus driver that is located at http://mbserver.w3.to/.

The driver was written in C++ but comes with all necessary files and is VERY, VERY stable. It supports outputing direct to the serial port with special strings for things like dialing the modem. I am using it on a location where the special strings are used to switch a smart RS-232 switch between 4 different data radio systems so we can poll from one system to the next without having to upgrade all the systems to the same configuration, we just reset the communication parameters and talk Modbus to the next system. I have some VB software written to run as a service under Windows NT that I can zip up and email to you if you need something to get you started. This software reads the points from the Modbus system and places them into an Access Database where we retrieve them later on if needed. I have also written a desktop application to communicate with the service so it can be started and stopped as needed from the task bar and provides data about the service like how many communications errors, data changes etc have occurred. Let me know.

Mike