What can a simple mistake teach us about IRF840 FETs?

[Integral]

A recent project required me to connect a number of analog signals to a manufacturing floor data collection system. To do this I made a set of 4 connectors which I could but into the tool simply by separating existing connectors and inserting mine into the circuit. In my connector I replaced 1 wire with a 100 Ohm resistor to convert a 4-20ma signal to a voltage, along with wires and a third connector for the data collection system.

While testing my connectors I measured the voltage out to the data collection system, 3 of the 4 measured .9V the 4th measured .5V. They should have been approximately equal, further investigation reveled that I had made a mistake by putting the 100 Ohm resistor in the wrong position in one of the connectors, it was on the far left it should have been on the right side. It was a easy fix to move the resistor. After the fix I proceeded to determine the slope and intercept of the line needed to convert the voltage to engineering units (in this case pressure). When I applied the equation to my measured voltages, they were wrong. Not just a little wrong but way wrong, my points were no where near the computed line! I finally used the line to compute a table of values across the range of input values. Something immediately jumped out at me. The voltage which returned the correct pressure was ~.5V. I had seen that number! That was the voltage returned by the “incorrectly” built connector.

Further investigation reveled that indeed the correct current was on the 24V return line, not as specified in the manufacturer documentation on the 24V supply. It was my initial error which guided me to a correct solution, even thou it was simply not right according to the documentation I had.

We later found a online copy of the sensors documentation which showed that the 4-20ma signal was in the 24V return line.

Had I not made that initial mistake it is not clear how long it would have taken me to arrive at the root cause of my problems.

 

[Danger]

That's why I try to mess everything up at least once before getting it right. :uhh:

 

[berkeman]

I had seen that number!

Yep. That happens to me sometimes as well. I spend a significant amount of time debugging issues (in analog & digital circuits, in microcontroller circuits and firmware, in software, in systems, etc.), and you really develop a toolbox of techniques that you use to step through stuff like that. It sounds like you have similar experiences and a similar toolbox.

Some of the hardest ones, though, are when you see something once, and then a year or two later see something similar -- now that's connecting the dots across a long ways!

One of the best toolbox techniques that we use here is a kind of relatively non-invasive kibbutzing when the situation warrants it. If you notice somebody puzzling over a difficult problem and you might be able to help, you stop off and ask a couple simple questions, and maybe offer an insight or two that the other person hasn't been considering. Just by asking a couple questions or two, you can often help the person doing the debugging to see the problem in a different way, and in doing so, they end up getting to the root cause and the answer quicker than they could have done without the extra ideas.

In a way it wastes some time to have to stop and explain what you are doing to somebody else. But you definitely get to know who are the best people to stop and invest a few minutes explaining stuff to... after a time or two of having a great idea come out of a simple discussion, you learn to make time for those kibbutzing moments.

 

[Integral]

That's why I try to mess everything up at least once before getting it right. :uhh:

I can relate to that. I often find myself going in some form of an iterative loop, getting it wrong and trying again, each try getting a bit closer to the desired result.

 

[Integral]

..snip ...
One of the best toolbox techniques that we use here is a kind of relatively non-invasive kibbutzing when the situation warrants it. If you notice somebody puzzling over a difficult problem and you might be able to help, you stop off and ask a couple simple questions, and maybe offer an insight or two that the other person hasn't been considering. Just by asking a couple questions or two, you can often help the person doing the debugging to see the problem in a different way, and in doing so, they end up getting to the root cause and the answer quicker than they could have done without the extra ideas.

In a way it wastes some time to have to stop and explain what you are doing to somebody else. But you definitely get to know who are the best people to stop and invest a few minutes explaining stuff to... after a time or two of having a great idea come out of a simple discussion, you learn to make time for those kibbutzing moments.

Absolutely, one of my prime rules is when you start to frustrated with a problem is to take a brake, think about something else for a bit, then talk about the problem at hand. If you can find someone to listen, they do not even have to be real knowledgeable in the field of interest. Just have to explain the problem out loud to someone then getting the view from another set of eyes is helpful beyond measure.

 

[Danger]

I see the 'wrong' paths as learning experiences unto themselves. Even if I know the 'correct' way to do something, I always look for alternatives just in case I can find something better. Usually I can't, but sometimes I stumble across something that can help in a totally unrelated problem.
As for the 'kibbutzing', it seems to be almost like seeing a shrink. Someone who just encourages you to talk about a problem can force you to examine it from a different perspective. I talk to myself all the time (just in my head) while trying to figure something out. Maybe it's a side-effect of being ambidextrous, or maybe it's normal for everyone and I just haven't heard about it, but my right (artistic) and left (logical) hemispheres constantly debate things until they come to an agreement. The weird part is that these arguments are verbal (although not vocalized); the two sides actually 'talk' to each other.

 

[turbo]

Talking about a puzzling program to someone who knows little about that specific process can be helpful, because you have to get to the basics to explain to that person what the process is supposed to be doing, and that might show where your reasoning is leading you astray.

 

[Ivan Seeking]

The benefits of mistakes? I found that IRF840 FETs can be as good as firecrackers.

 

[ice109]

The benefits of mistakes? I found that IRF840 FETs can be as good as firecrackers.

:rofl::rofl: