A method and system for edge cloud collaborative control of multi-node access of a label printer

Abstract

The application provides a label printer multi-node access edge cloud collaborative control method and system, relates to the technical field of edge cloud collaborative control, a local agent node is connected with a label printer, and real-time state parameters of the label printer are collected; a to-be-printed task is acquired, and the to-be-printed task is disassembled into a subtask unit according to the real-time state parameters; it is judged whether the execution burden of the subtask unit exceeds the local carrying capacity; the execution result of the local agent node is instruction-level fused with the execution result returned by the cloud, a printing instruction sequence is generated, and the printing instruction sequence is issued to the label printer for execution. The application can realize the calculation load balancing in the label printer multi-node access scene, and improve the processing efficiency of the printing task and the system robustness.

Description

Technical Field

[0001] This application relates to the field of edge-cloud collaborative control technology, and more specifically, to an edge-cloud collaborative control method and system for multi-node access of a label printer. Background Technology

[0002] In existing label printing control technologies, multiple label printers typically use a centralized server to receive print jobs, and the server directly sends complete print instructions to the designated individual printer for execution; alternatively, a local computer directly connects to the individual printer, where the local computer handles the processing and forwarding of print data. Some solutions incorporate cloud printing technology, uploading print jobs to the cloud for rendering before sending them back to the printer. In the field of edge-cloud collaboration, there are technical solutions that distribute computing tasks between edge nodes and the cloud, such as edge gateways determining the data processing location based on local resource status.

[0003] In existing label printing control technologies, multiple label printers typically employ a centralized server to process and distribute print jobs, or a local computer directly connected to a single printer. When multiple printers are connected simultaneously and the print jobs contain a large number of highly complex labels, relying entirely on local proxy nodes for processing can easily lead to processing delays or even system crashes due to limited local computing resources. Uploading all jobs to the cloud for processing results in significant network transmission latency, and when the cloud returns a large number of repetitive printer status setting instructions, it further increases the printer's parsing burden and reduces overall printing efficiency. Therefore, how to achieve computational load balancing in scenarios with multiple label printers connected, and improve print job processing efficiency and system robustness, is a challenge facing the industry. Summary of the Invention

[0004] This application provides an edge-cloud collaborative control method and system for multi-node access of label printers, which can realize computational load balancing in scenarios where multiple label printers are connected, thereby improving the processing efficiency of printing tasks and the robustness of the system.

[0005] Firstly, this application provides an edge-cloud collaborative control method for multi-node access of a label printer, the edge-cloud collaborative control method comprising the following steps: The local agent node establishes connections with multiple connected label printers and collects real-time status parameters of each label printer. Obtain the task to be printed, and break it down into multiple sub-task units according to the real-time status parameters; Determine whether the execution burden of each subtask unit exceeds the local carrying capacity. Subtask units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while subtask units that exceed the local carrying capacity are uploaded to the cloud for execution. The execution results from the local agent node and the execution results returned from the cloud are fused at the instruction level to generate a printing instruction sequence, which is then sent to the corresponding label printer for execution.

[0006] In this embodiment, the real-time status parameters include: the current queue length of each label printer, the estimated completion time of each label printer, the remaining media quantity of each label printer, the hardware health status of each label printer, and the link quality between each label printer and the local agent node.

[0007] In this embodiment, breaking down the print task into multiple sub-task units based on the real-time status parameters specifically includes: The file format of the task to be printed is parsed, and the printing data of each label is extracted one by one according to the file format specification. The extracted printing data of each label is constructed into a label sequence according to their original arrangement order in the file. Based on the media width of each label printer in the real-time status parameters, labels in the label sequence whose width exceeds the media width of all available printers are marked as unprintable labels and extracted as an independent subtask unit and uploaded to the cloud for execution. Traverse the tag sequence, detect the physical continuity between adjacent tags, merge consecutive tags with physical continuity into a physical continuous segment, and forcibly disassemble at the position where the physical continuity is interrupted; Within each physical contiguous segment, the printing media type of each label is scanned. Whenever the media type changes, the segment is disassembled at the current switching position, dividing the physical contiguous segment into sub-segments of the same media. Within each segment of the same medium, determine the rendering complexity index of each tag, extract the tags whose rendering complexity index exceeds the preset threshold into an independent subtask unit, and merge the remaining consecutive tags into another subtask unit.

[0008] In this embodiment, the printing media types include: thermal paper, thermal transfer paper, and coated paper.

[0009] In this embodiment, determining whether the execution burden of each subtask unit exceeds the local carrying capacity specifically includes: Each subtask unit is broken down into a sequence of printing primitives, which include: text rendering operation, vector graphics drawing operation, bitmap decoding operation, and font loading operation; A resource consumption coefficient is pre-defined for each printing primitive to determine the execution burden of each subtask unit; Collect the current available processor resources and current available memory resources of the local agent node to determine the instantaneous value of the local carrying capacity; The execution burden of each subtask unit is compared with the instantaneous value of the local carrying capacity. If the execution burden is less than or equal to the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has not been exceeded; if the execution burden is greater than the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has been exceeded.

[0010] In this embodiment, pre-calibrating a resource consumption coefficient for each printing primitive specifically includes: The local agent node performs benchmark tests upon initial startup, running a single text rendering operation, a single vector graphics drawing operation, a single bitmap decoding operation, and a single font loading operation, measuring the number of processor cycles and memory bytes used for each operation; The measurement results are scaled according to a preset normalization benchmark to obtain the resource consumption coefficient of each printing primitive.

[0011] In this embodiment, the execution result of the local proxy node refers to the print instruction fragment generated by the local proxy node after performing local rendering on sub-task units that do not exceed the carrying capacity; the execution result returned by the cloud refers to the compressed and encoded print instruction fragment generated by the cloud after performing remote rendering on sub-task units that exceed the carrying capacity.

