Etching machine chamber control methods, systems, and storage media

Abstract

The present disclosure provides an etching machine chamber control method, system and storage medium; wherein the method comprises: in response to a task instruction sent by a host, distributing the task instruction to a target control instance corresponding to a target lower device according to a target lower device identifier indicated by the task instruction; if the target control instance indicates that the target lower device is in an idle state, executing a starting process of a target task according to a task parameter indicated by the task instruction; in each execution cycle conforming to the execution of the target task, controlling a plurality of coil lines of the target lower device to execute a first command of a current cycle to obtain actual output data after execution of the target lower device; judging whether the target lower device has actually stopped outputting according to the actual output data of a plurality of execution cycles; and if the target lower device has actually stopped outputting, executing a stopping process of the target task. The present disclosure can improve the controllability of the etching machine chamber.

Description

Technical Field

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

[0002] In the semiconductor manufacturing field, etching is one of the key steps in integrated circuit manufacturing. Nowadays, semiconductor manufacturing generally adopts Equipment Automation Program (EAP) to communicate with process equipment through the SECS / GEM (SEMI Equipment Communication Standard / Generic Equipment Model) protocol to achieve centralized monitoring, remote command execution and process data acquisition.

[0003] The host computer control system of a multi-chamber etching equipment typically adopts the following architecture: each process chamber is equipped with an independent industrial computer, each industrial computer runs an independent host computer control program, and interacts with the corresponding lower-level devices through their respective serial communication links; EAP needs to establish independent SECS / GEM connections with multiple PM host computers.

[0004] As equipment evolves from single-coil to multi-coil and from single-chamber to multi-chamber, the difficulty of managing this architecture also increases, making it difficult to adapt to the industry's development. Summary of the Invention

[0005] In view of this, the purpose of this disclosure is to provide an etching chamber control method, system and storage medium to improve the controllability of the etching chamber.

[0006] In a first aspect, embodiments of this disclosure provide an etching machine chamber control method. This method is applied to a host computer in an etching machine chamber control system. The system further includes a host computer, a relay device, and multiple lower-level devices. Each lower-level device corresponds to a chamber, and each chamber corresponds to a multi-channel coil. The host computer 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: responding to a task instruction sent by the host computer; allocating the task instruction to a target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction; if the target control instance indicates that the target lower-level device is in an idle state, then executing a target task startup process according to the task parameters indicated by the task instruction; wherein the target task includes a first command executed according to a preset cycle; in each execution cycle conforming to the execution of the target task, controlling the multi-channel coil of the target lower-level device to execute the first command of the current cycle, and obtaining the actual output data after execution by the target lower-level device; determining whether the target lower-level device has actually stopped outputting based on the actual output data of multiple execution cycles; if it has actually stopped outputting, then executing a target task stop process.

[0007] Optionally, before the step of allocating the task instruction to the target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction in response to the task instruction sent by the host, the method further includes: creating a control instance corresponding to each lower-level device, and allocating a corresponding number namespace to each lower-level device control instance according to a preset offset rule; wherein, the number namespace is used to distinguish the lower-level device targeted by uplink and downlink data on the communication link between the host and the host computer.

[0008] Optionally, after the step of assigning the task instruction to the target control instance corresponding to the target lower-level device, the method further includes: searching for the setting parameters of each coil in a preset recipe library according to the process recipe identifier in the task parameters indicated by the task instruction, and obtaining the process recipe parameters; and generating the running configuration of the target task based on the process recipe parameters and the task parameters.

[0009] Optionally, if the target control instance indicates that the target lower-level device is in an idle state, then the steps of executing the target task startup process according to the task parameters indicated by the task instruction include: if the state machine of the target control instance indicates that the current state of the target lower-level device is idle, then obtaining the running configuration of the target task according to the task parameters indicated by the task instruction; wherein, the running configuration includes: a first command controlling the corresponding coil of the target lower-level device to execute according to a preset period; and executing the target task startup process based on the running configuration; wherein, the startup process includes at least: switching the state machine of the target control instance to a running state and reporting a task start notification to the host.

[0010] Optionally, in each execution cycle that conforms to the execution of the target task, the step of controlling the multiplexer of the target lower-level device to execute the first command of the current cycle and obtaining the actual output data after execution by the target lower-level device includes: in each execution cycle of the target task, determining whether there is a command to be executed in the preset command queue corresponding to the target control instance; wherein, the preset command queue corresponding to the target control instance is used to asynchronously receive commands that the target lower-level device needs to execute immediately; if there is a command to be executed, it is determined that the current execution cycle does not conform to the execution of the target task, and the commands to be executed in the preset command queue corresponding to the target control instance are executed sequentially; if there is no command to be executed, it is determined that the current execution cycle conforms to the execution of the target task, and the multiplexer of the target lower-level device is controlled to execute the first command of the current cycle and obtain the actual output data after execution by the target lower-level device.

[0011] Optionally, the startup process further includes: resetting the actual stop determination status bit; wherein the actual stop determination status bit includes: an output experience flag bit, a dejitter count flag bit, and a stop trigger flag bit; the step of determining whether the target lower-level device has actually stopped outputting based on the actual output data of multiple execution cycles includes: during the execution of the target task, when the actual output data after the execution of the target lower-level device is first obtained to be outputting, setting the output experience flag bit; when the actual output data after the execution of the target lower-level device is obtained to be outputting, incrementing the count of the dejitter count flag bit; when the actual output data after the execution of the target lower-level device changes from outputting to outputting and the count of the dejitter count flag bit is less than a preset number of times threshold, resetting the dejitter count flag bit; when the count of the dejitter count flag bit is greater than or equal to the preset number of times threshold, determining whether the target lower-level device has actually stopped outputting, and setting the stop trigger flag bit.

[0012] Optionally, the stopping process of the target task includes at least: switching the state machine of the target control instance to an idle state and reporting a task completion notification to the host.

[0013] Optionally, after the step of controlling the multiplexer of the target lower-level device to execute the first command of the current cycle in each execution cycle that conforms to the execution of the target task, the method further includes: reading the actual status data of the target lower-level device after the execution of the first command in the current cycle, and determining whether the target lower-level device has malfunctioned based on the actual status data.

[0014] Secondly, embodiments of this disclosure provide an etching machine chamber control system, which includes: a host computer configured to execute the etching machine chamber 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.

[0015] Thirdly, embodiments of this disclosure provide 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 etching chamber control method.

[0016] The embodiments disclosed herein bring the following beneficial effects: The aforementioned etching machine chamber control method, system, and storage medium, in this architecture, establishes an independent control instance for each lower-level device within the host computer and uses a relay device to achieve communication protocol conversion. This allows a single host computer to uniformly manage multiple chambers and multiple coils without modifying the business logic of the upper and lower-level devices, avoiding the deployment complexity and coordination difficulties caused by multiple independent control devices. By checking whether the control instance is idle before startup, tasks are ensured to start only when the device is available, avoiding task conflicts. By prioritizing the checking of the command queue during periodic execution, urgent commands receive higher execution priority than regular periodic operations and can be inserted for execution without waiting for a complete polling cycle. By sending setting parameters to multiple coils and reading the actual output status in each execution cycle, collaborative control and status feedback of multiple coils within the same control cycle are achieved. By determining whether it has actually stopped based on the actual output status of multiple execution cycles, misjudgments caused by instantaneous state fluctuations are avoided, making the stop determination more reliable. Moreover, this determination does not depend on external stop commands, making the collaborative control of multiple chambers and multiple coils more precise and efficient.

[0017] 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.

[0018] 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

[0019] 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.

