Creating a Homebrew Industrial Process Monitor? 97
pionzypherm asks: "I work at a glass plant for a major beer company. My job entails monitoring the furnaces that melt the glass. I have been working on a project on the side, collecting data from various sources and compiling it into an easily used form for the higher ups. I've finished two of our three furnaces, but one remains. This furnace uses technology from the early nineties. There is no networking, the hardware is completely closed and unavailable for any screen scraping. Two of the items I'm looking to monitor (and would appear to be the easiest starting point) are two valves for a gas and oxygen line which will provide data on a portion of our energy usage. I was thinking of a microcontroller board or something similar tied in to monitor the positions of the valves. I'm unsure where to begin though. What books, microcontroller boards or alternatives would you recommend for someone new to this? What suggestions would you have for such a project, and what pitfalls might I run into?"
Might be looking at this wrong... (Score:3, Insightful)
You might be making this too complicated.
Let's say you misjudge the tolerances and your fancy little project gets turned into cinders/melts inside the furnace?
Why can't you monitor the volume of gas flow and then calculate the energy? I assume these gases are stored in a tank or something like that. It should be comparatively easy to attatch some type of flow sensor upstream of the furnace.
Re:Industrial automation is a business (Score:4, Insightful)
Look dumbass, how do you think the "professionals" do it ? They just "homebrew" it and slap some fancy decals on it.
"Homebrewing" for your application is OK - BUT! (Score:4, Insightful)
If you really want meaningful data from those process streams, you're much better off installing calibratable (calibrable?) flowmeters on those lines that cover the performance range of the process fluids you're working with. If you've got the flow, you don't need the valve position, unless it's for a secondary indication to validate the valve's performance (e.g., position vs. Cv vs. measured flowrate). The flowmeters can be hooked up to provide data for remote collection, or more simply, display data for periodic local reading. Here's a mess [omega.com] to start with. Whomever you buy from, you'll need to develop specifications defining the operating range, operating conditions (pressure, temperature, humidity), power requirements, tolerances, calibration frequency, etc.
Re:Open resources (Score:4, Insightful)
A few suggestions from a CNC guy... (Score:4, Insightful)
I would just ask someone who does do this for a living out for lunch, it'll take them ten minutes. I do this when I need coding done. The price of a few beers to get the occasional patch or script written is a lot more efficient than many years learning coding to do it myself the one time a year the need comes up.
The learning curve on automation hardware is at least as steep as learning Linux, and with crappier documentation. Coding guys usually seem to underestimate the complexity of the physical engineering and design side, and think they are always bright enough to just pick it up and do our jobs. There is more to hardware engineering than the butt-crack guy with a monkeywrench, just like there is more to coding than script kiddies.
In short - unless you want to go into this as a hobby or career change, just treat a hungry engineer to lunch and call it good. Even if you paid him it'd be less than the books you'd need.
Re:Look into GE Fanuc or Allen Bradly (Score:3, Insightful)
1) Where is your data going? Who might use it and how.
2) What instrumentation are you going to use and how will it interfere with the process?
3) What are the safety and reliability issues?
4) Are there any legal ramifications?
These systems may be independent for a very good reason. I can't tell you how many data geeks have salivated over the SCADA and plant control systems I design and manage. All these folks mean well. However, they see this information as a wonderful fountain of pure lovely unadulterated data. Yeah, right, and the Brooklyn Bridge is for sale too. This data is subject to all sorts of problems including calibration errors, maintainance, gaps in the real time data stream, and so forth. That's why you have operators.
There are serious and very complex safety issues with using this data. It may not be up to standards for use as a database of record. It may even confuse things. It may also be subject to hacking. Note to all: Yes, it's true, process control systems are highly subject to hacking because patches are not applied in as timely a fashion. We have to make sure the patches work and are ultra stable before we apply them to a working industrial control system. That's why we try to stay off of the IT intranets. It's not that we don't want to share the data. It's that we don't want to spread incorrect data.
The operators are there to act as a primary source of data for you. Let them do their jobs. If you think that you can simplify their jobs, work with them. Don't foist some cheesy embedded system on them to do the job of a hardened industrial controller. You won't keep their trust that way.
In the long run, it's usually worth the expense to purchase a hardened controller to do this job. Could you do it yourself? Sure. Would it work well enough for anyone to use on the very first try? Not likely.
If you choose to forge ahead anyway, keep your eyes and ears wide open for experienced hands to give you suggestions. Part of the plant mentality is that we'll say our peice just once. If the outsider is any good, they'll listen to the wise suggestions. If not, their stuff will just break and we'll throw it out at the first opportunity. Our trash heap of such well meant projects is embarrassingly large. Be prepared to listen and learn.
Re:Don't want to be done on the cheap (Score:2, Insightful)
HAHAHAHA! Oh, if you only knew how most factories operate. I work with several leading edge semiconductor fabs and you'd be amazed at the amount of homebrew/seat-of-the-pants solutions abound.
I am currently working on a system to track production on about $300 MILLION dollars worth of equipment. My equipment budget? I was lucky to get $30,000 and most of that was for data storage hardware.
Face it, the suits don't think that factories make data. They think factories make widgets.
Re:Might be looking at this wrong... (Score:3, Insightful)
Invasive modifications to the gas or oxygen lines are definitely out of the question. We're talking approximately 40k cubic feet of gasflow per hour. Though we do already have two existing pressure readings, your post makes me think I might be able to replace those with industrial grade electronic meters to do some sort of venturi style measurement.
Re:Amen, brother! (Score:5, Insightful)
What the original poster is trying to do is not innovative in the least. In fact, it's pretty well-worn territory (which he may have been unaware of by no fault of his own).
If he had said "I've looked at all of the commerical options, and nothing fits quite right", I'd be in agreement with you that he should go out and try to create his own solution. However, this is not the case, and a lot of time and experience has gone into developing products that fit his needs very well.
And even at that, there will likely be a good deal of 'hacking' involved in getting these valves to do what he wants them to, given that they're industrial components. Any EE on the planet knows that it's preferable to use a commercially-available IC instead of constructing an equivalent circuit out of components as long as the IC fits the job. The same goes for industrial components.