[0012] In this embodiment, the execution results of the local proxy node and the execution results returned by the cloud are fused at the instruction level to generate a print instruction sequence, specifically including: The execution results of the local agent node and the execution results returned by the cloud are sorted according to the order of their corresponding subtask units in the task to be printed, resulting in an ordered sequence of instruction fragments. Traverse the ordered instruction fragment sequence and detect redundant instructions between two adjacent instruction fragments. The redundant instructions include: repeated printer status setting instructions, repeated font loading instructions, and repeated coordinate system definition instructions. When redundant instructions are detected, the redundant instructions in the subsequent instruction segment are deleted, and a status preservation indicator is inserted between the previous instruction segment and the subsequent instruction segment. All instruction fragments, after redundancy removal and status preservation indicator insertion, are concatenated sequentially to generate a print instruction sequence.

[0013] In this embodiment, the printing instruction sequence includes: status control instruction, layout positioning instruction, content rendering instruction, and execution trigger instruction.

[0014] Secondly, this application provides an edge-cloud collaborative control system for multi-node access of label printers, used to execute an edge-cloud collaborative control method for multi-node access of label printers, the edge-cloud collaborative control system comprising: The parameter acquisition module is used to establish connections between the local agent node and multiple connected label printers, and to collect the real-time status parameters of each label printer. The unit decomposition module is used to acquire the task to be printed and decompose the task to be printed into multiple sub-task units according to the real-time status parameters. The load assessment module is used to determine whether the execution load of each subtask unit exceeds the local carrying capacity. Subtask units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while subtask units that exceed the local carrying capacity are uploaded to the cloud for execution. The instruction delivery module is used to perform instruction-level fusion of the execution results of the local agent node and the execution results returned by the cloud, generate a printing instruction sequence, and then send it to the corresponding label printer for execution.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The local agent node establishes connections with multiple connected label printers and collects real-time status parameters of each printer. It then acquires the print job and breaks it down into multiple sub-task units based on the real-time status parameters. It determines whether the execution burden of each sub-task unit exceeds the local capacity, assigning sub-task units within the local capacity to the local agent node for execution, and uploading sub-task units exceeding the local capacity to the cloud for execution. Finally, it performs instruction-level fusion of the execution results from the local agent node and the execution results returned from the cloud to generate a print instruction sequence, which is then sent to the corresponding label printer for execution.

[0016] Therefore, this application demonstrates several key advantages. First, by establishing connections with multiple label printers through a local agent node and collecting real-time status parameters, it provides a comprehensive understanding of the dynamic information of each printer, laying a data foundation for subsequent task breakdown and edge-cloud task allocation decisions. Second, by using real-time status parameters to hierarchically break down printing tasks, physically continuous labels are grouped into the same sub-task unit to ensure media continuity, while labels with different media types are separated at switching points to avoid frequent switching of printing parameters. This better matches the actual capabilities and current status of each printer, providing a granular foundation for subsequent edge-cloud task allocation decisions. Third, by breaking down sub-task units into printing primitives and quantifying the execution burden, dynamic comparison and decision-making are performed using the real-time processor and available memory resources of the local agent node. This enables adaptive task allocation, allowing lightweight tasks to be processed quickly locally and heavyweight tasks to be offloaded to the cloud, thereby maximizing the utilization of edge computing resources while ensuring system stability. Finally, by performing redundancy detection and deletion on adjacent instruction fragments in the local execution results and the cloud-returned results, a directly executable printing instruction sequence is generated, reducing the amount of instruction transmission and the printer parsing burden, thereby improving the execution efficiency of printing tasks and system reliability.

[0017] In summary, the technical solution adopted in this application can achieve computational load balancing in scenarios where multiple label printers are connected, thereby improving the processing efficiency of printing tasks and the robustness of the system. Attached Figure Description

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

[0019] Figure 1 This is an exemplary flowchart of an edge-cloud collaborative control method for multi-node access of a label printer provided in this application; Figure 2 This is a schematic diagram of a device scenario for an edge-cloud collaborative control system for multi-node access of a label printer, as provided in this application. Figure 3 This is a module structure diagram of an edge-cloud collaborative control system for multi-node access of a label printer provided in this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0021] This application provides an edge-cloud collaborative control method and system for multi-node access of label printers. The core of this method involves a local agent node establishing connections with multiple connected label printers and collecting real-time status parameters from each printer. A print task is acquired, and based on the real-time status parameters, it is broken down into multiple sub-task units. The execution burden of each sub-task unit is determined to be within the local capacity. Sub-task units within the local capacity are assigned to the local agent node for execution, while those exceeding the local capacity are uploaded to the cloud for execution. The execution results from the local agent node and the cloud are then fused at the instruction level to generate a print instruction sequence, which is then sent to the corresponding label printer for execution.

[0022] Example 1: To better understand the above technical solution, the following will provide a detailed description of the technical solution in conjunction with the accompanying drawings and specific implementation methods. (Refer to...) Figure 1As shown in the figure, this is an exemplary flowchart of an edge-cloud collaborative control method for multi-node access of a label printer according to this embodiment of the present application. The edge-cloud collaborative control method includes the following steps: In step S1, the local agent node establishes connections with the multiple connected label printers and collects the real-time status parameters of each label printer.

