Four Cases of Ultrasound Equipment Failure Analysis and Repair

This error is very common in LOGIQ E9 machines. Although the prompt message is always "system error, please reboot the system," the causes of the fault vary widely. Based on experience, the problem is initially judged to be in the front end.
 

First, turn off the power and check all front-end boards. Open the front cover and carefully check that each board has liquid-like traces. On the GRLY board, a circuit is obviously burned out, which should be caused by liquid entering and causing a short circuit in the circuit board. So use anhydrous alcohol to clean the components. After completion, install and test the machine, the problem still exists. Because except for the GRLY board, other components have no visible damage, first replace the GRLY board, after powering on, the fault is different from before, the error message appears a few minutes after the application is loaded, then perform a T/R Channel test on the machine, the result is shown in Figure 1.

Figure 1 T/R Channel test diagram

It can be seen that the middle GTX is problematic. After multiple tests, it is basically verifiedThis conclusion. So replace the middle GTX, after powering on and scanning the test, the error message no longer appears. But it was found that the image is a bit like a post-processing problem, several probes have been tested the same, check the log, judge that MRX may also have a problem, finally after replacing MRX, the fault is completely resolved.

The entire fault handling process replaces three circuit boards: GRLY, GTX, and MRX. For faults caused by rodent infestation or accidental internal liquid ingress, the handling must be particularly careful. It is best to use anhydrous alcohol or precision circuit board cleaning solution to clean the circuit board. Do not use 75% alcohol to clean it, otherwise it may cause secondary damage to the machine. At the same time, it is necessary to improve the awareness of prevention and carry out periodic and preventive maintenance of the machine to prevent the machine from being repaired again after the fault is repaired, avoiding major losses.

If a "SystemError" is reported in the APPLICATION LOAD phase,Error message, the prompt message is the same as LOGIQ E9 R4.3.0 pressing the power button to turn on the machine, when the application is loaded, it reports "Systemerror", the prompt message "system error, please reboot the system: When the application is loaded, it reports "Systemerror", the prompt message "system error, please reboot the system.", sometimes it can Enter the scanning interface, but most of them cannot.
 

Usually this type of problem is caused by front-end hardware. When the system detects related problems,The safe machine will automatically protect itself, then stop loading, and give a "System Error" error message. Currently, this type of fault mostly occurs in GTX, Digital Receive Board (DRX) (R3), and Main Power Supper (MPS), such as hardware configuration errors or overloads. However, to determine which hardware is problematic, it is necessary to consider comprehensively and use effective troubleshooting methods. The first is to check the ERROR LOG running log, which is caused by the channel FPGA (Field-Programmable Gate Array) control part, and the ERROR LOG will generally reflect it.

(1) GTX faultThe following is the machine's error log. By checking the ERROR LOG, we can easily find that GTX4 at the LE9 physical location is having a problem:
 

Error; EA Error Handler(3340); Error from House Keeping: GFI 'Hardware Exception: Sub Type31: GFE Ch0 empty-GFE Ch1 empty GTX3 HVFAULT TS_LEVEL_OK_N. Severity: Fatal HW.'
 

Info; DFEManager(3340); Handle RunFlag: setting Run-Block flag to false!
 

Warning EA Error Handler(3340); Stops scan.
 

If the ERROR LOG does not indicate which GTX it is, a simple method is to use the rightmost position to unplug and plug in the GTX one by one until it is found that when a certain board is unplugged, the system no longer reports an error, at this time it can be basically determined that this GTX has a problem. Most of these faults are short circuits in the small output transformer of the GTX, causing a short circuit in the high-voltage drive circuit of the channel, so that the system detects an overload and then protects it.

(2) DRX fault。If no obviousError message, the fastest way is Common Service DesktopPerform a T/R Switch test. This test can help locate which GTX or DRX channel is having a problem. The test results are shown in Figure 2.

Figure 2 T/R Switch test diagram