[0020] Figure 1 This is a flowchart of one embodiment of the etching chamber control method in this disclosure; Figure 2 A schematic diagram of an etching machine chamber control system provided in an embodiment of this 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 an etching machine chamber control system provided in an embodiment of the present disclosure. Detailed Implementation

[0021] 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.

[0022] 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.

[0023] It is understood that the etching machine chamber 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 one 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 of the others; the communication status of one link does not affect the others. 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.

[0024] 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.

[0025] 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.

[0026] Specifically, the etching machine chamber 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 coils each via six independent serial ports. This single software package enables coordinated control of the coils in multiple chambers 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. The etching machine chamber control method provided in this disclosure is designed for semiconductor process equipment such as etching machines with multiple sets of coils. It allows for the simultaneous management of multiple lower-level coil drive devices on a single industrial computer, improving the controllability of the etching machine chambers and coils. Furthermore, the reduced number of industrial computers leads to lower costs.

[0027] 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 etching chamber control method in this disclosure includes: Step S10: In response to the task instruction sent by the host, the task instruction is assigned to the target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction. A control instance is an independent logical control unit created within the host computer software for each lower-level device. Each control instance has independent operating status and maintenance data, used to characterize the current working state of the corresponding lower-level device, such as idle state, running state, error state, or disconnected state. As a management object within the host computer, the control instance enables the host computer to manage multiple lower-level devices in a structured manner within a single software suite. The host computer creates a corresponding control instance for each lower-level device, and each control instance has a binding relationship with its corresponding lower-level device, its chamber, and its coil. That is, there is a mapping relationship between the control instance and the lower-level device it manages. This mapping relationship can be statically configured (e.g., preset through a configuration file) or dynamically established (e.g., automatically identifying the lower-level device and creating the corresponding control instance when the host computer starts up).

[0028] The mapping relationship between the control instances corresponding to each lower-level device is pre-bound. Specifically, it can be automatically created during initialization based on the actual list of connected lower-level devices, or it can be manually established by the operator based on the device configuration. The mapping relationship can be created using static mapping (such as preset in the configuration file) or dynamic mapping (such as the host computer automatically identifying the lower-level device and creating the corresponding instance), and the specific method is not limited here.

[0029] In this embodiment, the task instruction is a data instruction issued by the host computer to start or control the execution of the etching process. The task instruction at least includes a target lower-level device identifier, which indicates which lower-level device the current task should be assigned to for execution. The task instruction can be a remote command message sent by the host computer via the SECS / GEM protocol, or a job issuance instruction in other industrial control protocols; its specific data format depends on the communication protocol used between the host computer and the upper-level computer.

[0030] In one implementation, the task instruction can be a remote command message S2F41 under the SECS / GEM protocol, a JSON or binary instruction in a custom TCP / IP protocol, or a control message in an industrial fieldbus protocol; the specific method is not limited here. After the host computer assigns the task to the target control instance, it sends the task instruction to the corresponding lower-level device through a relay device.

[0031] In one implementation, when the host computer needs to initiate the etching process, it sends a task command to the host computer via a remote command message S2F41. The data structure of this message may contain a parameter named "Chamber," the value of which is the target lower-level device identifier. For example, a value of "PM3" indicates that the target chamber is process module 3. Upon receiving the remote command, the host computer parses the message payload, extracts the target lower-level device identifier "PM3," and then searches for a control instance matching this identifier in a control instance mapping table maintained internally by the host computer. This mapping table pre-configures the mapping relationship between each lower-level device identifier and its corresponding control instance, for example, "PM1→Instance 1, PM2→Instance 2, ..., PM6→Instance 6." The host computer locates the target control instance corresponding to "PM3" through the table lookup operation and then assigns the task command to that control instance. Specifically, the relevant parameters of the current task can be recorded in the data structure of the control instance, and the control instance is marked as pending startup. After assignment, the host computer returns a positive response to the host computer via an S2F42 message, indicating that the task has been successfully assigned. During subsequent cycle execution, the host computer sends control commands to the target lower-level device through a relay device. The relay device converts the commands sent by the host computer into a communication protocol format that the target lower-level device can recognize and then forwards them to the corresponding lower-level device. Similarly, the data returned by the lower-level device is uploaded to the host computer after being converted by the relay device.

[0032] When the host computer cannot match the corresponding control instance based on the target lower-level device identifier in the task instruction (e.g., the identifier is invalid, the corresponding lower-level device is not connected, or the corresponding control instance does not exist), the host computer returns an allocation failure response to the host computer, and may include an error code in the response to indicate the reason for the failure.

[0033] If the host computer receives multiple task instructions for different target lower-level devices, the host computer will assign each task to its corresponding control instance. Since each control instance is independent of the others, multiple tasks can be processed in parallel on different control instances without interfering with each other.

[0034] This implementation responds to task commands sent by the host computer and assigns tasks to corresponding target control instances based on the target lower-level device identifier. The host computer can automatically identify the target chamber of the task and route the task to the corresponding control instance, thus automating task routing and avoiding the tedious operation and error risks associated with manually specifying target devices. Furthermore, since the host computer maintains an independent control instance for each lower-level device, the operating states of each control instance are isolated from each other. An anomaly in one control instance will not affect the normal operation of other control instances, thereby improving the system's reliability and parallel processing capabilities.

[0035] Step S20: If the target control instance indicates that the target lower-level device is in an idle state, then execute the target task startup process according to the task parameters indicated by the task instruction; wherein, the target task includes a first command executed according to a preset cycle; This implementation method determines whether the target control instance indicates that the target lower-level device is in an idle state, and only executes the startup process when it is idle. This avoids resource conflicts, task chaos, or equipment damage caused by forcibly starting a new task when the device is busy executing other tasks or in an abnormal state, thereby improving the system's orderliness and security at the task scheduling level. By executing the startup process according to task parameters, the host computer can flexibly configure the runtime parameters of the target task according to different task parameters issued by the host, realizing the adaptive execution of different process tasks without manual intervention. The automated execution of the startup process allows the entire process from task allocation to process startup to be completed automatically by the host computer without manual intervention, reducing operation delays and human errors, and improving the efficiency and reliability of task startup.

[0036] In this embodiment, the target task includes a first command executed according to a preset cycle, which enables each coil to continuously receive control commands according to a fixed time rhythm during process execution, ensuring the continuity and stability of the process and providing a timing basis for the coordinated control of multiple coils.

[0037] The idle state is a state in which the lower-level device corresponding to the control instance is not currently executing any process tasks and there are no unhandled exceptions or errors. In this state, the lower-level device is in a standby ready state, possessing the physical and logical conditions to accept and execute new tasks. Specifically, the control instance can indicate the current state of the lower-level device through its internally maintained state machine. This state machine includes at least an idle state and a running state, and may also include disconnected states, error states, etc.

[0038] The host computer can issue task parameters to the host computer via task commands. Task parameters can include product parameters and process parameters, specifically including recipe identifiers (indicating the process plan to be executed), product identifiers (such as wafer ID or batch number, used for process traceability), process control parameters (such as target current values, target power values, and other physical quantities directly used to control the coil), task priority, and task timeout time. Task parameters can be provided directly by the host computer or obtained by the host computer from local or remote sources based on reference identifiers provided by the host computer.

[0039] The startup process may include at least one initialization operation that enables the target lower-level device to transition from an idle state to a process execution state. Specifically, the startup process includes at least switching the state of the control instance from an idle state to a running state, and returning confirmation information of task startup to the host computer to ensure consistency in state perception between the host computer and the host computer. When the host computer executes the startup process, it sends initial configuration instructions to the lower-level device through a relay device.

[0040] Depending on the specific implementation method, the startup process may also include: retrieving the corresponding process formula parameters from the formula library based on the process scheme identifier in the task parameters, verifying the legality of the retrieved process formula parameters, converting the process formula parameters into an executable running configuration for the control instance, and sending initial configuration instructions to lower-level devices, etc.