[0023] In practice, the local agent node establishes connections with each of the multiple connected label printers and collects real-time status parameters from each printer. Specifically, the local agent node is deployed within the local area network (LAN) where the label printers are located; it can be a standalone hardware device or a software service running on an existing industrial control computer. The local agent node establishes network connections with each label printer connected to the LAN via a Wi-Fi communication interface. During connection establishment, the local agent node sends connection requests to each printer, and upon response, the printer returns its device identifier. The local agent node then records this device identifier in its local device list. The local agent node sends a capability probe command to each label printer. This command contains a request for a bitmap of information types. The information type bitmap is an 8-byte field, with each bit representing a type of device information, including: Bit 0: Media type support bit, used to request the printer to return the types of media it supports; Bit 1: Media width range bit, used to request the printer to return the minimum and maximum media widths it supports; Bit 2: Resolution bit, used to request the printer to return the dots per inch of its printhead; Bit 3: Memory status bit, used to request the printer to return its current available cache size; Bit 4: Queue status bit, used to request the printer to return the number of pending print jobs in its internal command queue; Bit 5: Consumable balance bit, used to request the printer to return the number of remaining label sheets and the remaining ribbon length; Bit 6: Health status bit, used to request the printer to return the printhead wear level, the cumulative running time of the stepper motor, and the temperature sensor reading; Bit 7: Link test bit, used to request the printer to return the communication packet loss rate and average response latency over a recent period. After receiving the capability detection command, each label printer collects the corresponding device information according to the information type bitmap, encapsulates it into a capability response message, and returns it to the local agent node.

[0024] In addition, in specific implementation, the local agent node continuously collects the real-time status parameters of each label printer using the above method. The real-time status parameters include: the current queue length of each printer, i.e., the number of unexecuted print commands in the printer's internal cache; the estimated completion time of each printer, i.e., calculated based on the ratio of the current queue length to the printer's historical average printing speed; the remaining media of each printer, including: the number of remaining label sheets and the remaining ribbon length; the hardware health status of each printer, including: printhead wear level, stepper motor cumulative running time, temperature sensor readings; and the link quality between each printer and the local agent node, including: signal strength, packet loss rate, and round-trip latency.

[0025] In step S2, the task to be printed is obtained, and the task to be printed is broken down into multiple sub-task units according to the real-time status parameters.

[0026] In practice, the task to be printed is obtained by the local agent node through Wi-Fi or USB interface.

[0027] In this embodiment, the task to be printed is broken down into multiple sub-task units according to the real-time status parameters. This can be achieved through the following steps: The file format of the task to be printed is parsed, and the printing data of each label is extracted one by one according to the file format specification. The extracted printing data of each label is constructed into a label sequence according to their original arrangement order in the file. Based on the media width of each label printer in the real-time status parameters, labels in the label sequence whose width exceeds the media width of all available printers are marked as unprintable labels and extracted as an independent subtask unit and uploaded to the cloud for execution. Traverse the tag sequence, detect the physical continuity between adjacent tags, merge consecutive tags with physical continuity into a physical continuous segment, and forcibly disassemble at the position where the physical continuity is interrupted; Within each physical contiguous segment, the printing media type of each label is scanned. Whenever the media type changes, the segment is disassembled at the current switching position, dividing the physical contiguous segment into sub-segments of the same media. Within each segment of the same medium, determine the rendering complexity index of each tag, extract the tags whose rendering complexity index exceeds the preset threshold into an independent subtask unit, and merge the remaining consecutive tags into another subtask unit.

[0028] In practice, the process begins by parsing the file format of the task to be printed. Following the file format specifications, the print data for each label is extracted one by one. The extracted print data for each label is then constructed into a label sequence according to their original arrangement in the file. Specifically, the local agent node first calls the parser corresponding to the file format of the task to be printed, extracting the print data for each label one by one according to the format's specifications. For PDF files: the parser splits the file by page, treating each page as one label's print data. If a page contains multiple labels, the parser further identifies cropping boxes or dividing lines on the page, extracting each label area as independent print data. For image formats such as JPEG: the entire image file is treated as one label's print data. For ZPL files: the parser scans the file content, using "XA" instructions as the label start identifier and "XZ" instructions as the label end identifier, extracting the instruction sequence between each pair of "XA" and "XZ" as one label's print data. The extracted tags are numbered sequentially according to their order in the original file, forming a tag sequence. While constructing the tag sequence, the local agent node calculates a content hash value for each tag. Next, based on the media width of each tag printer in the real-time status parameters, tags in the tag sequence whose width exceeds the media width of all available printers are marked as unprintable tags and extracted as an independent sub-task unit, uploaded to the cloud for execution. Specifically, the media width information of each tag printer is read from the real-time status parameters, and the maximum value is taken as the maximum available media width locally. For each tag in the tag sequence, the local agent node parses its width information: for ZPL format, the parameter value of the "PW" instruction is extracted; for PDF or image formats, the page size or image width field is read, and the pixel width is converted to the actual physical width. Then, the local agent node compares the tag's physical width with the maximum available media width obtained from the real-time status parameters. If the tag width is less than or equal to the maximum available media width, the tag is determined to be printable locally, and the process continues to the next step. If the tag width is greater than the maximum available media width, the tag is determined to be unprintable on the currently connected printer. The local proxy node extracts all tags that exceed the width limit from the tag sequence. Each over-limit tag forms an independent sub-task unit, and its upload priority is determined based on the link quality in the real-time status parameters: if the link quality is good, it is uploaded immediately; if the link quality is poor, it is temporarily stored and waited for. The remaining normal-width tags are then further processed based on other parameters in the real-time status parameters.

[0029] In addition, in the specific implementation, the label sequence is traversed, and the physical continuity between adjacent labels is detected. Labels with physical continuity are merged into a single physical segment, and the sequence is forcibly broken at the point where physical continuity is interrupted. That is, for ZPL format labels, the local agent node extracts the "LL" and "LS" instructions from each label instruction sequence. Let the label length of the i-th label be Li, and the label starting offset be Si. Then, after the i-th label is printed, the length of the paper fed by the printer is (Li + Si). If the sum of the paper feed length of the i-th label and the starting offset S{i+1} of the (i+1)-th label equals the standard media length, i.e., the physical length occupied by a single label on a roll of label paper, then the i-th label and the (i+1)-th label are determined to have physical continuity; otherwise, a gap is determined to exist between them, and the physical continuity is interrupted. For cases where the tag length cannot be directly obtained, such as tags in pure image format, the local proxy node uses an image edge detection algorithm to estimate the physical boundaries of the tags. Specifically, it projects the tag image vertically in grayscale, calculates the cumulative grayscale value of each row of pixels, and identifies the locations of abrupt changes in grayscale values ​​as the upper and lower boundaries of the corresponding tags. The distance between the boundaries of two adjacent tags is the tag length. After traversal, the local proxy node segments the tag sequence based on the physical continuity detection results. Tags with physical continuity are merged into a single physical continuous segment, while locations where physical continuity is interrupted are marked as forced splitting points.

