Troubleshooting methods, systems, and storage media for etching machine chamber control systems

Abstract

This disclosure provides an anomaly handling method, system, and storage medium for an etching machine chamber control system. The method is applied to a host computer within the etching machine chamber control system. The system also includes a main unit, a relay device, and multiple lower-level devices. Each lower-level device corresponds to a chamber, and each chamber corresponds to multiple coils. The main unit communicates with the host computer, and the host computer communicates with each lower-level device through the relay device. The method includes: acquiring target fault codes corresponding to each lower-level device at preset intervals; if a communication connection with any lower-level device is detected to be broken, injecting a software virtual fault bit into the most recently acquired target fault code of the corresponding lower-level device; determining a fault handling strategy for each lower-level device based on its current operating status and the target fault code, and executing the determined fault handling strategy. This disclosure improves the flexibility of anomaly response.

Description

Technical Field

[0001] This disclosure relates to the field of semiconductor manufacturing technology, and in particular to an abnormality handling method, system, and storage medium for an etching machine chamber control system. Background Technology

[0002] Etching machines are critical equipment in semiconductor wafer manufacturing processes. Their coil control systems typically include a host computer, a main unit (such as an EAP system), and multiple lower-level devices (such as PMA / driver boards), each corresponding to a process chamber. The host computer communicates with each lower-level device through a relay device, and the main unit and host computer exchange data via a communication protocol (such as the SECS / GEM protocol). During etching machine operation, abnormal states of the lower-level devices and communication links directly affect the stability of the process and wafer yield; therefore, anomaly handling methods are an important component of the etching machine chamber control system.

[0003] The current method for handling anomalies in etching machine chamber control systems typically involves the host computer periodically reading hardware fault codes from various lower-level devices, then reporting an alarm to the main unit based on the fault codes, or triggering corresponding shutdown protection actions. This method is too rigid in handling anomalies and cannot flexibly cope with various fault types. Summary of the Invention

[0004] In view of this, the purpose of this disclosure is to provide an anomaly handling method, system and storage medium for an etching machine chamber control system to improve the flexibility of anomaly response.

[0005] In a first aspect, embodiments of this disclosure provide an anomaly handling method for an etching machine chamber control system, applied to a host computer in the etching machine chamber control system. The system further includes a host, a relay device, and multiple lower-level devices, each lower-level device corresponding to a chamber, each chamber corresponding to multiple coils. The host is communicatively connected to the host computer, and the host computer is communicatively connected to each lower-level device through the relay device. The method includes: acquiring target fault codes corresponding to each lower-level device at a preset cycle; wherein, the target fault code is generated by masking the hardware fault codes of the corresponding lower-level device in the current cycle with a specific hardware fault type using a preset fault mask of the corresponding lower-level device, the hardware fault code being used to define fault states bit by bit, each bit corresponding to a hardware fault type; if a communication connection with any lower-level device is detected to be disconnected, injecting a software virtual fault bit into the most recently acquired target fault code of the corresponding lower-level device; determining a fault handling strategy for each lower-level device based on the current operating state and target fault codes of each lower-level device, and executing the determined fault handling strategy.

[0006] Optionally, before the step of acquiring the target fault code corresponding to each lower-level device at a preset period, the method further includes: sending a preset fault mask corresponding to each lower-level device to the corresponding lower-level device, so that each lower-level device performs a bitwise AND operation between the preset fault mask and the most recently acquired hardware fault code to generate a target fault mask; wherein, the preset fault mask is used to define the masking status of each hardware fault type bitwise, with each bit corresponding to the masking enable of a hardware fault type; and returning the target fault code as part of a communication response message to the host computer.

[0007] Optionally, the step of injecting a software virtual fault bit into the most recently acquired target fault code of the corresponding lower-level device if a communication connection with any lower-level device is detected to be disconnected includes: detecting the communication response status of each lower-level device according to the preset period; if any lower-level device does not respond within at least one historical continuous period, then determining that the communication connection with the corresponding lower-level device is disconnected; setting a reserved software virtual fault bit in the most recently acquired target fault code of the corresponding lower-level device; wherein, the software virtual fault bit is a reserved bit in the hardware fault code for which no hardware fault type is defined; and maintaining the set state of the software virtual fault bit during the period of communication connection disconnection until the communication connection is detected to be restored.

[0008] Optionally, the step of detecting the communication response status of each lower-level device according to the preset period includes: acquiring the actual status information and actual output data of each lower-level device according to the preset period; if the acquisition fails in the current period, incrementing the no-response count bit of the corresponding lower-level device; if the acquisition is successful in the current period, resetting the no-response count bit of the corresponding lower-level device; when the no-response count bit of any lower-level device is greater than or equal to a preset number of times threshold, it is determined that the corresponding lower-level device has no response in at least one historical continuous period.

[0009] Optionally, the step of determining the fault handling strategy for each lower-level device based on its current operating status and target fault code, and executing the determined fault handling strategy, includes: for lower-level devices currently in an idle state, determining a new fault based on the corresponding target fault code, displaying the new fault, not reporting an alarm to the host, and not stopping the operation process of the corresponding chamber; for lower-level devices currently in a non-idle state, determining a new fault based on the corresponding target fault code, reporting an alarm to the host, and stopping the current operation process of the corresponding chamber.

[0010] Optionally, the step of determining the new fault based on the corresponding target fault code includes: performing a bitwise XOR operation on the previously processed target fault code and the most recently acquired target fault code to obtain a changed fault bitmask; performing a bitwise AND operation on the changed fault bitmask and the most recently acquired target fault code to obtain a new fault bitmask; and determining the fault type indicated by the new fault bitmask as the new fault.

[0011] Optionally, the method further includes: if the fault corresponding to the fault bit in the target fault code is detected to be eliminated, then sending an alarm clearing event for the corresponding fault to the host; if the communication connection with any lower-level device is detected to be restored to normal, then clearing the software virtual fault bit from the target fault code of the corresponding lower-level device; wherein, the determination condition for the communication connection to be restored to normal is: the target fault code of the corresponding lower-level device is successfully obtained in any preset period, and the no-response counter bit has been reset.

[0012] Optionally, before the step of acquiring the target fault codes corresponding to each lower-level device according to a preset period, the method further includes: creating a control instance corresponding to each lower-level device, maintaining the current operating state of the corresponding lower-level device through the state machine of the control instance; when a communication connection with any lower-level device is detected to be disconnected, switching the current operating state of the control instance of the corresponding lower-level device to the disconnected state; when a communication connection with any lower-level device is detected to be restored, switching the current operating state of the control instance of the corresponding lower-level device from the disconnected state to the idle state.

[0013] Secondly, this disclosure provides an etching machine chamber control system, the system comprising: a host computer configured to execute the etching machine control method; a host computer communicatively connected to the host computer; a relay device for protocol conversion of communication data between the host computer and lower-level devices; and multiple lower-level devices communicatively connected to the host computer via the relay device, each lower-level device corresponding to a chamber, and each chamber corresponding to multiple coils.

[0014] Thirdly, this disclosure provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are invoked and executed by a processor, the computer-executable instructions cause the processor to implement the above-described abnormal handling method of the etching chamber control system.

[0015] The embodiments disclosed herein bring the following beneficial effects: The aforementioned anomaly handling method, system, and storage medium of the etching machine chamber control system differentiates the masking of different hardware fault types through fault codes, filtering out fault types that do not require a response before they are acquired, thus avoiding unnecessary alarms or shutdowns triggered by non-critical faults. By injecting virtual fault bits into the software, the on / off status of the communication link is incorporated into the target fault code as a virtual fault, allowing hardware and communication faults to be handled uniformly, avoiding misjudgments or omissions due to information fragmentation. By determining the corresponding processing strategy based on the current operating status of the lower-level device, the fault response method matches the actual working scenario of the equipment. The same fault can be assigned different processing methods under different operating states, forming a multi-dimensional and flexible anomaly response mechanism, thereby significantly improving the flexibility of anomaly response while ensuring the safe operation of the equipment.

[0016] Other features and advantages of this disclosure will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the disclosure. The objects and other advantages of this disclosure are realized and obtained through the structures particularly pointed out in the description, claims and drawings.

