Equifactor(R) and the SnapCharT(R)
How important is the SnapCharT(R) in the Equifactor(R) process? The TapRooT(R) system teaches that the first step is developing a good SnapCharT(R), and then gathering more detailed information from there.
But what happens when you develop your SnapCharT(R), analyze your failure, find a lot of information about the failure, but you don’t know where to put it in the SnapCharT(R)? Let me give you an example.
A reciprocating compressor has failed, with a very high vibration in evidence. Your troubleshooting has exhausted the “easy” stuff from your Equifactor(R) analysis (speed incorrect, lubrication system inadequate), and you have now been forced into a teardown of the compressor. Upon inspection, you find:
– heavily fractured piston
– a loose piston rod nut
– metal fragments in the cylinder valves
– water condensed on cylinder surfaces
Now, where do you put these items on the SnapCharT(R)? TapRooT(R) teaches that we normally construct a SnapCharT(R) in the order of occurence; that is, insert the information in the spot in the SnapCharT(R) at the time at which it occurred. However, in this case, when did these new datapoints occur? Did a slug of water enter the cylinder and cause the problems? Did the connecting rod nut become loose due to the failure, or did the loose nut cause the failure? These pieces of data should go in the SnapCharT(R) in the order that they occurred, but in this case, when did these events occur?
A solution to this problem requires several steps.
1. If at all possible, eliminate one of the possible causes by further analysis. In this example, if there is a dehydrator just prior to the inlet, verify it is working properly and is not saturated. If it appears to be working correctly, the water probably did not enter the cylinder here. It may have condensed after opening the cylinder, especially if the cylnder is activley cooled.
2. For what is left (in this case, loose nut or failed piston), you may be forced to just leave these conditions after the incident on the SnapCharT(R). This is not a cardinal sin. In fact, it is much worse to force a condition before the incident by guessing and put it in the wrong place. You now have conclusions being drawn on incorrect information. For example, if you say the nut came loose first and force it before the incident, you have effectively made this the cause of the piston failure when in reality it may not have been.
3. For whatever is left, analyze the most likely causes of these conditions. For example, what could cause the piston to fail, assuming the connecting rod nut was not loose? Is the compressor being operated above its rated capacity? In fact, in this scenario, you would find that the cylinders have been re-bored to increase throughput by 25% above vendor spec. Would we have found this if we had assumed the nut had come loose first?
In general, your SnapCharT(R) should be developed in order of occurence. However, especially with equipment problems, this may be difficult to accomplish. Don’t force your SnapCharT(R) just to be more asthetically correct, if this will introduce errors into your analysis.
This type of problem can also be seen in incidents involving drug testing (when was the drug ingested?) or autopsies.