I think this is probably my last post on the topic for SPC, at least for awhile. I really didn’t plan on having this one, but in putting together my first two posts, a several people asked me a lot about what the SPC really look like and what you really need to implement SPC. And, since I mentioned the concepts of real-time SPC and historical SPC in my previous posts, they asked me about those as well. So, I thought I would do one more post about SPC and try to give you an overview and what an implementation of SPC might look like.
The first large project I worked on in my career taught me that reusing code isn’t just a way to get more done with less effort; it is also makes problems that have nothing to do with the code very obvious. Let me explain:
From my last post on this subject, you should probably think that statistical process control (SPC) is pretty cool, and pretty valuable, as long as you don’t think too much about all the math. (Actually, the math is pretty cool as well.) But, SPC is not for everybody and it not the cure all for everything that ails you or your manufacturing process. So, I’d like to talk about ways to know whether or not you’re really ready for SPC.
You’ve heard of SPC. Statistical process control applies statistical methods to control manufacturing processes. You can go look at all the equations yourself, and you’ll see it’s actually pretty cool math and a
practical application of mathematics in manufacturing.
Everyone Starts Out Green, But Getting A Handle On A Few Important Resources Will Move You To The Experienced Side Much Faster
Have you ever been on a project where everything went as planned? If you’re like me, the answer is no. I would like to say yes, but who would I be kidding? Issues can vary from bad wiring, incorrect instrumentation calibration, wrong equipment specified or delivered, equipment installed in the wrong place, poor documentation, communication issues, seized motors, and so on. That’s a list that doesn’t end. Devoting enough up-front time on a project will minimize surprises during commissioning, but as much as one plans and prepares for a project, there are always issues, and those issues will need to be resolved by you. Having the right tools in your arsenal will make all the difference in finding the best solution quickly. Tools are not limited to screwdrivers, serial cables, or multimeters. Tools include experience, resources, and having the right positive attitude.
It is a common practice in the electric utility industry to utilize multiple stages of shell and tube heaters to preheat feedwater going to the boiler. The challenge has always been transferring as much heat as possible from the steam inside the shell to the water in the tubes. The mechanical design of the heaters helps this by providing baffles to prevent steam from exiting the heater rather than condensing. Heaters cascade from the highest shell pressure being the last in the train to the lowest being the first. There is also one heater called a deaerator that is an open heater between the low-pressure and high-pressure closed heaters where steam mixes with feedwater and any entrained air is removed. The steam for heating feedwater comes from extraction stages of the turbine and from the drain of the next higher-pressure heater.
In this last installment on this topic I said that the main purpose of automation is no longer to eliminate labor. That may have been the purpose some decades ago, but it is no longer the purpose of automation.
This is a continuation of an earlier article which discussed the importance of specifications in engineering services projects. That article described the importance of good specifications to define a project’s scope of work. This posting continues from there, with advice intended to help developers continue the good work that began with specifications.