[0030] In addition, in practical implementation, within each physical contiguous segment, the printing media type of each label is scanned. Whenever the media type changes, a split is performed at the current switching position, dividing the physical contiguous segment into sub-segments of the same media type. That is, the printing media types include: thermal paper, thermal transfer paper, and coated paper. For ZPL format labels, the parser extracts the "MT" instruction from the label instruction sequence. The parameter value of this instruction directly indicates the media type, such as: "MTT" for thermal paper, "MTD" for thermal transfer paper, and "MTC" for coated paper. For PDF or image format labels, the parser reads the media type field from the file metadata. If it is not explicitly marked in the metadata, it is inferred from the keywords in the file source path. During the scanning process, the local agent node records the media type of each tag and compares whether the media types of adjacent tags are the same. Whenever the media type changes, a split point is set at the current change position. For example, if the media type sequence of tags in a physical continuous segment is: thermal paper, thermal paper, thermal transfer paper, thermal transfer paper, coated paper, then split points are set between the second and third tags and between the fourth and fifth tags, dividing the physical continuous segment into three sub-segments of the same media. Finally, within each sub-segment of the same media, the rendering complexity index of each tag is determined. Tags with rendering complexity indices exceeding a preset threshold are extracted as independent sub-task units, and the remaining continuous tags are merged into another sub-task unit. That is, the complexity index is equal to the number of vector graphics multiplied by the first weight coefficient, plus the number of bitmap image pixels divided by one hundred and multiplied by the second weight coefficient, plus the number of non-standard font types multiplied by the third weight coefficient, plus the number of text characters divided by one thousand and multiplied by the fourth weight coefficient. The default values ​​for each weight coefficient reflect the actual impact of different factors on rendering resource consumption. Vector graphics consume the most CPU and are given the highest weight; bitmap images consume a lot of memory and are given the second highest weight; font loading involves additional overhead and is given a medium weight; plain text rendering consumes the least and is given the lowest weight. These weight coefficients can be set based on expert experience. The rendering complexity index measures the degree of computational resource consumption of a tag on the local proxy node during rendering. The preset threshold value is dynamically set based on the hardware configuration and task type of the local proxy node. For local proxy nodes with lower configurations, the threshold is set to a smaller value; for nodes with higher configurations, the threshold is set to a larger value, which can be set based on expert experience. During the detection process, the local proxy node traverses each tag within the same media segment. If the complexity index of a tag is greater than the preset threshold, the tag is identified as a high-complexity tag and extracted as an independent subtask unit, not merged with other tags. For low-complexity tags with a complexity index less than or equal to the threshold, they are kept in a continuous arrangement, and several consecutive low-complexity tags are merged into the same subtask unit.

[0031] In step S3, it is determined whether the execution burden of each subtask unit exceeds the local carrying capacity. Subtask units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while subtask units that exceed the local carrying capacity are uploaded to the cloud for execution.

[0032] In this embodiment, determining whether the execution burden of each subtask unit exceeds the local carrying capacity can be achieved through the following steps: Each subtask unit is broken down into a sequence of printing primitives, which include: text rendering operation, vector graphics drawing operation, bitmap decoding operation, and font loading operation; A resource consumption coefficient is pre-defined for each printing primitive to determine the execution burden of each subtask unit; Collect the current available processor resources and current available memory resources of the local agent node to determine the instantaneous value of the local carrying capacity; The execution burden of each subtask unit is compared with the instantaneous value of the local carrying capacity. If the execution burden is less than or equal to the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has not been exceeded; if the execution burden is greater than the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has been exceeded.

[0033] In practical implementation, firstly, each subtask unit can be broken down into a sequence of printing primitives. That is, the local agent node traverses all the label printing data contained in the subtask unit and identifies and extracts the following: text rendering operation, which is the process of font parsing, glyph extraction, and character positioning for each text field in the label. The number of text characters in the subtask unit corresponds to the number of text rendering primitives; vector graphics drawing operation, which is the process of coordinate transformation and rasterization of vector graphics such as lines, rectangles, circles, and polygons in the label. Each independent vector graphic corresponds to a vector graphics drawing primitive; bitmap decoding operation, which is the process of format parsing, decompression, and pixel data restoration of bitmap images embedded in the label. Each bitmap image corresponds to a bitmap decoding primitive. For high-resolution bitmaps, they can be further broken down into multiple bitmap decoding primitives according to fixed-size pixel blocks; font loading operation, which is the process of loading, parsing, and caching non-standard font files used in the label. The first use of each non-standard font corresponds to a font loading primitive. The repeated use of the same font in subsequent labels is not counted as a new primitive. This yields a sequence of printing primitives, including text rendering, vector graphics drawing, bitmap decoding, and font loading operations. Next, a resource consumption coefficient is pre-assigned to each printing primitive to determine the execution burden of each subtask unit. The method for assigning the resource consumption coefficient will be detailed in subsequent steps. Let the printing primitive sequence of subtask unit T contain *a* text rendering primitives, *b* vector graphics drawing primitives, *c* bitmap decoding primitives, and *d* font loading primitives. Let the resource consumption coefficients for each type of primitive be Rt, Rv, Rb, and Rf, respectively. Then, the execution burden BT of subtask unit T is equal to a multiplied by Rt plus b multiplied by Rv plus c multiplied by Rb plus d multiplied by Rf. Here, the execution burden refers to the computational resources required to execute the subtask unit, roughly equivalent to the number of text character rendering operations performed.

