PLC/HMI Logging Rate Improvement

[jvian]

Until recently my facility has had third party support for developing and managing our test lab but the company is going out of business and we are attempting to take ownership of our own lab software and equipment. Our stands test various fluid components (pumps, valves etc.) where we monitor various sensors for pressure, temp, flow etc. and we control and monitor the system using a PLC/HMI setup. Currently we are using an Automation Direct DL205 PLC, TopServer OPC and WonderWare InTouch HMI and for most testing we have been very satisfied with the capabilities. Recently we have been asked to perform some more transient type testing and will need to monitor our sensors at a higher rate than normal. We need to be able to monitor our sensors on the order of 100-200ms and right now can only achieve 400-500ms which seems slow based on my research of PLC's in general.

My question for you folks:
1.) Does this seem reasonable to ask or are we asking too much for our current hardware/software?
- if not realistic for my current setup, what are some low cost alternatives (PAC?)
2.) What are common logging rates for other users?
3.) What factors directly influence logging or update rates? (very broad question I'm sure)
4.) We do have to perform a bit of math to manipulate our sensor data - is math better performed in the PLC or in the HMI?
- our support tech always seemed to believe it was all limited by InTouch and put much of the math in the PLC

I am personally familiar with the InTouch programming and can handle most if not all functions with regard to scripting and have been experimenting with TopServer as well. I do however have limited experience with the PLC ladder logic, though I'm confident I can churn through it and learn it as I have been educating myself with it for several weeks now and it seems fairly intuitive. Any advice would be great as to what some options are or how to proceed to better understand my logging capabilities. Again I am learning rapidly as I go but I do have some background in programming and was involved in the complete development of the test stand and feel this is a task I can bring in house over time. It is becoming too costly to wait (sometimes days) to get support when one of our production stands goes down.

Thank you in advance for your assistance and hopefully I can promptly answer any questions any of you may have.

- J -

 

[djs]

I would think that you bottle neck is the Wonderware. Most SCADA packages of this type are not designed to collect data at such a high rate. If your test period is fairly short you can use the PLC to collect and store the data to be read by the SCADA at the end of the test.

If this is not possible then you will need to go to new hardware and software. Various companies have data loggers and software which will probably meet any requirements you have.

 

[jvian]

Our tests are typically 8-10 hours with about 10 minutes of high speed data requirements but the remaining data would still need to be collected as well (1 second intervals) so I do not think collection on the PLC will be possible although I do not know what the memory limits are. Could you recommend some vendors which are industry common? I started to investigate National Instruments with LabView and Automation Direct Productivity 3000 PAC but did not want to spend too much time looking at new hardware if it was not warranted.

Bottom line is I will be needing to log at high rates and combine PID control with test stand automation similar to our current PLC. So if new hardware is the only option I will start to research so any recommendations would be great. Is PC data acquisition an option? Meaning use the PLC to control the stand but have some secondary hardware which would collect the data? My supervisor inquired about the PC logging yesterday and this is new to me.

Again any help would be great and thanks for the response.

- J -

 

[djs]

National Instruments is a major player in the data logging field. Unfortunately data logging at high rates and system control do not usually go hand in hand. How many analog signals do you need to record. Analog data values in most PLCs are 16 bit integer values, so a one hour recording at 0.1s would be 36k bytes for each value. Sampling rates at the PLC level can be varied also. Depending on your I/O count changing your PLC maybe the best option.

 

[PNachtwey]

Most scada systems can't keep up because they read data one item at a time. If the data acquisition device can buffer the data then it is possible to read the data at very fast increments because many readings can be read at once.

PLCs are not a good choice. They are asynchronous or non-deterministic. I would look for a PC card that can do DMA if you are only collecting analog data.





Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[jvian]

I thought it worth revisiting this now that I have had a few weeks to dig in and learn the system in much more detail as I was unfamiliar with the OPC client and had never seen RLL before. The bottleneck in the system was the Top Server OPC client more so than the InTouch HMI. In the end I ultimately did a complete application overhaul of the PLC, OPC and the HMI which is now more optimized and has a fairly high level of performance. The key for my system was a balance of I/O tags and logic. I have been able to get my logging rate down to approximately 150msec and was able to add even more functionality. It is amazing what these systems are capable of and I thought it worth sharing that this issue was resolved.

A last question, are there any other forums for PLC/HMI that are worth following?

- J -

 

[PNachtwey]

150ms isn't fast.

If you need to do PID control and record up to 16 channels of data at 1 ms intervals let me know. We can buffer up to 12.5 minutes of data at that rate or you can upload the data on-the-fly.

This is the best one.

http://www.plctalk.net/qanda/forumdisplay.php?f=2

Peter Nachtwey
Delta Computer Systems

http://www.deltamotion.com

 

[itsmoked]

Thanks jvian for the update. Much appreciated.

Keith Cress
kcress -

http://www.flaminsystems.com