Historian, Wonderware or Rockwell opinions please

[Conor 4]

Hi all, We are currently in the process of setting up an Historian to tie in with our Scada. We are running Wonderware V10 Scada. It is a toss up between Wonderware and Rockwell to which product we will be going with. As far as I can see we will need a system integrator to set-up the Wonderware Historian for us. I think with training I should be then able to maintain this system. My local Rockwell rep is coming in next week to go through a demo of Historian SE. I was wondering does anyone know if the Rockwell system is easy to set-up. Could we set this up ourselves? ANy info on these products would be great.

[paulengr 44]

Here's another option. Try iHistorian. It's the iFix historian now owned by GE Fanuc. You can use up to 10 points for free (unlimited). And the increments on the pricing isn't bad. In practice it is VERY easy to set up. Another option would be FactorySQL. I think it's personally the easiest one to set up. Instead of paying fees per point and such, you pay a one time fee and you are done. And it logs to SQL so it is much more compatible on the front end side of things than the competitors. With Rockwell and Wonderware, you pay and pay and pay for every little feature. Another option would be PI. I'm not a big PI fan because it's one of the priciest and I can never get their reps to call me back, but effectively PI defined the entire category of historian software. They are still a very strong market leader. Two things though that you need to consider right up front when it comes to historians. They often give you SQL-like front ends, but they are definitely not SQL compatible no matter what they tell you, except FactorySQL that is definitely full SQL server compatible since it uses a SQL server to store the data. All of these software packages try to give you the idea that you can simply "log everything" and then sort out the nuggets of gold from all that noise later. I can tell you for a fact that this is a recipe for disaster. Every time I actually implemented it that way, I came away sorry I ever did this. The salesman will really, really push for this kind of thing. They want to sell you the biggest software license, and a bunch of add-ons, and a whole lot of hardware (and additional software licenses). What you end up with is pathetic and a lot of work on the back end trying to sort out all the worthless data you collected. It is far better to decide what specific information you are interested in collecting ahead of time and implement THOSE functions, rather than just logging away willy-nilly. And you need to figure out ahead of time what you expect to get out of the data or else you just end up collecting a bunch of noise. Pay close attention to what you are getting. Wonderware for instance has a cheesy trending package (ActiveFactory) that looks great but can essentially only give you trend charts and/or send them to Excel. You can't do much else with it. The Excel data collection thing (essentially the Wonderware version of MS-Query) looks very powerful but you will spend lots of time learning the secrets of SQL programming and tearing your hair out because InSQL doesn't run as a standard SQL server at all, leading to lots of severe limitations in what you can and can't easily do. Rockwell is not so annoying when it comes to getting your data into a useful form but they make sure to charge you dearly for every single license that any end user (anyone accessing the data) has to have. GE Fanuc is just as bad, since you will be accessing it through either their almost SQL-like front end or through their Real Time Information Portal (roughly $1500/seat in license fees but at least it's first-come, first-served). PI has similar licensing schemes but I struggled with trying to get them to tell me what it is. At least in this regard, FactorySQL is much better. And you can use standard SQL tools to access your data. Better invest in time and effort learning SQL too with ANY of these packages. You can't really take full advantage of them without knowing SQL very well. Best I can tell you is that SQL is a language unlike pretty much any other. It is about as different from the "mainstream" languages (C, Java, BASIC) as ladder logic is to those languages...just like ladder logic, it is highly specialized towards one particular task (databases).

[Conor 4]

Thanks for that Paul. I have recently done a basic course in SQL. I am extracting data from our Wonderware to an SQL DB. I am by no means any kind of SQL guru, a novice. Our problem at the moment is that our system was set-up a few years ago, about 10. Anyway our data is being stored in csv and notepad files. Some of the csv files are over 50 Mb per day, which excel can't open complete file, it comes back with an error file too big. Our data is extreemly important to us, so I believe that it would be better for us to save this data to a server/db. We have a budget for an Historian, if I can sell it to the managers. My IT manager is behind me and my engineers as well. I have to convince the management to give me the money. As you said we need to know what info we want to store. We are kind of on top of that (I think). We have a fair idea of what we need to store. Thanks again for your help. Also, you didn't really mention Rockwell. Is there product any good???