[0034] In addition, in the specific implementation, the current available processor resources and current available memory resources of the local agent node are collected to determine the instantaneous value of local capacity. Specifically, the local agent node obtains the current available processor resources through the system call interface provided by the operating system. The processor resource value is represented by the processor idle rate, which is the proportion of time the processor has been idle in the past second, ranging from zero to one. Simultaneously, the current available memory resources are obtained, which is represented by the ratio of the current available physical memory size to the total physical memory size, also ranging from zero to one. The instantaneous value of local capacity, Cl, is obtained by weighted fusion of the available processor resources and available memory resources. Cl equals the processor weight multiplied by the processor idle rate plus the memory weight multiplied by the memory idle rate. The weighting coefficients, processor weight and memory weight, are not fixed but are self-learned and adjusted based on the historical task execution records of the local agent node. Specifically, the local agent node records the dimensions that actually become resource bottlenecks during the execution of the past 100 sub-task units. If the frequency of processor bottlenecks is higher than that of memory bottlenecks in a recent period, the processor weight is gradually increased and the memory weight is correspondingly decreased. Conversely, if memory bottlenecks occur more frequently, the processor weight is reduced and the memory weight is increased. Specific values ​​can be determined through experimental data statistics. Finally, the execution burden of each subtask unit is compared with the instantaneous value of the local carrying capacity. If the execution burden is less than or equal to the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity is not exceeded, and the subtask unit is assigned to the local proxy node for execution. If the execution burden is greater than the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity is exceeded, and the subtask unit is uploaded to the cloud for execution. That is, before comparing the execution burden value with the instantaneous value of the local carrying capacity, the local proxy node first multiplies the execution burden value by a safety redundancy coefficient. The safety redundancy coefficient is a value greater than 1, and its function is to add a safety margin to the execution burden value, making the decision more conservative. For example, when the safety redundancy coefficient is 1.2, the actual execution burden value used for comparison is 20% higher than the original estimated value. This means that the local proxy node will only choose local execution if the local carrying capacity is more than 20% higher than the estimated consumption; otherwise, it will upload to the cloud. The initial value of the safety redundancy coefficient is set to 1.2, which means a 20% safety margin is reserved. The initial value of the safety redundancy coefficient is derived from statistical experience of a large number of label printing tasks and can cover the estimated fluctuation range in most scenarios. However, a fixed safety redundancy coefficient cannot adapt to changes in different hardware environments and different task types. Therefore, this solution further introduces an adaptive adjustment mechanism for the safety redundancy coefficient. That is, whenever a sub-task unit determined to be executed locally is completed, the local agent node records the estimated execution burden before the execution of the sub-task unit and the resource consumption value measured during the actual execution of the sub-task unit.The measurement method for actual resource consumption is consistent with that used in benchmark tests. Specifically, the number of processor cycles and memory bytes used during execution are obtained through operating system performance counters and converted into actual consumption values ​​in units of equivalent text character rendering using the same normalization method as the execution burden estimate. The local agent node calculates the ratio of the actual consumption value to the execution burden estimate. This ratio serves as the deviation rate for this execution. A deviation rate greater than 1 indicates that the actual consumption is higher than the estimate, and the prediction is overly optimistic. A deviation rate less than 1 indicates that the actual consumption is lower than the estimate, and the prediction is overly conservative. A deviation rate equal to 1 indicates that the prediction is completely accurate. The local agent node maintains a historical deviation rate queue of a preset length, set by expert experience. Each time a new deviation rate is obtained, it is added to the queue, and the oldest deviation rate is removed. The moving average of all deviation rates in the queue is then calculated; this moving average is the updated safety redundancy coefficient.

[0035] In the specific implementation, after the above decision-making process, each subtask unit is assigned an execution method label, namely, local execution or cloud upload. Subtask units marked for local execution are sent to the local execution queue, which is a first-in-first-out priority queue, and the subtask units in the queue are arranged according to their original printing order. The rendering engine of the local proxy node retrieves the subtask units from the queue in sequence, calls the locally deployed simplified graphics library for rasterization rendering, and generates the corresponding printing instruction fragments. Subtask units marked for cloud upload are sent to the upload queue. The local proxy node encapsulates the task description file of the subtask unit into a cloud request message and sends it to the cloud node over the network. The content of the task description file depends on the original format of the subtask unit: for instruction-type labels, the task description file contains a complete ZPL or EPL instruction sequence; for image-type labels, the task description file contains compressed bitmap data. After receiving the request, the cloud node calls its deployed full-version graphics library for rasterization rendering, and compresses and encodes the generated printing instruction fragments before returning them to the local proxy node.

[0036] In this embodiment, the step of pre-calibrating a resource consumption coefficient for each printing primitive can be achieved through the following steps: The local agent node performs benchmark tests upon initial startup, running a single text rendering operation, a single vector graphics drawing operation, a single bitmap decoding operation, and a single font loading operation, measuring the number of processor cycles and memory bytes used for each operation; The measurement results are scaled according to a preset normalization benchmark to obtain the resource consumption coefficient of each printing primitive.

