We have seen this so often in Sherlock Ohms, where the engineers pore over the possible causes of a glitch only to find it's train going by or some other environmental factor. Interesting what can cause a hiccup in a system.
This example shows the problems that arise when groups within a company fail to communicate. One group asked to have something done, but no one reported back to them, and they assumed to got taken care of. Better communications, group meetings, and "loop back" documentation to prove something got done would help.
While I was at the General Motors Scarborough Van Plant I was presented with a line-stoppage report from an engineer. He had determined that a lot of line-stops were being caused by robot servo errors. My question to him was whether he had done any investigation as to the causes of the robot servo errors. I didn't have statistics, but from working in the CarTrac section I knew that robot servo errors were mostly caused by wrong build or bad build from Ladder 1, which built the frames. The robots moved the weld gun around the frame as the build data described the frame geometry. When Ladder 1 built wrong options, built out-of-order, or mis-located frame pieces, the robots hit them and stopped on a 'servo error'. My point was that the data didn't lead to a cause that could improve the line-stop numbers.
We see this today when using a GPS and some idiot put a building in the middle of the road the GPS is telling you to go down. Keeping up with the data and changes is vital in any endeavor, except government, of course. There it doesn't matter because you can just throw more money at it until the project is abandoned...
I just love when somebody does this to me. I design assembly drawings and then produce individual detail drawings for the tool maker to build. When done properly, the assembly goes together and the die produces the parts to print. Some times things need to be tweaked. ie overbend this, change an angle, move a flange etc.
When I do it myself, everything gets altered and all drawings updated. But occasionally the change takes place on the shop floor without documentation. When it comes time to rebuild or replace a worn die feature is when it is first found that the changes were undocumented. When the new part does not fit or work properly. all heads turn and all eyes are on me. It is uncomfortable until things get figured out.
The railcars were powered by electric linear motors. One part of the motor traveled with the railcar, the other part of the motor was continuous solid back iron between the rails. Most was single solid back iron except at locations where deceleration or acceleration was required and that had double solid back iron. The gap between the motor coils on the railcar and the backiron was set at 11mm...the air gap of the electric motor. Look up linear motors to get an idea what was involved at a much larger scale.
Are they robots or androids? We're not exactly sure. Each talking, gesturing Geminoid looks exactly like a real individual, starting with their creator, professor Hiroshi Ishiguro of Osaka University in Japan.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.