[Ken Moore 23]

Rockwell has an agreement with OSI-PI now, and sell a version of PI specifically for Rockwell PLC's. We installed OSI PI about two years ago, and I love it. PI is designed as a plant wide historian, so it runs on a server and it's pricey. I wouldn't go more than 20-30k tags on one server though. We historize everything. You never know what you might need until you need it. The key is setting a tag naming convention up front, then it's easier to filter the tags and find what you are looking for. My plant is a batch reaction plant, and PI can do batch tracking also. We group our tags by Reactor train, then vessel. So a tag might look something like this: R1:R:PIC100.SPT, which translates to Reactor 1 train, the reactor itself, and pressure controller 100's setpoint. If you wanted to see all the tags for this vessel, just search for R1:R:* ; for the cooker the search would be R1:C:* etc.....

[paulengr 44]

Rockwell's historian works pretty well. I have no qualms with the historian. I think their front end interfaces though are very limiting in terms of price-to-value. It seems like you have to pay for a very expensive license for pretty much every PC you put the service on. This can be incredibly expensive when every supervisor and manager and engineer in the plant needs the capability to access the system. But that was my experience 5 years ago and Rockwell may or may not have gotten a clue about pricing in the mean time. With FTA, it should be pretty easy to set up a floating license system but I don't know if they have that capability or not. Let me give you some idea of how I set things up in a discrete manufacturing plant as an example of how to do this kind of stuff. We were very interested in trending and downtime on our casting processes. The casting process takes about a minute per unit of product, and there were 4 parallel lines. One way to implement the data logging would have been to log raw data. I could log the positions of all the actuators and sensors on the machine. Then I'd have to set up a way for the calculation engine to glean from this data what a "cycle" of the machine is. And determine based on the cycle data (it's semi-automated, operators initiate each cycle of the machine and are intimately involved in putting in a fresh mold, pouring liquid metal into the ladles and such). This can be done and we might (or might not) get some useful data on how the machine is performing within each cycle. I set up some data collection on this but never really got anything useful out of it. The second approach is to create a "batch record". Each cycle of the machine recorded all the setup and measured parameters along with time stamps and various timers. With these records, it is very easy to check on production rates (just count the number of entries). By knowing what a "typical" or otherwise properly running cycle is, we could easily detect downtime by just looking at cycle times and picking off all the ones that exceeded the "typical" cycle time with some margin accounting for slow/fast cycles (charts of cycle times showed a typical long tail distribution...long tails were downtime). This provided far more and richer data to work with than the "log everything" approach. It is possible (especially with a metrics module) to do most of these additional side-calculations within the historian system but it took less than a dozen lines of code for almost every process step to implement this at the PLC level. All I did was create a "cycle counter". Then the historian logged data whenever the cycle counter updated (a triggered update instead of a timed one). Within the PLC, I made sure that all timers and such were updated in order so that the last piece of data to be updated was always the cycle counter.

[Conor 4]

Thanks again Paul, that info is really appreciated, I mean that!! I have looked into FactorySQL. I will definitely download it when I am back in work. I will get back to you and let you know how I am doing. Thanks again, Conor

[ace_taunton 0]

I would stay with Wonderware. Having worked with all of these platforms, Wonderware is best suited to meet your needs.

[PLCMentor.com 60]

Conor, I too am impressed with Factory SQL. In fact I just posted earlier today that we have added training videos on our PLCMentor training site. I also like the Wonderware product. In addition to the historian, they have a companion product that makes all the reports and other data sifting stuff easier. There is something to be said for easier integration between two packages made by the same company also (ie, intouch and historian). Russell