[0037] In practical implementation, firstly, the local agent node executes benchmark tests upon initial startup. This involves running a single text rendering operation, a single vector graphics drawing operation, a single bitmap decoding operation, and a single font loading operation, measuring the processor cycles and memory bytes consumed for each operation. In other words, the resource consumption coefficient is calibrated through benchmark testing. Benchmark testing is automatically triggered upon the first startup of the local agent node, which refers to the moment the local agent node software is installed and run for the first time. The local agent node first constructs a set of standardized test cases. For the text rendering primitive test case, the local agent node constructs a simple label containing one hundred standard ASCII characters, using the most common monospaced font, with a font size of twelve points. The character content is a cyclical repetition of "A" to "Z" up to one hundred characters. For the vector graphics drawing primitive test case, the local agent node constructs a label containing a complex polygon, defined by fifty randomly generated vertex coordinates. The vertex coordinates are evenly distributed within the label's width and height range. The polygon is filled with a solid fill, and the border line width is set to one pixel. For the bitmap decoding primitive test case, the local agent node constructs a JPEG image with a resolution of 300 x 300 pixels, containing a black and white checkerboard pattern, with a compression quality factor set to 75%. For the font loading primitive test case, the local agent node prepares a TrueType format Chinese font file, approximately 5 megabytes in size, containing about 7,000 commonly used Chinese glyphs. The font file is pre-stored in a fixed directory on the local agent node and loaded directly during benchmark testing. Then, the local agent node executes the above four test cases sequentially. Before executing each test case, it ensures the system is in an idle state. Before the measurement begins, the local agent node calls the performance counter interface provided by the operating system to record the initial values ​​of the current processor cycle counter and memory allocation counter. The local agent node then executes the print primitive operation in the test case. After execution, it reads the performance counter values ​​again, calculates the difference before and after execution, and obtains the number of processor cycles and memory bytes consumed in this execution. The processor cycle count is measured by reading the processor's timestamp counter, which records the number of clock cycles elapsed since the processor was powered on. The difference between the two reads is the number of processor cycles consumed during execution. The number of bytes of memory is measured by monitoring the increments of memory allocation and deallocation, recording the total amount of dynamically allocated memory minus the total amount of memory deallocated during execution. To ensure the stability of the measurement results, each test case is executed ten times, with a one-second interval between each execution to allow the system to return to an idle state. After ten executions, the local agent node removes the maximum and minimum values ​​from the ten measurements and takes the median of the remaining eight measurements as the original measurement result for this type of print primitive.

[0038] In addition, in the specific implementation, the measurement results are scaled according to a preset normalization benchmark to obtain the resource consumption coefficient of each printing primitive. That is, after completing the measurement of four test cases, the local agent node obtains four sets of raw measurement values, each containing two dimensions: processor cycles and memory bytes. These are then normalized. Specifically, the processor cycle measurement value for the text rendering primitive is recorded as "text processor cycles," and the memory byte measurement value is recorded as "text memory bytes." The resource consumption coefficient of the text rendering primitive is fixed at 1, i.e., based on itself. For vector graphics drawing primitives, the processor cycle measurement value is recorded as "graphics processor cycles," and the memory byte measurement value is recorded as "graphics memory bytes." The relative ratio of processor cycles is calculated, i.e., graphics processor cycles divided by text processor cycles. Then, the relative ratio of memory bytes is calculated, i.e., graphics memory bytes divided by text memory bytes. Adding these two relative ratios and dividing by two yields the resource consumption coefficient of the vector graphics drawing primitive. For the bitmap decoding primitive, the measured number of processor cycles is denoted as bitmap processor cycles, and the measured number of memory bytes is denoted as bitmap memory bytes. The relative ratio of processor cycles is bitmap processor cycles divided by text processor cycles, and the relative ratio of memory bytes is bitmap memory bytes divided by text memory bytes. Adding these two values ​​and dividing by two yields the resource consumption coefficient of the bitmap decoding primitive. For the font loading primitive, the measured number of processor cycles is denoted as font processor cycles, and the measured number of memory bytes is denoted as font memory bytes. The relative ratio of processor cycles is font processor cycles divided by text processor cycles, and the relative ratio of memory bytes is font memory bytes divided by text memory bytes. Adding these two values ​​and dividing by two yields the resource consumption coefficient of the font loading primitive.

[0039] In step S4, the execution results of the local agent node and the execution results returned by the cloud are fused at the instruction level to generate a printing instruction sequence, which is then sent to the corresponding label printer for execution.

[0040] In this embodiment, the execution results of the local proxy node and the execution results returned by the cloud are fused at the instruction level to generate a print instruction sequence. This can be achieved through the following steps: The execution results of the local agent node and the execution results returned by the cloud are sorted according to the order of their corresponding subtask units in the task to be printed, resulting in an ordered sequence of instruction fragments. Traverse the ordered instruction fragment sequence and detect redundant instructions between two adjacent instruction fragments. The redundant instructions include: repeated printer status setting instructions, repeated font loading instructions, and repeated coordinate system definition instructions. When redundant instructions are detected, the redundant instructions in the subsequent instruction segment are deleted, and a status preservation indicator is inserted between the previous instruction segment and the subsequent instruction segment. All instruction fragments, after redundancy removal and status preservation indicator insertion, are sequentially concatenated to generate a print instruction sequence, which is then sent to the corresponding label printer for execution.