[0041] Specifically, the startup process includes setting the current task information (including wafer ID, recipe ID, etc.), switching state machines, reporting the process start event to the host, and sending the first command to the target lower-level device when the first preset period (e.g., 150ms) arrives after the task starts. This includes writing the initial current to the coil of the lower-level device. The preset period of the first command can be configured according to the process type and the response characteristics of the coil. For example, it can be set to 100ms for fast-response coils and 200ms for slow-response coils.

[0042] The first command is a periodic control instruction sent by the host computer to the target lower-level device at a preset cycle during the execution of the target task, used to maintain or advance the process. The first command differs from a one-time command in that it is a periodic, repetitive, routine control operation, such as writing the current cycle's set current value to multiple coils each cycle; while a one-time command is a non-periodic emergency operation triggered externally under specific conditions, such as a stop command or a reset command. The specific content of the first command is determined by the nature of the target task, and at least includes the issuance of set parameters (such as set current, set power, etc.) for each coil, and may also include a query request for the operating status of the lower-level device. The first command being executed at a preset cycle means that during the execution of the target task, the host computer repeatedly sends the first command to the target lower-level device at specified time intervals (such as every 150 milliseconds, every 200 milliseconds, etc.), so that the operating parameters of each coil are continuously updated, thereby ensuring the continuity and stability of the process. The preset cycle can be fixed or dynamically adjusted according to the process stage, process parameters, or external conditions; no specific limitation is made here.

[0043] The control instance can indicate whether the target lower-level device is in an idle state in various ways, including but not limited to: indicating through the enumerated value of state machine variables, indicating through Boolean busy / idle flags, indicating through whether the current task identifier is empty, or indicating through a combination of conditions (e.g., the state is idle and the command queue is empty). Regardless of the determination method used, as long as it can characterize whether the lower-level device is currently ready to accept new tasks, it falls within the scope of this step.

[0044] When the target control instance indicates that the target lower-level device is in a non-idle state, the host computer can take different actions depending on the specific circumstances, including but not limited to: returning a negative response to the host and refusing to start the task; adding the task instruction to the task queue of the target control instance for subsequent processing; or forcibly interrupting the current task and starting the target task when specific conditions are met (such as a high-priority task).

[0045] After assigning task instructions to the target control instance, the host computer first reads the state machine variable maintained internally by that target control instance. This state machine variable is an enumeration type, and its possible values ​​are idle, running, error, and disconnected. The host computer determines whether the current value of this state machine variable is idle. If it is idle, the host computer extracts task parameters from the task instructions. The task parameters include the recipe ID and wafer ID. Then, based on the recipe ID, the host computer retrieves the corresponding process recipe from the local recipe library. The local recipe library is stored in the host computer's non-volatile storage medium and contains multiple recipe entries. Each recipe entry corresponds to a recipe ID and records the setting parameters of each coil required for the corresponding process. For example, for a four-coil configuration, each recipe entry can contain four setting current values.

[0046] After the host computer retrieves the process recipe indicated by the recipe ID in the task parameters, it extracts the corresponding four-channel coil setting parameters (e.g., channel 1 set current is 50A, channel 2 set current is 60A, channel 3 set current is 70A, and channel 4 set current is 40A). These setting parameters, along with the wafer ID, are encapsulated into the target task's runtime configuration, and then the startup process is executed. Specifically, the state machine variables of the target control instance are updated from idle to running, and confirmation information is returned to the host. In each subsequent execution cycle that conforms to the target task, the host computer packages the above four-channel coil setting parameters into a data frame conforming to the lower-level device communication protocol and sends it to the target lower-level device, causing each coil to continuously output according to the set values.

[0047] Step S30: In each execution cycle that meets the target task execution, control the multi-channel coil of the target lower-level device to execute the first command of the current cycle and obtain the actual output data after the target lower-level device has executed; In this embodiment, by controlling multiple coils to execute the first command of the current cycle and acquire actual output data in each execution cycle that conforms to the target task, the host computer can continuously provide setting parameters to each coil at a fixed time rhythm, ensuring the synchronization of multiple coils in the time dimension and avoiding the problem of output asynchrony between coils caused by inconsistent timing of control command transmission. By executing control and acquiring feedback within the same execution cycle, the host computer can obtain the actual operating status of each coil in each cycle, providing a data foundation for verifying the control effect. The coordinated control and feedback acquisition of multiple coils are completed in the same communication interaction sequence, reducing additional communication overhead and making it possible to manage more coil channels on the same hardware platform. The acquired actual output data also provides a basis for the stop determination of the target task, so that the stop determination no longer depends on a single external stop command, but is based on the actual output status of the lower device. The acquisition of actual output data enables the host computer to perceive the real-time status of each coil in each cycle, providing a reliable data foundation for subsequent automatic stop determination.

[0048] In this embodiment, before executing the periodic command (i.e., the first command) in each execution cycle of the target task, it is first determined whether the current cycle meets the execution conditions of the target task. Specifically, this can be determined by checking whether there is a second command with a higher execution priority than the periodic command. If such a command exists, the current cycle is determined not to meet the execution conditions of the target task; otherwise, it is determined to meet the execution conditions of the target task, and the current cycle is considered an execution cycle that meets the requirements for the target task. The execution conditions can also be set to other parameters, such as communication link status or lower-level device status, which will not be elaborated here.

[0049] The first command is a set of instructions generated by the host computer within the current cycle, based on the current process status and task parameters, to control the operation of multiple coils in the target lower-level device. The specific content of the first command can remain constant (e.g., constant current control) or change dynamically (e.g., stepped boost or sweep control) as the execution cycle progresses, depending on the specific process scheme. The first command at least includes the issuance of setting parameters for each coil, and may also include sending requests to query the operating status of the lower-level device.

[0050] When controlling the operation of multiple coils in a target lower-level device, control commands containing the setting parameters of each coil can be sent to the target lower-level device. The lower-level device then drives each coil to output according to the set values ​​based on the control commands. During control, the upper-level computer can write the setting parameters and the lower-level device executes the output, or the upper-level computer can write the setting parameters and then read the actual output data from the lower-level device.

[0051] When controlling multiple coils of a target lower-level device, a coordinated control method of unified writing and separate reading can be adopted. This involves sending the setting parameters of all coils at once within the same cycle, and then reading back the actual output data of each coil separately. Alternatively, a channel-by-channel control method of writing and reading data one channel at a time can be used. In one implementation, a register-based sequential addressing method is used to achieve unified writing and separate reading, simplifying communication operations and improving control efficiency.

[0052] Specifically, assuming the target lower-level device drives four coil channels (channels 1 to 4), and using a continuous register addressing method, the setting parameter registers for each channel are addressed consecutively. In each execution cycle, the host computer first determines whether the current cycle meets the execution conditions of the target task. If it does, the host computer packages the set current values ​​of the four coils in the current cycle (e.g., channel 1 set to 50A, channel 2 set to 60A, channel 3 set to 70A, and channel 4 set to 40A) into a single communication data frame and sends it to the target lower-level device via a relay device. The relay device converts the communication data frame into a protocol format recognizable by the target lower-level device and writes it all at once to consecutive register addresses on the target lower-level device, for example, four registers starting at address 0x0200. After the write operation is completed, the host computer reads the actual current values ​​of the four channels from the read area register address of the target lower-level device (e.g., the four registers starting at read area address 0x0100) within the same cycle, and reads the actual output status flag from the extended register, such as the status bit indicating power output enable. This flag can be an integer value; a non-zero value indicates that the lower-level device has power output, and a zero value indicates that there is no power output. The host computer records the read actual current values ​​as part of the actual output data for subsequent processing. This unified write and separate readback control method allows the setting and feedback acquisition of multiple coils to be completed in a single communication interaction, reducing communication overhead and improving control efficiency.

