Brett,
Your application sounds quite successful. Limited PLC memory will force historical data scalability to a different (PC based) approach.
FactoryPMI was designed for that exact migration - to work for plant level control, but also scale to managers desks and beyond. The real key to distributed data access is getting the data into an SQL database (or using a distributed or web based application, which typically uses one). The point is that your end users are running some client application (a web browser or install-less client app) to access that data - as opposed to a heavy HMI that has a local copy of RSLinx. You'll also want to investigate how pricing scales with concurrent clients - it doesn't with FactoryPMI.
A data logger, which will either be a hardware device or software application is a cheap way to dump data somewhere. It may be enough to copy the files to .CSV to read in Excel (TOTALLY DIFFERENT than using Excel to read from the PLC via DDE). Most hardware devices will upload a separate file each day to an FTP directory. Software utilities will write the files locally. Each case can easily be shared across the network. Your advantages are that the system is cheap and simple and your users can do pretty cool stuff in Excel (create graphs, manipulate the data, etc). Your disadvantages are that data mining is pretty much impossible - well, totally manual (you can't query spreadsheets that are stored in different files), and that it's not presented in a nice or customizable way. A more powerful data logger would get your data into Access at the very least or, better yet, a real SQL database. You have all the advantages as described above, except the system is more powerful, manageable, and complex.
Looking into my crystal ball the obvious next problem is that management would prefer to access and visualize data in a user friendly format. A heavy hitting IT department could make this happen with an SQL database directly with lots of man-hours of labor. For the rest of us, you're getting into what the industry refers to as a
historian - a software package that includes some front end that provides trending and other visualization to augment the engine that's logging the data. A good historian should include the option to dump any data that the user's looking at to a .CSV file to use in a spreadsheet. You often then get into dynamic reporting, which is to produce nice looking printable summary reports that analyze your data over some time period.
Try to get the best estimate of how large your project could expand - this often isn't easy or possible. Simple dataloggers may or may not suit your needs. If your needs expand with coolness factor, they probably will not. Most vendors make a clear separation of HMI/SCADA software, historians, web access plugins, reporting, and so on and have some migration path to expand with you. I would recommend that you sign up for a free
web demo from Inductive Automation to learn about the option of using SQL databases and a web based approach and whether that makes sense for your situation.
The most important question is what you're ultimately trying to accomplish. There are cheap ways to expand that will get you a lot of bang for your buck, but you may hit a "glass ceiling". If you have the big bucks to spend any vendor will provide a scaleable model.
brettdawnj said:
My application is quite simple as I am just monitoring many points in the feild on a prduction line. A very simple "Andon" type application that is not dangerous or hazardous in any way. Basically I have a compact logic L35E that talks to a panelview to display all the current and historical information of the system. The PLC stores everything so the data is available from there (it is almost like a little data base).
Basically there is storage for current, past 5 day average performance, past 5 week average performance and finally the past 5 month average performance. The system was designed to have only the one panelview on the shop floor to force the support people and management to go to the shop floor to see reality (trying to eliminate as much shooting from the hip management from closed office doors and lots of data on their PC's).
This phase of the project has worked quite well as they are asking me to duplicate this system multiple times in the factory. I am just wanting to know my options if they want to get the data off the shop floor and on to the network PC's. I thought I might put some very high level indicators on their desktops so they can see what is happening when they happen to be back at the office.
Any ideas or suggestions would greatly be appreciated.
Thanks,
Brett