[0041] In the specific implementation, firstly, all print instruction fragments corresponding to the execution results of the local agent node and the execution results returned by the cloud are sorted according to the order of their corresponding sub-task units in the task to be printed, resulting in an ordered instruction fragment sequence. That is, after receiving the data returned by the cloud, the local agent node first calls the corresponding decoding algorithm to decode and restore the data according to the compression method identifier marked by the cloud in the response message, obtaining the original print instruction fragments. Each print instruction fragment corresponding to the execution results of the local agent node and the execution results returned by the cloud is assigned a label when it is generated, recording the arrangement number of the sub-task unit corresponding to the instruction fragment in the original task to be printed. The local agent node sorts all instruction fragments according to their appearance order in the original task based on this arrangement number, resulting in an ordered instruction fragment sequence. Secondly, the ordered instruction fragment sequence is traversed to detect redundant instructions between two adjacent instruction fragments. The redundant instructions include: repeated printer status setting instructions, repeated font loading instructions, and repeated coordinate system definition instructions. Redundant instructions are detected through string matching. The local agent node extracts several instructions from the end of the previous instruction segment to form a detection window. The length of the detection window can be dynamically adjusted according to the actual length of the instruction segment and can be set by expert experience. Then, it extracts several instructions from the beginning of the next instruction segment to form a matching window of the same length. The local agent node compares the instructions in the two windows to see if they are completely identical, including the opcode and operands. If they are completely identical, the instructions in the matching window are determined to be redundant. If they are not completely identical, the window length is shortened and the comparison continues until the longest matching prefix is ​​found. Then, when a redundant instruction is detected, the redundant instruction in the next instruction segment is deleted, and a status preservation indicator is inserted between the previous and next instruction segments. That is, after detecting a redundant instruction, the local agent node performs a redundancy deletion operation on the next instruction segment, that is, it removes those instructions that are determined to be redundant from the next instruction segment. After deletion, only the non-redundant instruction parts are retained in the next instruction segment. While deleting redundant instructions, the local agent node inserts a state retention indicator between the preceding and following instruction segments. This state retention indicator is a special no-operation instruction that does not change any printer state or trigger any printing action; its sole purpose is to mark the state continuity between the two instruction segments. When the printer executes the state retention indicator, it interprets it as meaning it should retain all state settings from the end of the preceding instruction segment, without requiring reconfiguration.Furthermore, during the process of deleting redundant instructions, there may be instances where a subsequent instruction fragment contains setting instructions that are repeated from the previous one. However, subsequent instructions in the subsequent instruction fragment may depend on the intermediate states defined by these setting instructions. Simply deleting these redundant instructions could result in subsequent instructions in the subsequent instruction fragment lacking necessary state prerequisites. Therefore, the local agent node scans all execution-type instructions in the subsequent instruction fragment, excluding setting-type instructions, extracts the state parameter names that these execution-type instructions depend on, and then checks the set of state parameter names modified by the instructions in the subsequent instruction fragment that are determined to be redundant. If the two sets intersect, meaning that the execution-type instructions in the subsequent instruction fragment depend on a state parameter modified by a redundant instruction, a state dependency conflict is determined. When a state dependency conflict is detected, the local agent node abandons the deletion of the conflicting redundant instructions and retains them in the subsequent instruction fragment. For redundant instructions that do not conflict, the deletion operation is still performed.

[0042] In the specific implementation, all instruction fragments after redundancy removal and state preservation indicator insertion are sequentially concatenated to generate a print instruction sequence. Specifically, the local agent node concatenates all processed instruction fragments according to their order in the ordered instruction fragment sequence. The concatenation operation directly connects the end of the previous instruction fragment to the beginning of the next, with the inserted state preservation indicator serving as a separator between the two fragments, thus generating the print instruction sequence. The print instruction sequence includes: state control instructions, layout positioning instructions, content rendering instructions, and execution trigger instructions.

[0043] In practice, the instructions are sent to the corresponding label printer for execution. That is, the local agent node extracts the identification information of the target printer from the merged print instruction sequence. If all instruction fragments before merging are assigned to the same printer, then that printer is the target, and the printing task is completed through the target printer.

[0044] like Figure 2The diagram illustrates a scenario of a multi-node edge-cloud collaborative control system for label printers, as provided in this solution. The system includes a local agent node, a cloud node, and label printers. The local agent node connects to both the cloud node and each label printer. It establishes connections with the connected label printers and collects their real-time status parameters. The local agent node also acquires the print task, breaks it down into multiple sub-task units based on the real-time status parameters, determines whether the execution burden of each sub-task unit exceeds its local capacity, assigns sub-task units that do not exceed the capacity to the local agent node, and uploads the excess sub-task units to the cloud node for execution. Furthermore, the local agent node performs instruction-level fusion of the local execution results and the execution results returned by the cloud node to generate a print instruction sequence, which is then sent to the corresponding label printer for execution. The cloud node receives the sub-task units uploaded by the local agent node, performs remote rendering, and returns the results to the local agent node. The label printer receives and executes the print instruction sequence sent by the local agent node.

[0045] Therefore, this application demonstrates several key advantages. First, by establishing connections with multiple label printers through a local agent node and collecting real-time status parameters, it provides a comprehensive understanding of the dynamic information of each printer, laying a data foundation for subsequent task breakdown and edge-cloud task allocation decisions. Second, by using real-time status parameters to hierarchically break down printing tasks, physically continuous labels are grouped into the same sub-task unit to ensure media continuity, while labels with different media types are separated at switching points to avoid frequent switching of printing parameters. This better matches the actual capabilities and current status of each printer, providing a granular foundation for subsequent edge-cloud task allocation decisions. Third, by breaking down sub-task units into printing primitives and quantifying the execution burden, dynamic comparison and decision-making are performed using the real-time processor and available memory resources of the local agent node. This enables adaptive task allocation, allowing lightweight tasks to be processed quickly locally and heavyweight tasks to be offloaded to the cloud, thereby maximizing the utilization of edge computing resources while ensuring system stability. Finally, by performing redundancy detection and deletion on adjacent instruction fragments in the local execution results and the cloud-returned results, a directly executable printing instruction sequence is generated, reducing the amount of instruction transmission and the printer parsing burden, thereby improving the execution efficiency of printing tasks and system reliability.

[0046] In summary, the technical solution adopted in this application can achieve computational load balancing in scenarios where multiple label printers are connected, thereby improving the processing efficiency of printing tasks and the robustness of the system.

[0047] Example 2: This application provides an edge-cloud collaborative control system for multi-node access of label printers, referencing... Figure 3 As shown in the figure, this is a module structure diagram of the edge-cloud collaborative control system for multi-node access of a label printer according to this embodiment of the present application. The edge-cloud collaborative control system includes: The parameter acquisition module 100 is used to establish connections between the local agent node and multiple connected label printers, and to acquire the real-time status parameters of each label printer. The unit decomposition module 200 is used to acquire the task to be printed and decompose the task to be printed into multiple sub-task units according to the real-time status parameters. The load judgment module 300 is used to determine whether the execution load of each sub-task unit exceeds the local carrying capacity. Sub-task units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while sub-task units that exceed the local carrying capacity are uploaded to the cloud for execution. The instruction issuing module 400 is used to perform instruction-level fusion of the execution results of the local agent node and the execution results returned by the cloud, generate a printing instruction sequence, and then issue it to the corresponding label printer for execution.