[0017] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 This is a flowchart of an embodiment of the abnormal handling method of the etching machine chamber control system in this disclosure; Figure 2 This is a schematic diagram of an etching machine chamber control system according to an embodiment of the present disclosure; Figure 3 A schematic diagram of an etching machine provided in an embodiment of this disclosure; Figure 4 This is another schematic diagram of the etching chamber control system in an embodiment of this disclosure. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0021] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in this disclosure, claims, and accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0022] It is understood that the etching machine control method provided in this embodiment is applied to the host computer in the etching machine chamber control system. The system also includes a host, a relay device, and multiple lower-level devices. Each lower-level device corresponds to a chamber, and each chamber corresponds to multiple coils. The host is communicatively connected to the host computer, and the host computer communicates with each lower-level device through the relay device. The host computer can be an industrial control computer or embedded controller deployed on the etching machine side, used to receive control commands from the host and interact with each lower-level device through the relay device. The relay device is deployed between the host computer and the lower-level devices to realize protocol conversion and signal relay of communication data. It is connected to the host computer through an uplink communication link and to each lower-level device through multiple independent downlink communication links. Each downlink communication link is independent, and the communication status of one link does not affect other links. The lower-level devices are the underlying execution devices corresponding to the etching machine process chambers, used to drive the multiple coils in the chamber to perform etching process operations and collect operating status data such as coil current and voltage.

[0023] The communication connection between the host computer and the upper computer can be a single communication link established through the SECS / GEM (Semiconductor Equipment Communication Standard / Generic Equipment Model) protocol, or a connection through any other industrial communication protocol, such as Modbus (Modicon Communication Protocol), PROFINET (Process Field Network), EtherCAT (Ethernet for Control Automation Technology), TCP / IP (Transmission Control Protocol / Internet Protocol), etc. The specific connection is not limited here.

[0024] The host computer can be deployed with an Equipment Automation Programming (EAP) system. The host computer can run a Windows system. The host computer and each lower-level device are connected through independent communication links. For example, assuming there are 6 lower-level devices, the host computer will communicate with the 6 lower-level devices through 6 independent communication links.

[0025] Specifically, the etching machine control method provided in this disclosure runs on a multi-device host computer control software on a Windows industrial computer. It communicates with the host's EAP system via the SECS / GEM interface and connects to six lower-level devices via a relay device. The relay device communicates with six lower-level devices with four-channel coils via six independent serial ports. The software enables coordinated control of multi-chamber coils and allows for independent current setting, current limiting, polarity and enable management, and actual current and voltage readback for each chamber's four-channel coil. This etching machine control method is designed for semiconductor process equipment such as etching machines with multiple sets of coils. It allows for simultaneous management of multiple lower-level coil drive devices on a single industrial computer, improving the controllability of the etching machine coils and reducing costs due to the reduced number of industrial computers.

[0026] For ease of understanding, the specific process of the embodiments of this disclosure is described below. Please refer to [link / reference]. Figure 1 One embodiment of the anomaly handling method for the etching machine chamber control system in this disclosure includes: Step S10: According to a preset cycle, obtain the target fault code corresponding to each lower device; wherein, the target fault code is generated by masking the hardware fault code of the corresponding lower device in the current cycle with a specific hardware fault type through the preset fault mask of the corresponding lower device. The hardware fault code is used to define the fault state bit by bit, and each bit corresponds to a hardware fault type. In this embodiment, the target fault code is generated by masking hardware fault codes using a preset fault mask. This ensures that low-level faults are filtered out before reaching the host computer. The masked fault types (such as fan malfunction, single communication jitter, etc.) do not affect the normal execution of the etching process or wafer quality. After being filtered out, they will not trigger subsequent alarm reporting or shutdown processing, thereby avoiding unnecessary shutdowns caused by non-critical faults. The bit-by-bit definition of the hardware fault code allows the host computer to accurately locate the specific hardware type and specific channel where the fault occurred, providing a fine-grained data foundation for subsequent differentiated processing.

[0027] The acquisition of target fault codes and the periodic execution of coil control can be completed within the same communication transaction, sharing the same communication cycle and the same data frame. This achieves both periodic coil control and real-time fault monitoring without additional communication overhead or independent detection cycles. Since each lower-level device is connected to the host computer via an independent communication link, even if the communication link of one lower-level device fails, it does not affect the host computer's ability to acquire target fault codes from other lower-level devices, ensuring system fault tolerance and the parallelism of multi-chamber monitoring.

[0028] The specific duration of the preset period depends on the response speed of the lower-level device, the bandwidth of the communication link, and the system's real-time requirements for fault response. A shorter period results in higher real-time fault detection, but also consumes more communication resources; a longer period reduces communication load, but increases fault detection latency. In one implementation, the preset period is 500ms; in another, it is 150ms. The preset period and the period for the host computer to write setting parameters to the lower-level device and perform periodic operations can be configured independently or the same value. The preset period can be a fixed value (such as the system-preset 500ms), or it can be manually modified by the operator through the configuration interface. It can also be dynamically and adaptively adjusted according to the actual response time of the communication link and the processing speed of the lower-level device. For example, when the system detects high communication link load, it automatically extends the period to reduce communication consumption; when frequent faults are detected, it automatically shortens the period to increase monitoring density.

[0029] When the host computer acquires the target fault codes corresponding to each lower-level device, it can actively read data from the lower-level devices through a communication link. Specifically, the communication link between the host computer and each lower-level device can be a serial communication protocol (such as RS-232, RS-485), an industrial fieldbus protocol (such as EtherCAT, CANopen), or a communication link based on the TCP / IP Ethernet communication protocol. In one implementation, the acquisition operation and the operation of the host computer reading actual current, actual voltage, and ECAT_Value from the lower-level devices are completed in the same communication transaction. That is, the host computer sends a read request, and the lower-level device includes both the target fault code and the actual operating data in its response data frame.

[0030] In this embodiment, each lower-level device corresponds to one chamber and drives multiple coils. The target fault codes of each lower-level device are independent of each other; that is, the fault code status of one chamber will not affect the fault code data of another chamber. When the host computer acquires the target fault codes, it can adopt a sequential polling method for each lower-level device (for example, first acquire the target fault code of PM1, then acquire the target fault code of PM2, and so on), or it can acquire the target fault codes of multiple lower-level devices in parallel through multi-threading or multiple independent communication links. The target fault codes of each lower-level device are stored in their respective data areas in the host computer's memory, isolated from each other.

[0031] A preset fault mask is a data mask pre-configured and stored in the lower-level device to specify the types of hardware faults to be masked. The data format of the preset fault mask is the same as the hardware fault code, both being bit-defined binary strings, with each bit corresponding to the masking enable state of a hardware fault type. When a bit is a valid value (e.g., 1), it indicates that the corresponding hardware fault type is masked; when a bit is an invalid value (e.g., 0), it indicates that the corresponding hardware fault type is not masked. The preset fault mask is configured and sent to the lower-level device for storage before or at the initial stage of operation on the host computer. It can be configured independently for each chamber, meaning that lower-level devices in different chambers can have different mask configurations. For example, in one implementation, the preset fault mask for PM1 (i.e., chamber 1) masks two fault types: "fan malfunction" and "single communication jitter," while the preset fault mask for PM2 (i.e., chamber 2) only masks the "single communication jitter" fault type. The specific fault types to be masked can depend on the process requirements and equipment operating status of each chamber.

[0032] Preset fault masks can be configured independently by chamber (different chambers have different masks), uniformly by equipment type (same type of equipment uses the same mask), or dynamically by process stage (the same equipment uses different masks at different process stages). The mask configuration interface can be a graphical configuration interface on a host computer or a configuration file import method.

[0033] Hardware fault codes are information codes that lower-level devices detect and record themselves through their internal hardware detection circuits or firmware, indicating the state of internal hardware faults. Hardware fault codes define fault states bit by bit, with each bit corresponding to a type of hardware fault. For example, bit 0 can be defined as an overcurrent fault, bit 1 as an overheating fault, bit 2 as a short circuit fault, bit 3 as a power supply malfunction fault, bit 4 as a fan malfunction fault, bit 5 as a communication malfunction fault, and so on.

[0034] In four-channel power supply applications, each bit of the hardware fault code can further distinguish the specific channel where the fault occurred. For example, bit 0 corresponds to overcurrent in channel 1, bit 1 to overcurrent in channel 2, bit 2 to overcurrent in channel 3, and bit 3 to overcurrent in channel 4. The hardware fault code is generated in real time by the hardware detection circuit of the lower-level device and stored in a designated register of the lower-level device for the upper-level computer to read at preset intervals.

