Technical Discussion
Home LogIn Create A New Entry LogOut
Hello! Edit
Friday, December 25, 2009 These post the projects completed ...
PAC-3 Missile Test Systems Edit
Saturday, December 19, 2009 PAC-3 Missile Test Systems
It is good time to come back here after years working to upgrade the PAC-3 Missile Test Systems for Lockheed Martin, Corp. The main thing was to design and develop embedded software for the MBTC (Mux Bus Test Card).

The MBTC card is an electronic circuit board that bases on the INTEL mother board computer with two add-on electronics cards - the PCI card bus and the VME-to-VXI converter card.

The PC card bus interfaces to the Unit Under Tests. (UUTs)
The VMI-to-VXI converter card interfaces to the Labwindow/CVI software developer.

The MBTC card operates as a heart of the PAC-3 Missile test systems and does the following works:
a) Receiving commands, messages or data from the LabWindow/CVI software developer through the VME shared memory.
b) Processing commands, messages or data that read out from the VME shared memory and send them to the Unit Under Tests (UUTs).
c) Receving commands, messages or data from the UUTs and send them back to the LabWindow/CVI software developer through the VME shared memory.

The MBTC cards have been using in the PAC-3 Missile test systems. It has been working well, but there are some problems need to be fixed and improved to make a stable and reliable system.

The following problems have been making the unstable and unreliable system.
1. There is no handshake between the LabWindow/CVI software developer and the MBTC card. The LabWindow/CVI software developer communicates to the MBTC card through the VME shared memory. What would happen if the LabWindow/CVI software developer reads data out the VME shared memory while the MBTC card updates the VME shared memory - data confused ->Fail. It is a system fail, and it is not an UUT fail.

Improving: Redevelop LabWindow/CVI software test sets such that it reads data out the VME shared memory when it gets handshakes from the MBTC card.

2. LabWindow/CVI software test sets have been running on the Window-2000 with a low speed CPU compared to the MBTC card running on Window-XP with the high speed CPUs. Therefore, The MBTC card reads and processes commands, messages or data return from the Unit Under Tests (UUTs). After that it puts them back to the VME shared memory and assumes LabWindow/CVI software processing them at right time. It goes on to update the VME shared memory. However, in case the LabWindow/CVI software test set is not fast enough to response to this. It leads to some cases which data is overwrited by new data comming - data lost -> Fail. It is a system fail, and it is not an UUT fail.

Improving: It is not easy to upgrade the system because cost & time. The best solutuon redevelops LabWindow/CVI software test sets so that they do not run in a real time environment. they need to analyze commands, messages or data from the VME shared memory and inform to customer the test pass or fail. The MBTC card shall collect all needed infos and send the handshakes to the LabWindow/CVI software developer that informs data to be ready. Then the LabWindow/CVI software developer starts to read data out from the VME share memory and analyzes them - Sounds easy.

3. There is a very stupid thing in LabWidow/CVI software test sets that has remained in the PAC-3 Missile test systems for very long time (10 years ?) and nobody would like to make changes. The Labwindow/CVI software developer bases on few hundred miniseconds to read commands, messages or data from the VME shared memory. This is a real stupid thing and drives test engineers creazy *smile*(I saw this when working with the GPU - G Processing Unit - test set). What happens if they upgrade computer or make alter in Labwindow/CVI software test sets concerning to timing? Then system timing will vary and The PAC-3 test systems will fail even though the UUTs are good. Therefore, We have been having an unrelaible and unstable test system.

4. The hardware that based on FPGA and VHDL codes has been having some real problems.
  • There is no hardware specifications that details hardware requirements, so it is too risky to modify VHDL codes
  • The hardware engineer modified VHDL codes leading far away from the original requirements. He tried to make it working like the old system, but he did not take time to understand what the old system requires?
  • There is no investigation what are the old system problems? Therefore, the hardware engineer modified VHDL codes did not solve the old system problems and could inject more problems to the new MTS system
  • Unluckily, the old VHDL code was destroyed by new one and nobody kept the backup, so how to estimate the new MTS system is good or bad, stable or unstable, right or wrong? Unknown


  • 5. Anything else ... I shall tell you later *smile* . Good Luck - Test Eqiupment Team.
    NCI Group Project Edit
    Saturday, December 19, 2009 Builder System - Graphic User Interface
    Working to create a window application (Order Writer) for the NCI Group Company (Metal Building Components) that signed a software development contract to ORIONNET System Company. The following tasks required:
    o Design and develop software to build the Order Writer (OW) system that is a sub-window application of the Builder System (BS) that allows user’s to enter and modify data in “free format text fields” of length 100-255 characters.
    o Modify codes to create the Acrobat document that is a report generated from the data in these OW Access data tables.
    o This application is to write in C++ with Visual Studio 20005 using MFC (Microsoft Foundation Classes).
    o Work with end-users from initial requirements, design and implementation through maintenance and enhancements. Provided orientation and support to programmers of the NCI Group Company.
    NewMailer project Edit
    Monday, December 10, 2007 This project used to manage customers mails. Completed and added to the service page, will move to suitable place.
    Test Edit
    Wednesday, October 31, 2007 Test Pages
    Data Interface Communication Edit
    Friday, December 24, 2004 The control systems comunicate basing on the specification data or functions. It also calls protocal. However, these specifications are the confidential data, so each company has its owned spec. This section will discuss few of them and hope you will have good infos.
    Example Interface functions in a tester Edit
    Friday, December 24, 2004 Will discuss how to develop the interface functions in a tester. How to send a pointer through a serial communication to firmware site.
    Robotic a tester Edit
    Friday, December 24, 2004 Think of a network in a CPU or DSP chip, There are some interrupts in a DSP chip or CPU, each of them will update a token when it is called. Therefore, we could see what happens in the CPU or DSP and a message sends back to application layer in the special cases. Will discuss more later.
    How each bit in a byte implemented Edit
    Friday, December 24, 2004 Implemented the control system usng bit as protocal interface.
    Firmware Supports radio Control System Edit
    Friday, February 04, 2005 Completed correcting doccumentation, and prepare to post to web
    How to design a tester Edit
    Friday, December 24, 2004 Will discuss how to design software layers for a tester.
    Serial Communication State machine Edit
    Friday, December 24, 2004 Will be posted.
    State machine of the serial communication Edit
    Friday, December 24, 2004 This is serial communication that is implemented to get and post data frames sending or receiving from other sites.



    Home News Products Services Activities Contact us
    Top of Page

    Copyright © Thanh Nguyen 2004 - 2018
    ServerPath