Factory Talk Plantmetric's help

[mracer 2]

I am starting to set up a Plantmetric's/ historian system that will communicate with several OPC servers on some ABB robots as well as some wood working machines. I also have it talking to a ml1100 that looks at a machine for available/running and bar code feed back. What I am looking for is feed back from those of you that have worked with Plantmetric's. What should I look out for in setting these up? are there traps to watch out for? Tips that will help me down the road? I spent 4 days at Rockwell training and feel i have a good start but they didn't talk much about the setup of the OPC servers and setting up the tag's. I can see some RSSql training will be needed. Any input will be a lot of help. Thank, Great forum. racer

[Nathan 7]

RSSQL is a separate package from Plantmetrics and Historian that transfers data between SQL databases and PLCs in the form of defined transactions. It may or may not be necessary depending on your requirements. Plantmetrics defines work cells that helps you optimize your process by analyzing downtime. Historian, of course, logs historical data and provides views of it. You might also consider RSBizWare: Batch, MaterialTracker, or Scheduler based on your needs. They probably didn't get into OPC servers and tags because the HMI end of things (with FactoryTalk) runs on RSView SE. I'm surprised that your 4 day training course didn't cover the different Rockwell packages. I'll gladly answer OPC questions and anything that I can with this setup. The first step would probably to determine your needs and the scope of the project. You have a lot of Rockwell expertise in this forum to get you through it and your local distributer would be glad to help. I would encourage you to check out FactorySQL and FactoryPMI. They can accomplish the same tasks in a simpler manner. This is done by each piece working together through the SQL database instead of distributing complexity. The best way to quickly determine if it is right for you would be to sign up for a one hour web demo to see the products and get your questions answered. Good luck with the project. Edited 29 Dec 2006 by Nathan

[Chris Elston 79]

It is my understanding that RsSQL is not separate from these applications.

[TimWilborne 108]

I just took a shorter training session on RsSQL and that was my understanding too. I had a customer requesting RsSQL my local distributor suggested Historian because it has RsSQL embedded into it and gives you additional tools to pull the data back out But I could be wrong, it was a lot to take in. I will verify this and report back I'm going to try out Nathan's software also after I get my test PC cleaned up so perhaps I can offer a comparison.

[Nathan 7]

