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.
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.