Sometimes it's just voodoo. I once commissioned a vision system to assist a robot in placing some odd-form parts. Without it, the robot would mis-insert about 20% of the parts. Prior to conditioning the line engineer pronounced 'this will never work'. Once the system was commissioned the mis-insertion rate dropped to zero. After several hours of running and passing an acceptance test, the line engineer said 'see, I told you it wouldn't work' and then turned off the power. The robot promptly went back to misinserting 20% of the parts but the line engineer was happy.
The other end of voodoo is great expectations leading to common questions like: "how come the robot didn't know these are parts for another product line?", "how come it didn't know the part was out of tolerance?", "why doesn't the system know we feed a lot of scrap parts on Friday?" and from the more technically inclined "Why doesn't the robot know we changed the design" and "Why doesn't it know when I move a fixture to a new location" while from knows just enough to be dangerous': I didn't know if the sensor did anything so I just forced it on in the PLC.
BrainiacV; Isn't it amazing: Problem description: "I spilled a glass of soda into my keyboard, and now it is misbahaving - the problem must be your software update." Reply: "Don't you think pouring a glass of soda into a keyboard could cause a problem ?" Response: "Why can't you admit your software could be the problem ?" Conclusion: "Give your head a shake. I think your brain is stuck."
I agree on that as well, the curiosity is in our nature. The thing which is not apparent or not accessible to us always seem to be liable to error to a common person. I can understand the rough times a programmer might have to face in their service.
On one conveyor installation, a diverter would fail every once in a while. The hardware manager was blaming my code. I told him it had to be hardware because if it had been code, all of the diverters would be having the problem. It blew his mind that only one subroutine controlled all 60 diverters. And strangely, that made him suspect the software even more. We eventually traced it to a set of conveyor segments (it looked like a giant tank tread) that would not trigger the proximity switches he had installed as a gate against my control signal.
At another company, the QA manager complained that her keyboard was generating gibberish after she had installed a new version of our code. I traced the problem to being the keyboard by demonstrating that I could unplug the keyboard and plug it into another computer, and the problem followed the keyboard. At this point she admitted that she had spilled a drink on the keyboard earlier. But still unwilling to accept it was a hardware problem, said the problem didn't occur until our software had been loaded. I tried to explain that it may have taken a little bit for the liquid to seep into circuitry. I don't think she accepted that explanation.
When the problem is a system that had been working as required for some time, and then all at once is not, about the second question is "What has been changed", which often will narrow the area of search quite a bit. The first question is " just exactly what is happening, or not happening, that is a problem". Having an accurate description of the failure is usually a very good starting point in the diagnostic process.
@Braniac, I agree, but It is because generally people have the tendency to point at that place, that requires minimal amount of time and effort to solve the problem. And computer requires you to sit at your desk and figure out the problems in the code. It is just the natural way of things. If there is no problem found in the code then people shift to hardware problems, because they require more time and effort to deal with.They may even require disjointing the robot or unwiring all of the circuitory. So, I guess its justified people turning to the code first and then after that, to the hardware.
That is correct, another way to look at it is that we overlook our minor flaws because we would like to believe that we cant be that dumb. Generally, most of the problems that arise are due to the basic syntax error in case of programming or a loose connection/solder in hardware. And ofcourse they can be very annoying.
A new service lets engineers and orthopedic surgeons design and 3D print highly accurate, patient-specific, orthopedic medical implants made of metal -- without owning a 3D printer. Using free, downloadable software, users can import ASCII and binary .STL files, design the implant, and send an encrypted design file to a third-party manufacturer.
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.