Communication method and device of key controller RS485 and electronic equipment

Abstract

The invention provides a key controller RS485 communication method and device and electronic equipment, which are applied to a communication system formed by a main controller and a plurality of key controllers based on RS485 bus connection, and the method comprises the following steps: the main controller sends an inquiry message to all key controllers; the main controller judges whether response messages of the key controllers are received or not, and judges whether inquiry messages are sent to all the key controllers again or not according to the judgment result; if yes, the key state of the key controller which sends the response message currently is received, an inquiry message carrying a silence instruction is sent to other key controllers, and the silence instruction is used for indicating the key controller which does not send the response message currently to enter the silence state. According to the invention, the conversion from sequential polling to event-driven parallel response is realized, the reporting delay of the key state is shortened, the real-time performance and efficiency of bus communication are improved, the data conflict possibly caused by simultaneous response of multiple nodes is avoided, and the reliability of communication is ensured.

Description

Technical Field

[0001] This invention relates to the field of communication technology for RS485 key controllers, and specifically to a communication method and device for RS485 key controllers, as well as an electronic device. Background Technology

[0002] Radiotherapy equipment typically includes a main controller located in the control room and button controllers distributed in multiple physical locations such as the treatment room, gantry, and treatment bed. To achieve reliable data exchange between the main controller and each button controller, an RS485 half-duplex communication bus is commonly used to construct a master-slave network. In this network, the main controller acts as the sole master station, and each button controller acts as a slave station. The standard communication mechanism is as follows: the main controller polls each slave station sequentially by sending address frames; the addressed slave station is only allowed to send its current button status data on the bus as a response after receiving an inquiry directed to it.

[0003] However, this question-and-answer serial communication method based on strict polling has revealed inherent performance defects in practical applications. First, communication latency is significant. Regardless of whether the slave station has a status change, the master controller must complete a full round of polling for all slave stations before it can obtain the latest status of any slave station again. When there are many slave stations, the response cycle of a single button press will be dominated by the entire polling cycle, resulting in delayed operation feedback and affecting the real-time operation of the device. Second, communication efficiency is low. Most of the time, most slave stations do not update their status, but the master controller still needs to send a large number of invalid query frames and wait for each slave station's unchanged response, resulting in a waste of bus bandwidth and controller processing resources. In addition, the half-duplex nature of the RS485 bus means that only one node is allowed to send data at a time. Although the traditional polling mechanism avoids conflicts through master station scheduling, it comes at the cost of sacrificing response speed. Therefore, in radiotherapy equipment control scenarios that require high real-time performance and multi-node collaboration, the existing RS485 master-slave polling communication mode has become a key bottleneck in improving the overall system response performance.

[0004] Therefore, existing technologies still need further development. Summary of the Invention

[0005] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a communication method and device for a button controller RS485, as well as an electronic device, to solve the problems existing in the prior art.

[0006] To achieve the above-mentioned technical objectives, according to a first aspect of the present invention, the present invention provides a communication method for a button controller based on RS485, applied to a communication system consisting of a main controller and multiple button controllers connected via an RS485 bus, comprising: S100, The main controller sends an inquiry message to all button controllers; S200: The main controller determines whether it has received a response message from the button controller, and determines whether to send an inquiry message to all button controllers again based on the determination result. S300, If yes, then receive the key status of the key controller that is currently sending the response message, and send an inquiry message carrying a mute instruction to other key controllers. The mute instruction is used to instruct key controllers that are not currently sending response messages to enter a mute state. The key controllers in the mute state are configured not to respond to the inquiry message from the main controller.

[0007] Specifically, the main controller determines whether it has received a response message from the button controller, and based on the determination result, decides whether to send an inquiry message to all button controllers again, including: If the main controller does not receive a response message from the button controller, it will send an inquiry message to all button controllers again after a first preset time interval, until the main controller receives a response message from the button controller. If the main controller receives a response message from the button controller, it receives the button status of the button controller that sent the response message, and simultaneously sends the next query message, carrying a silence instruction in the query message so that other button controllers do not respond to the query message from the main controller.

[0008] Specifically, the silence instruction is included in a preset field of the query message, and each field of the silence instruction uniquely corresponds to a button controller, which is used to independently control the silence state of the corresponding button controller.

[0009] Specifically, the message structure of the query message also includes: a message header, a device address field, a data length field, a data field, a checksum field, and a message trailer; The data field is used to represent control information that controls the status of the indicator devices on each button controller.