I stand corrected. I thought that RSSQL was exclusively the transaction engine in dealing with SQL databases (MS SQL Server and Oracle). It would make sense to combine that with Plantmetrics and Historian since they are functionally so similar. My experience is a bit dated :(. Is there somebody that can verify this for sure. They appear to be separate packages on the website RSSQL historian Both are under the RSBizware umbrella, which is what's confusing, but neither one mentions the other. I also have a (slightly older) pricing information that has them separate. I'd really like to find out how this works. Edited 29 Dec 2006 by Nathan

[Gerry 13]

My information & experience is also somewhat dated... RSSQL is sold as a separate package with various tag limits and configuration options. Historian includes a version of RSSQL but has some constraints compared to the stand-alone versions. I think both include MS SQL server.

[TimWilborne 108]

I might be wrong but I thought my rep said only the Professional version included a licensed copy of MsSQL. I got tons of literature when I was there. I will try to dig through it this weekend

[Nathan 7]

That sounds accurate. Any version with an SQL Server license is going to cost you. MS gets a nice cut... I'm curious how powerful the embedded version of RSSQL is that comes with Historian and/or Plantmetrics versus when you would want to buy the full copy. Historian appears to come with 1 Plantmetrics workcell and probably some version of RSSQL. Are the packages actually getting more intertwined or just the licensing. It would certainly simplify things if the actual applications are getting rolled together to some extent. Historically, going to your HTML web reporting plugin to display tables or pie charts, going to your historian to log or view graphs of historical data, going to your HMI to see realtime statuses, going to your downtime tracker for analysis, going to your SQL engine to define SQL transactions to get data between databases, etc, etc, has driven me crazy. This doesn't even address specialty modules (power, batch, etc) or custom programming (better keep that VBA reference handy because your custom programming environment used to necessarily be within the HMI package). Consolidation of these functions makes a lot of sense.

[bikerdude 0]

mracer, I took a RSBizware course (4 day) that touched on the RSSQL end of things. It seems very complicated & the instructor recommended that a course on the subject would be a great help if one is starting a new project. I on the other hand, I am only resposible for maintaining a already running project. Things to watch out for: 1. The SQL database will grow rapidly & cause slowdown of reporting. You need a method of "pruning" old data that is no longer useful to keep the system responsive. This may be a MsSQL function & nothing to do with Historian. I wouldn't recommend keeping any data that is over a year old. Carefully choosing the update rate of the data points will lessen the problems here. A fast CPU & 2 Gig of ram will help as well. 2. If users are going to connect to the server thru HTTP to get the reports, I recommend 2 ethernet ports. One for PLC traffic & other for users. If the users walk right up to the PC & sit down to get the data, then this is a moot point. 3. Carefully choose user rights management & password protect the important stuff. Our system uses RSLinx as OPC server. I can't help you out on OPC from other sources. My understanding is that RsSQL can be purchased alone or as part of a "package deal". Either way, I believe it is required to get historian running. Good Luck BD

[mracer 2]

BD, That is what was recommended to us as well. I am starting with a clean slate so I feel now is the time to take that little extra to get it right. My problem is, I have managers that can't tell me what it is that they would like to see. Its something vary new to our company. Tracking the machines that is. Thanks everyone for the input. I wish I could ask better questions but its still so new to me. I am learning by reading everything I can. Racer

[Ken Moore 23]

I find that it is often difficult for management to tell you what they want when it comes to automation. However, they seem to easily find fault with what you propose. Because of this, when approaching something like this without any firm goals, I write up sort of a deliverables document and give it to management. That usually gets the ball rolling. They will look it over and things magically appear in their heads. They will add things, change things, delete things, and at the end of the day you will have a deliverables document you can use to scope your project. It's worth a shot.

[mracer 2]

Is there some where I can find an example of a document like you are talking about. I have no Idea where to even start for something like this. That document would help me if I could give them something to get me started. Thanks Ken. racer

[paulengr 44]

I have gone through several generations of setting these sorts of things up. This is my perspective. You will find that RSBizware has a great model for a discrete manufacturing plant if you do everything in terms of MTBF, OEE, MTTR, etc. Anything that it already has set up to model is going to go great. Where you will first run into problems is coming up with an acceptable model for a particular production unit. What constitutes "running" vs. "failed" vs. "down" is often very tricky. It's sort of like defining vulgarity...most people know it when they see it but pinning them down on a specific definition is difficult. I'd suggest that you look at the problem from several angles: 1. Identify EXISTING plant metrics. Use those first. If the plant doesn't use OEE, don't use it (at first). Develop your reports based on existic metrics (pieces produced per day/hour/week, downtime minutes/events, etc.). Once everyone gets used to what is going on, THEN introduce other alternative metrics. I can't stress this enough...if you want things to go well, work within the comfort zone of the plant. Just because they don't believe they currently have anything like this doesn't mean that it doesn't exist. Look carefully at the existing production reports. Primitive as it may be, it is there. 2. Start small if possible. Pick a "hot" area only if it is a good fit. Otherwise, use the plant bottleneck(s), the end of the production line, start of the production line, etc...anywhere that is relatively "easy". Again, consider item #1. If the plant normally reports feed rates and you are reporting output rates, you will encounter resistance because managers have to "get their heads around" the metrics you use. It is OK to augment the report...show both, but don't use alien metrics. 3. Make your reports similar to existing reports if possible. I always think of SAP when I think of how NOT to do it. SAP takes the attitude that if your existing plant metrics/reporting/systems don't work the "SAP way", then there is something fundamentally wrong with your plant system and that you should adapt the SAP way. That attitude is the reason that SAP has such high resistance everywhere it goes. There is a definite "right way to do things" with RSBizware. It is still very flexible. But there is already something existing in the current plant...and that has the value of familiarity if nothing else. Be aware of this value. You will be much more successful if you don't ignore it. 4. These systems are NOT a good idea for outside contractors. The reporting system usually evolves with the plant and with the changing strategies of the plant. Often plants just starting out with these kinds of tools start with one metric such as productivity as the overriding concern and later shift to others (quality, downtime). The first shot may not work all that well. For instance, I had to augment the productivity metrics on one particular line with the number of model changeovers. With any given model, the production rate was pretty much identical. The changeover itself was far more critical than the model. Furthermore, frequently these systems are key to continuous improvement and they evolve as the plant evolves. The #1 issue last year may be a minor player this year in a successful continuous improvement program. 5. Start with understanding how/what you need to be logging and get the logging going. Go around to each department and identify what their key values are. Realize of course that you may miss some. Piece counts, raw material amounts (batches or per hour), flows, anything of that nature. Also make sure to determine what the frequencies and historical relevance are. You may need to create two systems for each. For instance, we log emissions and several key operating parameters (air flow rates and such) on a cupola once every couple seconds for "real time" trending reports for troubleshooting. The data is only kept for a few days. There is another group of tables that log only once every 10 minutes. This data is kept for 6 months. It is used for reporting and for comparisons (has the vibration on the fan been gradually increasing over time or is there something going on today). 6. With RSBizware, once you have the above information, you can probably get a good idea of how you want to set up the "model". Notice as you read the manual that in terms of granularity, certain functions work better for certain areas. If you have multiple production steps in series on a single production line, you could set them up as a production cell or a line. There are advantages of doing it either way. If you set them up as a line, you will find it very difficult to come back later and collect metrics on individual production units. Another aspect of this involves queues themselves. Sometimes it is very easy to associate a particular piece of equipment with a particular queue. Other times, you may want to make the queue itself a separate item. Areas usually work well for referring to departments. But again, look at how the definitions work. 7. Again...consider the evolution issue. In the plant I'm at now, we started with just a report showing production totals. It evolved from there to another part of the plant showing only downtime. Then productivity, and finally OEE (although we never called it that). Now it is moving across the plant into each production department. We started with relatively "simple" models and things have evolved from there. 8. Not every concept "fits" in a given plant. SPC is essentially impossible in the plant I'm in now. I have SPC tools in the package but they are not really fully utilized. The QC area is located behind the annealing process in a ductile iron foundry. You can't inspect something that is over 1300 F effectively (it is hard to see defects on something that is glowing and hard to touch it anyways). In terms of time, it is over an hour and roughly 60 pieces away from the casting operation. We have done as much as we can (real time feedback from QC to production when defects are reported) but there's only so much that can be done. Very few of the QC measurements are quantifiable (it is mostly pass/fail, not # of defects). These practical issues make real SPC virtually impossible. Pareto charts and root cause analysis have been effective tools. 9. Some tools may not get used either. The PC's are not on the plant floor. We are making more efforts now to get the information out onto the floor, but the concept of a "dashboard" with instantaneous feedback on production rates has not really taken off. We also haven't really utilized the other version either...printing reports offline to PDF's and pumping them into the E-mail system. Managers are more interested in logging on and "exploring" what's going on...they want the "instantaneous feedback". 10. RSBizware has extensive tools for defining "up", "down", "failed", etc. Study these carefully. Definitions are a nightmare depending on the plant. For instance, we defined an oven as "up" if the conveyor chain was running, the temperature was above a certain point, and product was inside the oven. How about a semi-automated batch process like a casting machine? "Running" means that operators are putting sand cores into the machine and starting the casting cycle. "Down" means that they are impeded from doing this. Cleaning excess metal off the machine if it overflows a core, or retrieving more cores is also "running". Every hour, there is a cleaning procedure where some of the troughs are cleaned of build-up which takes between 3 and 10 minutes. This is also "running". There is no direct indicator of running. We have simply arbitrarily used any time over 10 minutes to indicate "down" because there is no better indicator. A similar issue is detecting "dry runs". In the current project (rolling out the reporting system to a new area), we get spurious signals from dry runs (since a dry run simulates every aspect of the run). Right now we chose to cull them by ignoring data outside the scheduled production times and also by ignoring the first couple pieces produced. I'm not happy with this solution, but it seems to be about as good as it can get at this point. 11. In a similar way, RSBizware is really hung up on scheduled vs. unscheduled time. In the foundry example, when the cupola is actually ready to produce iron is a bit of a hit or miss affair. Actual starting times vary by about +/-5 minutes typically. At production rates of a piece per minute per production line, this means that startup production rates can be influenced +/-10% depending on how you define your startup/shutdown. At the same time since it is not a 24 hour operation and it is important to capture "late starts" or early shutdowns, this also complicates defining "running" vs. "down". This is not specific to RSBizware...I have struggled with coming up with acceptable definitions for this situation even with a "generic" system. 12. Anything that reduces clerical work will be readily accepted. Anything that increases it is going to be met with resistance. Everyone involved in inputting data is going to be doing the cost/benefit calculation. One of the problems is that frequently upper management are the beneficiaries but "lower management" (front line supervisors) bear the brunt of the data entry. In a perfect world, a system like RSBizware would do all the clerical work automatically. But somewhere, somebody has to fill in explanations (why was it down, why were production rates lower than expected). This anecdotal information is frequently more important than the raw numbers and it is critical to success...and also the most time consuming in terms of clerical work. 13. Beware of the "information overload" problem. This is like alarm systems...too many alarms is just as bad as too few. 14. Be aware of the "level" of information. Front line supervisors need instant feedback...how good are we doing right now? Why is the production line down? When the superintendent calls me tomorrow, what am I going to be answering for? Superintendents and engineers are interested in trending...how well have we done over the past week? How can we improve? Plant managers want exception reports...what were the top 3 hitters this week? How well have we done compared with last month? For each group, a different report is often necessary. 15. In general, I'm a strong proponent of mockups. Having a web-based demonstration using actual plant data from YOUR plant (not the Bicycle example) makes a strong statement to any manager...it's something that they can touch/see/smell/feel. Even if some of the details are wrong/incorrect, showing someone an example goes much further than talking about a nebulous product that does not exist yet. These are time consuming but frequently the final result is usually not that different from the initial version. In the system I'm working with now, I was struggling with how to sell a 5 digit software package vs. the time involvement in developing a much simpler (but less configurable) home-brew reporting system. I got a 2 hour license demo version. A key strategy that the plant is working on is to control final product weight (material reduction effort). One of the demos actually used existing data to show histograms of weights that had "drill down" capability for each product model/production line. It was fairly responsive (results came up within a couple seconds) and showed both the metric that was familiar (the average weight) as well as the "spread" graphically. It kicked off a whole series of ways of analyzing the data to determine what the process capability actually was (how far we could push final product weight control), even though it was only intended as a demo. For 2 weeks straight I was getting calls at least twice a day to restart the demo. 16. Be aware of the limitations of how things are done in your plant now and that you can't "force" things. I have made one attempt at developing a production planning report/function and integrating it into the system to do away with yet another manual system that does exist. This project fell flat on it's face. We're just not disciplined enough...production scheduling is too "loose" to be automated at this point. I was forced to backtrack (quickly!) and remove the production scheduling system. The problem was that downstream reporting was hinged off this reporting system...it is still a problem I haven't fully overcome yet. 17. Recognize what matters most and where you have the most to gain. In the plant I'm in now, employee productivity has potential gains of 10-20%. Downtime is about 10%. Scrap is about 3%. There is room for potential improvement of 1-2% in terms of product weights. The priority order has been just the reverse (weight, scrap, downtime, productivity). In one of those "pilot runs" that we did, focussing on downtime and productivity yielded an increase of about 50% in terms of overall productivity (net pieces per hour, month over month). 18. Recongize that certain features that you need may not exist. We don't have sensors to detect "starved/no room" for the most part but this is a critical issue on one particular production line (operators tend to create surges in the system). This has been a problem. The solutions (counting production cycles of the upstream/downstream system for instance) tend to be problematic (one miscount and the system breaks). 19. Time can be an enemy. In the example I gave, QC operates roughly an hour behind production. If QC reports 10 scrap pieces at the end of the day, but there's no production for that hour, what's the scrap rate? (-10/0 =??) It is also rough...plugging in an arbitary one hour delay is not the answer either. A real production "tracking" system would solve many of these issues but getting a tracking system to work successfully is in itself a major project. 20. You will make mistakes. Hopefully you will make them early on. We were able to successfully try out multiple reports and gutted/rebuilt the "production cycle" detector multiple times before we settled on an acceptable one. We have had to redo the logging system a few times as well. We developed the report for one production line with simple text fields for the "downtime reason" field which makes it impossible to do charts and drill downs. Switching over to a "pick list" was not an easy thing to accomplish. In retrospect, we needed the free text initially though to develop the pick list. In another area, we decided halfway through that the basic hierarchy of the picklist was not working and had to redo everything after months of running. This basically turned the old history into garbage.

[mracer 2]

paulengr, Thanks for a great reply. This helps. You are right. Bizware has some great tools,If they is a standard system to use them on. On of the pc's of equipment I need to track is a Mazak laser. The cut program is a nest of anything from 1 to 6 different PC parts are cut in the same sheet. I an logging the available/running and have started setting up the operator's ID #. The problem with this is what do I use as a ideal cycle time? or PC count? I like the setup of the standard OEE report and on other equipment it will work well. I company I work for is vary different. We don't punch a clock, log time to a job nor do they track how much time is spent on any 1 work order for a run of parts. We make over 200 products non of them are run on a dedicated assemble line. It hard to explain. Anyway, thanks again for the great feedback. racer

[Ken Moore 23]

At the facility I work at we use the average of the 3 three shortest cycles for that product as the ideal cycle time. This average is updated manually at the end of each week. I'm trying to automate the calculation, but it still has bugs. If the three shortest cycle times recorded for product "A" is 50 minutes, 51 minutes, and 52 minutes, then the ideal cycle time is 51 minutes. Any time operations produces Part "A" and it takes more than 51 minutes, a datat entry is required, explaining the reason that "ideal" time was not achieved. We have several categories predefined, and a place for detailed explanations. It has taken us about one year to get the downtime tracking to work as it should. We require each operator to track and post the down time for his area. We had to get PC's on the floor, train the operators, and then cull the bad data for quite a while. Most operators will never report that the downtime or slow cycle time was caused by something they did or didn't do.