[0053] Actual output data refers to the actual state data of each coil of the target lower-level device after executing the first command of the current cycle. Actual output data includes at least status information indicating whether the lower-level device is actually outputting data, and may also include quantitative operating parameters such as the actual current value, actual voltage value, and output power value of each coil, as well as other status flags of the lower-level device (such as fault status flags, communication status flags, etc.). Actual output data can be obtained by actively reading it from the lower-level device after sending the first command, or by the lower-level device actively reporting it according to a predetermined format. Actual output data represents the actual physical state of the lower-level device, not the set or expected values ​​sent by the host computer.

[0054] The actual output data can be acquired through two methods: active reading, where the host computer sends a read request and the slave device returns a response (in this method, the host computer actively controls the timing of data acquisition); and passive receiving, where the slave device actively reports the actual output data according to a predetermined format (in this method, the host computer passively listens for and receives the data). In each execution cycle, the host computer sends the current cycle's set parameters (first command) to the target slave device via a relay device and obtains the actual output data from the target slave device after execution.

[0055] Step S40: Based on the actual output data of multiple execution cycles, determine whether the target lower-level device has actually stopped outputting; This implementation method determines the stop based on actual output data from multiple execution cycles. The host computer can make stop decisions based on the actual physical output state of the lower-level device, rather than solely on stop commands issued by the host. This eliminates reliance on a single external command for stop determination. Even if the host fails to issue a stop command in time due to network latency, program errors, or communication failures, the host computer can still autonomously determine the end of the process and trigger the stop procedure based on changes in the lower-level device's own output state, thus avoiding the inconsistency problem of "the host computer believing it is still running while the lower-level device has actually stopped." Furthermore, by comprehensively considering data from multiple cycles (rather than instantaneous data from a single cycle), transient state changes caused by communication interference, electromagnetic noise, or brief fluctuations in the lower-level device's output will not immediately trigger a stop determination, avoiding misjudgments. In addition, since the determination is based on the actual output data of each execution cycle, it is unaffected by communication jitter or delays, improving the reliability of the determination results. This determination mechanism enhances the host computer's ability to understand the physical state of the lower-level device, providing a data foundation for achieving consistency between the upper and lower-level states.

[0056] In one implementation, the actual output data of multiple execution cycles can be the actual output data of multiple consecutive execution cycles. These execution cycles are execution cycles that conform to the target task execution. When determining whether the target lower-level device has actually stopped outputting based on the actual output data of multiple execution cycles, the determination can be made based on the changing trend or duration of multiple actual output states (i.e., the actual output data of multiple consecutive execution cycles) within a preset time window. The host computer determines whether the target lower-level device has actually stopped outputting based on the actual output data of multiple cycles obtained from the relay device.

[0057] This step involves the host computer determining, based on the actual output data from multiple execution cycles, whether the target lower-level device has stopped outputting at the physical level. Specifically, "actually stopped outputting" can mean that the lower-level device no longer outputs energy to the drive coil at the physical level. This can include situations where the lower-level device's power output stage is turned off, the output current drops to zero, the output voltage drops to zero, or the output power drops to zero or below a preset threshold.

[0058] In one implementation, the actual output data includes the actual current and voltage values ​​of each coil. After acquiring this data in each execution cycle, the host computer calculates the actual output power value of each channel by multiplying the actual current and voltage of each coil. The host computer compares the power value of each channel with a preset power threshold (e.g., 0.5W, which can be set according to the coil characteristics). If the power value of all channels is less than the threshold, the cycle is determined to be a no-output cycle; if the power value of any channel is greater than the threshold, the cycle is determined to be an output cycle. The host computer maintains an output-free cycle counter to record the number of consecutive output-free cycles. After calculating the power value and comparing it with a threshold in each execution cycle, the counter is incremented if the current cycle is an output-free cycle; otherwise, it is reset to zero. When the output-free cycle counter reaches a preset number of times (e.g., five consecutive times, corresponding to a judgment window of approximately 750ms, the specific duration depending on the preset cycle value), the host computer determines that the target lower-level device has actually stopped outputting. This implementation improves the accuracy of the judgment by using power calculation to reflect the actual physical output situation.

[0059] When inconsistencies arise between the actual output data of multiple execution cycles, such as some cycles indicating output and others indicating no output, the host computer can determine whether the target lower-level device has actually stopped outputting using a preset judgment strategy. For example, when the number of cycles without output reaches a preset number of consecutive cycles, it is determined that output has actually stopped; when the ratio of cycles with output to cycles without output reaches a preset threshold, it is determined that output has actually stopped; or when the change of the output status flag conforms to a specific timing pattern, it is determined that output has actually stopped. The specifics are not limited here.

[0060] Step S50: If output has actually stopped, execute the stop procedure for the target task.

[0061] In this embodiment, after determining that the target lower-level device has actually stopped outputting, the target task's stop procedure is initiated. This stop procedure may include a sequence of operations that orderly transition the target lower-level device from an operating state to an idle or standby state. Because the stop procedure is automatically triggered in response to the actual output state at the physical layer, it is unaffected by the loss or delay of external commands. This results in higher certainty and predictability in the termination of the target task, reducing the risk of host-side task management chaos or data loss due to uncertain termination states.

[0062] Specifically, the stopping process may include at least switching the state of the target control instance from running to idle, reporting a task completion notification to the host, and may also include sending a stop confirmation command to the target lower-level device, releasing the system resources occupied by the target task, closing the data log files related to the target task, and recording the process completion event in the local log, etc. The specifics are not limited here.

[0063] In one implementation, the stop procedure includes: First, the host computer switches the state machine of the target control instance from the running state to the idle state and updates relevant variables in the state machine, which may include clearing the current task identifier and resetting the runtime counter; then, the host computer generates a task completion notification message and sends an S6F11 process stop event to the host via the SECS / GEM protocol. This event may carry the target lower-level device identifier, wafer ID, task execution duration, and actual output data summary, so that the host is aware that the target task has been terminated; finally, the host computer closes the CSV data record file named after the wafer ID, releases the memory resources related to the target task, and records a log entry in the local log indicating that the process stop event has been reported. After the stop procedure is completed, the host computer enters a state of waiting for the next task instruction, i.e., the idle state.

[0064] The stop and start processes can form a symmetrical relationship in state management; that is, the start process switches the control instance from an idle state to a running state, and the stop process switches the control instance from a running state back to an idle state. Together, these two processes constitute the lifecycle management of the target task, enabling the control instance to switch between idle and running states in an orderly manner.

[0065] The etching machine chamber control method provided by the above-described embodiments, in its architecture, establishes an independent control instance for each lower-level device within the host computer and achieves communication protocol conversion through a relay device. 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, avoiding the deployment complexity and coordination difficulties caused by multiple independent control devices. By determining whether the control instance is idle before startup, it ensures that tasks are only started when the device is available, avoiding task conflicts. By prioritizing the checking of the command queue during periodic execution, urgent commands receive higher execution priority than regular periodic operations and can be inserted for execution without waiting for a complete polling cycle. By sending setting parameters to multiple coils and reading the actual output status in each execution cycle, it achieves collaborative control and status feedback of multiple coils within the same control cycle. By determining whether it has actually stopped based on the actual output status of multiple execution cycles, it avoids misjudgments caused by instantaneous state fluctuations, making the stop determination more reliable. Moreover, this determination does not depend on external stop commands, making the collaborative control of multiple chambers and multiple coils more accurate and efficient.