[0048] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0049] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, including read-only memory (ROM), random access memory (RAM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), one-time programmable read-only memory (OTPROM), electrically-Erasable Programmable Read-Only Memory (EEPROM), compactdisc read-only memory (CD-ROM) or other optical disc storage, disk storage, magnetic tape storage, or any other computer-readable medium capable of carrying or storing data.

[0050] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

Claims

1. A method for edge-cloud collaborative control of multi-node access in a label printer, characterized in that, The edge-cloud collaborative control method includes the following steps: The local agent node establishes connections with multiple connected label printers and collects real-time status parameters of each label printer. Obtain the task to be printed, and break it down into multiple sub-task units according to the real-time status parameters; Determine whether the execution burden of each subtask unit exceeds the local carrying capacity. Subtask units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while subtask units that exceed the local carrying capacity are uploaded to the cloud for execution. The execution results from the local agent node and the execution results returned from the cloud are fused at the instruction level to generate a printing instruction sequence, which is then sent to the corresponding label printer for execution.

2. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, The real-time status parameters include: the current queue length of each label printer, the estimated completion time of each label printer, the remaining media of each label printer, the hardware health status of each label printer, and the link quality between each label printer and the local agent node.

3. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, Specifically, breaking down the print task into multiple sub-task units based on the real-time status parameters includes: The file format of the task to be printed is parsed, and the printing data of each label is extracted one by one according to the file format specification. The extracted printing data of each label is constructed into a label sequence according to their original arrangement order in the file. Based on the media width of each label printer in the real-time status parameters, labels in the label sequence whose width exceeds the media width of all available printers are marked as unprintable labels and extracted as an independent subtask unit and uploaded to the cloud for execution. Traverse the tag sequence, detect the physical continuity between adjacent tags, merge consecutive tags with physical continuity into a physical continuous segment, and forcibly disassemble at the position where the physical continuity is interrupted; Within each physical contiguous segment, the printing media type of each label is scanned. Whenever the media type changes, the segment is disassembled at the current switching position, dividing the physical contiguous segment into sub-segments of the same media. Within each segment of the same medium, determine the rendering complexity index of each tag, extract the tags whose rendering complexity index exceeds the preset threshold into an independent subtask unit, and merge the remaining consecutive tags into another subtask unit.

4. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 3, characterized in that, The printing media types include: thermal paper, thermal transfer paper, and coated paper.

5. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, Determining whether the execution burden of each subtask unit exceeds the local carrying capacity specifically includes: Each subtask unit is broken down into a sequence of printing primitives, which include: text rendering operation, vector graphics drawing operation, bitmap decoding operation, and font loading operation; A resource consumption coefficient is pre-defined for each printing primitive to determine the execution burden of each subtask unit; Collect the current available processor resources and current available memory resources of the local agent node to determine the instantaneous value of the local carrying capacity; The execution burden of each subtask unit is compared with the instantaneous value of the local carrying capacity. If the execution burden is less than or equal to the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has not been exceeded; if the execution burden is greater than the instantaneous value of the local carrying capacity, it is determined that the local carrying capacity has been exceeded.

6. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 5, characterized in that, The specific steps of pre-calibrating a resource consumption coefficient for each printing primitive include: The local agent node performs benchmark tests upon initial startup, running a single text rendering operation, a single vector graphics drawing operation, a single bitmap decoding operation, and a single font loading operation, measuring the number of processor cycles and memory bytes used for each operation; The measurement results are scaled according to a preset normalization benchmark to obtain the resource consumption coefficient of each printing primitive.

7. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, The execution result of the local proxy node refers to the print instruction fragment generated by the local proxy node after performing local rendering on sub-task units that have not exceeded the carrying capacity; the execution result returned by the cloud refers to the compressed and encoded print instruction fragment generated by the cloud after performing remote rendering on sub-task units that have exceeded the carrying capacity.

8. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, The execution results from the local proxy node are fused with the execution results returned from the cloud at the instruction level to generate a print instruction sequence, specifically including: The execution results of the local agent node and the execution results returned by the cloud are sorted according to the order of their corresponding subtask units in the task to be printed, resulting in an ordered sequence of instruction fragments. Traverse the ordered instruction fragment sequence and detect redundant instructions between two adjacent instruction fragments. The redundant instructions include: repeated printer status setting instructions, repeated font loading instructions, and repeated coordinate system definition instructions. When redundant instructions are detected, the redundant instructions in the subsequent instruction segment are deleted, and a status maintenance indicator is inserted between the previous instruction segment and the subsequent instruction segment. All instruction fragments, after redundancy removal and status preservation indicator insertion, are concatenated sequentially to generate a print instruction sequence.

9. The edge-cloud collaborative control method for multi-node access of a label printer as described in claim 1, characterized in that, The printing instruction sequence includes: status control instructions, layout positioning instructions, content rendering instructions, and execution trigger instructions.

10. A multi-node access edge-cloud collaborative control system for label printers, used to execute the edge-cloud collaborative control method for multi-node access of label printers as described in any one of claims 1 to 9, characterized in that, The edge-cloud collaborative control system includes: The parameter acquisition module is used to establish connections between the local agent node and multiple connected label printers, and to collect the real-time status parameters of each label printer. The unit decomposition module is used to acquire the task to be printed and decompose the task to be printed into multiple sub-task units according to the real-time status parameters. The load assessment module is used to determine whether the execution load of each subtask unit exceeds the local carrying capacity. Subtask units that do not exceed the local carrying capacity are handed over to the local proxy node for execution, while subtask units that exceed the local carrying capacity are uploaded to the cloud for execution. The instruction delivery module is used to perform instruction-level fusion of the execution results of the local agent node and the execution results returned by the cloud, generate a printing instruction sequence, and then send it to the corresponding label printer for execution.

Images