[0035] In practical applications of plasma etching machines, the lower-level device is a four-channel constant current source power supply, which integrates an analog-to-digital converter (ADC) and a digital-to-analog converter (DAC) for closed-loop control. The hardware detection circuitry within the lower-level device monitors the output current, voltage, and temperature of the four channels in real time. When the output current of any channel exceeds a preset overcurrent threshold, the corresponding bit of the hardware fault code is set—for example, bit 0 corresponds to overcurrent in channel 1, bit 1 to overcurrent in channel 2, bit 2 to overcurrent in channel 3, and bit 3 to overcurrent in channel 4. The preset fault mask can be configured bit-by-bit through the configuration interface of the upper-level computer. For example, an engineer can set the bit corresponding to "fan malfunction" (e.g., bit 8) to be masked, as fan malfunction does not affect the current etching process, while setting the bits corresponding to "overcurrent" and "overheating" to be unmasked. When the upper-level computer reads the target fault code within a preset cycle, if it finds that the overcurrent bit of a certain channel is 1, it will proceed to the subsequent fault handling process (such as alarm reporting or stopping the chamber process). If only the fan fault bit is 1 and that bit is masked, then the fault bit will not proceed to the next step.

[0036] Step S20: If a communication connection with any lower-level device is detected to be broken, inject a software virtual fault bit into the target fault code most recently obtained by the corresponding lower-level device; This implementation injects a software virtual fault bit into the most recently acquired target fault code when a communication connection loss is detected. This allows the communication connection loss status to be integrated into the target fault code as a fault bit, forming a complete fault view together with the bits in the hardware fault code. This achieves a unified presentation of hardware and communication faults, avoiding the problem of incomplete fault views on the host side caused by the two types of fault information belonging to different processing channels. The software virtual fault bit and the hardware fault bit are presented in the same data format. The host and operators can simultaneously know the hardware fault status and communication link status of the lower-level device by parsing the target fault code, without having to query the hardware fault log and communication status log separately. Since the injection operation occurs after the communication is lost, and the injection target is the most recently acquired target fault code, even if a new fault code cannot be obtained after the communication is lost, the original hardware fault information is still retained and integrated with the communication fault information, avoiding the problem of hardware fault information loss due to communication loss. This step transforms the communication fault from an invisible state to an explicit state. When communication is disconnected, the host computer no longer presents a false impression of no fault, but instead clearly indicates that communication has been interrupted through a virtual fault bit, eliminating the risk of misjudgment caused by communication being disconnected but the fault code still showing normal.

[0037] The determination of a communication connection failure can be based on various detection methods: it can be based on the timeout of the communication request (i.e., the host computer does not receive a response within a preset timeout period after sending a request), based on the cumulative determination of multiple consecutive communication failures (i.e., data is not successfully acquired in multiple preset periods), based on the detection of physical layer signals of the communication link (such as serial port carrier loss, Ethernet link status down, etc.), or based on communication anomaly information actively reported by the lower-level device. A communication connection failure differs from a single communication failure in that a single communication failure may be caused by momentary interference or a brief period of busy activity on the lower-level device, while a communication connection failure indicates that the communication link is continuously unavailable for a longer period of time, requiring recovery attempts and state switching.

[0038] The most recently acquired target fault code is the one successfully obtained by the host computer from the lower-level device in the most recent preset cycle before the communication connection was lost. Since the host computer cannot obtain new target fault codes from the lower-level device after the communication connection is lost, the target of the injected software virtual fault bit is the last valid target fault code of the lower-level device stored in the host computer's memory. This target fault code is stored in the data buffer allocated by the host computer for this lower-level device and is updated each preset cycle when a target fault code is successfully acquired. If the communication connection loss occurs before the first acquisition, i.e., before a target fault code has ever been successfully acquired, there is no valid target fault code in memory. In this case, a basic fault code can be constructed before injecting the virtual fault bit.

[0039] When injecting a software virtual fault bit into the most recently acquired target fault code of the corresponding lower-level device, it can be achieved through a bitwise OR operation. That is, the host computer performs a bitwise OR operation on the target fault code and a mask where only the software virtual fault bit is 1 and all other bits are 0. This sets the bit corresponding to the software virtual fault bit in the target fault code to 1, while the other bits remain unchanged. The injection operation is a software-level operation by the host computer. The difference between the software virtual fault bit and the bits in the hardware fault code is that the bits in the hardware fault code are generated by the lower-level device's hardware detection, while the software virtual fault bit is actively set by the host computer software when it detects a communication connection loss. The software virtual fault bit can use reserved bits in the hardware fault code for undefined hardware fault types to avoid semantic conflicts with any hardware fault type.

[0040] When the host computer and the slave device communicate via an RS-232 serial port, the host computer, in addition to reading the target fault code at preset intervals, can also monitor the physical layer signal status through the serial port driver. Specifically, the host computer monitors the serial port's Data Carrier Detect (DCD) signal and Data Set Ready (DSR) signal. When the slave device is powered off or the serial cable is unplugged, the DCD and DSR signals become invalid. When the host computer detects either physical layer signal becoming invalid, it immediately determines that the communication connection has been broken, without waiting for read failures at preset intervals. After determining the break, the host computer reads the most recently successfully acquired target fault code from memory and injects it into a software virtual fault bit. This detection method based on physical layer signals enables immediate detection of communication disconnection, shortening the time delay between communication disconnection and fault handling.

[0041] Step S30: Determine the fault handling strategy for each lower-level device based on the current operating status and target fault code of each lower-level device, and execute the determined fault handling strategy.

[0042] This implementation determines and executes fault handling strategies based on the current operating status and target fault codes of each lower-level device. The host computer can flexibly adjust the fault response method according to the actual working status of the device. The same fault is assigned different handling methods in different operating states. For example, in the idle state, it only displays the fault without reporting or stopping the machine, while in the non-idle state, it reports the fault and stops the machine. This avoids alarm flooding on the host side and misjudgment by maintenance personnel caused by unnecessary alarms triggered by non-critical faults in the idle state. This implementation also considers the specific types of faults. Different fault types can correspond to different handling strategies to achieve differentiated fault responses. The automated determination and execution of handling strategies eliminates the need for manual intervention in fault response, reduces the time delay between fault occurrence and fault response, and improves the efficiency and timeliness of anomaly handling.

[0043] The current operating status includes at least an idle state and a non-idle state. The idle state indicates that the lower-level device is not currently executing any process tasks and there are no unhandled anomalies, and it is in a ready state to accept new tasks. The non-idle state indicates that the lower-level device is currently executing a process task or is in other non-idle working modes. The non-idle state may also include the running state (executing a process task), the error state (a failure has occurred but communication still exists), and the disconnected state (the communication link has been disconnected).

[0044] The host computer independently maintains the current operating status of each lower-level device, and the current operating status of each lower-level device does not affect the others. For example, when one chamber is in an operating state, another chamber can be in an idle state; when one chamber is in a disconnected state due to communication loss, the operating status of other chambers is unaffected. The current operating status is dynamically updated according to the changes in the task execution stage, communication status, and fault status of the lower-level device. For example, when the target task starts, it switches from an idle state to an operating state; when the process ends, it switches from an operating state back to an idle state; and when communication is lost, it switches to a disconnected state. The maintenance of the current operating status can be implemented through the state machine of the control instance, through independent operating status variable storage, or through a combination of conditions (such as "whether a task is being executed" and "whether a fault exists").

[0045] In this embodiment, the handling strategy for the same fault can differ under different operating states. For example, the same fault may only be recorded and displayed in the idle state, while it may trigger an alarm and shutdown in the non-idle state. Different fault types under the same operating state can also correspond to different handling strategies. For example, an overcurrent fault triggers an immediate shutdown, while a high temperature warning only triggers log recording. The determination of the fault handling strategy can be based on preset mapping rules, such as "idle state + any fault → only display" and "operating state + overcurrent fault → report and stop," or it can be based on more complex decision logic, such as combining fault duration and fault frequency.

[0046] In one implementation, the fault handling strategy is determined according to a two-level hierarchical principle: the first level is based on the fault type, which can be achieved by setting a fault mask, and the masked fault types do not enter the processing flow; the second level is based on the operating status, which can be achieved by recording locally only in the idle state and reporting and stopping in the non-idle state.

