Diagnose faults

Topic:- Observation.

Knowing your Problems

Analogy is an interesting way to open doors to progress. Humans are very good at seeing links between sometimes quite different things and in those links, seeing new approaches and new opportunities.
I recently decided to go back to microprocessor problems for a little while since I had no real or urgent need to continue with a knowledge pursuit. I needed an EPROM programmer to update the firmware in the house control computer, the AMC (autonomic microprocessor controller), and could not really justify the 100s of pounds that would be needed to get one, particularly for such infrequent use. So I decided to try and make one as economically as I could. I decided to build the device around my PIC development board. This does not have the necessary I/O capability so some new digital circuitry would be needed. I felt quite confident of being able to design and manufacture this circuit. However, I had never used the PIC to take information from a PC and do anything with it, other than using the PIC programmer that came with a development board.
The development system I have, contains many in built software solutions to perform a full range of tasks. One of these ready built solutions was to read and write data from the PC. So the first thing I did, before any circuitry design, was to build a simple data writing and reading routine on the PC, in LISP. The idea was to test out the main thing I did not know how to do, the data transfer and use, before embarking on anything else. Obviously, if I could not solve this problem, the design and construction of the circuit would be pointless.
Once the PC end was sort of done, at least provisionally, I needed to tackle the PIC end to receive the data and do something with it as well as send back some acknowledgement. Here, the simplest solution was to use the ready built routines, which I did. However, when it didnt work, I tried to find out what was going wrong but realised this meant disassembling and understanding the ready built systems. I quickly realised that the effort in doing this would take me further away from the place that I wanted to be. I needed to understand the simple elements of the trial system in order to create the larger system. The correct way forward was to confront the original problem head on and learn how to do the data transfer from scratch. This would mean that when things went wrong, I would at least have a chance of understanding why and being able to correct things. It also meant that I would understand the whole problem and be able to develop the improved requirement and to design something, anything I needed without the constraint of the ready built solutions parameters.
My thoughts concerning knowledge and its use in organisations are never far away. I saw a link between this situation and one where a company needs to find a solution to a problem. For instance, if the company has a rich set of data that it wishes to use to improve performance by adjusting a range of variables, it may see the problem as, what should I do with this data to give me the correct adjustments for the variables I need to improve performance? Along comes a third party and offers a black box that can be connected to all of the data at the input and all of the variables at the output and solve the problem. The company may be initially suspicious and may want to know what is in the box. The third party may wish to protect this information but offer prior case studies to show that the box really can deliver the desired results in these similar situations. Watch out for the word similar. The companys attention is now distracted from the original problem and concentrated on looking at how similar situations are. Later the third party may offer another case which is very similar.
This all looks good so the company purchases the box and connects it up to the data and the variables. It seems to work for a while, and then it does not, or seems to be failing. What is going wrong now? The company cant answer this because they never did understand the original problem; the only course of action is to bring back the third party or another, better, third party. Or should the company value its problems, seek to own them and seek to understand them? Should the company build new knowledge out of its operations and capitalise on the growth of knowledge, or should it give this opportunity away the third parties? Dont let reinventing the wheel frighten you off, there is nothing wrong with learning how to invent.

Record Status:- general interest. : Created on 9/2011 : Last updated on 11/2011.

Additional documentation should be added within the tool KST and then exported to the web resource.