Wednesday, October 5, 2011

Stupid Connector Pinout Problem

Today I spent half of a working day correcting the problem with wrong IDC2-10 connector pinout. The usual pattern in which pins are ordered is as follows:
1 3 5 7 9
2 4 6 8 10
In the User's Manual of industrial PC, to which I must connect, the picture looks like:
1 2 3 4 5
6 7 8 9 10
I was slightly alarmed when I saw it the first time, but I thought that this is their right to re-order pins on their own module. Today, when I tried to get my PCB and this third-party industrial PC to work together, it was revealed that pins on its socket are actually ordered in a usual way, as shown in the first block. The unusual order that I observed in the manual was result of mere inaccuracy of their documentation writer. Strictly speaking, this is not my fault, but if I would check the actual ordering of pins before working on PCB, it would save me several hours of my life. Instead, today I have had to do some mounted-wire soldering on all manufactured devices to bring PCB footprints pinout to an actual state.

UPD: They fixed this error in the latest version of the manual. I should had to check for the latest version before using it.

Saturday, October 1, 2011

CRM and Electronics/Software Development

In my spare time, I like to read one aviation forum. From there I learned that in the area of civil aviation there exists the whole concept about how members of aircraft flying crew should communicate and behave with each other, in order to achieve the best possible flying safety. I think, that something similar can be adopted to the field of electronics/software command development projects.

Crew Resource Management explanation on Wikipedia

CRM is all about preventing, detecting and correcting (even potential) human errors at the earliest possible stage, thus achieving the best flight results and safety. If you will regard flight of an aircraft as a multi-people PROJECT, you may naturally see that CRM principles can be applied also to electronics/software multi-people development PROJECTS. Unfortunately, I did not hear that even basics of such approach are studied in any university. This leads to very big role of project leader and his personal communication skills in overall success of any development project.
Such dependency could be mitigated, in my view, by working out and accepting concept of interpersonal communication in software/electronics development industry.

In particular, co-pilots are specially trained to correct the captain and to question potentially wrong decisions if it seems appropriate in a given situation. But in the area of electronics/software development, authoritarian project leader often has too much power and possibilities to send a project in totally wrong direction.

Monday, September 26, 2011

Wrong Pin Numbers in PS/2 socket

Today I spent almost the whole working day to make (solder) a few adapters to remedy my PCB designing error. The problem was that I used MINIDIN-6 surface-mount female socket on my PCB, and I incorrectly routed PCB tracks to pins of that socket. It revealed that I used mirrored view of the socket when direct, non-inverted view should be used. Only one additional checking procedure would save me almost a whole working day.

PS/2 connector on Wikipedia

Tuesday, September 20, 2011

Forms (Windows) Interface Font

Delphi 7, while being very powerful IDE for Windows development, has some deviations from standards set by Microsoft. One of them is that by default, VCL forms use MS Sans Serif, 8pt font for all controls. This may look good on developer's machine, but on some target machines, this may look very bad because of lack of this font and substituting it for some another.
Standard behavior would be to use default OS Dialog font.
To overcome this, in each form's OnCreate event, invoke the following procedure:

procedure SetFormFontToSystemDefaultFont(Form: TForm);
var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(NonClientMetrics);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0);
  Form.Font.Handle := CreateFontIndirect(NonClientMetrics.lfMessageFont);
  if Form.Scaled then
  begin
    Form.Font.Height := NonClientMetrics.lfMessageFont.lfHeight;
  end;
end;

(Set ParentFont property to True for all controls on the Form for this to have effect).

Sunday, September 18, 2011

Delphi Inactive Forms Behavior

In Delphi 7, there is one drawback in VCL, which appears as lack of any indication of which window is active when user clicks with mouse on inactive window. Standard behavior of compliant windows application is to flash the title bar of active modal window in that case, but Delphi forms do not respond to this action.

To remedy this, add the following code to your modal forms:
type
  TMyForm = class(TForm)
  ...
  protected
    procedure CreateParams(var Para: TCreateParams); override;
  ....
  end;
.... 
procedure TMyForm.CreateParams(var Para: TCreateParams);
begin
  inherited;
  Para.WndParent := GetActiveWindow;//to allow title flashing of child modal dialogs
end;

Friday, September 16, 2011

Electronic Component Misorientation Problem

Today the first preproduction batch of my devices, consisting of four PCBs (Printed Circuit Boards), was finally completely mounted, and I began to power them up in order to test the mounting accuracy and device functionality. It was revealed during mounting that I had placed some components too close to each other, although this will not prevent embedded software developers from using the devices to debug their firmware. When I started to bring the live into the device, I found that at one position, on all devices, stabilitrons were mounted in opposite polarity. It seems that assemblers who performed actual soldering, are accustomed to the fact that diodes' Anode pole are usually goes to positive polarity, and Cathode pole - to negative. This is true for simple forward usage of regular and shottky diodes, but stabilitrons need to be used in reverse direction. I marked where the Anode should be on assembly drawing, nevertheless it seems that assembler was guided by datasheet, where Anode mark is showed, and polarity of PCB padstacks. I'm thinking about resorting to using SOT-23 case for this component in second version of a scheme (for those who are not familiar with it: this is 3-leads case, it have 2 leads on one side and one on another, thus it is impossible to place it in wrong orientation). It may be _slightly_ more expensive than currently used 2-leads case, but it will leave us from necessity to think about right orientation and to control it.

It seems, that many engineering decisions are often driven by similar motivation - to ease manufacturing and/or repairing processes, at price of slightly increasing components cost.

It also reminds me that responsibility of everyone who design any type of interfaces, is to make every interface as clean and consistent as possible, and to make sure that working with this interface requires from user absolutely minimum of possible knowledge of a system.

SOT-23 drawing

Thursday, September 15, 2011

On Interface Design

For historical reasons (it was chosen by management of our firm to process salary payments), I have an account in one bank, with Internet banking option. The problem with its bank-client application, which should be used to access an account and to perform financial operations, is that it is evident that in some points it looks very unprofessional. The most prominent things are appearing of default Borland C++ Builder Icon as an Icon for Alt+Tab window and in the title bar of some windows, and inability of built-in browser window to resize accordingly when its parent window is expanded to the whole screen size. I believe that their application does not contain flaws that may compromise data transfer security, but if I would choose from different banks now, I would not stick with such a poorly written software. Their offices look as they should be - clean, modern, with polite staff, but it seems that their management do not realize that when I work with Internet banking, the face of the bank is actually the software.
After noticing that, I began to tend to double-check all my user interface look-and-feel features and logic, although neither of my programs deal with user's financial data.