[0047] The anomaly handling method for the etching chamber control system provided in the above embodiments differentiates the masking of different hardware fault types through fault masks, filtering out fault types that do not require a response before they are acquired, thus avoiding unnecessary alarms or shutdowns triggered by non-critical faults. By injecting virtual fault bits into the software, the on / off status of the communication link is incorporated into the target fault code as a virtual fault, allowing hardware faults and communication faults to be handled uniformly, avoiding misjudgments or omissions due to information fragmentation. By determining the corresponding processing strategy based on the current operating status of the lower-level device, the fault response method matches the actual working scenario of the equipment. The same fault can be assigned different processing methods under different operating states, forming a multi-dimensional and flexible anomaly response mechanism, thereby significantly improving the flexibility of anomaly response while ensuring the safe operation of the equipment.

[0048] Next, we will explain the specific handling methods for abnormalities in the etching machine chamber control system.

[0049] In one embodiment, before the step of acquiring the target fault code corresponding to each lower-level device at a preset period, the method further includes: sending a preset fault mask corresponding to each lower-level device to the corresponding lower-level device, so that each lower-level device performs a bitwise AND operation between the preset fault mask and the most recently acquired hardware fault code to generate a target fault mask; wherein, the preset fault mask is used to define the masking status of each hardware fault type bitwise, with each bit corresponding to the masking enable of a hardware fault type; and returning the target fault code as part of a communication response message to the host computer.

[0050] This implementation sends a preset fault mask to the lower-level device before acquiring the target fault code. This allows the masking operation to be performed on the lower-level device side. The hardware fault code is filtered by the mask before being read by the upper-level computer, and the masked fault type is filtered out before reaching the upper-level computer. This reduces the processing burden on the upper-level computer and avoids the risk of masking failure due to upper-level computer software failure or processing delay, thus improving the reliability and execution efficiency of the masking mechanism. Since the mask is stored in the non-volatile storage medium of the lower-level device, the mask data will not be lost even if the lower-level device is powered off and restarted, eliminating the need to resend it after each power-on and simplifying the system initialization process.

[0051] A pre-defined fault mask defines the masking status of each hardware fault type bit by bit. This allows for flexible selection of the fault type to be masked by configuring each bit of the mask. Different chambers can be configured with different masks, and the mask for the same chamber can be dynamically adjusted during equipment operation without modifying the host computer software code, reducing the complexity and cost of system maintenance and fault masking strategy adjustment. The lower-level device dynamically performs a bitwise AND operation each time it responds to a read request from the host computer, ensuring that the target fault code reflects the latest hardware fault status and the latest mask configuration. When the hardware fault status changes (a new fault occurs or an existing fault is eliminated) or the mask configuration is updated, the target fault code is automatically updated in the next communication cycle, guaranteeing real-time fault detection and immediate effectiveness of the configuration.

[0052] This implementation returns the target fault code as part of the communication response message to the host computer, so that the host computer can obtain other operating data such as the actual current, actual voltage and ECAT_Value of each coil at the same time as obtaining the target fault code. There is no need to set up a separate communication transaction to obtain the target fault code, which reduces the number of communication times and communication overhead and improves communication efficiency.

[0053] After receiving the preset fault mask, the lower-level device performs a bitwise AND operation between the hardware fault code it detects and the stored preset fault mask each time it needs to report a fault status, thereby generating a target fault mask. When responding to a read request from the upper-level computer, the lower-level device includes the target fault code generated by the bitwise AND operation in the response data frame and sends it to the upper-level computer. The target fault code can be returned as a standalone data field, or it can be combined with other data (such as actual current, actual voltage, ECAT_Value, etc.) in the response data frame and returned.

[0054] In this embodiment, returning the target fault code as part of the communication response message rather than as a separate message reduces the number of communications and communication overhead. The host computer can simultaneously acquire the target fault code and other required data within a single communication transaction. In one embodiment, the host computer sends a read request at a preset period. The lower-level device includes the target fault code (stored at a specific address in the read area register) and the actual operating data of each coil (stored at other addresses in the read area register) in its response data frame. The host computer can complete the synchronous acquisition of fault status and process data with a single read. The hardware detection circuit inside the lower-level device continuously monitors the status of each hardware module and updates the latest fault status in the hardware fault code register in real time. The most recently acquired hardware fault code is used to indicate the latest hardware fault status detected and recorded by the lower-level device at the current moment.

[0055] The result of a bitwise AND operation is that the bits in the hardware fault code that are masked and are 1 retain their original values, while those bits that are masked and are 0 are cleared. The mathematical expression for a bitwise AND operation is: Target fault code = Hardware fault code AND Preset fault mask. For example, if the hardware fault code is 0b11110000 (indicating a fault in bits 4 to 7), and the preset fault mask is 0b00001111 (indicating bits 0 to 3 are 1, and the remaining bits are 0), then the result of the bitwise AND operation is 0b00000000—all hardware fault bits are masked because the corresponding bits in the mask are all 0. For example, if the hardware fault code is 0b00001111 (indicating a fault in bits 0 to 3), and the preset fault mask is 0b00001110 (indicating bits 1 to 3 are 1 and bit 0 is 0), then the bitwise AND operation result is 0b00001110, indicating that the faults in bits 1 to 3 are preserved, and the fault in bit 0 is masked.

[0056] In practical applications of plasma etching machines, the four-channel constant current power supply (lower-level device) integrates an ADC and DAC for closed-loop control. The power supply's hardware detection circuit monitors the output current, voltage, and temperature of the four channels in real time and encodes detected fault states as 32-bit hardware fault codes. Specifically, bit 0 indicates overcurrent in channel 1, bit 1 indicates overcurrent in channel 2, bit 2 indicates overcurrent in channel 3, bit 3 indicates overcurrent in channel 4, bit 4 indicates power supply abnormality, bit 5 indicates fan abnormality, and bit 6 indicates over-temperature alarm, etc.

[0057] During the initialization phase of the host computer, engineers configure preset fault masks for each chamber through the host computer's configuration interface. For example, if the engineer determines that the fan of PM1 is operating normally and does not need to mask any faults, then the preset fault mask for PM1 is 0xFFFFFFFF (all bits are 1, indicating that all fault types are not masked and are reported normally). However, if the engineer determines that the fan of PM2 is aging and needs to be replaced periodically, to avoid triggering unnecessary alarm reports due to fan malfunctions, bit 5 (the bit corresponding to fan malfunction) in the preset fault mask for PM2 is configured to 0, and the remaining bits are configured to 1, that is, the preset fault mask for PM2 is 0xFFFFFFDF.

[0058] The host computer sends the mask 0xFFFFFFFF of PM1 to the power supply corresponding to PM1, and the mask 0xFFFFFFDF of PM2 to the power supply corresponding to PM2. Each power supply stores the received mask in its local register. In each subsequent preset cycle, before reporting a fault code, the power supply corresponding to PM2 performs a bitwise AND operation between the detected hardware fault code and the stored mask 0xFFFFFFDF. If only bit 5 (fan malfunction) is set in the hardware fault code, the bitwise AND operation yields 0x00000000, and the fan malfunction fault is masked and not reported. If the hardware fault code contains both bit 0 (channel 1 overcurrent) and bit 5 (fan malfunction), the bitwise AND operation yields 0x00000001, the overcurrent fault is retained while the fan malfunction fault is masked, and the host computer can only detect the overcurrent fault and perform corresponding alarm reporting and stop processing.

[0059] In one implementation, if a communication connection with any downstream device is detected to be broken, the step of injecting a software virtual fault bit into the target fault code most recently acquired by the corresponding downstream device includes: detecting the communication response status of each downstream device at a preset period; if any downstream device does not respond within at least one historical consecutive period, then determining that the communication connection with the corresponding downstream device is broken; setting a reserved software virtual fault bit in the target fault code most recently acquired by the corresponding downstream device; wherein, the software virtual fault bit is a reserved bit in the hardware fault code for which no hardware fault type is defined; and maintaining the set state of the software virtual fault bit during the period of communication connection breakage until the communication connection is detected to be restored.

