How do you usually approach a problem?

[hihiip201]

Hi:Me and my team are currently building a 3d printer for a senior project, and throughout this project I have noticed that we often run into problems with calibration, drivers, etc. we find this troublesome because we often find it hard to identify the source of the problem.So my question is , how do you usually identify a problem? instead of thrusting into different direction blindly, how do we effectively deduce the source of the problem, I often just try taking off parts one by one and see when it works and when it does, but I am only amble to narraow down problems so far because if you remove part A, things may run smoothly but it's not clear rather or not part A is the source of the problem because it could be that part B is causing the problem in part A (i hope I am making sense).so just in general, how do you guys go about identifying a problem?edit: I am talking about problems/bugs in general in engineering, including mechanical (which is what I had trouble with the most).
thanks

 

[jedishrfu]

Programmers often run into this problem of trying to locate a bug. We do it by adding print statements at strategic points and see what's going on. Say we have data being processed by 5 different modules A, B, C, D, and E and we find that module E output is wrong. We run the program again focusing on first module C (via prints) if the data looks right then problem must lie in D or E so we look at D (because its in between) if its output is wrong then we know the bug is somewhere in D. We repeat the strategy as we look at the code in D and find the bug.

Similarly in electronics we would use a volt meter or oscilloscope to look at circuit signals in key spots until we find the problem. Electronics debugging is a real art since you can't just pop every component out to test it but instead must understand something about the circuit and how it works.

 

[Bobbywhy]

hihiip201, As jedishrfu mentions above, one must understand the circuit in order to troubleshoot a problem. This means a complete and absolute knowledge of the system from the simplified functional block diagram level to a detailed theory of operation. If you don't know what these terms mean you've a long way to go!

Then you need basic test equipment like a multimeter and oscilloscope, and you need to know how to use them correctly. More specialized systems require special test equipment.

Here are two guides for you to use to assist you to prepare yourself:

Elements of System Level Troubleshooting
http://www.allaboutcircuits.com/videos/5.html

here’s a textbook that costs about US$82.00:
Troubleshooting Electrical/Electronic Systems
3rd Edition
By: Glen A. Mazur, Thomas E. Proctor
http://www.atplearning.com/troubleshooting-electricalelectronic-systems-p14.aspx

 

[hihiip201]

Sorry guys I didn't mean to lead you guys in the wrong direction, but with problems encountered in engineering in general, not only electrical or computer engineering, but mechanical driving, how would I go about identifying problems?

 

[Bobbywhy]

Start by trying this:

http://en.wikipedia.org/wiki/Fault_detection_and_isolation

On the Wiki page study the "See Also" items, and the references at the bottom, and also, do a Google Search using the terms "fault isolation" for many other examples.

 

[Danger]

My first approach is always to just take the thing apart down to its smallest bits and then put it back together. If it still doesn't work, then it's time to get creative. A lot of the time, though, that initial rebuild will knock loose whatever was causing the problem.

 

[Bobbywhy]

Example: An airborne radar system in a fighter aircraft may have a malfunction, maybe mechanical, maybe electrical. It is up to the maintenance technician or engineer to discover which part is faulty, replace it, and test the system to prove the fault has been removed and the system functions 100% correctly again.

Since the radar system consists of about TEN replaceable subassembly units the worker could begin by changing out one unit with a known good unit and then testing the system. If the testing shows that the fault remains, then she knows that the fault was NOT in that unit replaced. Now she may continue this "shotgun" approach, as we call it, and just continue to change out subassemblies until finally one fixes the fault and the system tests A-OK.

Or, she could use the technique described in my post number three (a complete and absolute knowledge of the system from the simplified functional block diagram level to a detailed theory of operation). Knowing how the system functions (mechanical or electrical) she can to deduce from the failure symptoms WHICH subassembly is likely to be causing the fault, then change that subassembly, and retest to verify.

 

[Danger]

the worker could begin by changing out one unit with a known good unit and then testing the system. If the testing shows that the fault remains, then she knows that the fault was NOT in that unit replaced. Now she may continue this "shotgun" approach, as we call it, and just continue to change out subassemblies until finally one fixes the fault and the system tests A-OK.

That is always my second approach if my first doesn't work. Incidentally, there is a peculiarity regarding cars in this regard. Every time that you disassemble and reassemble an automatic transmission, there is one part left over. No one knows what it is, and the thing works better without it.

 