[0010] Specifically, the data field is divided into multiple sub-data units, each sub-data unit corresponds to a key controller, and the bits in each sub-data unit are used to independently control multiple indicator devices on the corresponding key controller.

[0011] Specifically, the method further includes: After the main controller sends an inquiry message carrying a silence command, it determines whether the current button controller has stopped sending response messages within a second preset time period. If so, it continues to send inquiry messages to all button controllers and simultaneously sends a command to release the silence state of all button controllers.

[0012] According to a second aspect of the present invention, a communication device for a key controller RS485 is provided, applied to the main controller of a communication system, the communication device comprising: The message sending unit is used to execute the operation of the main controller sending query messages to all key controllers; The message processing unit is used to execute the operation of the main controller to determine whether it has received a response message from the button controller, and to determine whether to trigger the message sending unit to send an inquiry message again based on the determination result; A silence control unit is used to, when the message processing unit determines that a response message has been received, execute the key state of the key controller that currently sends the response message, and control the message sending unit to send an inquiry message carrying a silence instruction to other key controllers; the silence instruction is used to instruct key controllers that have not currently sent a response message to enter a silence state.

[0013] According to a third aspect of the present invention, an electronic device is provided, including a processor and a memory, the memory being used to store executable instructions of the processor, the processor being configured to execute the executable instructions to implement the above-described communication method of the button controller RS485.

[0014] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the above-described communication method of the key controller RS485.

[0015] Beneficial effects: This invention provides a communication method and apparatus for RS485 key controllers. By having the key controller actively report its status upon detecting a key press event after the master controller broadcasts an inquiry, it breaks the traditional RS485 master-slave architecture's strict polling serial response mode. Furthermore, after receiving the first response, the master controller embeds a directional silence command in subsequent inquiry messages, temporarily silencing other currently inactive key controllers. This mechanism ensures that only one key controller is allowed to respond effectively at any given time, thus achieving a shift from sequential polling to event-driven parallel response while maintaining the RS485 half-duplex physical layer. This effectively shortens the key status reporting delay, improves the real-time performance and efficiency of bus communication, and avoids data conflicts that may arise from simultaneous responses from multiple nodes through the silence command, ensuring communication reliability. This method is particularly suitable for collaborative work scenarios involving multiple key controllers in radiotherapy equipment where real-time control response is crucial. Attached Figure Description

[0016] Figure 1 This is a flowchart of the RS485 communication method of the button controller provided in a specific embodiment of the present invention; Figure 2 This is a schematic diagram of the communication device of the RS485 key controller provided in a specific embodiment of the present invention; Figure 3 This is a topology diagram of the communication system provided in a specific embodiment of the present invention; Figure 4 This is a flowchart of the traditional working mode polling process provided in a specific embodiment of the present invention; Figure 5 This is a flowchart of the communication process of the RS485 button controller provided in a specific embodiment of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Other similar embodiments obtained by those skilled in the art based on the embodiments in this application without creative effort should all fall within the scope of protection of this application. Furthermore, directional terms mentioned in the following embodiments, such as "up," "down," "left," and "right," are only for reference to the directions in the accompanying drawings; therefore, the directional terms used are for illustrative purposes and not for limiting the invention.

[0018] This invention addresses the problems of long response delays and low communication efficiency caused by the traditional RS485 serial polling communication method used in existing radiotherapy equipment between the main controller and multiple button controllers (such as control room, gantry, and treatment bed controllers). It proposes an innovative parallel communication method. This method, while fully compatible with the existing two-wire RS485 half-duplex physical layer, proposes a new application layer communication protocol to transform the master-slave-response serial mode into an event-triggered, silent-control quasi-parallel mode. This improves communication speed and significantly enhances the system's real-time response capability and communication reliability without increasing hardware costs.

[0019] The present invention will be further described below with reference to the accompanying drawings and preferred embodiments.

[0020] Example 1 Please see Figure 1This embodiment provides a communication method for a button controller using RS485, applied to a communication system consisting of a main controller and multiple button controllers connected via an RS485 bus. The method includes: the main controller sending an inquiry message to all button controllers; the main controller determining whether it has received a response message from a button controller, and based on the determination result, deciding whether to send an inquiry message to all button controllers again; if so, receiving the button status of the button controller currently sending a response message, and sending an inquiry message carrying a mute instruction to other button controllers. The mute instruction is used to instruct button controllers that have not yet sent a response message to enter a mute state, wherein button controllers in a mute state are configured not to respond to the inquiry message from the main controller.