[0060] This implementation method detects the communication response status of each lower-level device at a preset cycle, and only determines that the communication connection is broken after a certain number of consecutive no responses. This avoids misjudging a single no response as a communication break due to instantaneous communication jitter, brief periods of busy lower-level devices, or occasional electromagnetic interference, thus improving the reliability and accuracy of communication break detection. By setting a reserved software virtual fault bit in the most recently acquired target fault code of the corresponding lower-level device after determining the break, the communication connection break status can be explicitly represented in the fault code. Together with the bits in the hardware fault code, it forms a complete fault view, achieving a unified and integrated presentation of communication faults and hardware faults. Since the software virtual fault bit is a reserved bit in the hardware fault code for which no hardware fault type is defined, its setting will not conflict with or overlap with any hardware fault type, ensuring the uniqueness and clarity of the meaning of each bit in the integrated fault code. By keeping the software virtual fault bit set during the communication connection disconnection, the communication fault information continues to exist in the target fault code throughout the entire disconnection period. It will not be lost or disappear due to the inability to obtain new data in subsequent cycles, ensuring that the host and operators can continuously know the abnormal communication status during the communication disconnection period, so as to take timely countermeasures.

[0061] The detection method for communication response status of each lower-level device can be set according to the communication protocol. In request-response protocols (such as MODBUS), the response status can be determined by whether a response is received within the timeout period; in periodic data exchange protocols (such as EtherCAT), the response status can be determined by whether valid process data is received within the expected time window; in custom protocols, the communication status can be actively probed by sending specific heartbeat commands or ping commands. The result of the communication response status includes at least two states: responsive and no response. When detecting the communication response status of each lower-level device, they can be detected sequentially one by one, or multiple lower-level devices can be detected simultaneously in parallel. In this embodiment, when a lower-level device fails to provide a valid response to the communication request from the host computer for several consecutive preset periods, the host computer determines that the communication connection with that lower-level device has been broken.

[0062] The software virtual fault bit is located in a position not assigned to any hardware fault type in the definition of the hardware fault code. Therefore, this bit is always 0 under normal conditions (when communication is normal), and can be safely used as a software virtual fault bit without conflicting with any hardware fault. In one implementation, the software virtual fault bit is bit 13 of the hardware fault code, which is not assigned to any hardware fault type in the definition of the hardware fault code. The specific position selection principle for the software virtual fault bit is: this bit is not defined with any hardware fault type in the hardware fault code, and it remains consistent in the hardware fault code definitions of all lower-level devices.

[0063] In this embodiment, after the communication connection is broken and before it is restored, the host computer maintains the set state of the software virtual fault bit, ensuring it remains at 1 in every subsequent fault handling step. Specifically, maintaining the set state can be achieved by the host computer using a target fault code containing the set software virtual fault bit (i.e., reading the most recently acquired target fault code from memory, which has been modified after the set operation) whenever processing the target fault code of the lower-level device during the communication disconnection. Even if the host computer cannot obtain a new target fault code from the lower-level device during the communication disconnection, the software virtual fault bit remains set, ensuring that the fault view of the lower-level device continuously includes the communication disconnection status information. Maintaining the set state ensures that communication fault information is not lost throughout the entire disconnection period.

[0064] When the host computer successfully acquires the target fault code of the lower-level device again in any subsequent preset cycle, the host computer determines that the communication connection has been restored. The detection of communication connection restoration corresponds to the detection of disconnection. In the subsequent cycles after disconnection, the host computer continuously attempts to send communication requests to the lower-level device. When a valid response is successfully received, the communication connection is determined to be restored.

[0065] In one implementation, the step of detecting the communication response status of each lower-level device according to a preset period includes: acquiring the actual status information and actual output data of each lower-level device according to the preset period; if the acquisition fails in the current period, incrementing the no-response count bit of the corresponding lower-level device; if the acquisition is successful in the current period, resetting the no-response count bit of the corresponding lower-level device; when the no-response count bit of any lower-level device is greater than or equal to a preset number of times threshold, it is determined that the corresponding lower-level device has no response in at least one historical continuous period.

[0066] This implementation determines the communication response status of lower-level devices by successfully acquiring their actual status information and output data. Successful acquisition indicates a response, while failure indicates no response. In case of failure, the no-response counter for that lower-level device is incremented by 1; in case of success, the no-response counter is reset to its initial value of 0. When the no-response counter value of any lower-level device reaches or exceeds a preset threshold, the host computer determines that the lower-level device has experienced at least one consecutive historical period of no response. In this case, the host computer determines that the lower-level device has been without response for at least one consecutive historical period.

[0067] This implementation ensures that only continuous, uninterrupted periods of no response are accumulated and counted in the number of consecutive no response cycles through the increment and reset mechanism of the no response counter. Once a successful acquisition occurs in the middle, the counter is cleared and needs to be accumulated again. This requirement of continuity makes the determination of communication disconnection more rigorous and accurate, and further reduces the probability of false judgment.

[0068] In this embodiment, the actual status information is data used to reflect the current operational health status of the lower-level device, and may include the lower-level device's operating status flags (such as whether it is running or in standby mode), fault status flags (such as whether a fault exists and the type of fault), temperature information (such as the internal temperature of the lower-level device), power supply status information (such as whether the power supply voltage is normal), etc. The actual output data is data used to reflect the current output status of the lower-level device, and may include the actual current value, actual voltage value, actual output power value of each coil, and the actual output status flag (ECAT_Value, used to indicate whether the lower-level device is actually outputting), etc.

[0069] In practical applications of plasma etching machines, the host computer communicates with a four-channel constant current power supply (the lower-level device) via an RS-485 serial port. During an etching process, suppose the host computer sends a target fault code read request to the four-channel power supply corresponding to PM3 within a preset cycle. Due to electromagnetic interference causing damage to the communication data frame, the power supply fails to correctly parse the host computer's request and therefore does not return any response. If the host computer does not receive a response within the timeout period (200ms), the acquisition fails, and the power supply's no-response count is incremented from 2 to 3. At this point, the no-response count reaches the preset threshold of 3, and the host computer determines that the communication connection with the power supply has been broken. The host computer then reads the most recently successfully acquired target fault code from memory (assumed to be 0x0000, indicating no previous fault), and sets the software virtual fault bit (bit 13) to obtain 0x2000 as the current target fault code. This target fault code triggers a fault display in idle mode or an alarm report in non-idle mode in subsequent steps. The host and operators can know that the communication has been interrupted by bit 13 of the fault code, avoiding the risk of misjudgment that the communication has been interrupted but the readings seem normal.

[0070] In one implementation, the steps of determining a fault handling strategy for each lower-level device based on its current operating status and target fault code, and executing the determined fault handling strategy, include: for lower-level devices currently in an idle state, determining a new fault based on the corresponding target fault code, displaying the new fault, not reporting an alarm to the host, and not stopping the operation process of the corresponding chamber; for lower-level devices currently in a non-idle state, determining a new fault based on the corresponding target fault code, reporting an alarm to the host, and stopping the current operation process of the corresponding chamber.

[0071] This implementation achieves differentiated fault response by employing different fault handling strategies for idle and non-idle states. In the idle state, only newly added faults are displayed, no alarms are reported, and the system remains operational. In the non-idle state, alarms are reported and the current process is stopped. The silent handling in the idle state avoids triggering unnecessary remote alarms due to non-critical faults occurring during idle periods, reducing the risk of alarm flooding on the host and the burden of misjudgment on maintenance personnel, allowing the host to focus more on alarm information that truly requires intervention.

[0072] Timely reporting and stopping during non-idle states ensures that faults occurring during process execution are promptly detected and recorded by the host computer, while simultaneously protecting equipment and wafers from further damage by halting the current process. During etching processes, any fault that may affect plasma stability (such as overcurrent, overheating, or communication failure) can lead to wafer scrapping or equipment damage; timely stopping is a critical measure to ensure production safety. This implementation only treats newly added faults as processing objects, rather than all faults. The same fault is only processed (displayed or reported) upon its first occurrence; persistent faults will not be triggered repeatedly in subsequent cycles, avoiding repeated screen refreshes and alarm flooding, allowing operators and the host computer to clearly understand newly occurring fault events.

[0073] In one implementation, the host computer compares the target fault code of the current cycle with the target fault code saved in the previous cycle, and identifies the bit that changes from 0 to 1 through bitwise operations. The fault type corresponding to this bit is the newly added fault.

