It comes down to laziness, going home early, taking the path of least resistance. Even if you pay people more, they will only care for a little bit. Hence, future raises.
Scaring employees into working hard is how Apple and some other companies keep their engineers working diligently. Otherwise, more will try to find a place to nap on the job. I should know, found some nappers under their desks.
@tekochip: That sounds like a bad ECR approval process, if design engineering had no input (or if production engineering could substitute for design engineering -- along the lines of, "If dad says no, go ask mom.")
I have found, through painful experience, the importance of having a well-thought-out process for approval of ECRs and deviation requests. At one place I worked, approval to use non-conforming parts only required the signature of one engineer -- any engineer -- and there was no documentation of the non-conformance other than "OK TO USE PER [ENGINEER'S NAME HERE]."
One engineer (who had a master's degree from MIT, and was not a dumb guy by any means) would sign these requests without even reading them.
You're right about asking the factory floor to tell you if it doesn't look right. I invite everyone to tell me their impressions on a new design. If a screw is hard to access, if something is difficult to service, or even, "gee, we used to have a wire that was this color, can we change it?" Of course you can't design by committee, and that's a terrible trap to fall into, but you can design a product that's built for production, service and the customer. There's a hidden agenda, too. I found that Production, Purchasing and Service would issue Engineering Change Notifications to alter product attributes to their preference. What's worse is that the ECNs would be signed off by Production Engineering and Development Engineering had no way of knowing what was changed. Sure enough, substandard parts would be substituted by Purchasing, and Production would stream-line a process that destroyed product integrity.
If you can get the other departments input during the prototype stage you can tell them why a component or process is specified.
Absolutely right about the use of solid wire in RV s. I was asked to repair a problem of missing power in an AIRSTREAM trailer, and the very small outlet boxes were wired with solid wire, white and black. The problem was found to be a broken jumper strip on an outlet, making the repair was a real challenge because of the short solid wires. But adding a jumper between the two hot scrfews solved the problem. I am no longer impressed with the quality. Plush does NOT equal quality, nor does having lots of cute features.
I have two issues with RVs. 1) using Romex a solid conductor wire in a vibration enviroment. It should be stranded. I believe it is criminal and hope some day the manufacturers that do this get sued out of business. The other is the change or lack there of across AC and DC systems. In AC green and bare are grounds. Black and colors are hots. White is neutral. Except for travelers. On my camper I put red tape on the + side. Both terminals are a mixture of black and white wires.
It's not just wiring that needs proper identification. Piping for water and process materials need the same identification. Imagine our surprise when water began pouring from a newly installed electrical panel. Before the conduit was completed and any wires had been pulled, the plumbers the floor above had mistaken the 1" conduit for a water line they were installing.
As a site engineer I learned to double check all tie-ins, and trace them back to their source. Once when tracing my project's supply lines, I was confused by a nearby fire sprinkler supply line I used as a reference. It was a freshly painted red, but seemed to change position when it ran through a wall. When the maintenance supervisor and I tracked his painter down, we got the answer. Before he started painting in the new room he'd made a point of checking again which pipe was red. He held the brush in that hand, then walked around the wall and began painting the pipe on that side red too... he just forgot he as facing the other direction.
In my first job that put me in the position of giving instructions to the production technicians, one of my first directives was "If something does not look right to you, please tell me". Not only did that assure that problems were reported as soon as they were realized, it also set the tone for good communications between engineering and production. Some things that looked like errors were just lack of clarity in the drawings, while there were some actual mistakes, although not many. Publicly thanking a tech for finding a problem did a whole lot for moral and greatly improved the cooperation that I got.
There was one interesting case of two detailers who assumed that I had forgotten to put the letter "K" after many of the resistor values in a design sketch that I gave them to detail. Since the first units built from the sketch worked well, more units were built using the finished drawing prior to my being able to check it. The technicians came to me complaining that the design could no longer be made to work at all, and asking what I had changed. It was not until I rescued my sketch that the problem became obvious. The techs got a laugh out of it, and I explained to the detailers in minute detail about not altering my designs. Once again I gave the directive, " if it does not look right, ASK ME". That seems to be the best way to get things right the first time.
Wire colors are an interesting challenge. For most of the auto companies, which were our major customers, there were not very many colors used. Red is for AC, blue is for DC, green is for frame ground, and black is for AC over 120 volts. Wire numbers at both ends of the wire are the way to go. And all terminals to be numbered the same as the wires that terminate in them. Of course the terminals must be in order, which does make tracing much simpler. Even color coded wires must have numbers, since not all cables use the same colors.
There's no excuse for anyone deviating from a design without proper approval. This is why having a well-functioning process in place for submitting, documenting, and approving or rejecting deviation requests is so important.
That being said, I also don't have a lot of patience with self-righteous engineers who refuse to consider perfectly reasonable deviation requests because "manufacturing should just follow the drawing." These individuals need to get off of their high horse, analyze the consequences of accepting the deviation, and make an engineering decision, rather than a knee-jerk reaction.
Life is rarely neat and orderly; in real-world manufacturing, all kinds of things come up that can't all be predicted, and some of them may require deviating from or changing a design. A good engineer is able to analyze these things objectively as they arise, and to make sound recommendations.
While the production team in this example was obviously in the wrong and engineering was obviously in the right, the tone of the article seems to suggest that engineering is always right and production is always wrong. A little more humility may be in order.
One reason why production personnel sometimes make changes without asking engineering is that whenever they approach engineering, they are met with a condescending and dismissive attitude. So they just stop asking. This obviously isn't a correct response, but it's an understandable one.
At the end of the day, engineering and manufacturing (and quality, and purchasing, and accounting, and marketing...) all need to work together so that the company can make money and everyone's paychecks will clear.
For the record, the person installing the control panel & wiring was not colorblind. Saying all the wires are grey might have been misleading. As I said, it was just a lazy approach to handling the job at their end.
There are countless laws that regulate color of wiring. Imagine if our homes were wired up with whatever was laying around, or "looked like it would work." I have been in a few homes where the owner took it upon themselves to handle the power distribution. Luckily, they never had an inspection from the city walk through or they most assuredly would have been fined and required to hire an electrician to fix it all. Take the time, do it right is always the lesson.
Using the correct color coding is very important, I've worked in TV stations which have hundreds of coax cables running all over the place, all of them one color, generally black. When one is troublshooting a problem, particularly when you've gone off the air, trying to trace a given cable through this snake pit is very frustrating. Any type of labeling seems to be the last thing anyone thought of during installation.
On another point, I needed some custom prototype power transformers and ordered them from a recommended source. The transformers arrived, all were of impecable quality, beautifully finished, except for two things, the color coding of the wires were not standard and there was no documentation. The primary did turn out to be black wires, the high voltage secondary was blue/grey/yellow, the filament windings, one was red, another green and third was purple/orange. Not exactly standard coding. There was no markings to tell which transformer was which except by measuring the voltage outputs. A high quality product totally messed up by using incorrect color coding and a lack of documentation. Needless to say, despite the quality, this transformer house is out of business now. What a shame, a couple of shortcuts by somebody, who knows who, killed the company.
I did send a letter to them asking about the color coding and documentation, I never did receive a reply.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.