[0021] Understandably, according to the above technical solution, by optimizing the traditional RS485 master-slave serial polling mechanism into a quasi-parallel communication method that involves broadcasting queries, event triggering, and then silent control, system performance is significantly improved without changing the existing two-wire half-duplex physical layer. When there is no button operation, the system only maintains low-load periodic broadcast listening to reduce power consumption. Once any button controller is pressed, the corresponding button controller can immediately report it. After receiving the status, the master controller sends a broadcast message containing a bit-mapped silent instruction, thereby causing other button controllers to enter a silent state. This eliminates multi-node response conflicts at the physical layer and ensures communication reliability. This mechanism transforms button response from sequential waiting that relies on a long polling cycle to event-driven instant response, greatly shortening the transmission delay of control commands and further improving the real-time response capability of the communication system. At the same time, through dynamic silent and recovery logic, it ensures fair and efficient utilization of bus resources, making it particularly suitable for radiotherapy equipment scenarios with stringent real-time control requirements.

[0022] See Figure 1 The implementation steps of the RS485 communication method for the button controller of the radiotherapy equipment in this embodiment are as follows: S100, The main controller sends an inquiry message to all button controllers; It should be further explained that, in this embodiment, the main controller, through its integrated RS485 bus driver circuit, sends signals to all button controllers physically connected in parallel on the same bus, i.e., Figure 3The button controllers shown—the treatment room button controller, the first rack button controller, the second rack button controller, the first treatment bed button controller, and the second treatment bed button controller—send a data message, namely the aforementioned query message, to inquire whether any button has been pressed on any of the button controllers. This sending refers to broadcasting. To achieve broadcasting, the master controller sets its device address field (see Table 1) to a reserved, specific address that does not represent any single slave station, such as 0x00, when constructing the query message. All button controllers on the bus can receive this electrical signal at the physical layer and determine that the address is a broadcast address through their protocol parsing layer, thus receiving and processing the message. This is fundamentally different from the one-to-one addressing of specific slave station addresses (such as 0x01, 0x02) in traditional polling. The query message is not a simple instruction but a structured data frame. Its standard structure includes: a fixed header (such as 0xAABB, used for frame start synchronization), device address (broadcast address 0x00), data length, data field, silence instruction field, CRC checksum, and a fixed trailer (such as 0xFFEE). Therefore, the query message is a composite instruction package that carries control information and a silence strategy. The data fields in it can be used to issue control commands, such as updating the status of LED indicators on each button controller panel, to achieve synchronization of control and status feedback.

[0023] S200: The main controller determines whether it has received a response message from the button controller, and determines whether to send an inquiry message to all button controllers again based on the determination result. S300, If yes, then receive the key status of the key controller that is currently sending the response message, and send an inquiry message carrying a mute instruction to other key controllers. The mute instruction is used to instruct key controllers that are not currently sending response messages to enter a mute state. The key controllers in the mute state are configured not to respond to the inquiry message from the main controller.

[0024] In this embodiment, the main controller determines whether it has received a response message from the button controller, and based on the determination result, decides whether to send an inquiry message to all button controllers again, including: If the main controller does not receive a response message from the button controller, it will send an inquiry message to all button controllers again after a first preset time interval, until the main controller receives a response message from the button controller. If the main controller receives a response message from the button controller, it will receive the button status of the button controller that sent the response message, and at the same time send the next inquiry message, carrying a silence instruction in the inquiry message so that other button controllers do not respond to the inquiry message from the main controller.

[0025] It should be noted that the above-mentioned silence instruction is included in the preset fields of the query message, and each field of the silence instruction uniquely corresponds to a button controller, which is used to independently control the silence state of the corresponding button controller.

[0026] Furthermore, the message structure of the query message also includes: a message header, a device address field, a data length field, a data field, a checksum field, and a message trailer; wherein, the data field is used to represent control information for controlling the status of the indicator devices on each button controller. The data field is divided into multiple sub-data units, each sub-data unit corresponding to one button controller, and the bits in each sub-data unit are used to independently control multiple indicator devices on the corresponding button controller.