[0074] In a practical application scenario of a plasma etching machine, assuming the four-channel constant current source power supply PM4 was in the running state in the previous preset cycle, the host computer detects a new fault "Channel 3 overcurrent" and executes the non-idle state processing strategy, i.e., reporting an alarm to the host and stopping the current operation of PM4. After the stop process is completed, the running state of PM4 switches from the running state to the idle state. In the current preset cycle, the target fault code of PM4 is 0x0004 (the channel 3 overcurrent fault persists), but the current running state of PM4 is already in the idle state. The host computer compares the target fault code 0x0004 of the current cycle with the target fault code 0x0004 saved in the previous cycle. They are the same, and there is no new fault bit (bit2 was 1 in the previous cycle and is still 1 in the current cycle), so no processing is triggered.

[0075] If a new fault occurs in PM4 during a subsequent cycle (e.g., bit 5 "Fan Abnormality" becomes 1), since PM4 is in an idle state at this time, the host computer will display "Fan Abnormality" as a new fault on the user interface, but will not report an alarm to the host computer or stop the operation of PM4 (PM4 is already in an idle state). This handling method allows faults that occur during the device's idle period to be recorded and displayed locally, but will not trigger unnecessary remote alarms.

[0076] In one implementation, the step of determining a new fault based on a corresponding target fault code includes: performing a bitwise XOR operation on the previously processed target fault code and the most recently acquired target fault code to obtain a changed fault bitmask; performing a bitwise AND operation on the changed fault bitmask and the most recently acquired target fault code to obtain a new fault bitmask; and determining the fault type indicated by the new fault bitmask as a new fault.

[0077] This implementation method obtains a changed fault bit mask by performing a bitwise XOR operation between the previously processed target fault code and the most recently acquired target fault code. Then, it performs a bitwise AND operation between the changed fault bit mask and the most recently acquired target fault code to obtain a new fault bit mask. This allows the identification of new faults to accurately distinguish between two state changes: new (from 0 to 1) and eliminated (from 1 to 0). Only bits that change from 0 to 1 are identified as new faults, while bits that change from 1 to 0 are not identified as new faults, thus ensuring the separation of new fault identification from eliminated fault identification.

[0078] This implementation uses a combination of bitwise XOR and bitwise AND operations to prevent persistent faults from being repeatedly identified as new faults in each cycle. Since two target fault codes are identical (XOR result is 0), no new fault bitmask is generated, thus avoiding repeated triggering of displays or reports for the same fault across multiple cycles, eliminating alarm flooding and fault log redundancy. By defining the fault type indicated by the new fault bitmask as a new fault, it ensures that only newly occurring faults trigger subsequent displays or reports, allowing operators and the host to promptly perceive newly emerging fault states without being interfered with by persistent fault information. Both bitwise XOR and bitwise AND operations are bit-level parallel operations, capable of simultaneously processing all bits (e.g., 32 bits) within a single instruction cycle. This offers higher computational efficiency compared to bit-by-bit cyclic comparisons, making it suitable for real-time systems requiring rapid processing of a large number of fault bits in each preset cycle.

[0079] The target fault code processed in the previous cycle is the target fault code used by the host computer as the basis for fault handling in the previous preset cycle. This target fault code can be obtained from the lower-level device (when communication is normal) or injected after being virtualized by software (when communication is disconnected). After each fault handling is completed, the host computer saves the target fault code used in the current cycle in memory as the "target fault code processed in the previous cycle".

[0080] The most recently acquired target fault code is the target fault code obtained by the host computer from the lower-level device in the current preset cycle (when communication is normal), or the target fault code successfully acquired most recently when communication is disconnected (when communication is disconnected, the target fault code may have been injected into a software virtual fault bit). This target fault code is the fault status information to be processed in the current cycle, reflecting the real-time fault status of the lower-level device in the current cycle (including hardware faults and communication virtual faults). In one implementation, this target fault code has the same data format and bit width as the "previously processed target fault code", and the difference between the two is quantized by bitwise operations.

[0081] In this embodiment, the newly added fault bitmask is a bitmask used to indicate a newly added fault where the fault bit changes from 0 to 1. A bit that is 1 in the newly added fault bitmask indicates that the corresponding fault type is newly appearing in the current cycle and did not exist in the previous cycle. The host computer searches a predefined fault type mapping table (which defines the correspondence between each bit and a specific fault type) based on each bit that is 1 in the newly added fault bitmask, and extracts the fault type name corresponding to each bit as the newly added fault.

[0082] In one embodiment, the method further includes: if the fault corresponding to the fault bit in the detected target fault code has been eliminated, then sending an alarm clearing event for the corresponding fault to the host; if the communication connection with any lower-level device is detected to be restored to normal, then clearing the software virtual fault bit from the target fault code of the corresponding lower-level device; wherein the determination condition for the communication connection to be restored to normal is: the target fault code of the corresponding lower-level device is successfully obtained in any preset period and the no-response counter bit has been reset.

[0083] This implementation sends an alarm clearing event to the host when the fault corresponding to the fault bit in the target fault code is detected to be cleared. This ensures that the alarm status on the host side is synchronized with the actual fault status of the device in real time, avoiding misjudgment and maintenance interference caused by the continuous display of cleared faults as alarm status. This ensures that the host can accurately reflect the real-time health status of the device. Furthermore, by clearing the software virtual fault bit from the target fault code when the communication connection is detected to be restored, the communication connection status is synchronized with the setting / clearing status of the virtual fault bit. This prevents the restored communication fault status from continuing to exist in the target fault code and interfering with subsequent fault judgment.

[0084] To check whether the fault in the corresponding fault bit of the target fault code has been eliminated, you can compare the changes of each fault bit in the target fault code. If the fault bit changes from 1 to 0, then you can determine that the fault in the corresponding fault bit has been eliminated.

[0085] In the SECS / GEM protocol, the alarm clearing event corresponding to the fault is sent to the host via an S5F1 message. The alarm clearing flag ALCD (Alarm Clear Data) in the message is set to 0, indicating that the alarm has been cleared. The message also contains the alarm ID (ALID) corresponding to the fault, which is used to indicate the alarm status that the host wants to clear.

[0086] In this embodiment, whether the communication connection of the lower-level device has been restored to normal is determined by whether the target fault code of the corresponding lower-level device has been successfully acquired in any preset period and whether the no-response count bit has been reset. After the communication is detected to be restored, the upper-level computer needs to clear the previously injected software virtual fault bits so that the target fault code is restored to a state that only contains hardware fault information.

[0087] When clearing software virtual fault bits, after detecting that the communication connection has been restored, the software virtual fault bits (such as bit 13) previously injected into the target fault code of the lower-level device can be reset from 1 to 0. Specifically, the software virtual fault bits can be cleared through a bitwise AND operation. This involves performing a bitwise AND operation between the target fault code and a mask where only the software virtual fault bits are 0 and all other bits are 1. This operation clears the software virtual fault bits to zero, while other bits remain unchanged (including hardware fault bits).

[0088] In one implementation, before the step of acquiring the target fault codes corresponding to each lower-level device at a preset period, the method further includes: creating a control instance corresponding to each lower-level device, maintaining the current operating state of the corresponding lower-level device through the state machine of the control instance; when a communication connection with any lower-level device is detected to be disconnected, switching the current operating state of the control instance of the corresponding lower-level device to the disconnected state; when a communication connection with any lower-level device is detected to be restored, switching the current operating state of the control instance of the corresponding lower-level device from the disconnected state to the idle state.

[0089] This implementation creates a corresponding control instance for each lower-level device and independently maintains the current operating state of each lower-level device through the state machine of the control instance. This allows the host computer to manage the operating state of multiple chambers in a structured manner within a single software suite, with the states of each control instance being isolated from each other and not affecting each other.

[0090] A control instance is an independent logical management unit created within the host computer software for each lower-level device. It is used to centrally manage key information such as the operating status, task context, and communication status of the corresponding lower-level device. The host computer assigns an independent control instance to each lower-level device, and there is a binding relationship between this control instance and the corresponding lower-level device, its chamber, and coil group; that is, one control instance uniquely corresponds to one lower-level device.