[0066] Next, the specific methods for controlling the etching machine chamber will be explained.

[0067] In one implementation, before the step of allocating the task instruction to the target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction in response to the task instruction sent by the host, the method further includes: creating a control instance corresponding to each lower-level device, and allocating a corresponding number namespace to each control instance corresponding to the lower-level device according to a preset offset rule; wherein, the number namespace is used to distinguish the lower-level device targeted by uplink and downlink data on the communication link between the host and the host computer.

[0068] This implementation creates a corresponding control instance and assigns a numbering namespace to each lower-level device before task allocation. This allows data from or destined for different lower-level devices to be accurately distinguished by the numbering identifier on a single communication link between the host and the upper-level computer. This avoids the resource consumption and management complexity of establishing independent communication links for each lower-level device, and also avoids data crosstalk or identity confusion caused by multiple devices sharing the same numbering. The preset offset rules of the numbering namespace ensure the determinism and predictability of numbering allocation. That is, the host does not need to know the specific number of each lower-level device in advance; it only needs to calculate according to the offset rules to know the lower-level device corresponding to any number, thereby simplifying the host's communication logic. The creation of control instances provides a structured management carrier for subsequent tasks, status queries, data reporting, and other operations, enabling the upper-level computer to manage multiple lower-level devices in a unified manner within a single software, improving the system's scalability and maintainability. The independence of the numbering namespace also ensures that each control instance is isolated from each other at the data level. The number of one control instance will not overlap with the number of another control instance, thereby avoiding the risk of data confusion.

[0069] In the semiconductor industry standard SECS / GEM protocol, communicating parties identify different types of data and events using digital identifiers. For example, Serial Voltage Identification (SVID) is used to identify device status information, Collection Event ID (CEID) is used to identify events reported by the device, and Alarm ID (ALID) is used to identify alarm information from the device. In this embodiment, the numbering namespace may include SVID, CEID, ALID segments, as well as device ID, channel, and data type segments from custom protocols.

[0070] When allocating a corresponding number namespace to the control instance corresponding to each lower-level device according to the preset offset rules, the same base number (base address) can be assigned to all control instances first. Then, based on the serial number or identifier of the lower-level device corresponding to each control instance, a fixed offset (i.e., step size) is added to the base address to obtain the number range corresponding to the control instance, which is the number namespace allocated to the control instance corresponding to the lower-level device.

[0071] For example, assuming the base address of SVID is 10000 and the step size of each control instance is 100, then the SVID namespace for the control instance corresponding to PM (Process Module) 1 is 10000 to 10099, PM2 is 10100 to 10199, and so on, with PM6 being 10500 to 10599. The base address of CEID is 20001 and the step size of each control instance is 1, then PM1's CEID is 20001, PM2's is 20002, and so on, with PM6 being 20006. The base address of ALID is 30000 and the step size of each control instance is 100, then PM1's ALID namespace is 30000 to 30099, PM2's is 30100 to 30199, and so on, with PM6 being 30500 to 30599.

[0072] In one implementation, the preset offset rules can be: a linear allocation rule of base address plus offset, a multiplicative allocation rule of base address plus sequence number multiplied by step size, a rule of grouping allocation by device type, and a rule of setting different base addresses according to function type. For example, SVID uses one set of base addresses and offsets, CEID uses another set of base addresses and offsets, and ALID uses a third set of base addresses and offsets. Specific rules are not limited here. Using preset offset rules to allocate the numbering namespace ensures that the numbering ranges of each control instance do not overlap, and that there is a definite correspondence between the number and the lower-level device, facilitating the host to deduce the data source through the number.

[0073] Uplink and downlink data include both. Uplink data refers to data transmitted from the host computer to the main computer, and may include status data, event notifications, and alarm information reported by the lower-level devices. Downlink data refers to data transmitted from the main computer to the host computer, such as task instructions, parameter settings, and control commands issued by the main computer. The numbered namespace is used to distinguish the lower-level devices to which uplink and downlink data belong on the communication link. That is, whether it is uplink or downlink data, the identifier in the numbered namespace indicates the lower-level device to which the data belongs.

[0074] The allocated number namespace can be stored in the host computer's memory (in the form of a mapping table or hash table) or persistently stored in a configuration file. Maintaining the number namespace includes: assigning numbers when a control instance is created, reclaiming numbers when a control instance is destroyed, and dynamically adjusting number allocation during device hot-plugging.

[0075] In one implementation, after assigning the task instruction to the target control instance corresponding to the target lower-level device, the method further includes: searching for the setting parameters of each coil in a preset recipe library according to the process recipe identifier in the task parameters indicated by the task instruction, and obtaining the process recipe parameters; and generating the operation configuration of the target task based on the process recipe parameters and the task parameters.

[0076] In the semiconductor industry, process recipe identifiers are commonly referred to as RecipeID, ProcessID, RCP_ID, or similar names. In this embodiment, the process recipe identifier is issued by the host computer via a task command. The host computer uses this identifier as a keyword to search a preset recipe library to obtain the corresponding complete set of process parameters.

[0077] The preset recipe library is a database or dataset containing one or more process recipe entries, pre-stored on the host computer's local storage medium. It is used to store the mapping relationship between each process recipe identifier and the corresponding coil setting parameters. The preset recipe library is stored in the host computer's non-volatile storage medium (such as hard disk, solid-state drive, EEPROM, etc.) to ensure that the recipe data is not lost after the host computer is powered off and restarted.

[0078] In one implementation, each recipe entry in the preset recipe library may include: a recipe identifier (consistent with the process scheme identifier issued by the host), setting parameters for each coil (such as the setting current value, current limit value, enable state, polarity direction, etc. for each channel), recipe version information, and a timestamp of recipe creation or modification.

[0079] The runtime configuration is a set of executable parameters generated by the host computer to execute the target task. It is a data structure that can be directly used to control the lower-level devices to execute the process. When generating the runtime configuration for the target task, the process recipe parameters and task parameters can be substituted into a preset template to obtain the runtime configuration.

[0080] The runtime configuration can include various information fields, including but not limited to: target lower-level device identifier, product identifier, process recipe identifier, setting parameters for each coil (setting current value, current limit value, enable status, polarity direction, etc. for each channel), recipe version information, task number, task start timestamp, and configuration generation timestamp. The specific number of fields in the runtime configuration depends on the actual process requirements and control accuracy requirements.

[0081] The recipe version information returned by the recipe server in the runtime configuration is used for subsequent version tracking. The recipe validity period information is used to verify whether the recipe is still valid. If the version information returned by the recipe server is inconsistent with the version cached locally on the host computer, the host computer can trigger a recipe update process to cache the new version recipe locally for later use, ensuring the consistency of process parameters.

[0082] After the host computer retrieves the process formula parameters from the preset formula library, it performs a validity check on the obtained formula parameters before generating the operating configuration. The validity check includes one or more of the following: checking whether the set current value of each channel is between the minimum and maximum values ​​allowed by the equipment (e.g., the current of each channel cannot exceed 100A and cannot be negative); checking whether the enable status of each channel is valid (the enable mask cannot be 0, i.e., at least one channel is enabled); checking whether the current limit value is greater than or equal to the maximum value of the set current values ​​of all channels (i.e., the current limit value must be large enough to accommodate the normal output of each channel); and checking whether the formula is within its validity period (the formula may have an expiration date). If the parameter verification passes, the formula parameters are used to generate the operating configuration; if the verification fails (e.g., the set current of a certain channel exceeds the maximum value allowed by the equipment), the host computer does not generate the operating configuration, but instead returns a startup failure response to the host computer, carrying a specific verification error code in the response, indicating that the formula parameters exceed the equipment's capability range. This embodiment prevents abnormal execution caused by incorrect formula data or changes in equipment capabilities through parameter verification, thus improving the safety of process execution.