(3) MPS faultFor MIAN POWER SUPPLY faults, weCan also find the corresponding information through ERROR LOG:
 

Debug; acqGfi(3600); WatchDog: Watchdog still alive, errors =0x0060 [--(ACFAIL)-(TS_LEVEL_OK)----];
 

Friday, Feb 12 07:26:43, 2010; info; acqHousekeeping(3068); TxPs event log;
 

seq[01]date[00/00/00]time[00:02:19]source [System(rack)supply]type[Error]detail[FanFailure].
 

Meanwhile, pay attention to the P4 interface on the MIANPOWER SUPPLY, especially whether the fan drive plate with 24V voltage is running normally. If it is rotating, it indicates that the 24V output has no problem. The P4 interface and pin voltage definition diagram are shown in Figure 3.
 

Figure 3 Main power supply P4 interface (a) and pin voltage definition diagram (b)

If the instrument does not start normally, the computer malfunction [9] should be considered first. Check the working status of each port of the computer one by one to understand the fault phenomenon and log files. For problems such as "System Error", check the ERROR LOG file first! We can get most of the fault reference information from it; if there is no typical prompt, use Service Diagnostics to perform a T/R Switch test to help locate the GTX or DRX; the exclusion method can also be used to swap out the GTX and DRX to determine the faulty board.

The device intermittently appears to Enter the virtual interface after powering on and reports "systemerror"。

Software or port data loss during machine startup is prone to cause the system virtual interface. From the error message, it is considered that the front end was not normally recognized during startup, causing the machine to Enter the virtual interface. Therefore, the system and application were reinstalled first. However, after the reinstallation, the fault remained unchanged, and the software factor was ruled out. Then the hardware problem was detected, and by analyzing the device's work log and comparing it with the log during the normal period, it was found that the MPS voltage was lost in the log when the machine reported an error. It is judged that it may be a MPS power supply fault that caused the front end not to be recognized during startup, so the MPS was replaced. However, the same fault reappeared a few weeks after the new MPS was replaced. The same fault with two MPSs feels unlikely, but the voltage loss error is still found in the work log. Considering that the backplane fault may also cause the power supply to fail to communicate normally with the front end, the band-pass filter (Band Pass, BP) board was also replaced. Two weeks after replacing the BP board, the device still intermittently encountered the problem of powering on and Entering the virtual interface. This time, TS was used to carefully analyze the log, and it was found that the latest log had a clearer log pointing to MPS causing this fault.

Error;EAErrorHandler(1948);Error from HAL:TxPS voltage readback mismatch.Severity:NonFatalSW.

Info;DFEManager(1948);HandleRunFlag：setting RunDfe flag to false.

Error;ScUdt.DataModule(1948);RingBuffer:stop:Error;ScUdt.DataModule(1948);Cannot call stop() with state FreezeWarning;EAErrorHandler(1948);Stops scan.

Warning;EchoScanner(1948);Stopping backend on a un-recoverable EA error message.

There are abnormal records of the transmission power supply voltage when the fault occurs. JudgmentThe possibility of MPS failure is very high. After replacing MPS again, MPS measurementTest passed, and after later use, the machine completely recovered to normal.

This fault is mainly caused by the MPS board itself losing voltage and not being recognized by the machine.However, the same fault still occurred after replacing the new circuit board, which forced us to consider the backplane connected to the MPS. By analyzing and comparing the error logs before and after several times, it can finally be determined that the fault is caused by the superposition of two factors: the MPS board itself is damaged, and the backplane contact problem causes the MPS board's power supply to fail to communicate normally with the front end.

For this type of fault, careful analysis and comparison are required. Because the fault, from surface analysis toActual operation is all directed at and aimed at the same MPS circuit board, and finally, in addition to the fact that the board itself is indeed damaged, the contact problem related to the MPS board is also found. Therefore, during the maintenance process, we must carefully think and analyze, carefully observe and compare, and must not be limited to one area to search.