[jim hardy]

General approach is "draw an imaginary circle around problem and gradually tighten that circle".

Programmers will tell you fastest way is a "Binary Search", isolating the trouble into one half or the other of your imaginary circle.

So in the ten board example given above:
one could swap half the boards from a good system; that tells you which half contains the bad board.
If that cures it put half the original ones back,
and continue to isolate it to one board that way.

That should isolate one of ten boards in maximum of four tries.
But one is seldom so lucky.

 

[jedishrfu]

General approach is "draw an imaginary circle around problem and gradually tighten that circle".

Programmers will tell you fastest way is a "Binary Search", isolating the trouble into one half or the other of your imaginary circle.

So in the ten board example given above:
one could swap half the boards from a good system; that tells you which half contains the bad board.
If that cures it put half the original ones back,
and continue to isolate it to one board that way.

That should isolate one of ten boards in maximum of four tries.
But one is seldom so lucky.

That's not how we'd do it. That's how an engineer imagines how programmers do it. We don't touch hardware due to union rules and wait for the engineer. :-)

 

[Bobbywhy]

This link from post number three offers this:

“Some of the strategies used in troubleshooting include block diagram thinking, signal tracing, signal injection, diagnostic software, observation and substitution.

Observation; the most important tool in your troubleshooting toolkit is the power of observation- when we say ‘observation' this is all of the senses, you can see but you can also smell, and you can also hear, and often times in a diagnostic system it is not always what you see, sometimes it's what you smell that tells a lot. Those of you that have been around in this business you know there that's smell of burning components that tells you something is very wrong. Sometimes even you'll hear sounds that shouldn't be there.”

Elements of System Level Troubleshooting
http://www.allaboutcircuits.com/videos/5.html

 

[jim hardy]

That's not how we'd do it. That's how an engineer imagines how programmers do it. We don't touch hardware due to union rules and wait for the engineer. :-)

Indeed, i have high regard for programmers . In one way you guys are quite fortunate - software doesn't break, hardware does.

But what is a simple hardware guy like myself to make of this?

In computer science, a binary search or half-interval search algorithm finds the position of a specified value (the input "key") within a sorted array.[1][2] In each step, the algorithm compares the input key value with the key value of the middle element of the array. If the keys match, then a matching element has been found so its index, or position, is returned. Otherwise, if the sought key is less than the middle element's key, then the algorithm repeats its action on the sub-array to the left of the middle element or, if the input key is greater, on the sub-array to the right. If the remaining array to be searched is reduced to zero, then the key cannot be found in the array and a special "Not found" indication is returned.
A binary search halves the number of items to check with each iteration, so locating an item (or determining its absence) takes logarithmic time. A binary search is a dichotomic divide and conquer search algorithm.

http://en.wikipedia.org/wiki/Binary_search_algorithm

You're right - i can only imagine. :)

 

[timthereaper]

If you want things as general as they get, a system is a collection of components with inputs connected to outputs that define a path of logic. To troubleshoot an anomalous output, check the inputs of each component in the path. This means you should at least know what each component does, i.e. what outputs should be generated for a specific input. If you check the inputs and they're wrong, then something is wrong up the line somewhere. If the inputs are right and the outputs are right for that component, then check that component off your search list. If the inputs are right for that component and the outputs are wrong, then you have a bad component and you need to replace it or search within that component for bad sub-components.

That having been said, the differing methods of problem solving are really based on how well you know your components and your system. If you don't know anything about the components or system logic except what the "right answer" looks like, you'd probably use the "shotgun" approach (what I do when I work on cars :-) ). The "take apart a working system" method usually is used when you don't know what the individual components really do, but you know the general operation of the system. Individual component testing is what you would do if you understand your components and system. If you practically know how everything was built/created, then you can even do sub-component testing.

Of course, any mixture of these problem-solving methods will be employed depending on your knowledge of components. For example, a programmer working with an API knows his/her code really well, but has only as much knowledge about the inner workings of the API calls as the available documentation contains and their own testing. This kind of situation can also occur in mechanical and electrical systems as well, since you typically buy components from vendors that contain specs for their products, but you generally won't know the intricate details of the product.

 

[jehan60188]

tagging this topic to read later