[0083] In one implementation, if the target control instance indicates that the target lower-level device is in an idle state, then the steps of executing the target task startup process according to the task parameters indicated by the task instruction include: if the state machine of the target control instance indicates that the current state of the target lower-level device is idle, then the running configuration of the target task is obtained according to the task parameters indicated by the task instruction; wherein, the running configuration includes: a first command that controls the corresponding coil of the target lower-level device to execute according to a preset period; and the startup process of the target task is executed based on the running configuration; wherein, the startup process includes at least: switching the state machine of the target control instance to the running state and reporting a task start notification to the host.

[0084] The host computer pre-generates the runtime configuration of the target task and stores it in the context of the target control instance. In this embodiment, the host computer checks the state machine of the target control instance and confirms that its current state is idle. After confirmation, the host computer executes the startup process based on the runtime configuration.

[0085] As an example, and not a limitation, the startup process is executed in the following order: First, the host computer obtains the parameters from the running configuration, assuming these include the target lower-level device identifier "PM3", the wafer ID "WAFER_20240801_001", the set current values ​​for the four coils (50A, 60A, 70A, 40A), and the preset period value (150ms). Then, the host computer switches the state machine of the target control instance from "idle state" to "running state." During this switch, the host computer updates the state machine variables from idle enumeration values ​​to running enumeration values ​​and records the switch timestamp. After the state switch is complete, the host computer generates a task start notification message. This message is an S6F11 process start event conforming to the SECS / GEM standard, and its CEID uses the CEID namespace corresponding to the target control instance (e.g., the CEID for PM3 is 20003). The event includes the target lower-level device identifier "PM3", wafer ID "WAFER_20240801_001", recipe identifier "RCP_OXIDE_01", and task start timestamp. The host computer reports this event to the host computer via the communication link between the host computer and the host computer, informing the host computer that the target task has been successfully started. After the reporting is completed, the host computer initiates a periodic control loop with the target lower-level device, causing subsequent execution cycles to begin.

[0086] In one implementation, the startup process includes a failure rollback mechanism. If an error occurs at any step of the startup process (e.g., the lower-level device fails to respond to the initialization command, the communication link malfunctions, or the task start notification fails to be sent), the host computer triggers the rollback mechanism. Specific actions of the rollback mechanism may include: switching the state machine from the running state back to the idle state (if the state machine has already been switched), canceling started timers, clearing the constructed running configuration, closing open data files, and logging the startup failure. After completing the rollback, the host computer returns a startup failure response to the host computer, carrying an error code indicating the cause of the failure and the steps that occurred. Failure rollback ensures that the system is not in an inconsistent intermediate state when the startup process fails, avoiding resource leaks or state chaos caused by partial startup success or partial startup failure, thus improving the system's robustness.

[0087] In one implementation, the step of controlling the multiplexer of the target lower-level device to execute the first command of the current cycle and obtain the actual output data after execution by the target lower-level device in each execution cycle that conforms to the target task includes: in each execution cycle of the target task, determining whether there is a command to be executed in the preset command queue corresponding to the target control instance; wherein, the preset command queue corresponding to the target control instance is used to asynchronously receive commands that the target lower-level device needs to execute immediately; if there is a command to be executed, it is determined that the current execution cycle does not conform to the execution of the target task, and the commands to be executed in the preset command queue corresponding to the target control instance are executed sequentially; if there is no command to be executed, it is determined that the current execution cycle conforms to the execution of the target task, and the multiplexer of the target lower-level device is controlled to execute the first command of the current cycle and obtain the actual output data after execution by the target lower-level device.

[0088] This implementation prioritizes checking the command queue for pending commands in each execution cycle that aligns with the target task. This allows externally inserted urgent commands (such as stop, reset, and parameter update commands) to be processed immediately at the start of the next execution cycle without waiting for current or subsequent regular cycle operations to complete. This significantly reduces the response latency of urgent commands and eliminates the risk of urgent commands being blocked due to the incomplete regular operations of the previous cycle. By asynchronously receiving commands that need immediate execution into the command queue, command reception and execution are decoupled in terms of time and execution thread. In other words, commands can be inserted into the queue at any time without interfering with ongoing regular cycle operations or imposing additional real-time requirements on the communication link. When pending commands exist, regular cycle operations are skipped, and queued commands are executed first. This ensures that the execution of urgent commands does not compete with regular cycle operations for communication link or control resources, avoiding command conflicts and resource contention. When no pending commands exist, regular cycle operations are executed normally, maintaining high efficiency and stability in the absence of urgent commands. The introduction of command queues means that the processing delay of emergency commands no longer depends on the length of the regular cycle, but on the time for checking the command queue and executing the command, thereby improving the system's response speed to emergency events.

[0089] In this step, the preset command queue is a data structure allocated by the host computer to the target control instance for temporary storage of commands to be executed. The command queue is a first-in, first-out (FIFO) or priority-ordered data buffer. Its function is to decouple command reception from command execution in time; that is, commands can be inserted into the queue at any time, while command execution is scheduled within a fixed execution cycle. The command queue stores at least commands that need to be executed immediately, and may also include commands that need to be executed delayed or one-time commands.

[0090] Asynchronous reception refers to the independence of command insertion and command processing operations in terms of time and execution thread. Specifically, external commands (such as stop or reset commands issued by the host via a communication link, stop buttons clicked by operators on a host computer interface, or control instructions issued by other software modules) can be added to the tail of the command queue at any time (or inserted according to priority) without waiting for the execution cycle to arrive. The asynchronous reception mechanism allows the command initiator to disregard when the command is executed; once a command is added to the queue, the execution cycle will process it during its next scheduled execution. In contrast to synchronous reception, which requires the command initiator to wait for the command to be processed before returning, asynchronous reception allows the initiator to return immediately after the command is added to the queue, without waiting for the command to complete execution.

[0091] Specifically, the target control instance is associated with a preset command queue, which is implemented as a FIFO (First-In-First-Out) linked list. The current length of the queue is stored in an integer variable. At the beginning of each execution cycle (i.e., before executing the first command), the host computer first checks the length variable of the command queue: if the length variable is greater than 0, it means there is a command to be executed in the queue; if the length variable is equal to 0, it means the queue is empty and there is no command to be executed. In the current cycle of this embodiment, the length of the command queue is 0, so there is no command to be executed. The host computer determines that the current cycle meets the execution of the target task and then performs the normal cycle operation: packaging and sending the set current values ​​of each coil to the target lower-level device, and reading the actual output data. After the normal cycle operation is completed, the host computer enters the next execution cycle. This situation of no command to be executed occupies most of the execution cycles, ensuring the continuity and stability of process execution.

[0092] In one implementation, the startup process further includes: resetting the actual stop determination status bit; wherein the actual stop determination status bit includes: an output experience flag bit, a debouncing count flag bit, and a stop trigger flag bit; the step of determining whether the target lower-level device has actually stopped outputting based on the actual output data of multiple execution cycles includes: during the execution of the target task, when the actual output data after the execution of the target lower-level device is first obtained and there is output, setting the output experience flag bit; when the actual output data after the execution of the target lower-level device is obtained and there is no output, incrementing the count of the debouncing count flag bit; when the actual output data after the execution of the target lower-level device changes from no output to output and the count of the debouncing count flag bit is less than a preset number threshold, resetting the debouncing count flag bit; when the count of the debouncing count flag bit is greater than or equal to the preset number threshold, determining whether the target lower-level device has actually stopped outputting, and setting the stop trigger flag bit.

