Programs, especially subroutines, can sometimes be finicky when executed through robots. This gives them a personality of sorts, which isn't always a good thing, especially when it comes to surgical robots.
Very early in robot programming, and in PLC programming, it was pointed out about the sequence of operation, where the lines are executed in sequence. So before giving a command it is always needed to define what that command will be, and what all of the variables will be. That works for timers and counters also, in addition to analog outputs and drive position/speed commands.
So the person who changed the program broke a very early programming rule.
TJM, "been there and done that". Troubleshooting via email one time certainly was better than a service call to a shop someplace about 200 miles north of Quebec. So I had the customers tech take voltage readings and after only two exchanges the failure diagnosis was positive. We sent the replacement parts via super-rush delivery and they got them in only a week. The tech put in the new parts and the machine played perfectly and the customer was very happy. My boss was peeved because we didn't get to charge for our in-shop repairs. Some folks have strange priorities, especially about supporting customers who pay a lot for support contracts. But Delpi-Diesel had strange attitudes about a lot of things.
The problem described is a common issue that seems to occur with the way Motoman interfaces Fronius welding systems at the factory. I've seen the same problem occur on several different systems. Motoman writes macro programs that change the weld schedule and settings on the Fronius welder immediately before starting the arc. The weld settings for previous weld don't always take effect before the arc starts. This works OK if the settings are the same as used for the previous weld. However if the previous weld was using spray transfer at a high voltage and the next weld is a small CMT weld on thin material, it will blow a hole in the part exactly as described by the author. I suspect that variations in the length of the wire stickout may determine why this problem occurs randomly. If the wire stickout is short, the welding conditions may have time to change while the wire is running in to the joint. If it is long the wire may already be touching the work and arc start may occur before the welding conditions change.
The authors fix for this problem is correct. Insert instructions that select the weld schedule and settings before the robot reaches the arc start position.
And if there comes a situation where the error is too random, and there is no such problem you can think of then its best to change the controlling variables one by one (Hit and trial) and observe that how does the machine react under the controlled set of commands. And thus, a correction factor can be applied.
When there is no obvious solution that you know of, Its always better to observe the machines under the repeated experiments with similar conditions and recognize the pattern. This will ultimately make things quite easier to diagnose.
That works only if you can get on site. When a ship in the middle of the Pacific calls for troubleshooting advice, you have only what is relayed to you with which to work. That makes diagnosing much more difficult.
There is great knowledge in the plant personnel, it's how you ask the question that can make a big difference. They often have a different langauge or "lack of formal training" but the info is really there. They may not know the exact word to use but with a observant engineer, you can determine so much of what is happening.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
The IEEE Computer Society has named the top 10 trends for 2014. You can expect the convergence of cloud computing and mobile devices, advances in health care data and devices, as well as privacy issues in social media to make the headlines. And 3D printing came out of nowhere to make a big splash.
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.