[0027] Understandably, by embedding a silence instruction field with bit mapping relationships into the query message, precise, independent, and dynamic control of the silence state of each button controller is achieved. This effectively avoids multi-node response conflicts on the RS485 half-duplex bus at the software level, ensuring absolute communication reliability. Simultaneously, the data field in the message structure adopts a sub-unit design, dividing the data into controllers and bits. This allows the main controller to update the status of multiple indicators (such as LEDs) on all button controllers in parallel and accurately within a single broadcast. This decomposes the traditional serial polling into a highly efficient parallel pipeline of control command downlink and event response uplink, greatly optimizing bus bandwidth utilization and ensuring real-time response while achieving synchronous and efficient transmission of control commands and status feedback.

[0028] Furthermore, this embodiment implements event-driven operation, which differs from the traditional time-slice polling mode. After sending an inquiry message, the main controller initiates a listening process. The logic and mechanism for judgment are as follows: After sending the inquiry message, the main controller starts a timer corresponding to a first preset duration, preferably 0.1 seconds, and continuously listens to the RS485 bus. If, before the timer expires, the main controller's receiving circuit successfully captures a response message from any button controller (confirmed via CRC check), the judgment result is yes, and the process immediately proceeds to step S300, corresponding to the button controller's button being pressed. If, within the entire first preset duration, the main controller does not receive any valid response message, the judgment result is no. At this time, the main controller determines that all buttons are currently in an idle state. Subsequently, it waits for the preset duration to end, then loops back to step S100 to initiate a new round of broadcast inquiry. Understandably, by adopting the above technical solution, a low-duty-cycle periodic listening loop is formed. This mechanism transforms the system's communication activity from traditional, indiscriminate periodic polling to on-demand response based on actual needs (key events). During periods of inactivity, the bus only broadcasts very short messages at fixed intervals, greatly reducing bus load and system power consumption; once an event occurs, the response is almost instantaneous, thus significantly shortening the average delay from key press to the main controller's perception.