[0093] This implementation maintains three status bits to determine whether the target lower-level device has actually stopped outputting. By setting an output experience flag and only setting it when output is first detected, the stop determination only takes effect after the device has entered an actual output state. This prevents the risk of misjudging a stop due to no output data before the process has started, ensuring that the triggering condition for the stop determination has the timing constraint of "the device must start before stopping". By setting an anti-jitter count flag and incrementing the count when there is no output and resetting the count when output resumes, the stop determination is triggered only after a sufficient number of consecutive no-output states. Single or occasional no-output states caused by instantaneous communication jitter, electromagnetic interference, or brief fluctuations in the lower-level device output will not falsely trigger the stop, effectively improving the anti-interference capability and reliability of the stop determination. By setting a stop trigger flag and setting it when a stop is determined, the stop process is triggered only once during the entire target task. This avoids repeated execution of the stop process, repeated state switching, and repeated reporting of task end notifications due to the unrestricted stop trigger flag, ensuring the single execution of the stop process and the consistency of state switching.

[0094] In this embodiment, the output history flag is used to record whether the target lower-level device has entered the actual output state during the current target task. The initial value of this flag is "false" (or 0), indicating that no actual output has been detected. When the host computer first obtains the actual output data as "output has occurred" in a certain execution cycle, it sets the flag to "true" (or 1), indicating that the target lower-level device has actually output during this target task. Once this flag is set to "true", it will not be reset during the entire target task (unless it is reset during the startup process). Its function is to ensure that the stop determination only takes effect after the device has actually output, avoiding the misjudgment of "stopped" when the actual output data is "no output" before the process has started.

[0095] The anti-jitter count flag is used to record the number of consecutive times a no-output state is detected. The initial value of this flag is 0, indicating that counting has not yet started or the count has been reset. In each execution cycle of the target task, if the actual output data obtained is no output and the output experience flag is true, the anti-jitter count flag is incremented by 1. If, during continuous counting, the actual output data obtained in a certain cycle recovers to output, and the current anti-jitter count has not yet reached the preset threshold, the anti-jitter count flag is reset to 0. The purpose of the anti-jitter count flag is to prevent misjudgments caused by instantaneous communication jitter or brief fluctuations in the output of the lower-level device. A stop judgment will only be triggered when the no-output state persists for a sufficiently long time (i.e., no output is detected multiple times consecutively).

[0096] The stop trigger flag is used to prevent the stop process from being triggered repeatedly after a stop has already been determined. The initial value of this flag is false (or 0), indicating that the stop process has not yet been triggered. When the anti-jitter count flag reaches or exceeds a preset threshold and the stop trigger flag is false, the host computer determines that the target lower-level device has actually stopped outputting and sets the stop trigger flag to true (or 1), indicating that the stop process has been triggered. Once the stop trigger flag is set to true, even if the anti-jitter count continues to increase, the stop process will not be triggered repeatedly, thus avoiding repeated stop process execution caused by repeated reporting of the same stop event. These three flags are reset during the target task's startup process. Each time a new task is started, these three flags are reset to their respective initial values ​​(output experience flag is false, anti-jitter count flag is 0, and stop trigger flag is false) to ensure that the stop determination state of the previous task does not interfere with the determination process of the current task.

[0097] A "output present" status indicates that the lower-level device is currently outputting energy to the drive coil. Conversely, a "no output" status indicates that the lower-level device is not currently outputting energy to the drive coil. The specific methods for determining whether there is output or not can be: a non-zero value for the actual output status flag indicates output, while a zero value indicates no output; or an actual current value greater than a preset threshold (e.g., 0.5A) indicates output, while a value less than or equal to the preset threshold indicates no output; or an actual power value greater than a preset threshold indicates output, while a value less than or equal to the preset threshold indicates no output.

[0098] Increasing the anti-shake count flag can be done by incrementing its current value by 1. For example, if the current value is 0, it becomes 1; if it's 1, it becomes 2. Resetting the anti-shake count flag restores its value to its initial value of 0. Resetting typically occurs in two situations: first, during the startup process when resetting the actual stop determination status bit; second, during the execution of the target task, when the actual output data changes from no output to output, and the anti-shake count has not yet reached the preset threshold. The reset logic in the second case implements the anti-shake mechanism. If the output of the lower-level device only disappears briefly (e.g., a momentary drop to zero due to a sudden load change), the anti-shake count is cleared to zero after the output resumes, thus preventing a single zero-drop event from accumulating into a stop determination.

[0099] In a specific embodiment, it is assumed that the preset threshold number of times is 3. During the startup process of the target task, the host computer resets the output process flag, anti-jitter count flag, and stop trigger flag of the target control instance to their initial values: false, 0, and false, respectively. After the target task starts, the host computer acquires the actual output data in each execution cycle and executes the following judgment logic sequentially: In the first execution cycle, the actual output data obtained by the host computer indicates that there is output (ECAT_Value = non-zero). Since the output experience flag is currently false and output is detected for the first time, the host computer sets the output experience flag to true and keeps the debouncing count at 0; In the 2nd to 10th execution cycles, the actual output data indicates that there is output, the output experience flag is kept as "true", and the debouncing count is kept as 0; In the 11th execution cycle, the actual output data indicates no output (ECAT_Value=0). The output experience flag is true, so the host computer increments the anti-bounce counter flag from 0 to 1; In the 12th execution cycle, the actual output data still indicated no output. The host computer then increased the anti-jitter count from 1 to 2. In the 13th execution cycle, the actual output data still indicates no output. The host computer increases the anti-jitter count from 2 to 3. At this point, the anti-jitter count reaches the preset threshold (3 times), and the host computer determines that the target lower-level device has actually stopped outputting and sets the stop trigger flag to true. Subsequently, the host computer executes the stop procedure for the target task; In the 14th execution cycle, although the actual output data still indicates no output, the host computer no longer repeatedly determines to stop because the stop trigger flag has been set to true, thus avoiding the stop process being executed repeatedly. The output history flag always remains true, serving as a historical record of "this task has actually output," and is unaffected by the stop trigger.

[0100] In one implementation, the termination process for the target task includes at least: switching the state machine of the target control instance to an idle state and reporting a task completion notification to the host. In this implementation, by switching the state machine of the target control instance to an idle state, the state of the control instance within the host computer is kept consistent with the physical termination state of the lower-level device. This allows the host computer's scheduling logic to make subsequent task allocation decisions based on accurate state information, avoiding task conflicts caused by inconsistent states. After the state switch is complete, the target control instance can accept new task instructions, improving device utilization efficiency and task scheduling flexibility. By reporting a task completion notification to the host, the host can promptly learn that the target task has ended, thereby updating the task status on the host side, reclaiming the resources allocated to the task, and matching the task completion notification with previously issued task instructions and task start notifications, completing the full lifecycle management from task issuance to task completion.

[0101] The task completion notification can include various information fields, including but not limited to: target lower-level device identifier, wafer identifier, task execution duration, task execution result (normal / abnormal), stop determination criteria, and a summary of the actual output data of each coil. The specific format of the task completion notification depends on the communication protocol between the host and the upper-level computer; for example, it may be an S6F11 event in the SECS / GEM protocol, or a JSON or binary message in a custom protocol.

[0102] If the task completion notification fails to be reported, the host computer can adopt various handling strategies, including but not limited to: recording the reporting failure in the local log and retrying the reporting after communication is restored; abandoning the reporting and keeping the state switch effective; or sending an alarm prompt to the operator interface. Regardless of the strategy adopted, the state switch operation itself is not affected by the reporting result, because the physical stop state of the lower-level device will not change due to the success or failure of the reporting.

[0103] In one implementation, after the step of controlling the multi-channel coil of the target lower-level device to execute the first command of the current cycle in each execution cycle that conforms to the target task execution, the method further includes: reading the actual status data of the target lower-level device after the execution of the first command of the current cycle, and determining whether the target lower-level device has malfunctioned based on the actual status data.