[0091] The host computer uses the state machine within the control instance to record and manage the current operating state of the corresponding lower-level devices. A state machine is a logical model consisting of a set of predefined states and transition rules between them. In one implementation, the state machine includes at least four states: idle, running, error, and disconnected. Once the control instance is created, its state machine begins maintaining the operating state of the corresponding lower-level devices. The state of the control instance's state machine is dynamically updated as the lower-level devices' task execution phase, communication status, and fault status change. For example, it switches from the idle state to the running state when the target task starts, and switches back from the running state to the idle state when the process ends.

[0092] As an example, and not a limitation, assume that the host computer manages six control instances simultaneously, corresponding to PM1 through PM6. At any given moment, the states of each control instance may differ: PM1 is in the running state (performing an etching process), PM2 is in the idle state (standby), PM3 is in the disconnected state (communication disconnected), PM4 is in the error state (a fault has occurred, but communication still exists), PM5 is in the running state, and PM6 is in the idle state. The state of each control instance is maintained independently by its own state machine. When communication with PM3 is disconnected, only the control instance corresponding to PM3 switches to the disconnected state; the states of PM1, PM2, PM4, PM5, and PM6 remain unaffected. When the host computer acquires the target fault codes of each lower-level device within a preset cycle, the fault handling strategy is determined based on the current operating state of each control instance. For example, if a fault occurs in PM1 while it is running, the non-idle state handling strategy is executed; if a fault occurs in PM2 while it is idle, the idle state handling strategy is executed; and if a fault occurs in PM3 while it is disconnected (disconnected state is a non-idle state), the non-idle state handling strategy is executed. This independent maintenance mechanism ensures that the chambers do not affect each other, and a change in the state of one chamber will not affect other chambers.

[0093] For the corresponding method embodiments described above, see [link to relevant documentation]. Figure 2 The diagram shows a schematic of an etching machine chamber control system, which includes: The host computer is configured to execute the etching machine control method; Host computer: Communicates with the host computer; Multiple lower-level devices: each of them is connected to the upper-level computer via the relay device. Each lower-level device corresponds to a chamber, and each chamber corresponds to multiple coils.

[0094] The aforementioned etching machine chamber control system allows the host computer to send commands to the upper-level computer. The upper-level computer and each lower-level device communicate via a relay device to convert the communication protocol. This enables a single host computer to uniformly manage multiple chambers and multiple coils without modifying the business logic of the upper and lower-level devices, thus avoiding the deployment complexity and coordination difficulties caused by multiple independent control devices.

[0095] The above-mentioned anomaly handling method for the etching machine chamber control system differentiates the masking of different hardware fault types through fault codes, filtering out fault types that do not require a response before they are acquired, thus avoiding unnecessary alarms or shutdowns triggered by non-critical faults. By injecting virtual fault bits into the software, the on / off status of the communication link is incorporated into the target fault code as a virtual fault, allowing hardware and communication faults to be handled uniformly, avoiding misjudgments or omissions due to information fragmentation. By determining the corresponding handling strategy based on the current operating status of the lower-level device, the fault response method matches the actual working scenario of the equipment. The same fault can be assigned different handling methods under different operating states, forming a multi-dimensional and flexible anomaly response mechanism, thereby significantly improving the flexibility of anomaly response while ensuring the safe operation of the equipment.

[0096] The host computer can be an industrial control computer or embedded controller deployed on the etching machine side. It receives control commands from the host computer and interacts with each lower-level device via a relay device. The relay device, deployed between the host computer and the lower-level devices, performs protocol conversion and signal relay for communication data. It connects to the host computer via an uplink communication link and to each lower-level device via multiple independent downlink communication links. Each downlink communication link is independent; the communication status of one link does not affect other links. The lower-level devices are the underlying execution devices corresponding to the etching machine's process chamber. They drive multiple coils within the chamber to perform etching process operations and collect operating status data such as coil current and voltage.

[0097] The communication connection between the host computer and the upper computer can be a single communication link established through the SECS / GEM (Semiconductor Equipment Communication Standard / Generic Equipment Model) protocol, or a connection through any other industrial communication protocol, such as Modbus (Modicon Communication Protocol), PROFINET (Process Field Network), EtherCAT (Ethernet for Control Automation Technology), TCP / IP (Transmission Control Protocol / Internet Protocol), etc. The specific connection is not limited here.

[0098] The host computer can be equipped with an Equipment Automation Programming (EAP) system. The host computer can run a Windows system. The host computer communicates with each lower-level device through a relay device. Specifically, the relay device is connected to the host computer via an uplink communication link, and each lower-level device is connected to it via multiple independent downlink communication links. For example, assuming there are 6 lower-level devices, the relay device communicates with each of the 6 lower-level devices through 6 independent downlink communication links. Each downlink communication link is independent, and the communication status of one link does not affect the normal communication of other links.

[0099] The lower-level device can be a magnetic control system that outputs a constant driving current and transmits the driving current to the coil. The coil is positioned above the etching cavity (i.e., the chamber). When it receives the driving current, it forms a magnetic field of specific intensity and distribution in the etching cavity. This magnetic field constrains and guides the ionized plasma in the etching cavity, ensuring that the active ions move precisely toward the target area on the wafer surface.

[0100] Figure 3 The diagram shows an etching machine 10, which includes a magnetic control system 110, a gas output module 120, an etching chamber 130, an electrostatic chuck and heating plate 140, a high-voltage power supply 150, and a coil 160. Specifically, the magnetic control system 110 includes a controller 111, a constant current source device 112, and a communication middleware 113.

[0101] The controller 111 sends a drive signal to the constant current source device 112 according to preset etching process parameters. These etching process parameters include the wafer material and the etching pattern precision. In response to the drive signal, the constant current source device 112 outputs a constant drive current and transmits the drive current to the coil 160 to drive the coil 160 to generate a constant magnetic field 11. The communication middleware 113 is electrically connected to the constant current source device 112. The communication middleware 113 provides a communication interface for data distribution logic. The communication middleware 113 can collect data such as current, voltage, and power output from the constant current source device 112 and transmit the collected data to the controller 111.

[0102] Coil 160 is electrically connected to constant current source device 112, and coil 160 is positioned above etching cavity 130. When coil 160 receives driving current, coil 160 forms a magnetic field 11 of specific intensity and distribution within etching cavity 130. Magnetic field 11 constrains and guides the ionized plasma within etching cavity 130, ensuring that active ions move precisely toward the target area on the surface of wafer 12, thus guaranteeing the directionality and precision of etching.

[0103] The gas output module 120 is used to input a specific type of reactive gas, including fluorine- or chlorine-containing gases, into the etching chamber 130. The reactive gas is ionized to generate a plasma composed of ions, electrons, and highly reactive free radicals. The highly reactive free radicals chemically react with the material on the surface of wafer 12, generating volatile compounds. Charged ions in the plasma are accelerated under the influence of an electric field and vertically bombard the surface of wafer 12. The physical impact of high-energy ions not only removes atoms from the surface of wafer 12 but also enhances the chemical reaction rate and achieves highly directional anisotropic etching, thereby etching vertical sidewalls and precisely replicating the patterns on the photoresist.

[0104] An electrostatic chuck and heating plate 140 are disposed at the bottom of the etching chamber 130. When the wafer 12 is placed on the surface of the electrostatic chuck and heating plate 140, the electrostatic chuck and heating plate 140 fix the wafer 12 through electrostatic adsorption effect, preventing the wafer 12 from shifting or vibrating during the etching process, providing and maintaining a constant substrate temperature, preventing the reaction gas from condensing on the surface of the wafer 12, and ensuring the stability of the chemical reaction rate.

[0105] The high-voltage power supply 150 is electrically connected to the electrostatic chuck and the heating plate 140. The high-voltage power supply 150 is used to provide two power signals of opposite polarity to the electrostatic chuck and the heating plate 140 to control the electrostatic chuck and the heating plate 140 to adsorb or release the wafer 12.

[0106] Each lower-level device drives a multi-coil group (e.g., 4 coils, denoted as CH1, CH2, CH3, and CH4) corresponding to the cavity. By independently adjusting the current ratio of each coil (e.g., adjusting the current ratio of the inner and outer coils), the magnetic field distribution within the cavity can be finely adjusted. For example, if the magnetic field is too strong at the center and weak at the edges, compensation can be made by using the current in the edge coils to reduce the standard deviation of the plasma density distribution within the wafer from 8% to 2%, thereby improving etching uniformity.

