Slashdot Mirror
Creating a Homebrew Industrial Process Monitor?
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?"
Are they not willing to fund it/hire someone to do it?
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.
If all humans were like you, we'd still be hunting with spears, because "hunting is for hunters, doing it with your half-assed bent stick and string that throws a small spear is dangerous."
Look dumbass, how do you think the "professionals" do it ? They just "homebrew" it and slap some fancy decals on it.
...let's be clear about this: all you're doing is monitoring and gathering data - there is to be no feedback signal from the homebrew rig to control the valves. There's a whole field devoted to control theory, one that is best not trifled with, especially with industrial processes that can potentially cause fatalities.
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 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.
Science never settles, never rests.
Most home-brew CNC machines are open loop so that tech wouldn't apply to this problem.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
I build CNC and automation equipment, so I can pretty safely say that from what you describe this is a brain-squishingly trivial project. Probably one that can be done over lunch - After you spend five years climbing the learning curve, which is not at all trivial.
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.
I'll second what Rogue974 said. I'm a registered control systems engineer. Before you go "monitoring" a furnace you need to consider several things:
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.
Nearly fifty percent of all graduates come from the bottom half of the class!
"If this is an industrial application, you really don't want to homebrew it....if the information is valuable enough to record, its worth the money up front"
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.
I feel like you're missing the point here.
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.
-- If you try to fail and succeed, which have you done? - Uli's moose