[0104] This implementation method reads the actual status data of the lower-level device and determines whether a fault has occurred after the control multi-channel coil executes the first command of the current cycle. This allows the host computer to promptly perceive the operational health status of the lower-level device in each execution cycle, achieving early fault detection and rapid response. This avoids process failures or equipment damage caused by undetected faults. By performing fault detection in each execution cycle, it ensures that faults are detected in the shortest possible time after they occur, reducing the fault detection delay window and providing a time basis for rapid response. Since fault detection is automatically completed during routine cycle operations, no additional detection cycles or manual intervention are required, reducing the complexity of equipment maintenance and response delays. Recording the fault judgment results along with periodic data provides a complete data foundation for subsequent fault analysis and root cause localization, facilitating equipment maintenance and process optimization.

[0105] Actual status data refers to relevant data information about the internal operating status of the target lower-level device. Specifically, it characterizes the operational health status of the lower-level device, including the presence of faults, anomalies, or warnings, as well as the working status of various modules within the device, such as temperature, communication status, and power status. When actual status data indicates a fault in the lower-level device, the host computer can take corresponding measures, including but not limited to: recording fault logs, reporting alarms to the host, stopping the current target task, or triggering a fault recovery process.

[0106] Fault detection can be achieved by reading an independent fault code register (e.g., each bit corresponds to a fault type), or by reading the fault flag bit in the status register, or by analyzing the deviation between the actual operating parameters and the set parameters of each channel. The specific method is not limited here.

[0107] 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 chamber control method described above; 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.

[0108] The aforementioned etching machine chamber control system allows the host computer to send commands to the upper-level computer. The upper-level computer establishes an independent control instance for each lower-level device, and a relay device converts the communication protocol. This enables a single host computer to manage multiple chambers and multiple coils without altering the business logic of the upper and lower-level devices, avoiding the deployment complexity and coordination difficulties associated with multiple independent control devices. By checking the idle state of the control instance before startup, tasks are ensured to start only when the device is available, avoiding task conflicts. Prioritizing the check of the command queue during periodic execution ensures that urgent commands receive higher execution priority than regular periodic operations, allowing them to be inserted for execution without waiting for a complete polling cycle. By sending set parameters to the multiple coils and reading the actual output status in each execution cycle, collaborative control and status feedback of multiple coils within the same control cycle are achieved. Determining whether a stop has actually occurred based on the actual output status of multiple execution cycles avoids misjudgments caused by instantaneous state fluctuations, making stop determination more reliable. Furthermore, this determination does not rely on external stop commands, resulting in more precise and efficient collaborative control of multiple chambers and multiple coils.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

[0118] 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.

[0119] 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.

[0120] 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.

[0121] 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.

[0122] 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).

[0123] For ease of understanding, Figure 4The 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.

[0124] 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.

[0125] 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.

[0126] 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 etching chamber control method.

[0127] The etching chamber control method, system, and storage medium computer program product 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 details, please refer to the method embodiments, which will not be repeated here.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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 controlling the chamber of an etching machine, 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: In response to the task instruction sent by the host, the task instruction is assigned to the target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction; If the target control instance indicates that the target lower-level device is in an idle state, then the target task startup process is executed according to the task parameters indicated by the task instruction; wherein, the target task includes a first command executed according to a preset period; In each execution cycle that conforms to the target task, the multi-channel coil of the target lower-level device is controlled to execute the first command of the current cycle, and the actual output data after the target lower-level device is executed is obtained; Based on the actual output data of multiple execution cycles, determine whether the target lower-level device has actually stopped outputting; If output has actually stopped, then execute the stop procedure for the target task. In each execution cycle that conforms to the target task, the step of controlling the multiplexer of the target lower-level device to execute the first command of the current cycle and obtaining the actual output data after the target lower-level device has executed the command includes: In each execution cycle of the target task, it is determined whether there is a command to be executed in the preset command queue corresponding to the target control instance; wherein, the preset command queue corresponding to the target control instance is used to asynchronously receive commands that the target lower-level device needs to execute immediately; If there are commands to be executed, it is determined that the current execution cycle does not meet the execution of the target task, and the commands to be executed in the preset command queue corresponding to the target control instance are executed sequentially. If there is no command to be executed, the current execution cycle is determined to be in line with the execution of the target task. The multi-channel coil of the target lower-level device is controlled to execute the first command of the current cycle, and the actual output data after the target lower-level device is executed is obtained.

2. The method according to claim 1, characterized in that, Before the step of allocating the task instruction to the target control instance corresponding to the target lower-level device according to the target lower-level device identifier indicated by the task instruction, in response to the task instruction sent by the host, the method further includes: Create a control instance corresponding to each lower-level device, and assign a corresponding number namespace to the control instance corresponding to each lower-level device according to the preset offset rules; The numbering namespace is used to distinguish the downstream device to which uplink and downlink data are targeted on the communication link between the host and the upper computer.

3. The method according to claim 1, characterized in that, After the step of assigning the task instruction to the target control instance corresponding to the target lower-level device, the method further includes: Based on the process formula identifier in the task parameters indicated by the task instruction, the setting parameters of each corresponding coil are searched from the preset formula library to obtain the process formula parameters. Based on the process formula parameters and the task parameters, the operation configuration of the target task is generated.

4. The method according to claim 1, characterized in that, If the target control instance indicates that the target lower-level device is in an idle state, then the steps of executing the target task startup process according to the task parameters indicated by the task instruction include: If the state machine of the target control instance indicates that the current state of the target lower-level device is idle, then the running configuration of the target task is obtained according to the task parameters indicated by the task instruction; wherein, the running configuration includes: a first command that controls the corresponding coil of the target lower-level device to execute according to a preset cycle; Based on the aforementioned runtime configuration, the startup process of the target task is executed; wherein, the startup process includes at least: switching the state machine of the target control instance to the running state and reporting a task start notification to the host.

5. The method according to claim 1, characterized in that, If the target control instance indicates that the target lower-level device is not idle, then a negative response is returned to the host and the task is refused to start; The task instruction is added to the task queue of the target control instance for further processing.

6. The method according to claim 1, characterized in that, The startup process further includes: resetting the actual stop determination status bit; wherein, the actual stop determination status bit includes: output experience flag bit, anti-jitter count flag bit, and stop trigger flag bit; The step of determining whether the target lower-level device has actually stopped outputting based on the actual output data of multiple execution cycles includes: During the execution of the target task, when the actual output data after the execution of the target lower-level device is first obtained and there is output, the output experience flag is set; When the actual output data obtained after the target lower-level device executes is no output, the count of the anti-shake count flag is incremented; If the actual output data of the target lower-level device changes from no output to output after execution, and the count of the anti-shake count flag is less than a preset number of times, then reset the anti-shake count flag. When the count of the anti-shake count flag is greater than or equal to a preset number of times threshold, it is determined whether the target lower-level device has actually stopped outputting, and the stop trigger flag is set.

7. The method according to claim 1, characterized in that, The termination process of the target task includes at least the following: switching the state machine of the target control instance to an idle state and reporting a task completion notification to the host.

8. The method according to claim 1, characterized in that, After the step of controlling the multiplexer of the target lower-level device to execute the first command of the current cycle in each execution cycle that conforms to the target task execution, the method further includes: Read the actual status data of the target lower-level device after the execution of the first command in the current cycle, and determine whether the target lower-level device has malfunctioned based on the actual status data.

9. A control system for an etching machine chamber, characterized in that, The system includes: The host computer is configured to execute the etching chamber 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 chamber control method according to any one of claims 1-8.

Images