[0029] It should be noted that the above technical solution is the core of this invention for resolving RS485 multi-slave contention conflicts and achieving reliable quasi-parallel communication. When the master controller receives an acknowledgment message, it parses the message. According to the acknowledgment message protocol, the data field contains the key state of the key controller that sent the message (for example, a specific position in a word set to 1 indicates that the corresponding key controller's key is pressed). By parsing this field, the master controller can accurately receive or know which key controller performed what action. For example, if a key is pressed, the pin corresponding to that button in the MCU of the key controller changes from low to high. The MCU then determines that a key has been pressed, and the key controller will send an acknowledgment message, reporting its key state to the master controller. That is, while acquiring the key state, the master controller immediately generates a new query message carrying a silence instruction and broadcasts it again. This silence instruction is an independent field (e.g., 1 byte) embedded in the query message. Each bit in this byte is pre- and uniquely assigned to a specific key controller. For example, bit 0 corresponds to the first key controller, bit 1 corresponds to the second key controller, and so on. When a bit is set to 1, it indicates that the corresponding button controller enters a silent state; setting it to 0 indicates that it is allowed to respond normally or to de-silence. When other button controllers receive this broadcast message, they will parse the silence instruction field. If they find that the bit mapped to themselves is 1, they will set a silence flag in the software logic or hardware flag bit of their MCU. During the validity period of this flag, even if the physical buttons of these controllers are pressed, their MCUs will be prohibited from starting the transmission process to respond to the master controller's query after detecting the button event because they have detected the silence flag. This physically prevents multiple slave stations from driving the RS485 bus at the same time, avoiding data frame collisions and signal conflicts that could disrupt the RS485 communication line and cause communication data distortion.

[0030] In this embodiment, after the main controller sends an inquiry message carrying a silence command, it determines whether the current button controller has stopped sending response messages within a second preset time period. If so, the main controller continues to send inquiry messages to all button controllers and simultaneously sends a command to release the silence state of all button controllers. Understandably, the release from the silence state is dynamic. When a button on the current button controller is released, the current button controller stops sending response messages. While the main controller continuously broadcasts an inquiry message carrying the silence command, it monitors whether it receives a response message from the current button controller again within a second preset time period, preferably 0.1 seconds. If no response is received within this timeout, the operation is considered complete. Subsequently, in the next broadcast inquiry, the main controller sets all bits of the silence command to 0 (i.e., 0x00). After all slave stations receive this command, they clear their own silence flags, and the system fully returns to the initial equal listening state, waiting for the next arbitrary button event, thus repeating the cycle.

[0031] Based on the above technical solution, this embodiment constructs an efficient, reliable, and real-time multi-controller parallel communication mechanism on a standard RS485 half-duplex link. The logic of each step is rigorous, and their combined effect achieves the invention's objective of improving response speed and ensuring communication reliability.

[0032] See Figures 3-5 The working principle of this invention will be illustrated below with specific examples: See Figure 3 This diagram illustrates the topology of the communication system provided in this embodiment. The communication system in this embodiment includes a main controller, a treatment room button controller, two rack button controllers, and two treatment bed button controllers. All button controllers are connected via a two-wire RS485 bus, forming a master-slave network. The main controller acts as the master station, and each button controller acts as a slave station. The traditional working mode is as follows... Figure 4 As shown, the master controller must strictly follow the order to poll each slave station sequentially, i.e., a serial polling with one question and one answer. This results in the button response time of any button controller being at least the time to poll the entire bus, which has an inherent delay.

[0033] The following is combined with Figure 5 The flowchart shown further illustrates the implementation steps of the communication method in this embodiment: Step 1: The main controller initiates a broadcast query; After the main controller is powered on and initialized, the communication process begins. First, it broadcasts an inquiry message to all button controllers on the bus. Here, broadcasting refers to the message sent by the main controller with a specific broadcast address (e.g., 0x00) in the device address field, so that all slaves on the bus can receive the instruction simultaneously. This step initializes the communication link and notifies all slaves at the lowest time cost by sending an inquiry message at the same time, laying the foundation for possible parallel responses in the future. Compared with traditional addressing one by one, it saves the time of the initial addressing.

[0034] Step 2: The main controller listens for and judges responses; After sending an inquiry message, the main controller starts a timer and listens to the RS485 bus to determine whether it receives a response message from any button controller within a preset time (e.g., one communication cycle). The result of this determination determines the subsequent process branch. Understandably, the above steps introduce an event-driven listening mechanism. The main controller no longer passively waits for the timeout of a specific slave station, but actively listens for events to occur on the bus, i.e. whether a key press has occurred. This changes the inefficient mode of traditional polling, where you have to wait regardless of whether there is an event. Based on the judgment results, the process is divided into the following two core branches: Branch 1: No response received. If the main controller does not receive any response message within a preset time (e.g., 0.1 seconds), it indicates that all buttons on the button controllers are currently in the released state, and no button events have occurred. At this time, the main controller will jump back to step 1 after a first preset time interval (e.g., 0.1 seconds as mentioned above) and initiate a new round of broadcast queries. This loop will continue, forming a normalized low-power listening state. This achieves low-load operation when there are no events. The system only maintains periodic heartbeat broadcasts, resulting in low bus activity, low power consumption, and is prepared for immediate response to any button events that may occur at any time.

[0035] Branch 2: Upon receiving a response, proceed to step S300. If the main controller receives a response message from a button controller (e.g., rack button controller) within 0.1s, it means that a button event has occurred, and the process enters the core silent control phase.

[0036] Step 3: Event handling and silent control; In this step, the main controller performs two key operations: (1) Receive and parse the key status reported by the key controller (i.e. the first rack key controller) that is currently sending the response message. The status information comes directly from the data field of its response message. (2) Immediately (or at the next communication opportunity) broadcast an inquiry message carrying a mute instruction to all key controllers. The unique feature of this message is that it contains a mute instruction field.

[0037] This silence instruction is the core of the quasi-parallel communication implementation in this embodiment. In a preferred embodiment, the above-mentioned silence instruction is a data field with a length of 1 byte (8 bits), such as... Figure 3 As shown, the system typically has 5 button controllers, so the 5 valid bits in this byte (e.g., the lower 5 bits) can be used, with each bit uniquely and consistently mapped to a specific button controller. For example: Bit 0: Corresponds to the button controller in the treatment room; Bit 1: Corresponds to the first rack button controller; Bit 2: Corresponds to the second rack button controller; Bit 3: Corresponds to the button controller for the first treatment bed; Bit 4: Corresponds to the button controller for the second treatment bed; When a bit is set to logic 1, it indicates that the corresponding button controller is commanded to enter a silent state; when it is set to logic 0, it indicates that the silent state is enabled or deactivated.

[0038] In the scenario of step 3, since the rack button controller is reporting button press events, it needs to exclusively occupy the bus to continuously and reliably report changes in button status (such as button press, release, etc.). Therefore, the mute instruction generated by the master controller will set all bits (Bit0, Bit2, Bit3, Bit4) to 1 except for the bit (Bit1) corresponding to the current button controller. After this instruction is broadcast with the query message, other button controllers will find that the mute state bit mapped to themselves is 1 when parsing the message, and will enter the mute state. In the mute state, even if the buttons of these controllers are pressed, their MCUs will not trigger the response program to the master controller's query.

[0039] It is understandable that RS485 is a half-duplex bus, meaning only one transmitter can drive the bus level at any given time. The silence command ensures that only the activated button controller (the first rack button controller in this embodiment) has the right to respond during the event response period, fundamentally eliminating data frame collisions, level disturbances, and communication failures caused by multiple slave stations responding simultaneously, thus greatly improving communication reliability. Furthermore, after the master controller broadcasts a query, all slave stations listen in parallel. Once a slave station has an event, it obtains a temporary, exclusive response window, which is equivalent to providing each slave station with a parallel response channel on demand. This optimizes the traditional polling O(n) response delay to an event trigger delay close to O(1), further improving real-time response. The master controller does not need to maintain complex conflict detection and arbitration algorithms; it can manage bus access permissions simply by configuring the silence command, making the software implementation simple and reliable.

[0040] The message structure is further explained below. The query message sent by the main controller has a refined structure, as shown in Table 1: Table 1. Structure of the query message sent by the main controller to the button controller Message header: Default 0xAABB; Device address: 0x00 indicates broadcast; Data length: The number of bytes in the "data" section; Data: The data sent by the main controller to all button controllers is generally used to control the LED status on the button controllers. Five WORDs control the LED status of the five button controllers respectively. Each WORD controls the LED indicator status on one button controller. A bit value of 1 in the WORD indicates that the corresponding LED is lit, and a bit value of 0 indicates that the corresponding LED is off. For example, WORD1 controls the LED status of the treatment room button controller, WORD2 controls the LED status of the first rack button controller, WORD3 controls the LED status of the second rack button controller, WORD4 controls the LED status of the first treatment bed button controller, and WORD5 controls the LED status of the second treatment bed button controller. This allows the main controller to update the visual feedback (such as button backlight and status indicator) of all operation panels in parallel and accurately while querying, achieving downlink synchronization of control commands and status feedback, resulting in a better human-computer interaction experience.

[0041] Silence command: 0x00 means all devices are de-silenced, 0x1E (binary 11110) means the treatment room button controller is de-silenced, other button controllers remain silent, and so on; CRC check: CRC check of the "data"; Message tail: Default 0xFFEE; The structure of the response message sent by the button controller to the main controller is shown in Table 2: Table 2. Structure of the response message sent from the button controller to the main controller Message header: Default 0xAABB; Device address: 0x01 indicates the first button controller, and so on; Data length: The number of bytes in the "data" section; Data fields: Also contains 5 WORDs, but here each WORD represents the current state of all buttons on a button controller (bit = 1 indicates that a button is pressed). When each button controller reports its own state, it carries the global button state of the entire system. This allows the main controller to indirectly obtain the previous state of other button controllers (even if they are currently silent) by analyzing a single response message, even when the main controller is silent. This provides an information basis for possible coordinated control or state recovery.

[0042] Data: Data sent from the button controller to the main controller, including the button status information on the button controllers. Five WORDs represent the button status of the five button controllers. A bit in a WORD equal to 1 indicates the corresponding button is pressed, and a bit equal to 0 indicates the corresponding button is released. WORD1 represents the button status of the treatment room button controller, WORD2 represents the button status of the first rack button controller, WORD3 represents the button status of the second rack button controller, WORD4 represents the button status of the first treatment bed button controller, and WORD5 represents the button status of the second treatment bed button controller. CRC check: CRC check of the "data"; Message tail: Default 0xFFEE; The mechanism for releasing the silence state: When a button on the activated button controller (the first rack button controller in this example) is released, its MCU detects the change in level and stops sending response messages. After the main controller sends an interrogation message carrying the silence instruction, it starts a listening timer for a second preset duration. If no response message is received from the previously active controller within this duration, it is determined that the button has been released and the event processing is completed.

[0043] At this point, the main controller will set all valid bits of the mute command byte to 0 in the next broadcast query (for example, sending a mute command 0x00). After this mute command is broadcast, all key controllers will parse and find that their own mute bit is 0, and immediately exit the mute state, restore normal responsiveness, and return to the initial listening loop starting from step 1. This mechanism ensures that mute control is dynamic and temporary, taking effect only when necessary. Once the need for exclusive communication ends, the full node listening mode is immediately restored, guaranteeing continuous and equal operability for all operating units. This avoids the risk of the entire communication system being locked down due to a key being pressed for a long time, further improving the reliability and availability of the communication system.

[0044] In summary, this embodiment constructs a highly efficient parallel communication protocol on a standard RS485 hardware platform through a collaborative mechanism of broadcast query-event-triggered response-silent command control. It creatively utilizes the software means of silent commands to solve the conflict problem of half-duplex bus in a multi-slave event-driven model. Thus, in scenarios where medical radiotherapy equipment has extremely high requirements for real-time operation, it achieves a significant improvement in response speed and a solid guarantee of communication reliability, demonstrating outstanding practical value and innovation.

[0045] It should be noted that this embodiment provides a communication method for RS485 button controllers. By having the main controller broadcast an inquiry, the button controller actively reports its status when it detects a button event, breaking the traditional RS485 master-slave architecture's strict polling serial response mode. Furthermore, after receiving the first response, the main controller embeds a directional silence command in subsequent inquiry messages, temporarily silencing other button controllers that are not currently active. This mechanism ensures that only one button controller is allowed to respond effectively at any given time, thus achieving a shift from sequential polling to event-driven parallel response while maintaining the RS485 half-duplex physical layer. This effectively shortens the button status reporting delay, improves the real-time performance and efficiency of bus communication, and avoids data conflicts that may arise from simultaneous responses from multiple nodes through the silence command, ensuring communication reliability. This method is particularly suitable for multi-button controller collaborative work scenarios in radiotherapy equipment where high real-time control response requirements are required.

[0046] Example 2 Please see Figure 2 This embodiment provides a communication device for a button controller using RS485, applied to the main controller of a communication system. The device includes: The message sending unit is used to execute the operation of the main controller sending query messages to all key controllers; The message processing unit is used to execute the operation of the main controller to determine whether it has received a response message from the button controller, and to determine whether to trigger the message sending unit to send an inquiry message again based on the determination result; A silence control unit is used to, when the message processing unit determines that a response message has been received, execute the key state of the key controller that currently sends the response message, and control the message sending unit to send an inquiry message carrying a silence instruction to other key controllers; the silence instruction is used to instruct key controllers that have not currently sent a response message to enter a silence state.

[0047] It should be noted that this embodiment provides a communication device for an RS485 button controller, applied to the main controller of a communication system. It includes a message sending unit, a message processing unit, and a silence control unit. This embodiment modularly sets up the message sending unit, message processing unit, and silence control unit within the main controller, solidifying the new communication method into a high-efficiency, reliable hardware or firmware entity. The message sending unit ensures global broadcast of instructions; the message processing unit implements event-driven intelligent listening and scheduling; and the silence control unit is used to execute conflict avoidance strategies. This modular design allows the entire logic of broadcast querying, event triggering, and silence control to operate stably, accurately, and with low latency, ensuring the reliable implementation of the communication method. The clear division of functional units improves the modularity and maintainability of the main controller software, ultimately ensuring that the entire radiotherapy equipment control system obtains real-time, conflict-free, high-performance communication capabilities. This effectively shortens the reporting delay of button status, improves the real-time performance and efficiency of bus communication, and avoids data conflicts that may be caused by simultaneous responses from multiple nodes through silence commands, ensuring communication reliability. It is particularly suitable for collaborative working scenarios of multi-button controllers in radiotherapy equipment where high real-time control response requirements are required.

[0048] Example 3 In a preferred embodiment, this application also provides an electronic device, the electronic device comprising: The computer device includes a memory and a processor. The memory stores computer-readable instructions that, when executed by the processor, implement the RS485 communication method of the key controller. This computer device can be broadly categorized as a server, terminal, or any other electronic device with the necessary computing and / or processing capabilities. In one embodiment, the computer device may include a processor, memory, network interface, communication interface, etc., connected via a system bus. The processor of the computer device can be used to provide the necessary computing, processing, and / or control capabilities. The memory of the computer device may include a non-volatile storage medium and internal memory. The non-volatile storage medium may store an operating system, computer programs, etc. The internal memory can provide an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface and communication interface of the computer device can be used to connect and communicate with external devices via a network. When the computer program is executed by the processor, it performs the steps of the method of the present invention.

[0049] The present invention can also be implemented as a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, causes the steps of the method of the embodiments of the present invention to be performed. In one embodiment, the computer program is distributed across multiple network-coupled computer devices or processors, such that the computer program is stored, accessed, and executed in a distributed manner by one or more computer devices or processors. A single method step / operation, or two or more method steps / operations, may be executed by a single computer device or processor or by two or more computer devices or processors. One or more method steps / operations may be executed by one or more computer devices or processors, and one or more other method steps / operations may be executed by one or more other computer devices or processors. One or more computer devices or processors may execute a single method step / operation, or execute two or more method steps / operations.

[0050] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover 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.

[0051] The technical features described above can be combined arbitrarily. Although not all possible combinations of these technical features are described, any combination of these technical features should be considered to be covered by this specification, provided that such combination does not contain contradictions.

[0052] The specific embodiments of the present invention described above do not constitute a limitation on the scope of protection of the present invention. Any other corresponding changes and modifications made in accordance with the technical concept of the present invention should be included within the scope of protection of the claims of the present invention.

Claims

1. A communication method of a key controller RS485, applied to a communication system composed of a master controller and a plurality of key controllers connected based on an RS485 bus, characterized in that, include: S100, The main controller sends an inquiry message to all button controllers; S200: The main controller determines whether it has received a response message from the button controller, and determines whether to send an inquiry message to all button controllers again based on the determination result. S300, If yes, then receive the key status of the key controller that is currently sending the response message, and send an inquiry message carrying a mute instruction to other key controllers. The mute instruction is used to instruct key controllers that are not currently sending response messages to enter a mute state. The key controllers in the mute state are configured not to respond to the inquiry message from the main controller.

2. The RS485 communication method for the key controller according to claim 1, characterized in that, The main controller determines whether it has received a response message from the button controller, and based on the determination result, decides whether to send an inquiry message to all button controllers again, including: If the main controller does not receive a response message from the button controller, it will send an inquiry message to all button controllers again after a first preset time interval, until the main controller receives a response message from the button controller. If the main controller receives a response message from the button controller, it receives the button status of the button controller that sent the response message, and simultaneously sends the next query message, carrying a silence instruction in the query message so that other button controllers do not respond to the query message from the main controller.

3. The RS485 communication method for the key controller according to claim 1, characterized in that, The silence instruction is included in a preset field of the query message, and each field of the silence instruction uniquely corresponds to a button controller, which is used to independently control the silence state of the corresponding button controller.

4. The RS485 communication method for the key controller according to claim 3, characterized in that, The message structure of the query message also includes: a message header, a device address field, a data length field, a data field, a checksum field, and a message trailer; The data field is used to represent control information that controls the status of the indicator devices on each button controller.

5. The RS485 communication method for the key controller according to claim 4, characterized in that, The data field is divided into multiple sub-data units, each sub-data unit corresponds to a button controller, and the bits in each sub-data unit are used to independently control multiple indicator devices on the corresponding button controller.

6. The RS485 communication method for the key controller according to claim 1, characterized in that, The method further includes: After the main controller sends an inquiry message carrying a silence command, it determines whether the current button controller has stopped sending response messages within a second preset time period. If so, it continues to send inquiry messages to all button controllers and simultaneously sends a command to release the silence state of all button controllers.

7. A communication device for a key controller RS485, used as the main controller of a communication system, characterized in that, The communication device includes: The message sending unit is used to execute the operation of the main controller sending query messages to all key controllers; The message processing unit is used to execute the operation of the main controller to determine whether it has received a response message from the button controller, and to determine whether to trigger the message sending unit to send an inquiry message again based on the determination result; A silence control unit is used to, when the message processing unit determines that a response message has been received, execute the key state of the key controller that currently sends the response message, and control the message sending unit to send an inquiry message carrying a silence instruction to other key controllers; the silence instruction is used to instruct key controllers that have not currently sent a response message to enter a silence state.

8. The communication device for the key controller RS485 according to claim 7, characterized in that, The silence control unit is also used to generate the silence command and set the silence command in a preset field of the query message, wherein each field of the silence command uniquely corresponds to a button controller.

9. An electronic device comprising a processor and a memory, the memory being used to store executable instructions of the processor, characterized in that, The processor is configured to execute the executable instructions to implement the RS485 communication method of the key controller as described in any one of claims 1 to 6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the RS485 communication method of the key controller as described in any one of claims 1 to 6.

Images