[0107] The relay device can be a control module. When it connects to the host computer, it can receive control commands (including setting parameters, current index number, etc.) issued by the host computer and upload data reported by the lower-level devices (including actual current, actual voltage, fault status, etc.) to the host computer. When it connects to the lower-level devices, it can poll each lower-level device according to a predetermined sequence, issue control commands at regular intervals, and read the real-time operating data fed back by each lower-level device.

[0108] The relay device also has independent cache partitions for control commands from different sources to achieve isolated processing of the two types of commands: when a control command is received from an external system, the relay device locks the current coil output current parameter and responds to the external command first. In scenarios where no external command is issued, the relay device directly forwards the current parameter set by the host computer to the corresponding lower-level device driver unit. Through this mechanism, the two types of control commands do not interfere with each other, avoiding command overwriting or parameter corruption, and ensuring the stability and controllability of the magnetic field output.

[0109] During the periodic polling of each lower-level device, the relay device can also simultaneously collect the actual operating data returned by each lower-level device (including the actual current value, actual voltage value, and actual output status flag of each channel). The relay device summarizes the collected data and uploads it to the host computer. The host computer then performs status determination in the periodic control based on this data (such as determining whether the output has actually stopped).

[0110] For ease of understanding, Figure 4 The diagram shows a more specific etching machine chamber control system. The host corresponds to the EAP system, and the magnetic control system corresponds to the lower-level device. The magnetic control system communicates with the host computer via a relay device. Each magnetic control system corresponds to one etching chamber, and each etching chamber corresponds to four coils.

[0111] Specifically, during the execution of the target task, the host computer sends the set parameters for the current cycle to the relay device in each execution cycle. The relay device then forwards the set parameters to the target magnetic control system. The communication middleware 113 of the target magnetic control system receives the set parameters, the controller 111 performs digital-to-analog conversion, and the constant current source device 112 outputs the corresponding drive current to each coil 160. Simultaneously, the communication middleware 113 collects real-time operating data such as the actual output current, voltage, and actual output status of each coil 160, which is then aggregated by the relay device and uploaded to the host computer.

[0112] The host computer determines whether the target magnetic control system has actually stopped outputting based on the actual output data acquired over multiple cycles. The presence of the relay device eliminates the need for the host computer to establish independent physical communication links with each magnetic control system. The relay device enables coordinated control and data acquisition of multiple magnetic control systems through unified scheduling. Each chamber's magnetic control system operates independently; an malfunction in one chamber does not affect the normal operation of other chambers, thus improving the system's fault tolerance and reliability.

[0113] This embodiment also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are called and executed by a processor, the computer-executable instructions cause the processor to implement the above-described abnormal handling method of the etching chamber control system.

[0114] The abnormal handling method of the etching machine chamber control system, the etching machine chamber control system and the computer program product of the storage medium provided in this disclosure include a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation, please refer to the method embodiments, which will not be repeated here.

[0115] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0116] Furthermore, in the description of the embodiments of this disclosure, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this disclosure based on the specific circumstances.

[0117] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0118] In the description of this disclosure, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings, and are only for the convenience of describing this disclosure and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this disclosure. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0119] Finally, it should be noted that the above embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A method for handling anomalies in an etching machine chamber control system, characterized in that, A host computer is used in the chamber control system of an etching machine. The system also includes a main unit, a relay device, and multiple lower-level devices. Each lower-level device corresponds to a chamber, and each chamber corresponds to multiple coils. The main unit is communicatively connected to the host computer, and the host computer is communicatively connected to each lower-level device through the relay device. The method includes: According to a preset cycle, the target fault codes corresponding to each lower-level device are obtained; wherein, the target fault codes are generated by masking the hardware fault codes of the corresponding lower-level devices in the current cycle with specific hardware fault types through the preset fault mask of the corresponding lower-level devices; the hardware fault codes are used to define the fault status bit by bit, with each bit corresponding to a hardware fault type. If a communication connection with any lower-level device is detected to be broken, a software virtual fault bit is injected into the target fault code most recently acquired by the corresponding lower-level device. Based on the current operating status and target fault codes of each lower-level device, determine the fault handling strategy for each lower-level device and execute the determined fault handling strategy.

2. The method according to claim 1, characterized in that, Before the step of acquiring the target fault codes corresponding to each lower-level device at a preset period, the method further includes: Each lower-level device sends a preset fault mask to the corresponding lower-level device, so that each lower-level device performs a bitwise AND operation between the preset fault mask and the most recently acquired hardware fault code to generate a target fault mask; wherein, the preset fault mask is used to define the masking state of each hardware fault type bitwise, and each bit corresponds to the masking enable of a hardware fault type. The target fault code is returned to the host computer as part of a communication response message.

3. The method according to claim 1, characterized in that, The step of injecting a software virtual fault bit into the most recently acquired target fault code of the corresponding lower-level device if a communication connection with any lower-level device is detected to be broken includes: The communication response status of each lower-level device is detected according to the preset cycle. If any lower-level device does not respond within at least one consecutive historical period, the communication connection with the corresponding lower-level device is determined to be broken. Set the reserved software virtual fault bit in the target fault code most recently obtained by the corresponding lower-level device; wherein, the software virtual fault bit is a reserved bit in the hardware fault code for which no hardware fault type is defined; During the period when the communication connection is disconnected, the software virtual fault bit remains set until the communication connection is detected to be restored.

4. The method according to claim 3, characterized in that, The step of detecting the communication response status of each lower-level device according to the preset period includes: Acquire the actual status information and actual output data of each lower-level device according to the preset cycle; If the current cycle fails to acquire the data, increment the no-response count bit of the corresponding lower-level device. If the current cycle is successfully acquired, the no-response counter bit of the corresponding lower-level device is reset; When the no-response count of any lower-level device is greater than or equal to a preset number of times threshold, it is determined that the corresponding lower-level device has no response for at least one historical continuous period.

5. The method according to claim 1, characterized in that, The step of determining the fault handling strategy for each lower-level device based on its current operating status and target fault code, and then executing the determined fault handling strategy, includes: For lower-level devices that are currently in an idle state, a new fault is identified based on the corresponding target fault code, the new fault is displayed, no alarm is reported to the host, and the operation process of the corresponding chamber is not stopped; For a lower-level device that is currently in a non-idle state, a new fault is identified based on the corresponding target fault code, an alarm is reported to the host, and the current operation process of the corresponding chamber is stopped.

6. The method according to claim 5, characterized in that, The step of determining the new fault based on the corresponding target fault code includes: Perform a bitwise XOR operation between the previously processed target fault code and the most recently acquired target fault code to obtain the change fault bit mask; Perform a bitwise AND operation between the changed fault bit mask and the most recently acquired target fault code to obtain the new fault bit mask; The fault type indicated by the newly added fault bit mask is determined as a newly added fault.

7. The method according to claim 5, characterized in that, The method further includes: If the fault corresponding to the fault bit in the target fault code is detected to be cleared, an alarm clearing event corresponding to the fault is sent to the host. If the communication connection with any lower-level device is detected to be restored to normal, the software virtual fault bit is cleared from the target fault code of the corresponding lower-level device; wherein, the determination condition for the communication connection to be restored to normal is: the target fault code of the corresponding lower-level device is successfully obtained in any preset period and the no-response counter bit has been reset.

8. The method according to claim 1, characterized in that, Before the step of acquiring the target fault codes corresponding to each lower-level device at a preset period, the method further includes: Create a control instance corresponding to each lower-level device, and maintain the current operating state of the corresponding lower-level device through the state machine of the control instance; When a communication connection with any lower-level device is detected to be broken, the current running state of the control instance of the corresponding lower-level device is switched to the disconnected state. When a communication connection with any lower-level device is restored, the current operating state of the control instance of the corresponding lower-level device is switched from disconnected to idle.

9. A control system for an etching machine chamber, characterized in that, The system includes: The host computer is configured to execute the etching machine control method as described in any one of claims 1-8; Host computer: Communicates with the host computer. Intermediate device: used to perform protocol conversion on communication data between the host computer and the lower device; Multiple lower-level devices: each of them is connected to the upper-level computer via the relay device. Each lower-level device corresponds to a chamber, and each chamber corresponds to multiple coils.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when invoked and executed by a processor, cause the processor to implement the etching machine control method according to any one of claims 1-8.

Images